رفع خطای Trust Relationship در Windows Server؛ تعمیر Secure Channel بدون خروج از دامنه

اگر هنگام ورود به یک کامپیوتر عضو دامنه یا سرور عضو Active Directory پیام The trust relationship between this workstation and the primary domain failed می‌بینید، معمولاً کانال امن (Secure Channel) میان حساب کامپیوتر و Domain Controller قابل اعتبارسنجی نیست. در بسیاری از موارد می‌توان بدون خارج‌کردن سیستم از دامنه، پس از بررسی DNS، ارتباط با DC و زمان سیستم، با Test-ComputerSecureChannel -Repair یا Reset-ComputerMachinePassword مشکل را رفع کرد. این راهنما برای Domain Member Server و کلاینت عضو دامنه است؛ دستور Test-ComputerSecureChannel را برای Domain Controller به کار نبرید.

نشانه‌های خرابی Trust Relationship و تفاوت آن با خطای ورود کاربر

پیام اصلی ممکن است در صفحه Sign-in ویندوز ظاهر شود. در Event Viewer نیز خطاهای NETLOGON مانند 3210 دیده می‌شوند یا دستور nltest /sc_query وضعیت ناموفق کانال امن را گزارش می‌کند. اما هر خطای ورود لزوماً به معنی خراب‌شدن رمز حساب کامپیوتر نیست: قطعی DNS، دسترسی‌نداشتن به Domain Controller، اختلاف شدید زمان، اختلال شبکه و مشکل replication نیز می‌توانند علائم مشابه ایجاد کنند. به همین دلیل ترتیب بررسی اهمیت دارد.

پیش‌نیازها و اقدامات ایمن پیش از تعمیر

• با یک حساب دارای دسترسی Local Administrator وارد سیستم مشکل‌دار شوید؛ اگر ورود دامنه‌ای ممکن نیست، از حساب محلی مجاز استفاده کنید.
• PowerShell را با Run as administrator باز کنید. برای تعمیر به اعتبارنامه دامنه با مجوز مناسب برای حساب کامپیوتر نیاز دارید.
• نام دامنه و DC سالم را مشخص کنید. در نمونه‌ها contoso.local و dc01.contoso.local صرفاً جای‌نگهدار هستند.
• اگر سرور از راه دور مدیریت می‌شود، قبل از تغییر Secure Channel دسترسی کنسول خارج از باند، بکاپ/Checkpoint سازگار و پنجره نگهداری داشته باشید. Snapshot ماشین مجازی را بدون توجه به سازگاری AD به‌عنوان راهکار بازگشت عمومی فرض نکنید.
• روی Domain Controller، Cluster حساس یا سیستمی با مشکل هم‌زمان replication، مراحل تعمیر عضو دامنه را بدون بررسی تخصصی اجرا نکنید.

مرحله اول: بررسی عضویت دامنه و کشف Domain Controller

ابتدا مطمئن شوید کامپیوتر واقعاً عضو دامنه است و می‌تواند DC پیدا کند. این فرمان‌ها روی همان دستگاه مشکل‌دار اجرا می‌شوند:

Get-ComputerInfo | Select-Object CsName,CsDomain,CsPartOfDomain
nltest /dsgetdc:contoso.local
Get-Service Netlogon

در خروجی، CsPartOfDomain باید True باشد و nltest نام DC و اطلاعات دامنه را برگرداند. اگر DsGetDcName failed یا خطای مشابه دارید، فعلاً رمز حساب کامپیوتر را Reset نکنید؛ اول DNS و ارتباط شبکه را اصلاح کنید.

مرحله دوم: بررسی DNS، رکوردهای SRV و پورت‌های لازم

کلاینت عضو دامنه باید برای یافتن DC از DNS مناسب Active Directory استفاده کند، نه صرفاً DNS عمومی اینترنت. آدرس DNS کارت شبکه و رکوردهای سرویس را بررسی کنید:

Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName dc01.contoso.local
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.contoso.local
Test-NetConnection dc01.contoso.local -Port 389
Test-NetConnection dc01.contoso.local -Port 88
Test-NetConnection dc01.contoso.local -Port 445

