یکی از خطاهای رایج در محیط‌های Domain و مخصوصاً در SQL Server، خطای زیر است:

Cannot generate SSPI context
The target principal name is incorrect

این خطا معمولاً نشان‌دهنده مشکل در احراز هویت Kerberos و تنظیمات SPN (Service Principal Name) است.

🧠 SSPI Context چیست؟

در Windows Authentication، ارتباط بین کلاینت و SQL Server از طریق Kerberos انجام می‌شود:

1. کلاینت به Domain Controller درخواست Ticket می‌دهد
2. DC بر اساس SPN بررسی می‌کند
3. اگر SPN صحیح باشد، Ticket صادر می‌شود
4. SQL Server احراز هویت را قبول می‌کند

👉 اگر SPN مشکل داشته باشد، فرآیند شکست می‌خورد و خطای SSPI Context ظاهر می‌شود.

🚨 علت اصلی مشکل (سناریوی رایج)

در بسیاری از سازمان‌ها:

• SQL Server با Domain Account اجرا می‌شود (مثلاً: DOMAIN\sqlsvc)
• اما SPN به اشتباه روی Computer Account ثبت شده است

این اختلاف باعث می‌شود Kerberos نتواند سرویس را شناسایی کند.

🧨 مثال اشتباه

❌ SPN روی Computer Account:

• SQLSERVER01 (Computer Object)

❌ در حالی که سرویس روی:

• DOMAIN\sqlsvc

 

 🛠️ روش کامل رفع مشکل (دو بخش)

🟢 بخش اول: رفع مشکل از طریق Active Directory (روش گرافیکی)

این روش در محیط‌های Enterprise بسیار مهم و رایج است.

📌 مرحله 1: ورود به Active Directory

روی Domain Controller ابزار زیر را اجرا کنید:

Active Directory Users and Computers (ADUC)

📌 مرحله 2: فعال کردن نمایش پیشرفته

از منوی بالا:

View → Advanced Features

✔ این گزینه را فعال کنید

📌 مرحله 3: پیدا کردن سرور SQL

در لیست سرورها:

• Computer Object مربوط به SQL Server را پیدا کنید

روی آن راست کلیک کنید و وارد:

Properties

📌 مرحله 4: رفتن به Attribute Editor

در پنجره Properties:

✔ تب Attribute Editor را باز کنید

📌 مرحله 5: پیدا کردن SPN

در لیست Attribute ها، مقدار زیر را پیدا کنید:

servicePrincipalName

📌 مرحله 6: حذف SPN اشتباه

اگر مواردی مشابه زیر دیدید:

MSSQLSvc/ServerName:1433

MSSQLSvc/ServerName.domain.local:1433

👉 اگر سرویس روی Domain Account اجرا می‌شود، این SPNها نباید روی Computer Object باشند

✔ آنها را انتخاب کرده و حذف کنید

⏳ مرحله 7: صبر برای Replication

چند دقیقه صبر کنید تا تغییرات بین Domain Controllerها اعمال شود.

🔄 مرحله 8: پاک کردن Cache در کلاینت

روی کلاینت اجرا کنید:

 klist purge

🟢 بخش دوم: ثبت صحیح SPN روی Service Account

بعد از حذف SPN اشتباه، باید SPN را درست ثبت کنید:

setspn -A MSSQLSvc/ServerName:1433 DOMAIN\sqlsvc
setspn -A MSSQLSvc/ServerName.domain.local:1433 DOMAIN\sqlsvc

🚨 بررسی مشکلات دیگر (خیلی مهم)

🔴 Duplicate SPN

اگر SPN در دو جا ثبت شده باشد:

Computer Account

Service Account

❌ Kerberos کاملاً Fail می‌شود

بررسی:

setspn -X

🌐 مشکل DNS

اگر نام سرور درست resolve نشود:

nslookup servername
ping servername

📡 استفاده از IP (اشتباه رایج)

❌ اشتباه:

10.10.10.5

✔ درست: 

SQLSERVER01.domain.local

⏱️ مشکل Time Sync

اگر اختلاف زمان بین Client و Server زیاد باشد:

w32tm /query /status

🔀 مشکل Alias

اگر از SQL Alias استفاده می‌کنید:

👉 باید SPN برای alias هم تعریف شود

🧪 تست نهایی

روی کلاینت:

klist

اگر MSSQLSvc را دیدید یعنی OK ✔

در SQL Server:

SELECT auth_scheme
FROM sys.dm_exec_connections WHERE session_id = @@SPID

✔ باید خروجی:

KERBEROS

🏢 نکات حرفه‌ای (Production Best Practices)

✔ SQL Server همیشه با Domain Service Account اجرا شود
✔ SPN فقط روی Service Account باشد
✔ اتصال با IP ممنوع شود
✔ DNS همیشه سالم باشد
✔ Time Sync با Domain Controller ضروری است
✔ تغییر Service Account = بررسی SPN

🎯 جمع‌بندی

این خطا معمولاً به یکی از موارد زیر مربوط است:

• SPN اشتباه در Active Directory
• Duplicate SPN
• DNS مشکل
• Time mismatch
• استفاده از IP یا Alias
• تغییر Service Account

🚀 نتیجه نهایی

با اصلاح SPN از طریق Active Directory (Advanced Features + Attribute Editor) و ثبت صحیح روی Service Account،
بیش از ۹۰٪ این خطا به‌طور کامل رفع می‌شود.