چرا لپ‌تاپ Protected Users پیش از ورود به VPN نیاز دارد

یک لپ‌تاپ، یک حساب کارآمد و یک شبکه هتل مجموعاً حلقه‌ای از ورود می‌سازند که هیچ تلاش دوباره‌ای آن را نمی‌شکند. حساب در Protected Users قرار دارد، که Windows را از ذخیره تأییدگری که برای احراز هویت کاربر به‌صورت برون‌خط لازم دارد بازمی‌دارد. هر طرحی به شکل «نخست وارد شوید، سپس تونل را متصل کنید» ترتیب را برعکس دارد، و محافظت دقیقاً همان کاری را می‌کند که وعده می‌دهد. ادامه مطلب یک حساب سنتی Active Directory روی میزبان پشتیبانی‌شده Windows را فرض می‌کند.

محافظت در واقع چه چیزی را برمی‌دارد

Windows معمولاً تأییدگر را در حافظه پنهان نگه می‌دارد تا حساب دامنه هنگام در دسترس نبودن کنترل‌کننده دامنه بتواند وارد شود. Protected Users این را برای حساب مسدود می‌کند، که ورود برون‌خط به دامنه را به‌جای غیرقابل‌اعتماد کردن، به‌عنوان یک امکان حذف می‌کند.

این مشکل معمول حافظه پنهان کهنه نیست، و درمان‌های معمول کارساز نیستند. ورود مکرر برخط، تغییر دوباره گذرواژه یا بالا بردن شمار ورودهای ذخیره‌شده توانایی را بازنمی‌گرداند، زیرا هیچ‌یک از این کارها تأییدگری را که سیاست از ذخیره آن خودداری می‌کند نمی‌سازد. حساب همان‌گونه که طراحی شده رفتار می‌کند، و طراحی فرض می‌کند شبکه هنگام درخواست Windows حاضر است. برخورد با نشانه به‌عنوان خطای حافظه پنهان همان راهی است که تیم‌ها به بازسازی نمایه‌ای می‌رسند که هرگز خراب نبوده.

چرا تونل باید پیش از دسکتاپ وجود داشته باشد

دستگاه باید در همان لحظه‌ای که Windows می‌خواهد به احراز هویت دامنه برسد، و این پیش از وجود هر نشست کاربر است. کارخواه VPN که تنها پس از ظاهر شدن دسکتاپ آغاز می‌شود، ورود تازه‌ای را منتظر مسیری می‌گذارد که هرگز نمی‌رسد. وابستگی از آنِ ماشین است، نه کاربری که هنوز وارد نشده.

از یک ترتیب پیش از ورود پشتیبانی‌شده و مورد توافق با صاحبان نقطه پایانی و هویت استفاده کنید. تونل دستگاه Always On VPN که با گواهی رایانه احراز هویت می‌شود، هنگامی واجد شرایط است که دستگاه مدیریت‌شده پیش‌نیازهای آن استقرار را برآورده کند. یکپارچه‌سازی پشتیبانی‌شده فروشنده در صفحه ورود گزینه دیگری است. نمایه کاربری معمولی با محرک خودکار هیچ‌کدام نیست، هرقدر هم در رابط کارخواه شبیه به نظر برسد.

این مسیر به تحلیل نام برای دامنه، یک کنترل‌کننده دامنه در دسترس و پروتکل‌های احراز هویتی که حساب می‌تواند به کار ببرد نیاز دارد، و هیچ نشانگر «متصل» هیچ‌یک از اینها را فراهم نمی‌کند. مسیرها و صافی‌های آن باید سرویس‌های هویت را حمل کنند و چیز دیگری که لازم نیست، زیرا همان فهرست پیشوند سطحی است که یک لپ‌تاپ دزدیده‌شده پیش از ورود کسی به دست می‌آورد. تصمیم‌های تونل تقسیم‌شده برای تونل کاربر به تونل دستگاه منتقل نمی‌شود، پس هر دو را جداگانه بازبینی کنید.

دسترس‌پذیری سازگاری احراز هویت نیست

تونل می‌تواند بسته‌ها را بی‌عیب حمل کند در حالی که احراز هویت دامنه شکست می‌خورد، زیرا سازوکاری که آزموده می‌شود یکی از آن‌هایی است که حساب اجازه استفاده از آن را ندارد. در دامنه‌ای که محدودیت‌های گروه را اعمال می‌کند، NTLM برای اعضا در دسترس نیست و Kerberos به حسابی و پیکربندی سازگار با AES نیاز دارد. مسیر بسته نمی‌تواند هیچ‌یک را ترمیم کند. به همین دلیل یک ping پاک به کنترل‌کننده دامنه شاهدی بر موفقیت ورود نیست.

