رفع مشکل Join نشدن به دامین؛ بررسی DNS و پیدا نشدن Domain Controller

سیستم جدید به شبکه وصل شده است. سایت‌ها باز می‌شوند و ظاهراً همه‌چیز برای تحویل دستگاه آماده است؛ اما درست در آخرین مرحله، عضویت در دامین متوقف می‌شود. ویندوز نمی‌تواند Domain Controller را پیدا کند.

برای رفع مشکل Join نشدن به دامین، ابتدا باید بفهمیم سیستم در کدام مرحله متوقف شده است: پیدا کردن دامین، برقراری ارتباط با سرور یا دریافت مجوز عضویت؟ در این پرونده، روی مرحلهٔ اول تمرکز می‌کنیم؛ جایی که یک DNS نامناسب می‌تواند اینترنت را در دسترس نگه دارد، اما مسیر رسیدن به دامین داخلی را نشان ندهد.

نکتهٔ اصلی پرونده این است:
باز شدن سایت‌ها، سلامت DNS داخلی دامین را ثابت نمی‌کند.

نوع پرونده: سناریوی آموزشی.
نام‌ها و آدرس‌ها برای یک لابراتوار نمونه انتخاب شده‌اند. این متن گزارش یک رخداد ثبت‌شده در شبکهٔ مشتری نیست و نتیجه‌های تمرین باید در محیط آزمایشگاهی شما بررسی شوند. تمرکز مقاله بر Active Directory محلی یا AD DS است؛ عضویت در Microsoft Entra ID موضوع متفاوتی است.

پاسخ کوتاه: برای رفع مشکل Join نشدن به دامین از کجا شروع کنیم؟

ابتدا DNS تنظیم‌شده روی کلاینت را ببینید. سپس بررسی کنید همان DNS می‌تواند رکوردهای مورد نیاز برای پیدا کردن Domain Controller را پاسخ دهد یا خیر.

اگر پرس‌وجو از DNS فعلی ناموفق است، اما پرس‌وجوی مستقیم از DNS داخلی پاسخ درست می‌دهد، یک سرنخ مهم داریم: احتمالاً کلاینت از مسیر نامناسبی برای پیدا کردن دامین استفاده می‌کند.

این مقایسه نقطهٔ شروع تشخیص است؛ برای تأیید علت، باید تنظیم اصلاح شود و شناسایی DC و عضویت در دامین نیز دوباره آزمایش شوند. بررسی DNS نیز از اولین قدم‌های راهنمای عیب‌یابی عضویت در دامین مایکروسافت است.

چرا اینترنت وصل است، اما دامین پیدا نمی‌شود؟

برای باز کردن یک سایت عمومی، سیستم به اطلاعاتی نیاز دارد که در DNS عمومی قابل دسترسی است. برای پیدا کردن سرویس‌های Active Directory، باید به اطلاعات مربوط به دامین داخلی دسترسی داشته باشد.

این دو نیاز الزاماً از یک مسیر پاسخ داده نمی‌شوند. DNS عمومی ممکن است نام سایت‌ها را به‌درستی پاسخ دهد، اما دربارهٔ دامین آزمایشگاهی شما هیچ اطلاعاتی نداشته باشد.

ضمن اینکه Active Directory فقط دنبال آدرس یک نام معمولی نیست. رکوردهای SRV به کلاینت کمک می‌کنند سرور ارائه‌دهندهٔ سرویس مورد نیاز را پیدا کند. بنابراین پاسخ گرفتن برای نام یک سرور، به‌تنهایی به معنی سالم بودن تمام مراحل شناسایی دامین نیست.

در این پرونده سه پرسش جدا داریم:

1. کلاینت نام کدام دامین را جست‌وجو می‌کند؟
2. پاسخ را از کدام DNS می‌گیرد؟
3. آیا می‌تواند با DC معرفی‌شده ارتباط برقرار کند؟

صورت مسئلهٔ پرونده: دستگاه آماده است، عضویت انجام نمی‌شود

یک لابراتوار کوچک با یک Domain Controller آماده در نظر بگیرید. سرویس AD DS و DNS از قبل روی سرور پیکربندی شده‌اند و رکوردهای دامین وجود دارند. هدف این مقاله نصب Active Directory از صفر نیست.

