رفع خطای 18452 در SQL Server

رفع خطای 18452 در SQL Server: راهنمای جامع ورود ناموفق از دامنه نامعتبر

خطای 18452 در SQL Server یکی از رایج‌ترین پیام‌های “Login failed” است که هنگام تلاش برای اتصال به پایگاه داده با استفاده از احراز هویت ویندوز (Windows Authentication) رخ می‌دهد. این خطا به‌طور خاص نشان می‌دهد که حساب کاربری تلاش‌کننده برای ورود، از یک دامنه (Domain) می‌آید که توسط سرور SQL (یا دامنه میزبان آن) به‌عنوان یک دامنه مورد اعتماد (Trusted Domain) شناسایی نشده است. درک این خطا و روش‌های رفع آن برای مدیران پایگاه داده و توسعه‌دهندگان ضروری است تا بتوانند اتصال‌های امن و پایدار را تضمین کنند. این خطا اغلب به مسائل مربوط به روابط اعتماد بین دامنه‌ها، پیکربندی سرویس‌ها یا تنظیمات احراز هویت در SQL Server اشاره دارد و می‌تواند باعث توقف ناگهانی برنامه‌های کاربردی وابسته به SQL Server شود.

هنگامی که کاربران با این خطا مواجه می‌شوند، نمی‌توانند به SQL Server متصل شوند، که می‌تواند منجر به اختلال در عملکرد برنامه‌های کاربردی، از دست رفتن دسترسی به داده‌ها و کندی در فرآیندهای تجاری شود. پیام کامل خطا معمولاً به شکل زیر است:


Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

این پیام به صراحت نشان می‌دهد که مشکل از عدم اعتماد دامنه مبدأ به دامنه مقصد یا بالعکس است و ارتباط مستقیمی با تنظیمات احراز هویت ویندوز در محیط‌های دارای چندین دامنه یا جنگل (Forest) دارد. برای رفع این مشکل، لازم است که مدیران سیستم و پایگاه داده با هم همکاری کنند تا زیرساخت‌های Active Directory و تنظیمات SQL Server را مورد بررسی و اصلاح قرار دهند. عدم توجه به این خطا می‌تواند به معنای عدم دسترسی کامل به داده‌های حیاتی و سرویس‌های مرتبط با پایگاه داده باشد.

علل اصلی خطای 18452 در SQL Server

شناخت دقیق علت بروز خطای 18452 کلید اصلی رفع آن است. این خطا معمولاً به دلایل زیر رخ می‌دهد و درک هر یک از این موارد به شما کمک می‌کند تا به درستی به عیب‌یابی بپردازید:

1. عدم وجود یا خرابی روابط اعتماد دامنه (Domain Trust Relationships)

مهم‌ترین و رایج‌ترین علت خطای 18452، عدم وجود یک رابطه اعتماد معتبر بین دامنه حساب کاربری که سعی در اتصال دارد و دامنه SQL Server است. احراز هویت ویندوز برای کار در محیط‌های چند دامنه نیاز به این دارد که دامنه‌ها به یکدیگر اعتماد داشته باشند. اگر چنین رابطه‌ای وجود نداشته باشد یا به درستی پیکربندی نشده باشد (مثلاً یک طرفه باشد در حالی که نیاز به دو طرفه بودن است، یا خراب شده باشد)، SQL Server نمی‌تواند اعتبار حساب کاربری را تأیید کند.

یک رابطه اعتماد دامنه به یک دامنه اجازه می‌دهد تا اعتبارنامه‌های (credentials) کاربران را از دامنه دیگر احراز هویت کند. این فرآیند احراز هویت متقابل در اکتیو دایرکتوری (Active Directory) ضروری است. بدون این اعتماد، کنترل‌کننده‌های دامنه (Domain Controllers) نمی‌توانند درخواست‌های احراز هویت را از دامنه‌های نامعتبر پردازش کنند، و در نتیجه، SQL Server این ورود را رد می‌کند. این وضعیت می‌تواند ناشی از عدم ایجاد صحیح اعتماد، انقضای اعتماد، یا تغییرات در DNS یا تنظیمات شبکه باشد که اعتماد موجود را مختل کرده است.

