رفع خطای ‘Cannot Generate SSPI Context’ در SQL Server: راهنمای جامع عیبیابی
خطای ‘Cannot generate SSPI context’ یکی از رایجترین و گیجکنندهترین مشکلات احراز هویت در محیطهای SQL Server است که اغلب به دلیل پیکربندی نادرست کربروس (Kerberos) یا نامهای اصلی سرویس (SPN) رخ میدهد. این خطا مانع از اتصال کلاینتها به SQL Server میشود و میتواند بهرهوری سیستم را مختل کند. درک کامل مکانیزم SSPI و کربروس برای حل این مشکل حیاتی است. این راهنما به شما کمک میکند تا ریشه این خطا را شناسایی کرده و آن را به طور موثر رفع کنید.
درک مکانیزم SSPI و احراز هویت کربروس
رابط برنامهنویسی سرویس امنیتی (SSPI) مجموعهای از APIها در ویندوز است که برای انجام عملیات امنیتی مانند احراز هویت استفاده میشود. وقتی کلاینتی به SQL Server متصل میشود، SSPI سعی میکند با استفاده از پروتکلهای امنیتی مختلفی مانند NTLM یا کربروس، احراز هویت را انجام دهد. خطای ‘Cannot generate SSPI context’ به این معنی است که SSPI قادر به تکمیل فرآیند احراز هویت، معمولاً به دلیل عدم توانایی در یافتن یا استفاده از اطلاعات کربروس معتبر، نیست.
کربروس یک پروتکل احراز هویت قویتر و ایمنتر از NTLM است که برای محیطهای دامین (Active Directory) طراحی شده است. برای اینکه احراز هویت کربروس به درستی کار کند، باید SPN (Service Principal Name) مناسب برای سرویس SQL Server ثبت شده باشد. SPN اساساً یک شناسه منحصر به فرد برای یک سرویس در یک دامین کربروس است.
نقش نامهای اصلی سرویس (SPN) در احراز هویت کربروس
SPN یک شناسه است که در Active Directory ثبت میشود و به کلاینتها اجازه میدهد تا نمونه (instance) SQL Server را در شبکه شناسایی کنند. هنگامی که یک کلاینت سعی میکند به SQL Server متصل شود، آن SPN را درخواست میکند تا بتواند بلیت کربروس را برای سرویس SQL Server دریافت کند. اگر SPN وجود نداشته باشد، نادرست باشد، یا برای حساب کاربری اشتباهی ثبت شده باشد، کربروس شکست میخورد و SSPI به NTLM برگشت میکند (در صورت فعال بودن) یا خطای SSPI context را صادر میکند.
بررسی SPNهای موجود برای SQL Server
اولین گام در عیبیابی خطای SSPI context، بررسی SPNهای ثبت شده برای SQL Server است. میتوانید از ابزار `setspn` در Command Prompt یا PowerShell برای مشاهده SPNها استفاده کنید.
برای مشاهده SPNهای ثبت شده برای یک حساب کاربری خاص:
setspn -L <DomainName>\<SQLServiceAccount>
به عنوان مثال، اگر سرویس SQL Server شما با حساب `SQLService` در دامین `mydomain.com` اجرا میشود:
setspn -L mydomain\SQLService
برای مشاهده تمام SPNهای ثبت شده برای نام سرور SQL شما:
setspn -L <SQLServerNetBIOSName>
و همچنین برای FQDN سرور (Full Qualified Domain Name):
setspn -L <SQLServerFQDN>
SPNهای مورد نیاز برای SQL Server به دو فرمت اصلی هستند:
* برای نمونه پیشفرض (Default Instance): `MSSQLSvc/<FQDN>:1433` و `MSSQLSvc/<NetBIOSName>:1433`
* برای نمونه نامگذاری شده (Named Instance): `MSSQLSvc/<FQDN>:<PortNumber>` و `MSSQLSvc/<NetBIOSName>:<PortNumber>` (اگر پورت استاتیک باشد) یا `MSSQLSvc/<FQDN>:<NamedInstance>` و `MSSQLSvc/<NetBIOSName>:<NamedInstance>` (اگر پورت پویا باشد)
توجه داشته باشید که SQL Server به طور خودکار SPNهای مورد نیاز خود را در زمان راهاندازی ثبت میکند، اما این تنها در صورتی امکانپذیر است که سرویس با حساب `Local System` یا `Network Service` (در SQL Server 2008 به بعد) اجرا شود، یا حساب سرویس دارای مجوزهای لازم برای ثبت SPN در Active Directory باشد.
ثبت SPNهای SQL Server به صورت دستی
اگر SPNهای مورد نیاز وجود نداشتند یا نادرست بودند، باید آنها را به صورت دستی ثبت کنید. این کار نیاز به دسترسی مدیریتی به Active Directory دارد.
برای حذف SPNهای اشتباه یا تکراری:
setspn -D MSSQLSvc/<FQDN>:<PortNumberOrInstanceName> <AccountName>
برای افزودن SPN صحیح:
setspn -A MSSQLSvc/<FQDN>:<PortNumberOrInstanceName> <AccountName>
مثال:
اگر SQL Server روی `SQLServer01.mydomain.com` با پورت `1433` و با حساب سرویس `mydomain\SQLService` اجرا میشود:
setspn -A MSSQLSvc/SQLServer01.mydomain.com:1433 mydomain\SQLService
setspn -A MSSQLSvc/SQLServer01:1433 mydomain\SQLService
پس از ثبت SPN، ممکن است نیاز باشد سرویس SQL Server را ریستارت کنید و یا DNS کش کلاینت را پاک کنید.
بررسی پورت SQL Server
اگر از یک نمونه نامگذاری شده (Named Instance) استفاده میکنید که از پورت پویا استفاده میکند، کربروس میتواند با مشکل مواجه شود زیرا پورت ممکن است تغییر کند. برای اطمینان از عملکرد صحیح کربروس، توصیه میشود برای نمونههای نامگذاری شده نیز از پورت استاتیک استفاده کنید. میتوانید پورت را در SQL Server Configuration Manager تنظیم کنید.
مشکلات احراز هویت دو مرحلهای (Double Hop) و Kerberos Delegation
خطای SSPI context ممکن است در سناریوهای “double hop” نیز رخ دهد، جایی که یک سرویس (مانند IIS) به عنوان واسطه بین کلاینت و SQL Server عمل میکند و نیاز به نمایندگی (delegation) اعتبار احراز هویت دارد. در این موارد، `Kerberos delegation` باید به درستی پیکربندی شود.
برای پیکربندی `Kerberos delegation`، حساب سرویس واسطه (مثلاً حساب سرویس IIS) باید در Active Directory برای `delegation` به سرویس SQL Server قابل اعتماد باشد. این پیکربندی در Active Directory Users and Computers (ADUC) انجام میشود:
1. حساب سرویس واسطه را پیدا کنید.
2. به تب “Delegation” بروید.
3. گزینه “Trust this user for delegation to specified services only” را انتخاب کنید.
4. سپس “Use any authentication protocol” را انتخاب کرده و سرویس SQL Server را به لیست اضافه کنید.
عوامل رایج دیگر و راهحلها
* **اختلاف ساعت (Time Skew)**: کربروس به شدت به همگامسازی ساعت بین کلاینت، سرور و کنترلکننده دامین حساس است. اگر اختلاف ساعت بین این ماشینها بیش از 5 دقیقه باشد، احراز هویت کربروس شکست میخورد. از NTP برای همگامسازی ساعت استفاده کنید.
* **مشکلات DNS**: اگر DNS به درستی FQDN سرور SQL را به IP صحیح ترجمه نکند، SPN ممکن است کار نکند. از دستور `nslookup` یا `ping` برای بررسی صحت تفکیک DNS استفاده کنید.
* **فایروال**: پورتهای مورد نیاز SQL Server (معمولاً TCP 1433 و پورتهای نمونه نامگذاری شده) و همچنین پورتهای کربروس (TCP/UDP 88) باید در فایروال باز باشند.
* **SPNهای تکراری**: وجود چندین SPN یکسان برای حسابهای مختلف در Active Directory باعث سردرگمی کربروس و شکست احراز هویت میشود. همیشه از ابزار `setspn -X` برای یافتن SPNهای تکراری استفاده کنید.
برای یافتن SPNهای تکراری:
setspn -X
اگر SPN تکراری یافت شد، باید SPNهای نادرست را با استفاده از `setspn -D` حذف کنید.
* **مدیر پیکربندی SQL Server**: اطمینان حاصل کنید که پروتکلهای TCP/IP در SQL Server Configuration Manager فعال هستند. همچنین، برای نمونههای نامگذاری شده، سرویس SQL Server Browser باید در حال اجرا باشد.
* **بررسی لاگهای رویداد (Event Logs)**: لاگهای رویداد سیستم و امنیت در ویندوز سرور SQL و کلاینت میتوانند اطلاعات ارزشمندی در مورد دلیل شکست احراز هویت ارائه دهند. به دنبال رویدادهای مربوط به کربروس، SSPI یا خطاها با Event IDهای مرتبط باشید.
نتیجهگیری
عیبیابی خطای ‘Cannot generate SSPI context’ در SQL Server اغلب حول محور پیکربندی صحیح SPNها و احراز هویت کربروس میچرخد. با دنبال کردن این مراحل، میتوانید به طور سیستماتیک ریشه مشکل را شناسایی و حل کنید. همیشه اطمینان حاصل کنید که SPNها به درستی برای حساب سرویس SQL Server ثبت شدهاند، هیچ SPN تکراری وجود ندارد و تمامی تنظیمات شبکه و دامین برای پشتیبانی از کربروس بهینه هستند.
