خطاهای NLA در RDP: علل، راه‌حل‌ها و بهترین شیوه‌ها

معرفی

احراز هویت در سطح شبکه (NLA) یک کنترل امنیتی اصلی برای پروتکل دسکتاپ از راه دور است که کاربران غیرمجاز را قبل از ایجاد یک جلسه کامل متوقف می‌کند. با این حال، زمانی که NLA شکست می‌خورد، تیم‌های IT با ورودهای مسدود شده، پیام‌های خطای مبهم و کاربران نهایی ناامید مواجه می‌شوند که نمی‌توانند به سرورهای حیاتی دسترسی پیدا کنند. این راهنما توضیح می‌دهد که NLA چیست، چرا این خطاها رخ می‌دهند و چگونه می‌توان به طور سیستماتیک مشکلات NLA را عیب‌یابی و حل کرد بدون اینکه وضعیت امنیتی RDP شما تضعیف شود.

NLA در RDP چیست؟

احراز هویت در سطح شبکه یک بهبود امنیت RDP است که با ویندوز ویستا و ویندوز سرور ۲۰۰۸ معرفی شده است. به جای ساختن کامل جلسه دسکتاپ از راه دور و سپس درخواست اعتبارنامه، NLA از کاربران می‌خواهد که ابتدا احراز هویت کنند. تنها پس از احراز هویت موفق، پشته RDP جلسه گرافیکی را ایجاد می‌کند.

NLA به CredSSP (ارائه‌دهنده پشتیبانی امنیتی اعتبارنامه) متکی است تا اعتبارنامه‌های کاربر را به‌طور ایمن به سیستم هدف منتقل کند. در محیط‌های متصل به دامنه، CredSSP با Active Directory صحبت می‌کند تا حساب را قبل از برقراری جلسه تأیید کند. در میزبان‌های مستقل یا گروه کاری، CredSSP حساب‌های محلی پیکربندی‌شده برای ورود از راه دور را تأیید می‌کند.

مزایای کلیدی NLA شامل:

• کاهش پنجره برای حملات نیروی بی‌رحمانه و انکار خدمات بر روی نقاط انتهایی RDP نمایان شده
• فعال‌سازی ورود یکپارچه (SSO) برای کاربران دامنه، بهبود تجربه کاربری
• بهبود عملکرد با انجام احراز هویت قبل از ایجاد جلسه

با این حال، NLA به نسخه‌های سیستم‌عامل و وصله‌ها حساس است، TLS پیکربندی و سلامت دامنه. زمانی که هر یک از این پیش‌نیازها شکست بخورد، NLA می‌تواند اتصالات معتبر را به‌طور کامل مسدود کند.

علائم رایج خطاهای NLA در RDP چیست؟

مسائل مربوط به NLA معمولاً با پیام‌های مشابهی ظاهر می‌شوند، صرف نظر از علت اصلی. شما احتمالاً با یک مشکل NLA مواجه هستید اگر با موارد زیر روبرو شوید:

• کامپیوتر از راه دور به احراز هویت سطح شبکه (NLA) نیاز دارد، اما کامپیوتر شما از آن پشتیبانی نمی‌کند.
• یک خطای احراز هویت رخ داده است. عملکرد درخواست شده پشتیبانی نمی‌شود.
• خطای اصلاح اوراکل رمزگذاری CredSSP.
• اعتبارنامه‌های شما کار نکردند.
• قطع ارتباط یا زمان‌های خروج ناگهانی در حین دست دادن اولیه RDP یا بلافاصله پس از وارد کردن اعتبارنامه‌ها

این علائم می‌توانند بر روی هر دو میزبان متصل به دامنه و مستقل تأثیر بگذارند. در عمل، آن‌ها معمولاً به سیاست‌های امنیتی نامتناسب، مسدود شدن دسترسی به کنترل‌کننده دامنه، یا اجزای RDP قدیمی در هر دو طرف برمی‌گردند.

علت‌های خطاهای NLA در RDP چیست؟

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

• عدم سازگاری سیستم عامل کلاینت یا سرور
• کنترل‌کننده دامنه در دسترس نیست
• عدم تطابق پچ CredSSP
• پیکربندی نادرست رمزگذاری TLS یا RDP
• تعارضات سیاست گروه یا رجیستری
• پروفایل‌های کاربری یا اعتبارنامه‌های خراب شده
• سناریوهای گروه کاری و غیر دامنه