2. عدم ثبت نام‌های اصلی سرویس (Service Principal Names – SPNs) برای Kerberos

در محیط‌هایی که از احراز هویت ویندوز و پروتکل Kerberos برای اتصال به SQL Server در شبکه‌های پیچیده یا بین دامنه‌ای استفاده می‌شود، SPNها نقش حیاتی دارند. SPN یک شناسه منحصربه‌فرد برای یک سرویس (مانند SQL Server) است که با یک حساب کاربری دامنه مرتبط می‌شود. اگر SPN مربوط به سرویس SQL Server به درستی ثبت نشده باشد یا با حساب کاربری اشتباهی مرتبط شده باشد، احراز هویت Kerberos شکست می‌خورد و ممکن است سیستم به احراز هویت NTLM بازگردد. NTLM ممکن است در برخی سناریوهای بین دامنه‌ای، به‌ویژه در دامنه های غیرقابل اعتماد، مشکل‌ساز باشد یا به‌طور کامل پشتیبانی نشود. اگر SPN صحیح نباشد، مشتری قادر به یافتن سرویس SQL Server با استفاده از Kerberos نخواهد بود و ممکن است به NTLM بازگردد که با پیام “untrusted domain” در ترکیب با تنظیمات امنیتی خاص، منجر به خطا شود. این مسئله به‌خصوص در اینستنس‌های نام‌گذاری شده (Named Instances) یا در مواردی که SQL Server با پورت‌های غیرپیش‌فرض اجرا می‌شود، شایع‌تر است.

به‌طور خلاصه، Kerberos برای احراز هویت در محیط‌های Active Directory پیچیده‌تر، به SPNها نیاز دارد. عدم وجود SPN مناسب یا ثبت نادرست آن می‌تواند باعث شود که درخواست‌های احراز هویت به NTLM بازگردند و در نتیجه، در محیط‌های چند دامنه با اعتماد محدود یا بدون اعتماد، خطای 18452 رخ دهد.

3. پیکربندی نامناسب احراز هویت SQL Server (فقط Windows Authentication)

اگر SQL Server فقط برای “Windows Authentication Mode” پیکربندی شده باشد و کاربر بخواهد از یک دامنه نامعتبر متصل شود، طبیعی است که با این خطا مواجه خواهد شد. در این حالت، SQL Server هیچ راه دیگری برای احراز هویت کاربر غیر از استفاده از سیستم احراز هویت ویندوز که به اعتماد دامنه وابسته است، ندارد. در برخی موارد، به‌ویژه در محیط‌های توسعه یا تست، ممکن است لازم باشد که “SQL Server and Windows Authentication Mode” (که به آن Mixed Mode نیز گفته می‌شود) فعال شود تا امکان ورود با حساب‌های SQL Server نیز فراهم شود. با این حال، حتی با Mixed Mode، برای احراز هویت ویندوز همچنان نیاز به اعتماد دامنه است. این دلیل بیشتر به عنوان یک راهکار جایگزین (استفاده از SQL Login) مطرح است تا یک علت مستقیم برای “untrusted domain” در خود Windows Authentication، اما می‌تواند به عنوان یک راه حل موقت یا دائمی در صورت عدم امکان ایجاد اعتماد دامنه مفید باشد.

4. مشکلات DNS یا ارتباطات شبکه

اگرچه کمتر مستقیم است، اما مشکلات مربوط به تفکیک نام (Name Resolution) یا ارتباطات شبکه بین سرور کلاینت و سرور SQL Server می‌تواند منجر به ناتوانی در برقراری ارتباط صحیح با کنترل‌کننده دامنه و در نتیجه عدم توانایی در احراز هویت شود. این می‌تواند به صورت غیرمستقیم به خطای “untrusted domain” منجر شود، زیرا سرور SQL قادر به شناسایی یا ارتباط با دامنه مبدأ نیست. اگر DNS به درستی کار نکند، سرور کلاینت یا سرور SQL ممکن است نتوانند کنترل‌کننده‌های دامنه یکدیگر را پیدا کرده و ارتباط لازم برای احراز هویت را برقرار کنند. همچنین، مسدود شدن پورت‌های لازم توسط فایروال نیز می‌تواند به مشکلاتی در احراز هویت منجر شود.