پاسخ SRV باید DCهای معتبر دامنه را نشان دهد و برای تست‌های TCP، فیلد TcpTestSucceeded در شرایط شبکه مجاز True باشد. این سه پورت فقط بخشی از الزامات ارتباط با AD هستند؛ RPC Endpoint Mapper، پورت‌های پویا، DNS و سایر وابستگی‌ها نیز مهم‌اند. Test-NetConnection در نمونه بالا TCP را می‌سنجد و تست UDP نیست. اگر DNS یا مسیر شبکه مشکل دارد، راهنمای عیب‌یابی DNS در Windows Server را دنبال کنید.

مرحله سوم: بررسی ساعت و Windows Time

اختلاف زمان زیاد می‌تواند احراز هویت Kerberos را مختل کند. قبل از Repair، وضعیت منبع زمان و ساعت محلی را ببینید:

w32tm /query /status
w32tm /query /source
Get-Date

اگر منبع زمان نامعتبر است یا سرویس W32Time همگام نمی‌شود، ابتدا مسیر NTP/Domain Hierarchy را اصلاح کنید؛ اجرای بی‌هدف Resync یا تنظیم دستی ساعت، ریشه مشکل را حل نمی‌کند. برای جزئیات به رفع خطای w32tm /resync در Windows Server مراجعه کنید.

مرحله چهارم: تست واقعی Secure Channel بدون تغییر تنظیمات

پس از اطمینان از دسترسی به DC، روی کلاینت یا Member Server این دستورات را اجرا کنید:

Test-ComputerSecureChannel -Verbose
nltest /sc_query:contoso.local

در حالت سالم، دستور اول True برمی‌گرداند. False یا خطا به بررسی بیشتر نیاز دارد؛ خطاهای دسترسی، DNS و Netlogon را از عدم تطابق رمز Machine Account تفکیک کنید. برای مشاهده رویدادهای اخیر:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='NETLOGON'; StartTime=(Get-Date).AddHours(-12)} -ErrorAction SilentlyContinue | Select-Object -First 20 TimeCreated,Id,Message

اگر خروجی خالی است، الزاماً مشکل وجود ندارد؛ Event Viewer و گزارش‌های DC را نیز متناسب با سناریو بررسی کنید. در برخی خطاها کدهای 0x5 یا 0xc0000022 دیده می‌شوند که باید همراه با لاگ و وضعیت دسترسی تفسیر شوند.

مرحله پنجم: تعمیر Secure Channel با PowerShell

اگر ارتباط شبکه و DNS سالم است و تست کانال امن شکست خورده، از حساب محلی ادمین روی دستگاه عضو دامنه، فرمان تعمیر را با اعتبارنامه مجاز اجرا کنید:

$cred = Get-Credential
Test-ComputerSecureChannel -Repair -Credential $cred -Server dc01.contoso.local -Verbose

پنجره اعتبارنامه را با حساب مجاز دامنه پر کنید؛ رمز عبور را داخل اسکریپت یا Command History به‌صورت متن ساده ننویسید. پس از اجرای موفق، کانال امن را دوباره تست کنید:

Test-ComputerSecureChannel -Verbose
nltest /sc_verify:contoso.local

اگر دستور اول True و وضعیت Secure Channel در nltest موفق است، با یک ورود دامنه‌ای کنترل‌شده و دسترسی به سرویس وابسته نتیجه را تأیید کنید. اگر Repair خطا می‌دهد، پیام دقیق و رویدادهای NETLOGON را بررسی کنید؛ بلافاصله دستگاه را از دامنه خارج نکنید.

راه جایگزین: Reset-ComputerMachinePassword

در برخی سناریوها بازنشانی رمز حساب کامپیوتر از خود Member Server مؤثر است. این دستور، رمز حساب ماشین را با DC تعیین‌شده هماهنگ می‌کند و باید با مجوز مناسب اجرا شود:

$cred = Get-Credential
Reset-ComputerMachinePassword -Server dc01.contoso.local -Credential $cred
Test-ComputerSecureChannel -Verbose

این دستور با Reset کردن رمز کاربر یا حذف حساب کامپیوتر از Active Directory تفاوت دارد. روی Domain Controller از روش‌های اختصاصی DC طبق مستندات Microsoft استفاده کنید؛ Test-ComputerSecureChannel برای DC ممکن است نتیجه False Positive بدهد.

اگر تعمیر موفق نشد، چه چیزی را بررسی کنیم؟

۱. DNS درست است ولی DC انتخابی در دسترس نیست

با nltest /dsgetdc DC کشف‌شده را بررسی کنید. اگر DC خاصی در شبکه در دسترس نیست، Route، Firewall، Site/Subnet و DNS را اصلاح کنید و سپس یک DC سالم را برای Repair انتخاب کنید.