این نام‌ها مخصوص مثال هستند. در شبکهٔ خودتان از نام واقعی دامین و آدرس DNS تأییدشدهٔ همان شبکه استفاده کنید. برابر بودن آدرس DNS و DC نیز ویژگی این لابراتوار است؛ در همهٔ زیرساخت‌ها چنین نیست.

فرض سناریو این است که کلاینت از طریق دروازه به اینترنت دسترسی دارد و DNS عمومی نیز پاسخ می‌دهد. با وجود این، تلاش برای عضویت در دامین داخلی با خطای پیدا نشدن Domain Controller روبه‌رو می‌شود.

برای بازسازی مشکل، تنظیمات سرور سالم را خراب نمی‌کنیم؛ فقط مسیر DNS یک کلاینت آزمایشگاهی را بررسی می‌کنیم.

پیش از شروع: سه موردی که مسیر تشخیص را عوض می‌کنند

ویرایش ویندوز را بررسی کنید.
این تمرین برای Windows 11 Pro نوشته شده است. Windows Home امکان عضویت در دامین AD محلی را ندارد؛ در چنین حالتی تغییر DNS این قابلیت را به ویندوز اضافه نمی‌کند.

دسترسی لازم داشته باشید.
تغییر تنظیمات کلاینت به دسترسی مدیر محلی نیاز دارد. حسابی که برای Join استفاده می‌کنید نیز باید مجوز مناسب در دامین داشته باشد؛ برای این کار الزاماً نباید از حساب پرقدرت Domain Admin استفاده کرد.

تنظیمات فعلی را ثبت کنید.
پیش از تغییر DNS، آدرس‌ها و وضعیت دریافت خودکار یا دستی آن را یادداشت کنید. در این تمرین فقط تنظیم کلاینت آزمایشگاهی را تغییر می‌دهیم.

قدم اول: DNS واقعی کلاینت را ببینید

روی کلاینت، Windows PowerShell را باز کنید و اجرا کنید:

ipconfig /all

در خروجی، کارت شبکه‌ای را پیدا کنید که به شبکهٔ آزمایشگاهی متصل است. آدرس IP، دروازه و DNS Servers آن را بررسی کنید.

اگر دستگاه چند کارت شبکه، Wi-Fi یا اتصال VPN دارد، تمام خروجی را بخوانید؛ مشاهدهٔ یک DNS درست روی یک کارت، برای نتیجه‌گیری دربارهٔ همهٔ مسیرهای دستگاه کافی نیست.

در سناریوی ما، DNS کارت مرتبط به‌جای
10.20.30.10
روی
8.8.8.8
تنظیم شده است. این هنوز حکم نهایی نیست؛ در مرحلهٔ بعد باید اثر آن را اندازه بگیریم.

پیش از دست بردن در سرور، از کلاینت بپرسید نشانی دامین را از چه کسی می‌گیرد.

قدم دوم: پاسخ DNS فعلی و DNS داخلی را مقایسه کنید

برای بررسی رکورد شناسایی DC، روی کلاینت این پرس‌وجو را اجرا کنید:

Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.ad.modir.test" -Type SRV -DnsOnly

این فرمان، با تنظیمات جاری کلاینت، رکورد SRV مورد نظر را جست‌وجو می‌کند. در لابراتوار سادهٔ این مقاله، DNS عمومی آن را نمی‌شناسد. متن دقیق خطا می‌تواند با شرایط پاسخ‌دهی شبکه تفاوت داشته باشد.

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

Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.ad.modir.test" -Type SRV -Server 10.20.30.10 -DnsOnly

تغییر مهم، افزودن آدرس DNS داخلی است. این فرمان تنظیم دائمی کارت شبکه را عوض نمی‌کند؛ فقط مقصد همین پرس‌وجو را مشخص می‌کند.

در محیط سالمِ تعریف‌شده برای تمرین، باید پاسخ SRV مرتبط با DC دریافت شود. در پاسخ، نام مقصد یا
NameTarget
و پورت را بررسی کنید. در این مثال، انتظار داریم مقصد
DC01.ad.modir.test
و پورت سرویس LDAP برابر 389 باشد. این‌ها معیار مورد انتظارند، نه خروجی ثبت‌شدهٔ یک اجرای واقعی.