راهکارهای عملی برای رفع خطای 18452 در SQL Server

برای رفع خطای 18452، بسته به علت ریشه‌ای، چندین گام عملی وجود دارد که باید دنبال شوند. این راهکارها شامل بررسی تنظیمات دامنه، پیکربندی SQL Server و اطمینان از صحت SPNها هستند.

1. بررسی و ایجاد روابط اعتماد دامنه (Domain Trust)

این اولین و مهم‌ترین گام است. اطمینان حاصل کنید که بین دامنه کلاینت (که کاربر از آن متصل می‌شود) و دامنه SQL Server (که سرویس SQL Server روی آن اجرا می‌شود) یک رابطه اعتماد (Trust Relationship) وجود دارد و به درستی پیکربندی شده است. این رابطه باید دو طرفه (Two-Way Trust) باشد مگر اینکه شرایط خاصی یک رابطه یک‌طرفه (One-Way Trust) را توجیه کند که در آن دامنه SQL Server به دامنه کلاینت اعتماد دارد.

چک کردن روابط اعتماد:

در هر کنترل‌کننده دامنه (Domain Controller) در هر دو دامنه، ابزار “Active Directory Domains and Trusts” را باز کنید. روی نام دامنه خود راست کلیک کرده و “Properties” را انتخاب کنید. به تب “Trusts” بروید. در اینجا می‌توانید لیست روابط اعتماد موجود را مشاهده کنید و وضعیت آن‌ها را بررسی کنید. اطمینان حاصل کنید که یک رابطه اعتماد معتبر بین دو دامنه وجود دارد و وضعیت آن “Verified” است. همچنین، بررسی کنید که جهت اعتماد (مثلاً Incoming/Outgoing) با نیازهای شما مطابقت دارد.
ایجاد رابطه اعتماد جدید (در صورت نیاز):

اگر رابطه اعتماد وجود ندارد یا خراب شده است، باید آن را ایجاد یا بازسازی کنید. این کار معمولاً توسط مدیران شبکه و Active Directory انجام می‌شود و نیازمند دسترسی‌های مدیریتی در هر دو دامنه است.

مراحل کلی شامل: باز کردن “Active Directory Domains and Trusts” > راست کلیک روی دامنه > Properties > تب Trusts > New Trust… و دنبال کردن ویزارد است. مطمئن شوید که نوع اعتماد (Forest Trust، External Trust)، جهت (Two-way، One-way) و احراز هویت (Domain-wide authentication، Selective authentication) به درستی انتخاب شده‌اند. پس از ایجاد، حتماً رابطه اعتماد را Verify کنید تا از صحت عملکرد آن اطمینان حاصل شود.

2. پیکربندی احراز هویت SQL Server به حالت مختلط (Mixed Mode Authentication)

اگر ایجاد روابط اعتماد دامنه امکان‌پذیر نیست یا تنها راه حل موقت است، می‌توانید SQL Server را به حالت احراز هویت مختلط (SQL Server and Windows Authentication Mode) پیکربندی کنید. این کار به شما امکان می‌دهد تا کاربران SQL Server (SQL Logins) ایجاد کنید و آن‌ها را برای اتصال به پایگاه داده از هر دامنه یا حتی خارج از دامنه استفاده کنید.

مراحل تغییر حالت احراز هویت:

SQL Server Management Studio (SSMS) را با یک حساب کاربری که دسترسی ‘sysadmin’ به SQL Server دارد، باز کنید. این حساب می‌تواند یک کاربر ویندوز معتبر (در صورت وجود اعتماد) یا یک کاربر SQL Server موجود باشد.
به آبجکت سرور خود در Object Explorer راست کلیک کرده و “Properties” را انتخاب کنید.
از پنجره “Server Properties”، به صفحه “Security” بروید.
در بخش “Server authentication”، گزینه “SQL Server and Windows Authentication mode” را انتخاب کنید.
روی “OK” کلیک کنید.
برای اعمال تغییرات، سرویس SQL Server را Restart کنید. این کار را می‌توانید از طریق SQL Server Configuration Manager یا Services.msc انجام دهید. Restart کردن سرویس برای اعمال کامل تغییرات در حالت احراز هویت ضروری است.