۲. رمز حساب کامپیوتر بین دستگاه و Active Directory همگام نیست

بازگردانی قدیمی ماشین مجازی، مشکل replication، حساب کامپیوتر تکراری یا تغییر رمز حساب ماشین می‌تواند سبب اختلاف شود. پیش از Reset کردن شیء کامپیوتر در AD، وضعیت replication و نام تکراری را بررسی کنید. Reset کردن Computer Object از کنسول AD بدون برنامه بازگردانی، ممکن است وضعیت را بدتر کند.

۳. خطای Access denied در Repair

حساب استفاده‌شده ممکن است مجوز لازم را نداشته باشد، کانال ارتباطی مشکل داشته باشد یا سیاست امنیتی مانع عملیات شود. اعتبارنامه را با حساب مجاز و مسیر دسترسی سالم بررسی کنید؛ Domain Admin بودن را بدون نیاز واقعی به‌عنوان راه‌حل دائمی انتخاب نکنید.

۴. مشکل پس از ری‌استارت برمی‌گردد

در این حالت احتمالاً علت ریشه‌ای مثل DNS اشتباه، DC ناسالم، replication، ماشین‌های Clone شده با نام یکسان یا Snapshot قدیمی همچنان وجود دارد. به‌جای تکرار Repair، علت بازگشت خطا را پیدا کنید.

آخرین راهکار: خروج و عضویت مجدد در دامنه

اگر Repair و Reset-ComputerMachinePassword پس از رفع مشکلات زیرساختی موفق نشدند، با برنامه بازگشت و تأیید مالک سرویس، امکان Unjoin/Rejoin را بررسی کنید. پیش از این کار پروفایل‌های کاربری، دسترسی سرویس‌ها، حساب‌های اجرای Task و Application Pool، مجوزها، BitLocker/Recovery Key و دسترسی RDP را مستندسازی کنید. خروج از دامنه و ورود دوباره معمولاً نیازمند Restart است و ممکن است روی سرویس‌ها و پروفایل‌ها اثر بگذارد؛ بنابراین برای سرور Production نخستین راهکار نیست.

چطور مطمئن شویم Trust Relationship واقعاً درست شده است؟

پس از اصلاح، این چک‌لیست عملی را اجرا کنید: Test-ComputerSecureChannel باید True بدهد؛ nltest /sc_verify باید وضعیت موفق داشته باشد؛ DNS و SRV باید DC معتبر برگردانند؛ ساعت سیستم باید با Domain Hierarchy سازگار باشد؛ ورود یک کاربر مجاز دامنه و دسترسی به سرویس‌های وابسته باید بدون خطا انجام شود. Event Log را در بازه پس از تعمیر بررسی کنید تا خطای تازه NETLOGON ثبت نشده باشد.

Test-ComputerSecureChannel -Verbose
nltest /sc_verify:contoso.local
w32tm /query /source
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='NETLOGON'; StartTime=(Get-Date).AddMinutes(-30)} -ErrorAction SilentlyContinue | Select-Object -First 10 TimeCreated,Id,Message

اگر مشکل دسترسی فایل‌سرور همچنان پابرجاست اما Secure Channel سالم است، موضوع می‌تواند مربوط به SMB، پورت 445 یا Permission باشد؛ از راهنمای عیب‌یابی Shared Folder و SMB در Windows Server استفاده کنید.

Rollback و احتیاط‌های عملیاتی

برای دستورهای تست نیازی به Rollback نیست چون تغییری ایجاد نمی‌کنند. برای Repair/Reset، بازگشت به رمز قبلی حساب ماشین معمولاً راهکار امن و قابل اتکایی نیست؛ اگر تعمیر موفق نشد، با بررسی DC، Event Log، replication و اعتبارنامه، مسیر Recovery را انتخاب کنید. از Snapshot Restore یا Reset مکرر Computer Account بدون بررسی سازگاری AD خودداری کنید. در سرور راه دور، تا تأیید ورود دامنه‌ای و دسترسی مدیریتی، نشست کنسول محلی را حفظ کنید. برای سناریوهای میزبانی Active Directory روی سرور مجازی، پایداری شبکه و دسترسی کنسول مدیریتی در زمان عیب‌یابی اهمیت زیادی دارد.

مراجع رسمی: Microsoft Learn: Broken trust relationship، Test-ComputerSecureChannel و Reset-ComputerMachinePassword.