عدم سازگاری سیستم عامل کلاینت یا سرور

نسخه‌های قدیمی ویندوز یا کلاینت‌های RDP شخص ثالث ممکن است از NLA یا رفتار مدرن CredSSP به طور کامل پشتیبانی نکنند. به عنوان مثال، نسخه‌های قدیمی ویندوز XP یا نسخه‌های اولیه ویندوز Vista نمی‌توانند به سرورهای تحت فشار NLA متصل شوند مگر با به‌روزرسانی‌های خاص. حتی در سیستم‌های پشتیبانی شده، باینری‌های کلاینت RDP قدیمی می‌توانند باعث بروز خطاهای "کامپیوتر شما از NLA پشتیبانی نمی‌کند" شوند، با وجود اینکه سیستم‌عامل به طور ظاهری از آن پشتیبانی می‌کند.

کنترل‌کننده دامنه در دسترس نیست

در یک محیط متصل به دامنه، NLA به دسترسی به یک کنترل‌کننده دامنه برای اعتبارسنجی اعتبارنامه‌ها و حفظ کانال امن ماشین وابسته است. اگر کنترل‌کننده دامنه آفلاین باشد، مسدود شده توسط یک فایروال یا اینکه یک مشکل اعتماد وجود دارد، احراز هویت NLA ممکن است با وجود اینکه خود سرور فعال است، شکست بخورد. شما اغلب خطاهایی را مشاهده خواهید کرد که به اتصال کنترل‌کننده دامنه یا پیام‌های عمومی "خطای احراز هویت رخ داده است" اشاره دارند.

عدم تطابق پچ CredSSP

با شروع از به‌روزرسانی‌های "رفع اشکال رمزنگاری اوراکل" در سال ۲۰۱۸، CredSSP در مورد نحوه حفاظت از اعتبارنامه‌ها سخت‌گیرتر شد. اگر یک کلاینت به‌روزرسانی را داشته باشد اما سرور نداشته باشد (یا برعکس)، ممکن است دو نقطه انتهایی در مورد یک پیکربندی امن توافق نکنند. این عدم تطابق می‌تواند خطاهای "رفع اشکال رمزنگاری اوراکل CredSSP" را ایجاد کند و ورود به NLA را تا زمانی که هر دو طرف وصله شوند یا سیاست گروه تنظیم شود، متوقف کند.

پیکربندی نادرست رمزگذاری TLS یا RDP

NLA به امنیت لایه انتقال (TLS) برای محافظت از تبادل اعتبارنامه‌ها تکیه دارد. اگر TLS 1.0/1.1 غیرفعال شود بدون اینکه TLS 1.2 به درستی فعال شود، یا اگر مجموعه‌های رمزنگاری ضعیف اعمال شوند، ممکن است دست دادن بین کلاینت و سرور قبل از اتمام NLA شکست بخورد. سخت‌افزار امنیتی سفارشی، حالت FIPS، یا گواهی‌نامه‌های پیکربندی نادرست می‌توانند NLA را مختل کنند، حتی اگر RDP استاندارد بدون NLA ممکن است تحت برخی شرایط هنوز کار کند.

تعارضات سیاست گروه یا رجیستری

اشیاء سیاست گروه (GPOها) و سیاست‌های امنیتی محلی نحوه رفتار RDP، CredSSP و رمزنگاری را کنترل می‌کنند. سیاست‌های متضاد یا بیش از حد سخت می‌توانند NLA را در سناریوهایی که مشتریان از آن پشتیبانی نمی‌کنند یا الگوریتم‌های سازگار با FIPS را که مشتریان شما نمی‌توانند استفاده کنند، الزامی کنند. تغییرات رجیستری برای SCHANNEL یا CredSSP می‌توانند ناهماهنگی‌های مشابهی را معرفی کنند که منجر به "عملکرد درخواست شده پشتیبانی نمی‌شود" و سایر خطاهای عمومی می‌شود.

پروفایل‌های کاربری یا اعتبارنامه‌های خراب شده

گاهی اوقات، مشکل به یک کاربر یا ماشین خاص محدود می‌شود. اعتبارنامه‌های کش شده خراب شده، یک عدم تطابق شناسه امنیتی (SID) یا یک فایل Default.rdp آسیب دیده می‌تواند بر احراز هویت NLA تأثیر بگذارد. در این موارد، ممکن است متوجه شوید که یک کاربر دیگر می‌تواند از همان دستگاه وارد شود، یا همان کاربر می‌تواند از یک کلاینت متفاوت وارد شود، اما نه هر دو به طور همزمان.