نتیجه‌ها را چگونه تفسیر کنیم؟

پاسخ «نام وجود ندارد» با «پاسخی نرسید» یکسان نیست.
اولی می‌تواند حاصل پرسیدن از سرور نامناسب یا نبودن رکورد باشد؛ دومی می‌تواند به دسترسی شبکه یا سرویس DNS مربوط باشد. پیش از هر اصلاح، متن خطا را نگه دارید.

قدم سوم: آیا نام DC به آدرس قابل استفاده تبدیل می‌شود؟

پیدا شدن رکورد SRV پایان بررسی نیست. کلاینت باید بتواند نام معرفی‌شده در پاسخ را هم به آدرس تبدیل کند:

Resolve-DnsName -Name "DC01.ad.modir.test" -Type A -Server 10.20.30.10 -DnsOnly

در لابراتوار IPv4 این مقاله، انتظار داریم آدرس
10.20.30.10
برگردد. در یک شبکهٔ دیگر ممکن است چند DC، چند آدرس یا رکوردهای IPv6 وجود داشته باشند؛ ملاک، تطبیق پاسخ با طراحی همان محیط است.

اگر SRV وجود دارد، اما نام مقصد آن به آدرس اشتباه تبدیل می‌شود، تغییر DNS کلاینت به‌تنهایی کافی نیست. باید رکورد مقصد و علت ثبت آدرس نادرست بررسی شود. مایکروسافت نیز آدرس نامناسب یا غیرقابل‌دسترسیِ ثبت‌شده برای DC را از موارد قابل بررسی در این خطا می‌داند.

قدم چهارم: DNS کلاینت را هدفمند اصلاح کنید

پس از تأیید پاسخ DNS داخلی، Windows PowerShell را با گزینهٔ
Run as administrator
باز کنید.

برای دیدن نام کارت‌ها و DNS تنظیم‌شده، اجرا کنید:

Get-DnsClientServerAddress -AddressFamily IPv4

در فرمان بعد،
Ethernet
را فقط در صورتی نگه دارید که نام کارت متصل به لابراتوار شما همین است:

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses "10.20.30.10"

این فرمان DNS کارت انتخاب‌شده را به‌صورت دستی تنظیم می‌کند و تنظیم DNS دریافتی از DHCP را برای آن کارت کنار می‌زند. آدرس IP و دروازه را تغییر نمی‌دهد.

سپس کش DNS کلاینت را پاک کنید:

ipconfig /flushdns

پاک کردن کش، رکورد گمشده را روی سرور ایجاد نمی‌کند؛ فقط پاسخ‌های ذخیره‌شدهٔ قبلی کلاینت را کنار می‌گذارد.

اکنون پرس‌وجوی SRV را دوباره،
بدون پارامتر Server،
اجرا کنید:

Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.ad.modir.test" -Type SRV -DnsOnly

هدف این است که پاسخ گرفتن فقط با تعیین دستی مقصد ممکن نباشد؛ تنظیم عادی کلاینت هم باید بتواند اطلاعات مورد نیاز را پیدا کند.

آیا DNS عمومی را به‌عنوان DNS دوم بگذاریم؟

برای این سناریو، خیر. DNS دوم نیز باید بتواند نام‌ها و رکوردهای داخلی مورد نیاز دامین را پاسخ دهد. ترکیب یک DNS داخلی با یک DNS عمومی، جایگزین طراحی درست افزونگی DNS نیست.

کلاینت را طوری تنظیم کنید که از Resolverهای مناسب شبکه استفاده کند. حل نام‌های اینترنتی را نیز از مسیر طراحی‌شدهٔ DNS داخلی، مانند Forwarder یا Recursion مجاز، فراهم کنید. اگر DNS داخلی فقط نام‌های داخلی را پاسخ می‌دهد، مشکل نام‌یابی اینترنت را در همان مسیر حل کنید؛ آدرس عمومی را بی‌دلیل به کلاینت برنگردانید.