پس از تغییر حالت احراز هویت به Mixed Mode، می‌توانید کاربران SQL Server جدید ایجاد کنید. این کاربران مستقل از Active Directory هستند و می‌توانند از هر کلاینتی با ارائه نام کاربری و رمز عبور به SQL Server متصل شوند:


USE [master]
GO
CREATE LOGIN [YourSqlUser] WITH PASSWORD=N'YourStrongPassword!', DEFAULT_DATABASE=[YourDatabaseName], CHECK_EXPIRATION=OFF, CHECK_POLICY=ON
GO
ALTER SERVER ROLE [sysadmin] ADD MEMBER [YourSqlUser]
GO

این قطعه کد SQL یک کاربر جدید SQL به نام YourSqlUser با رمز عبور تعیین شده ایجاد می‌کند و سپس آن را به نقش سرور sysadmin اضافه می‌کند. برای امنیت بیشتر، توصیه می‌شود به جای sysadmin، نقش‌های مناسب‌تر با حداقل دسترسی لازم را به کاربر اختصاص دهید. همچنین، حتماً یک رمز عبور قوی (Strong Password) استفاده کرده و سیاست‌های مربوط به انقضای رمز عبور را متناسب با نیازهای امنیتی سازمان خود تنظیم کنید. CHECK_EXPIRATION=OFF از انقضای رمز عبور جلوگیری می‌کند که ممکن است در برخی موارد مورد نیاز باشد، اما CHECK_POLICY=ON همچنان از پیچیدگی رمز عبور اطمینان حاصل می‌کند.

3. ثبت نام‌های اصلی سرویس (SPNs) برای Kerberos

اگر SQL Server با یک حساب دامنه اجرا می‌شود و از احراز هویت Kerberos استفاده می‌کنید، اطمینان حاصل کنید که SPN های صحیح برای سرویس SQL Server ثبت شده‌اند. عدم وجود SPN یا SPN نادرست می‌تواند باعث بازگشت به NTLM و در نتیجه خطای “untrusted domain” شود. این مرحله برای اطمینان از اینکه Kerberos به درستی کار می‌کند، حیاتی است.

مراحل بررسی و ثبت SPN:

تعیین حساب سرویس SQL Server:

با استفاده از SQL Server Configuration Manager، حساب کاربری که سرویس SQL Server (MSSQLSERVER برای اینستنس پیش‌فرض یا MSSQL$INSTANCENAME برای اینستنس نام‌گذاری شده) و SQL Server Agent تحت آن اجرا می‌شوند را شناسایی کنید. این حساب باید یک حساب دامنه (مثلاً DOMAIN\ServiceAccount) باشد، نه یک حساب محلی (Local System یا Local Service).
بررسی SPN های موجود:

از یک خط فرمان (Command Prompt) با امتیازات Administrator در یک Domain Controller یا سرور عضو دامنه که ابزارهای RSAT روی آن نصب است، دستور setspn -L را برای حساب سرویس اجرا کنید تا SPN های ثبت شده فعلی را مشاهده کنید. این کار به شما کمک می‌کند تا هرگونه SPN تکراری یا نادرست را شناسایی کنید.
```
setspn -L DOMAIN\ServiceAccount
        
```
همچنین می‌توانید SPNهای مرتبط با نام سرور SQL Server را بررسی کنید:
```
setspn -L SQLServerNetBIOSName
setspn -L SQLServerFQDN
        
```
برای یک اینستنس نام‌گذاری شده (Named Instance)، باید از فرمت SQLServerNetBIOSName:InstanceName یا SQLServerFQDN:InstanceName استفاده کنید:
```
setspn -L SQLServerNetBIOSName:InstanceName
setspn -L SQLServerFQDN:InstanceName
        
```
خروجی باید شامل SPN های درستی برای سرویس SQL Server باشد. اگر SQL Browser فعال باشد، ممکن است نیاز به ثبت SPN برای آن نیز داشته باشید.
حذف SPN های تکراری یا نادرست (در صورت نیاز):

