اعتماد دامنه پس از یک ماه آفلاین از کار افتاد؟ نخست بررسی کنید
یک ایستگاه کاری عضو می‌تواند بیش از بازهٔ گذرواژهٔ ماشین آفلاین بماند و اعتماد را از دست ندهد. پیش از بازنشانی حساب، کانال امن را اثبات کنید.
یک لپ‌تاپ شش هفته بیرون از VPN می‌ماند، بازمی‌گردد و کاربر نمی‌تواند با حساب دامنه وارد شود. خطا به رابطهٔ اعتماد اشاره می‌کند، پس کسی حساب رایانه را بازنشانی می‌کند یا کاربر را به تونل کامل مجبور می‌کند و به نظر می‌رسد مشکل برطرف می‌شود. هیچ‌یک از این دو کار اثبات نکرد که چه چیزی خراب بوده است. یک عضو Windows می‌تواند بسیار بیشتر از بازهٔ معمول گذرواژهٔ ماشین آفلاین بماند و اعتماد را به‌طور خودکار از دست ندهد، بنابراین نخستین کار جدا کردن خطای دسترسی از ناسازگاری واقعی راز است.
خطا شبیه اعتماد است، اما سه وضعیت شبیه هم‌اند
کاربر ممکن است با اطلاعات دامنهٔ ذخیره‌شده در حافظهٔ نهان وارد شود، ایستگاه کاری نتواند کنترل‌کنندهٔ دامنه را پیدا کند، یا عضو و دامنه واقعاً دربارهٔ حساب ماشین اختلاف داشته باشند. تنها سومی در معنای دقیق، رابطهٔ اعتماد شکسته است.
سلامت تکرار AD چهارمین مشاهده است و اصلاً به این ایستگاه کاری مربوط نیست. این سلامت، توافق میان کنترل‌کننده‌های دامنه را توصیف می‌کند و داشبورد تکرار سالم اثبات نمی‌کند که راز محلی این ماشین با حساب رایانه‌اش می‌خواند.
پیش‌فرض آشنا یعنی 30 روز یک سیاست تغییر است، نه مهلت انقضای آفلاین. توضیح Microsoft دربارهٔ گذرواژهٔ حساب ماشین یک فرایند تغییر هماهنگ را توصیف می‌کند و سازمان می‌تواند بازهٔ دیگری تنظیم کند.
یک نماد VPN هیچ چیزی دربارهٔ کانال امن اثبات نمی‌کند
پیش از آنکه هر آزمونی معنایی داشته باشد، اتصال باید به‌قدر کافی خوب باشد تا به سرویس‌های دامنه برسد. یعنی حل‌کنندهٔ DNS موردنظر دامنه، کنترل‌کننده‌ای که یافت شود، سرویس‌های احراز هویت در دسترس و ساعتی که برای Kerberos به‌قدر کافی نزدیک باشد.
تونل کامل می‌تواند در اینجا طرحی کاملاً معتبر باشد. تغییر به تونل تقسیم‌شده پیش‌نیاز رابطهٔ سالم با دامنه نیست و برخورد با آن به‌عنوان پیش‌نیاز، تشخیص را به تغییر معماری تبدیل می‌کند. بررسی کنید ایستگاه کاری در واقع کدام کنترل‌کننده را انتخاب می‌کند و آن نام را همراه خطا نگه دارید.
nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verboseسرور DNS، کنترل‌کنندهٔ حل‌شده و متن دقیق خطا را ثبت کنید. کلاینت VPN که اتصال را گزارش می‌کند به شما می‌گوید تونل وجود دارد، نه اینکه مسیر دامنه کار می‌کند. کنترل‌کننده‌ای که روی درگاه Kerberos پاسخ می‌دهد اما روی درگاه فهرست پاسخ نمی‌دهد، یافتهٔ دیوار آتش است، نه یافتهٔ اعتماد.
پیش از تعمیر، عضو را بیازمایید
روی یک عضو دامنهٔ Windows مجاز، Test-ComputerSecureChannel -Verbose بررسی فقط‌خواندنی کانال میان ماشین و دامنه است. آن را در بافت ماشینی که بررسی می‌کنید اجرا کنید، نه از یک کنترل‌کنندهٔ دامنه که نقش و قواعد بازیابی دیگری دارد. خروجی و وضعیت خروج را ثبت کنید، نه واژهٔ قبول یا رد را. اگر cmdlet در آن ساخت موجود نباشد، ماژول مشکلی جداست.
نتیجه هنوز به بافت نیاز دارد. اگر ماشین نتواند به کنترل‌کنندهٔ انتخاب‌شده برسد یا نزد آن احراز هویت کند، آزمون ناموفق اثبات مستقلی بر انقضای گذرواژهٔ آفلاین نیست. خطای واقعی و کنترل‌کنندهٔ به‌کاررفته را نگه دارید و پس از مطمئن شدن از درستی مسیر، آزمون را تکرار کنید.
رویدادهای Netlogon را روی عضو و روی کنترل‌کنندهٔ مربوط در زمان حادثه به هم مرتبط کنید. نام ماشین، نشانی مبدأ، زمان و هر شاهد تغییر حساب را نگه دارید. ورود موفق کاربری دیگر یا داشبورد سالم کنترل‌کننده نمی‌تواند جای تبادل این ماشین را بگیرد.
فقط رابطه‌ای را تعمیر کنید که اثبات کرده‌اید
وقتی اتصال پایدار شد و مدیر تأیید کرد که تعمیر مناسب است، حالت -Repair این cmdlet با اعتبارنامه‌های مجاز یکی از عملیات پشتیبانی‌شده برای ایستگاه کاری عضو است. این حالت رابطه را تغییر می‌دهد و آزمون فقط‌خواندنی دیگری نیست.
پیش از تغییر، یک حساب بازیابی محلی تأییدشده و مسیری برای مدیریت در دسترس نگه دارید. کنترل‌کننده‌های دامنه نقش بازیابی دیگری دارند و این رویه نباید آن‌ها را مانند ایستگاه‌های کاری معمولی ببیند. از گردش‌کار بازیابی سازمان استفاده کنید، نه از اجرای پشت‌سرهم چند ابزار بازنشانی و امید به اینکه یکی از آن‌ها درست است.
پس از تعمیر، یک آزمون تازهٔ کانال امن و عملیات اصلی دامنه را بررسی کنید. نمایه‌های کاربر و وضعیت برنامه‌ها را حفظ کنید و برداشتن و دوباره پیوستن را نخستین اقدام توضیح‌نشده نکنید.
وقتی خطا بازمی‌گردد چه چیزی را بررسی کنیم
اگر خطا بازگشت، به بازگردانی، هویت تکراری و زمان تغییرات حساب نگاه کنید، نه به بازنشانی دوبارهٔ همان حساب. تصویر بازیابی‌شده، عکس فوری، هویت ماشین کلون‌شده یا بازنشانی حساب رایانه‌ای که جای دیگری انجام شده، همه شایستهٔ بررسی‌اند.
بازنشانی موفق موقت شاهد بازیابی مفیدی است، اما اثبات نمی‌کند که یک VPN متناوب علت ناسازگاری نخستین بوده است. رخداد بعدی است که به شما می‌گوید آیا علت هرگز برطرف شده یا نه.
کنترل‌کننده، سرور DNS و خروجی آزمون را در تیکت بنویسید. همین سابقه است که شکست واقعی اعتماد را از لپ‌تاپی که ساده نتوانست دامنه را پیدا کند جدا می‌کند.