قدم پنجم: پیدا کردن DC را از عضویت در دامین جدا کنید

اگر ابزار
nltest
روی کلاینت در دسترس است، اجرا کنید:

nltest /dsgetdc:ad.modir.test /force

این آزمون از کلاینت می‌خواهد DC دامین را شناسایی کند. در صورت موفقیت، اطلاعات DC را بررسی کنید. موفقیت این مرحله نشان می‌دهد از مانع شناسایی عبور کرده‌اید؛ هنوز مجوز حساب یا موفقیت نهایی Join را ثابت نمی‌کند.

اگر nltest در سیستم شما شناخته نمی‌شود، آن پیام را با «پیدا نشدن DC» اشتباه نگیرید؛ ابزار اجرا نشده است. بررسی‌های DNS را نگه دارید و از ابزارهای مدیریتی موجود در محیط استفاده کنید.

برای یک بررسی محدودِ ارتباط TCP می‌توانید اجرا کنید:

Test-NetConnection -ComputerName "DC01.ad.modir.test" -Port 389

مقدار
TcpTestSucceeded
فقط دربارهٔ همان اتصال TCP نتیجه می‌دهد. این آزمون نه UDP 389 را بررسی می‌کند و نه همهٔ ارتباطات مورد نیاز Join را. پاسخ Ping نیز به‌تنهایی تأیید سلامت سرویس‌های Active Directory نیست.

قدم ششم: عضویت در دامین و اثبات نتیجه

برای تلاش دوباره روی کلاینت آزمایشگاهی:

1. با اجرای
   sysdm.cpl
   پنجرهٔ
   System Properties
   را باز کنید.
2. در تب
   Computer Name،
   گزینهٔ
   Change
   را انتخاب کنید.
3. در قسمت
   Member of،
   گزینهٔ
   Domain
   را انتخاب کنید.
4. نام کامل
   ad.modir.test
   را وارد کنید؛ نام کوتاه یا آدرس IP سرور را جای آن ننویسید.
5. اطلاعات حساب دارای مجوز عضویت را وارد کنید.
6. پس از پیام موفقیت، کارهای باز را ذخیره و سیستم را راه‌اندازی مجدد کنید.

بعد از راه‌اندازی مجدد، در Windows PowerShell اجرا کنید:

Get-CimInstance Win32_ComputerSystem | Select-Object Name, Domain, PartOfDomain

برای کلاینت این تمرین، نام دامین باید با
ad.modir.test
مطابقت داشته باشد و
PartOfDomain
برابر
True
باشد.

برای بررسی تکمیلی کانال امن، روی همین کلاینت عضو دامین و در Windows PowerShell مدیریتی می‌توانید اجرا کنید:

Test-ComputerSecureChannel -Verbose

این آزمون برای کامپیوتر عضو دامین است؛ آن را برای قضاوت دربارهٔ سلامت یک Domain Controller استفاده نکنید. در این مرحله نیازی به افزودن گزینهٔ
Repair
نداریم، چون هدف، بررسی نتیجه است.

معیار پایان پرونده، فقط ناپدید شدن پیام خطا نیست:
نام‌یابی از مسیر عادی کلاینت درست کار کند، عضویت پس از راه‌اندازی مجدد تأیید شود و ارتباط مورد انتظار با دامین برقرار باشد.

اگر DNS درست شد، اما Join هنوز انجام نشد

رفع یک ایراد ممکن است خطای مرحلهٔ بعد را آشکار کند. ادامهٔ تشخیص را بر اساس خطای جدید انجام دهید:

لاگ Join را با زمان آخرین تلاش بخوانید

لاگ مرتبط روی کلاینت در این مسیر قرار دارد:

C:\Windows\Debug\NetSetup.log

زمان تلاش ناموفق را یادداشت کنید و بخش مربوط به همان تلاش را بخوانید. ممکن است فایل شامل خطاهای قدیمی باشد؛ یک عبارت
Failed
در میانهٔ لاگ، بدون توجه به زمان و ادامهٔ عملیات، برای تعیین علت کافی نیست.