ممکن است دو سامانه اعتبارنامه در کار باشند. VPN می‌تواند در برابر یک ارائه‌دهنده هویت احراز هویت کند در حالی که Windows جداگانه به ورود دامنه نیاز دارد، و پذیرش اولی چیزی درباره دومی نمی‌گوید. «VPN متصل شد» و «کاربر وارد شد» دو مشاهده جداگانه‌اند، و درست کردن یکی به معنای دیگری نیست.

شواهد احراز هویت را بخوانید

برای یک تلاش، رویدادها را هم از کارخواه و هم از یک کنترل‌کننده دامنه گردآوری کنید، نه تنها از یک سو. گزارش‌های Protected Users زیر Applications and Services Logs\Microsoft\Windows\Authentication قرار دارند، و ممکن است مدیر پیش از آنکه چیزی ثبت شود ناچار شود گزارشی را روشن کند. مُهرهای زمانی را با گزارش اتصال خود تونل همبسته کنید، زیرا خطای ترتیب از هر دو سو مانند خطای اعتبارنامه دیده می‌شود.

فرمان نخست در زیر هر گزارش احراز هویتی را که دستگاه آشکار می‌کند فهرست می‌کند، پس همان را می‌خوانید که وجود دارد نه آن را که یک نوشته وبلاگی نام برده است. دومی پس از دانستن نام، ورودی‌های تازه را می‌خواند. به دنبال بسته احراز هویت، حساب و شرط شکست بگردید، زیرا مسیر شبکه غایب و سازوکار ردشده شواهد متفاوتی بر جای می‌گذارند و تنها یکی از آن‌ها مشکل VPN است. اگر تونل پس از تلاش بالا آمد، ترتیب نادرست بود هر چه آن ورودی‌ها بگویند.

Get-WinEvent -ListLog *Authentication*
Get-WinEvent -LogName Microsoft-Windows-Authentication/Operational -MaxEvents 20

مرز را از راه‌اندازی سرد اثبات کنید

آزمون را از حالت خارج‌شده یا تازه راه‌اندازی‌شده با حسابی محدود اجرا کنید، و پیش از تغییر هر چیزی برای کاربران دارای امتیاز، مسیر بازیابی تأییدشده‌ای را باز نگه دارید. آزمون روی دسکتاپی که از پیش در حال اجراست هیچ بخشی از مسیر کد مهم را تمرین نمی‌کند، و همین بیشتر گزارش‌های مربوط به اصلاحی را توضیح می‌دهد که تا راه‌اندازی مجدد بعدی دوام آورد. سپس چهار گام را به این ترتیب بگذرانید.

1. تأیید کنید که دستگاه پیش از ورود کسی می‌تواند کنترل‌کننده دامنه را پیدا کند، با nltest /dsgetdc:corp.example.com.
2. ورود دامنه را بیازمایید، سپس بپرسید آیا اصلاً بلیتی گرفته شد، با klist.
3. گزارش احراز هویتی را که دستگاه ثبت می‌کند با دو فرمان بالا بخوانید، و بسته و شرط شکست را یادداشت کنید.
4. تأیید کنید که اعتبارنامه بازیابی تأییدشده هنوز از صفحه ورود کار می‌کند، زیرا اگر آزمون مرز شکست بخورد تنها راه بازگشت همین است.

باز کردن یک اشتراک فایل با اعتبارنامه‌های ارائه‌شده هم ورود تعاملی برون‌خط نمی‌سازد، پس جایگزین هیچ‌یک از گام‌های بالا نیست. اگر سازمان واقعاً به ورود بدون اتصال نیاز دارد، پاسخ طراحی سازگار حساب و نقطه پایانی است که آگاهانه انتخاب شده باشد. بیرون آوردن حساب از گروه، یا نگه داشتن یک ورود اضطراری نامحدود روی هر لپ‌تاپ، تصمیمی در سیاست هویت است که تغییر VPN نمی‌تواند به‌جای شما بگیرد.

مستندات Protected Users هم رفتار تأییدگر و هم محدودیت‌های دامنه‌ای را که این طراحی به آن‌ها وابسته است توصیف می‌کند. پیش از سفر هر کسی فرایند بازیابی را برنامه‌ریزی کنید، زیرا آزمون راه‌اندازی سرد تنها جایی است که تمرین می‌شود.