سناریوهای گروه کاری و غیر دامنه

NLA یک محیط را فرض می‌کند که در آن هویت‌های کاربر می‌توانند به‌طور قوی تأیید شوند، معمولاً از طریق Active Directory. در سیستم‌های گروه کاری، حساب‌های محلی باید به‌دقت پیکربندی شوند و باید اجازه ورود از طریق Remote Desktop را داشته باشند. اگر NLA اجباری شود اما هیچ کنترل‌کننده دامنه‌ای در دسترس نباشد، یا تنظیمات حساب محلی نادرست باشد، احتمالاً خطاهای مرتبط با NLA را مشاهده خواهید کرد حتی اگر سرور قابل دسترسی به نظر برسد.

چگونه خطاهای NLA را در RDP برطرف کنیم؟

از مراحل زیر به ترتیب استفاده کنید، از کمترین تهاجمی تا بیشترین تهاجمی. این رویکرد به بازگرداندن دسترسی در حالی که امنیت را در هر جا که ممکن است حفظ می‌کند، کمک می‌کند.

• تأیید پشتیبانی NLA در کلاینت و سرور
• بررسی اتصال به کنترل‌کننده دامنه (در صورت لزوم)
• سطح و سیاست‌های پچ CredSSP را هم‌راستا کنید
• فعال‌سازی و اعتبارسنجی پروتکل‌های TLS مورد نیاز
• بررسی و تنظیم سیاست گروه
• NLA را به طور موقت غیرفعال کنید تا دسترسی را بازیابی کنید
• تنظیم مجدد کلاینت RDP و پیکربندی شبکه

تأیید پشتیبانی NLA در کلاینت و سرور

اولاً، اطمینان حاصل کنید که هر دو نقطه پایانی قادر به NLA هستند.

• اجرا winver بر روی هر دو کلاینت و سرور برای تأیید اینکه آنها ویندوز ویستا / ویندوز سرور ۲۰۰۸ یا جدیدتر هستند.
• اطمینان حاصل کنید که آخرین به‌روزرسانی‌های کلاینت Remote Desktop نصب شده‌اند (از طریق Windows Update یا برنامه Microsoft Remote Desktop در پلتفرم‌های غیر ویندوز).
• اگر از کلاینت‌های RDP شخص ثالث استفاده می‌کنید، تأیید کنید که پشتیبانی NLA به‌طور صریح در تنظیمات کلاینت مستند و فعال شده است.

اگر هیچ‌یک از طرفین از NLA پشتیبانی نمی‌کند، برنامه‌ریزی کنید که آن مؤلفه را ارتقا دهید یا جایگزین کنید تا امنیت به‌طور کلی تضعیف نشود.

بررسی اتصال به کنترل‌کننده دامنه (در صورت لزوم)

در ماشین‌های متصل به دامنه، قبل از تغییر تنظیمات RDP، اتصال دامنه را تأیید کنید.

• تست قابلیت دسترسی پایه شبکه به کنترل‌کننده‌های دامنه (به عنوان مثال، پینگ dc01.yourdomain.com ).
• استفاده nltest /dsgetdc:yourdomain.com برای تأیید اینکه مشتری می‌تواند یک کنترل‌کننده دامنه را پیدا کند.
• در PowerShell، اجرا کنید آزمایش-کانال امن کامپیوتر برای بررسی کانال امن ماشین به دامنه.

اگر کانال امن شکسته شده است، آن را با تعمیر کنید:

تست-کانال امن کامپیوتر - تعمیر - اعتبارنامه (گرفتن-اعتبارنامه)

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

سطح و سیاست‌های پچ CredSSP را هم‌راستا کنید

سپس تأیید کنید که هم کلاینت و هم سرور به‌روزرسانی‌های امنیتی فعلی، به‌ویژه آن‌هایی که مربوط به CredSSP هستند، را دارند.

• تمام به‌روزرسانی‌های مهم و امنیتی را بر روی هر دو نقطه پایانی نصب کنید.
• بررسی کنید که آیا از Group Policy برای پیکربندی "رفع مشکل رمزگذاری Oracle" استفاده شده است:
  پیکربندی کامپیوتر → الگوهای مدیریتی → سیستم → واگذاری اعتبارنامه .

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