اگر SPN های نادرست یا تکراری (مثلاً با حساب‌های دیگر) پیدا کردید، ابتدا آنها را حذف کنید. بسیار مهم است که SPN فقط به یک حساب کاربری مرتبط باشد تا از بروز خطاهای احراز هویت Kerberos جلوگیری شود.
```
setspn -D MSSQLSvc/SQLServerFQDN:Port DOMAIN\WrongServiceAccount
        
```
این دستور -D (Delete) برای حذف یک SPN خاص استفاده می‌شود.
ثبت SPN های صحیح:

برای اینستنس پیش‌فرض (Default Instance) SQL Server که روی پورت 1433 گوش می‌دهد، SPN های زیر را ثبت کنید. این SPN ها شامل نام NETBIOS و FQDN سرور به همراه پورت پیش‌فرض هستند:
```
setspn -A MSSQLSvc/SQLServerNetBIOSName:1433 DOMAIN\ServiceAccount
setspn -A MSSQLSvc/SQLServerFQDN:1433 DOMAIN\ServiceAccount
        
```
در این دستورات، SQLServerNetBIOSName نام NETBIOS سرور، SQLServerFQDN نام کامل دامنه (Fully Qualified Domain Name) سرور SQL و DOMAIN\ServiceAccount حساب دامنه ای است که سرویس SQL Server تحت آن اجرا می‌شود. 1433 نیز پورت پیش‌فرض SQL Server است.

برای یک اینستنس نام‌گذاری شده (Named Instance) که روی پورت پویا یا یک پورت خاص دیگر گوش می‌دهد، SPN های زیر را ثبت کنید. در اینجا، به جای پورت، نام اینستنس استفاده می‌شود:
```
setspn -A MSSQLSvc/SQLServerNetBIOSName:InstanceName DOMAIN\ServiceAccount
setspn -A MSSQLSvc/SQLServerFQDN:InstanceName DOMAIN\ServiceAccount
        
```
اگر از پورت خاصی استفاده می‌کنید (مثلاً 1435) و اینستنس نام‌گذاری شده است، SPN ها باید شامل شماره پورت باشند:
```
setspn -A MSSQLSvc/SQLServerNetBIOSName:1435 DOMAIN\ServiceAccount
setspn -A MSSQLSvc/SQLServerFQDN:1435 DOMAIN\ServiceAccount
        
```
پس از ثبت یا به‌روزرسانی SPNها، سرویس SQL Server را Restart کنید تا تغییرات اعمال شوند. همچنین، برای اطمینان از اینکه کلاینت‌ها بلیط‌های Kerberos جدید دریافت می‌کنند، ممکن است لازم باشد کلاینت‌ها نیز Restart شوند یا دستور klist purge را روی آنها اجرا کنید.

4. بررسی مشکلات شبکه و DNS

اطمینان حاصل کنید که سرور کلاینت و سرور SQL Server می‌توانند یکدیگر را از طریق شبکه پیدا کنند و نام‌ها به درستی تفکیک (resolve) می‌شوند. مشکلات DNS می‌توانند مانع از یافتن کنترل‌کننده‌های دامنه و احراز هویت شوند. این مرحله شامل بررسی زیرساخت‌های پایه شبکه است.

تست Ping و Nslookup:

از کلاینت به سرور SQL Server، دستور ping را با نام NETBIOS و FQDN سرور SQL Server اجرا کنید تا از اتصال شبکه و تفکیک نام مطمئن شوید. اگر Ping ناموفق بود، مشکلات اتصال شبکه یا فایروال محتمل است.
```
ping SQLServerNetBIOSName
ping SQLServerFQDN
        
```
همچنین، از دستور nslookup برای تأیید تفکیک نام معکوس (Reverse DNS) استفاده کنید تا مطمئن شوید IP به نام صحیح Resolve می‌شود.
```
nslookup SQLServerFQDN
nslookup SQLServerIPAddress
        
```
بررسی فایروال:

اطمینان حاصل کنید که هیچ فایروال (نه روی کلاینت، نه روی سرور SQL و نه فایروال شبکه) پورت‌های لازم برای ارتباط SQL Server (معمولاً TCP 1433 برای اینستنس پیش‌فرض و پورت‌های پویا برای اینستنس‌های نام‌گذاری شده یا پورت‌های مشخص شده) را مسدود نکرده است. برای اینستنس‌های نام‌گذاری شده، پورت UDP 1434 (برای SQL Browser) نیز باید باز باشد.