خطای
0x54b
می‌تواند به مشکل تماس یا شناسایی دامین مربوط باشد. در مقابل، خطایی مانند
0xaac
که به استفادهٔ دوباره از حساب کامپیوتر اشاره می‌کند، مسیر بررسی دیگری دارد. در حالت دوم، تغییر مکرر DNS یا حذف عجولانهٔ حساب کامپیوتر جای بررسی مجوزها و سیاست Account Reuse را نمی‌گیرد.

برای آزمون، فایروال را کامل خاموش نکنید

Join به چند سرویس وابسته است. DNS، LDAP، Kerberos، SMB و RPC هرکدام بخشی از ارتباط را فراهم می‌کنند. موفقیت یک تست پورت، مجوز عبور تمام این ترافیک را ثابت نمی‌کند.

به‌جای خاموش کردن کامل فایروال، لاگ و قواعد مسیر کلاینت تا DC را بررسی کنید و فقط نیاز همان زیرساخت را با مستندات پورت‌های Active Directory تطبیق دهید. نیازهای ارتباطی با نقش سرورها و طراحی شبکه تفاوت دارند.

سه میان‌بُر که علت این پرونده را پنهان می‌کنند

۱. نوشتن نام DC در فایل hosts:
این کار رکورد SRV ایجاد نمی‌کند و جای مسیر صحیح شناسایی سرویس‌های دامین را نمی‌گیرد.

۲. تکرار Join بدون آزمون تازه:
اگر DNS یا مسیر ارتباط تغییر نکرده، کلیک دوباره اطلاعات تشخیصی چندانی اضافه نمی‌کند. هر تلاش باید بعد از یک تغییر مشخص یا برای ثبت شواهد تازه باشد.

۳. تغییر هم‌زمان چند تنظیم:
وقتی DNS، ساعت، فایروال و حساب کامپیوتر را با هم تغییر می‌دهید، حتی موفقیت نهایی هم مشخص نمی‌کند کدام مورد علت بوده است. در این لابراتوار، اصلاح هدفمند DNS و تکرار همان آزمون‌ها، مقایسه را قابل فهم نگه می‌دارد.

اصلاح پایدار: سیستم بعدی دوباره همین مشکل را نداشته باشد

اگر کلاینت‌ها تنظیمات DNS را از DHCP دریافت می‌کنند، فقط اصلاح دستی یک دستگاه کافی نیست. بررسی کنید منبع تخصیص تنظیمات، Resolverهای مناسب دامین را به کلاینت‌های آن شبکه معرفی می‌کند.

در شبکه‌های دارای VPN، چند کارت شبکه یا سیاست‌های اختصاصی نام‌یابی، مسیر درخواست‌های مربوط به دامین را نیز بررسی کنید. فرض سادهٔ «یک کارت و یک DNS» را به همهٔ دستگاه‌ها تعمیم ندهید.

اگر راه‌حل پایدار، اصلاح DHCP بوده است، پس از اصلاح و دریافت تنظیمات جدید، استثنای دستی کلاینت آزمایشگاهی را فقط در صورت تناسب با طراحی شبکه بردارید. برای بازگشت DNS همان کارت به تنظیمات دریافتی از DHCP می‌توان از این فرمان استفاده کرد:

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ResetServerAddresses

بعد از آن، DNS واقعی کارت و پرس‌وجوی SRV را دوباره بررسی کنید. بازگشت به حالت خودکار زمانی پایان اصلاح است که منبع خودکار هم تنظیم درست ارائه کند.

چک‌لیست نهایی رفع مشکل Join نشدن به دامین

• ویرایش ویندوز از عضویت در دامین AD محلی پشتیبانی می‌کند.
• نام کامل دامین و نام کامپیوتر درست هستند.
• DNS کارت مرتبط و دیگر اتصال‌های فعال بررسی شده‌اند.
• پاسخ DNS جاری با پاسخ مستقیم DNS داخلی مقایسه شده است.
• رکورد SRV و آدرس نام مقصد آن بررسی شده‌اند.
• شناسایی DC از موفقیت نهایی Join تفکیک شده است.
• خطای جدید، در صورت وجود، با لاگ همان تلاش تطبیق داده شده است.
• عضویت پس از راه‌اندازی مجدد تأیید شده است.
• منبع تنظیمات DNS برای جلوگیری از تکرار مشکل بررسی شده است.