فعال‌سازی و اعتبارسنجی پروتکل‌های TLS مورد نیاز

اطمینان حاصل کنید که TLS 1.2 پشتیبانی و فعال شده است، زیرا بسیاری از محیط‌ها اکنون نسخه‌های قدیمی‌تر TLS را غیرفعال می‌کنند.

در ویندوز سرور، تنظیمات SCHANNEL را در رجیستری زیر بررسی کنید:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

برای پشتیبانی از کلاینت TLS 1.2، تأیید کنید که:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client

"Enabled"=dword:00000001

شما ممکن است نیاز داشته باشید که کلیدهای TLS 1.2 سمت سرور را نیز تنظیم کنید و سپس سرور یا حداقل خدمات Remote Desktop را دوباره راه‌اندازی کنید. همچنین تأیید کنید که گواهی RDP معتبر، مورد اعتماد و از امضاهای منسوخ استفاده نمی‌کند.

بررسی و تنظیم سیاست گروه

سیاست گروه معمولاً جایی است که اجرای NLA و پیکربندی امنیت RDP تعریف می‌شود.

باز gpedit.msc (یا شیء معادل GPMC) و به:

پیکربندی کامپیوتر → تنظیمات ویندوز → تنظیمات امنیتی → سیاست‌های محلی → گزینه‌های امنیتی

به‌ویژه بررسی کنید:

• برای اتصالات از راه دور، نیاز به احراز هویت کاربر با استفاده از احراز هویت سطح شبکه است.
• هر سیاستی که الگوریتم‌های سازگار با FIPS را تحمیل کند یا انواع رمزنگاری را محدود کند

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

NLA را به طور موقت غیرفعال کنید تا دسترسی را بازیابی کنید

اگر تمام دسترسی از راه دور به یک سرور حیاتی را از دست داده‌اید، خاموش کردن موقت NLA می‌تواند آخرین راه‌حل ضروری باشد.

شما می‌توانید:

• به حالت ایمن با شبکه راه‌اندازی شوید و تنظیمات Remote Desktop را تنظیم کنید، یا
• با استفاده از رسانه بازیابی بوت کنید، هسته سیستم را بارگذاری کنید و کلید RDP-Tcp را در رجیستری ویرایش کنید.

تنظیمات:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

"UserAuthentication"=dword:00000000

این گزینه NLA را برای شنونده RDP غیرفعال می‌کند. پس از اینکه دسترسی خود را بازیابی کردید، علت اصلی (اتصال دامنه، وصله‌ها، TLS یا سیاست‌ها) را برطرف کنید، سپس با بازگرداندن مقدار به ۱، NLA را دوباره فعال کنید. غیرفعال نگه‌داشتن NLA در بلندمدت به‌طور قابل‌توجهی خطر حملات brute-force و سوءاستفاده را افزایش می‌دهد.

تنظیم مجدد کلاینت RDP و پیکربندی شبکه

اگر مشکلات NLA به نظر می‌رسد که به یک دستگاه کلاینت خاص محدود است، قبل از تغییر سیاست سرور، یک بازنشانی محلی انجام دهید.

• حذف کنید Default.rdp فایل در %userprofile%\Documents برای پاک کردن تنظیمات کش شده.
• هر اعتبار ذخیره شده را در مدیریت اعتبار ویندوز حذف و دوباره اضافه کنید.
• تأیید کنید که TCP 3389 (یا پورت RDP سفارشی شما) از طریق فایروال‌های محلی و دستگاه‌های شبکه میانی مجاز است.
• از یک مشتری دیگر در همان شبکه تست کنید تا مشخص شود که آیا مشکل خاص مشتری است یا بیشتر جهانی.

این مرحله بهداشتی ساده اغلب مشکلات مربوط به اعتبارنامه‌های کش‌شده خراب یا گزینه‌های نمایش و امنیت نادرست در کلاینت RDP را حل می‌کند.

بهترین روش‌ها برای جلوگیری از خطاهای NLA در آینده چیست؟

پس از رفع مشکل فوری، محیط خود را تقویت کنید تا NLA همواره ایمن و قابل اعتماد باقی بماند.