5. بررسی لاگ‌های رویداد ویندوز (Windows Event Logs)

لاگ‌های رویداد (Event Logs) در ویندوز سرور، به‌ویژه Security Log و System Log، می‌توانند اطلاعات ارزشمندی در مورد دلایل دقیق شکست احراز هویت ارائه دهند. به دنبال رویدادهای مربوط به Kerberos، NTLM، و رویدادهای امنیتی مربوط به ورود ناموفق باشید.

Event Viewer:

برنامه Event Viewer را روی سرور SQL و همچنین روی کنترل‌کننده‌های دامنه مربوطه باز کنید. به بخش “Windows Logs” > “Security” بروید و رویدادهای مربوط به خطاها و هشدارهای اخیر را بررسی کنید. کدهای رویداد (Event IDs) مانند 4625 (Login Failure) می‌توانند اطلاعات دقیقی در مورد نوع شکست ارائه دهند. جزئیات این رویدادها، از جمله Substatus Code و Network Information، می‌توانند به شناسایی علت دقیق کمک کنند. به دنبال “Client Address” و “Target User Name” باشید تا ارتباط بین کلاینت و کاربر را پیدا کنید.

6. ایجاد Login برای گروه دامنه در SQL Server

به جای ایجاد Login برای هر کاربر به صورت جداگانه، بهتر است یک گروه دامنه (Domain Group) ایجاد کرده و کاربران مورد نظر را به آن گروه اضافه کنید. سپس یک Login در SQL Server برای آن گروه دامنه ایجاد کنید. این روش مدیریت دسترسی‌ها را بسیار ساده‌تر و امن‌تر می‌کند، به‌خصوص در محیط‌های بزرگ که کاربران زیادی نیاز به دسترسی دارند.

مثال برای ایجاد Login برای یک گروه دامنه:


USE [master]
GO
CREATE LOGIN [DOMAIN\YourDomainGroup] FROM WINDOWS WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english]
GO
ALTER SERVER ROLE [public] ADD MEMBER [DOMAIN\YourDomainGroup]
GO
-- Optionally, grant specific database access
USE [YourDatabaseName]
GO
CREATE USER [YourDomainGroup] FOR LOGIN [DOMAIN\YourDomainGroup]
GO
ALTER ROLE [db_datareader] ADD MEMBER [YourDomainGroup]
GO
ALTER ROLE [db_datawriter] ADD MEMBER [YourDomainGroup]
GO

در این مثال، ابتدا یک Login برای گروه دامنه YourDomainGroup در SQL Server ایجاد می‌شود. سپس، به آن گروه دسترسی‌های لازم در سطح سرور و همچنین دسترسی به پایگاه داده YourDatabaseName و نقش‌های db_datareader و db_datawriter در آن پایگاه داده اختصاص داده می‌شود. این روش نه تنها مدیریت را ساده می‌کند، بلکه با ساختار Active Directory نیز همخوانی دارد و از اصول حداقل دسترسی (Principle of Least Privilege) پشتیبانی می‌کند. مطمئن شوید که DOMAIN\YourDomainGroup را با نام دامنه و گروه واقعی خود جایگزین می‌کنید و دسترسی‌ها را متناسب با نیازهای امنیتی تعیین می‌کنید.

با پیگیری دقیق این مراحل و بررسی سناریوهای مختلف، می‌توان خطای 18452 را در SQL Server شناسایی و رفع کرد. این خطا اغلب نیاز به همکاری بین مدیران پایگاه داده و مدیران شبکه/Active Directory دارد، زیرا ریشه آن معمولاً در زیرساخت‌های احراز هویت ویندوز نهفته است. عیب‌یابی سیستماتیک و بررسی دقیق هر یک از دلایل احتمالی ذکر شده، منجر به حل دائمی این مشکل خواهد شد و پایداری و امنیت دسترسی به SQL Server را تضمین می‌کند.

رفع خطای 18452 در SQL Server