پرسش‌های متداول

آیا هر خطای Join نشدن به دامین از DNS است؟

خیر. DNS نقطهٔ مهمی برای شروع است، اما محدودیت ارتباط، مجوز، حساب کامپیوتر موجود و مشکلات احراز هویت هم می‌توانند مانع عضویت شوند. بعد از هر آزمون، باید مسیر بررسی را با شواهد همان محیط انتخاب کرد.

آیا DNS کلاینت همیشه باید IP خود Domain Controller باشد؟

خیر. کلاینت باید از DNS یا Resolver مناسبی استفاده کند که رکوردهای دامین را به‌درستی پاسخ می‌دهد. در لابراتوار ما DNS و DC روی یک سرور هستند؛ این الزام همهٔ شبکه‌ها نیست.

چرا nslookup جواب می‌دهد، اما Join هنوز ناموفق است؟

باید دید چه نامی، با چه نوع رکوردی و از کدام سرور پرسیده شده است. پاسخ یک رکورد A، سلامت SRV یا دسترسی به سرویس‌ها را ثابت نمی‌کند. همچنین آزمون مستقیم یک DNS الزاماً نشان نمی‌دهد مسیر عادی نام‌یابی کلاینت همان است.

آیا پاک کردن کش DNS به‌تنهایی مشکل را حل می‌کند؟

اگر علت، پاسخ قدیمی ذخیره‌شده باشد ممکن است کمک کند؛ اما DNS اشتباه، رکورد گمشده یا مسدود بودن مسیر شبکه را اصلاح نمی‌کند. در این پرونده، پاک کردن کش پس از اصلاح تنظیم انجام می‌شود.

آیا نام دامین را باید با آدرس IP سرور جایگزین کنیم؟

خیر. در مرحلهٔ عضویت، نام دامین AD را وارد کنید. دسترسی به IP یک سرور، جایگزین پیدا کردن دامین و سرویس‌های آن نیست.

نتیجهٔ این پرونده

در سناریوی این مقاله، اشکال هدف این است که کلاینت برای پیدا کردن دامین داخلی از DNS نامناسب سؤال می‌پرسد. اینترنت در دسترس است، اما اطلاعات مورد نیاز Active Directory از آن مسیر به دست نمی‌آید.

تشخیص زمانی قابل دفاع می‌شود که نام و نوع پرس‌وجو را ثابت نگه داریم، پاسخ DNS جاری را با DNS داخلی مقایسه کنیم و بعد از اصلاح، همان مسیر را دوباره بسنجیم.

درس کاربردی پرونده این است:

قبل از تغییر سرور، مسیر رسیدن کلاینت به اطلاعات دامین را روشن کنید.

این روش کمک می‌کند رفع مشکل Join نشدن به دامین از آزمون‌وخطا به یک بررسی مرحله‌ای و قابل تکرار تبدیل شود.

پروندهٔ مرتبط

در پروندهٔ اول نیز ظاهر یک بخش از سیستم سالم بود، اما زنجیرهٔ کامل به نتیجه نمی‌رسید: داده در زبیکس ثبت می‌شد، ولی اعلان به گیرنده نمی‌رسید. برای تمرین همین شیوهٔ تفکیک مراحل، مقالهٔ

رفع مشکل ارسال نشدن هشدار در Zabbix 7.4

را بخوانید.

دیگر سناریوها در

پرونده‌های عیب‌یابی مدیر شبکه

قرار می‌گیرند.

منابع فنی

• 
  راهنمای عیب‌یابی عضویت در دامین
  
• 
  نقش رکوردهای SRV در شناسایی Domain Controller
  
• 
  توصیه‌های مایکروسافت برای DNS کلاینت
  
• 
  مستندات Resolve-DnsName
  
• 
  مستندات Set-DnsClientServerAddress
  
• 
  مستندات Test-NetConnection
  
• 
  روش عضویت کامپیوتر در دامین
  
• 
  مستندات Test-ComputerSecureChannel
  
• 
  مجوزهای عضویت در دامین
  
• 
  نیازهای فایروال Active Directory