• سیستم‌های عامل و کلاینت‌های RDP را به‌روز نگه‌دارید
• نظارت بر سلامت دامنه و هویت
• سیاست‌های RDP و NLA را از طریق GPO استاندارد کنید
• فعال‌سازی ثبت رویداد و نظارت بر امنیت
• RDP را در پشت نقاط ورودی امن ایزوله کنید

سیستم‌های عامل و کلاینت‌های RDP را به‌روز نگه‌دارید

یک ریتم استاندارد برای پچ کردن سرورها و نقاط پایانی حفظ کنید. بر روی نسخه‌های پشتیبانی شده ویندوز هماهنگ شوید و از باقی گذاشتن مشتریان قدیمی و بدون پچ در تولید خودداری کنید. خطوط پایه به‌روزرسانی مداوم، عدم تطابق‌های CredSSP و TLS را که معمولاً NLA را مختل می‌کند، کاهش می‌دهد.

نظارت بر سلامت دامنه و هویت

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

سیاست‌های RDP و NLA را از طریق GPO استاندارد کنید

تعریف کنید RDP رمزنگاری، اجرای NLA و سیاست‌های CredSSP به‌طور مرکزی. آن‌ها را بر اساس نقش‌های دستگاه، مانند سرورهای تولید در مقابل آزمایشگاه‌های تست، به ازای OU یا گروه امنیتی اعمال کنید. استانداردسازی انحراف پیکربندی را کاهش می‌دهد و در زمان بروز مشکلات، عیب‌یابی را بسیار سریع‌تر می‌کند.

فعال‌سازی ثبت رویداد و نظارت بر امنیت

نظارت بر Event Viewer در میزبان‌های RDP، به‌ویژه:

• گزارش‌های ویندوز → امنیت
• گزارش‌های ویندوز → سیستم
• گزارش‌های برنامه‌ها و خدمات → مایکروسافت → ویندوز → TerminalServices

تکرار ورودهای ناموفق، خطاهای handshake TLS یا خطاهای CredSSP را با SIEM خود همبسته کنید، در صورت امکان. این نظارت به تمایز بین مشکلات پیکربندی و حملات فعال کمک می‌کند.

RDP را در پشت نقاط ورودی امن ایزوله کنید

حتی با NLA، قرار دادن RDP به طور مستقیم در معرض اینترنت ریسک بالایی دارد. RDP را پشت یک دروازه امن، VPN یا پروکسی به سبک ZTNA قرار دهید. در صورت امکان MFA اضافه کنید. ابزارهایی مانند TSplus Advanced Security می‌توانند محدودیت‌های بیشتری را در مورد اینکه کجا، چه زمانی و چگونه کاربران متصل می‌شوند، اعمال کنند و احتمال وقوع حوادث مرتبط با NLA را که به سرور می‌رسند، کاهش دهند.

امنیت RDP را با TSplus Advanced Security تقویت کنید

NLA تنها بخشی از معادله ریسک RDP را حل می‌کند. TSplus Advanced Security لایه‌های اضافی دفاعی را در اطراف سرورهای ویندوز و دسکتاپ‌های راه دور شما اضافه می‌کند بدون پیچیدگی‌های انبوه VDI. ویژگی‌هایی مانند حفاظت دینامیک در برابر حملات brute-force، محدودیت‌های مبتنی بر IP و کشور، سیاست‌های ساعات کاری و قوانین دسترسی در سطح برنامه به حفظ حمله‌کنندگان در خارج کمک می‌کند در حالی که کاربران قانونی به کار خود ادامه می‌دهند.

برای سازمان‌هایی که به RDP وابسته هستند اما می‌خواهند کنترل‌های امنیتی قوی‌تر و ساده‌تری داشته باشند، ترکیب NLA با TSplus Advanced Security راهی عملی برای تقویت دسترسی از راه دور و کاهش بار کاری پاسخ به حوادث ارائه می‌دهد.

نتیجه

خطاهای NLA در RDP ناامیدکننده هستند، به ویژه زمانی که بدون تغییرات واضح در محیط ظاهر می‌شوند. در واقع، آن‌ها تقریباً همیشه به مشکلات خاصی در نسخه‌های سیستم‌عامل، اتصال دامنه، وصله CredSSP، پیکربندی TLS یا سیاست‌های امنیتی اشاره دارند. با کار از طریق یک چک‌لیست ساختاریافته، می‌توانید دسترسی ایمن را بدون متوسل شدن به راه‌حل‌های دائمی پرخطر بازیابی کنید.

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