NLA грешки в RDP: Причини, решения и най-добри практики

Въведение

Аутентификация на ниво мрежа (NLA) е основен контрол за сигурност за протокола за отдалечен работен плот, който спира неавтентифицирани потребители преди да бъде създадена пълна сесия. Когато NLA не успее, ИТ екипите се сблъскват с блокирани входове, неясни съобщения за грешки и разочаровани крайни потребители, които не могат да достигнат критични сървъри. Това ръководство обяснява какво е NLA, защо се появяват тези грешки и как систематично да отстранявате и решавате проблеми с NLA, без да отслабвате вашата сигурност на RDP.

Какво е NLA в RDP?

Аутентификация на ниво мрежа е подобрение на сигурността на RDP, въведено с Windows Vista и Windows Server 2008. Вместо да изгражда пълната сесия на отдалечен работен плот и след това да иска удостоверения, 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 криптиране
• Конфликти на груповата политика или регистъра
• Повредени потребителски профили или удостоверения
• Работна група и сценарии без домейн

Несъвместимост на клиентската или сървърната операционна система

По-старите версии на Windows или клиенти на трети страни за RDP може да не поддържат напълно NLA или съвременното поведение на CredSSP. Например, наследствените версии на Windows XP или ранните версии на Vista не могат да се свържат с NLA-наложени сървъри без специфични актуализации. Дори на поддържани системи, остарелите бинарни файлове на RDP клиента могат да причинят грешки "вашият компютър не поддържа NLA", въпреки че операционната система номинално го поддържа.

Контролер на домейн недостъпен

В среда, присъединена към домейн, NLA зависи от достигането на контролер на домейн, за да валидира удостоверенията и да поддържа защитения канал на машината. Ако контролерът на домейн е офлайн, блокиран от един файъруол или има проблем с доверието, NLA удостоверяването може да се провали, въпреки че самият сървър е активен. Често ще виждате грешки, споменаващи свързаност с домейн контролер или общи съобщения за "възникнала грешка при удостоверяване".

Несъответствие на CredSSP пача

Започвайки с актуализациите от 2018 г. "Отстраняване на криптиране на Oracle", CredSSP стана по-строг относно начина, по който се защитават удостоверенията. Ако клиентът има актуализацията, но сървърът не (или обратно), двете крайни точки може да не се съгласят относно сигурната конфигурация. Тази несъответствие може да генерира грешки "отстраняване на криптиране на Oracle на 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 Patch
• Активирайте и валидирайте необходимите TLS протоколи
• Прегледайте и коригирайте груповата политика
• Временно деактивирайте NLA, за да възстановите достъпа
• Нулиране на конфигурацията на RDP клиента и мрежата

Потвърдете NLA поддръжка на клиент и сървър

Първо, уверете се, че и двете крайни точки са способни на NLA.

• Стартирай winver и на клиента, и на сървъра, за да потвърдите, че са Windows Vista / Windows Server 2008 или по-късно.
• Уверете се, че последните актуализации на клиента за отдалечен работен плот са инсталирани (чрез Windows Update или приложението Microsoft Remote Desktop на платформи, различни от Windows).
• Ако използвате RDP клиенти на трети страни, уверете се, че поддръжката на NLA е изрично документирана и активирана в настройките на клиента.

Ако нито една от страните не поддържа NLA, планирайте да надстроите или замените този компонент, вместо да отслабвате сигурността глобално.

Проверете свързаността с контролера на домейна (ако е приложимо)

На компютри, присъединени към домейн, валидирайте свързаността с домейна преди да променяте настройките на RDP.

• Тествайте основната мрежова достъпност до контролерите на домейна (например, пинг dc01.yourdomain.com ).
• Използвайте nltest /dsgetdc:yourdomain.com да потвърди, че клиентът може да намери контролер на домейн.
• В PowerShell, изпълнете Тест-КомпютърСигуренКанал да провери сигурния канал на машината към домейна.

Ако защитеният канал е нарушен, поправете го с:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

След ремонта рестартирайте машината, ако бъде подканена, след това тествайте NLA отново. Решете проблеми с неправилна конфигурация на DNS, правила на защитната стена или проблеми с VPN, които могат периодично да блокират достъпа до домейна.

Синхронизиране на нива и политики на CredSSP Patch

След това потвърдете, че както клиентът, така и сървърът имат актуални актуализации за сигурност, особено тези, свързани с CredSSP.

• Инсталирайте всички важни и защитни актуализации на двете крайни точки.
• Проверете дали е използвана групова политика за конфигуриране на „Отстраняване на Oracle за криптиране“ под:
  Конфигурация на компютъра → Административни шаблони → Система → Делегиране на удостоверения .

На временно основание в тестова среда можете да зададете политиката на по-позволителна стойност, за да потвърдите, че строга настройка причинява неуспеха. В продукция дългосрочното решение трябва да бъде да приведете всички системи до последователно ниво на корекции, вместо постоянно да разхлабвате политиката.

Активирайте и валидирайте необходимите TLS протоколи

Уверете се, че TLS 1.2 е поддържан и активиран, тъй като много среди вече деактивират по-старите версии на TLS.

На Windows Server проверете настройките на 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 от страна на сървъра, а след това да рестартирате сървъра или поне Услугите за отдалечен работен плот. Също така потвърдете, че RDP сертификатът е валиден, доверен и не използва остарели подписи.

Прегледайте и коригирайте груповата политика

Груповата политика често е мястото, където се определят прилагането на NLA и конфигурацията за сигурност на RDP.

Отворено gpedit.msc (или еквивалентният GPMC обект) и навигирайте до:

Конфигурация на компютъра → Настройки на Windows → Настройки за сигурност → Локални политики → Опции за сигурност

Проверете по-специално:

• Изисквайте удостоверяване на потребителя за дистанционни връзки, използвайки удостоверяване на ниво мрежа.
• Всякакви политики, които налагат алгоритми, съвместими с 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, като възстановите стойността на 1. Дългосрочното деактивиране на NLA значително увеличава уязвимостта към опити за брутфорс и експлоатация.

Нулиране на конфигурацията на RDP клиента и мрежата

Ако проблемите с NLA изглеждат изолирани до конкретно клиентско устройство, извършете локален нулиране преди да промените политиката на сървъра.

• Изтрийте Default.rdp файл в %userprofile%\Documents за да изчистите кешираните настройки.
• Премахнете и добавете отново всички запазени идентификационни данни в Windows Credential Manager.
• Потвърдете, че TCP 3389 (или вашият персонализиран RDP порт) е разрешен през локалните защитни стени и междинните мрежови устройства.
• Тест от друг клиент в същата мрежа, за да се определи дали проблемът е специфичен за клиента или по-глобален.

Тази проста хигиенна стъпка често решава проблеми с повредени кеширани удостоверения или неправилно приложени опции за показване и сигурност в RDP клиента.

Какви са най-добрите практики за избягване на грешки NLA в бъдеще?

След като непосредственият проблем бъде решен, укрепете средата си, така че NLA да остане както сигурна, така и надеждна.

• Поддържайте операционните системи и RDP клиенти актуални
• Наблюдение на домейна и здравето на идентичността
• Стандартизиране на RDP и NLA политики чрез GPO
• Активирайте регистрационния дневник на събития и мониторинг на сигурността
• Изолирайте RDP зад сигурни входни точки

Поддържайте операционните системи и RDP клиенти актуални

Поддържайте стандартен ритъм на актуализации за сървъри и крайни точки. Съгласувайте поддържаните версии на Windows и избягвайте да оставяте по-стари, неактуализирани клиенти в продукция. Последователните базови линии за актуализации намаляват несъответствията между CredSSP и TLS, които обикновено нарушават NLA.

Наблюдение на домейна и здравето на идентичността

За системи, присъединени към домейн, третирайте здравето на домейн контролера като част от вашия RDP стек. Използвайте инструменти като dcdiag , репадмин и журналите на контролера на домейна, за да уловят проблеми с репликацията или DNS рано. Прекъсващите проблеми с домейна могат да се проявят като проблеми с RDP и NLA много преди потребителите да забележат други симптоми.

Стандартизиране на RDP и NLA политики чрез GPO

Определете вашето RDP шифроване, прилагане на NLA и политики на CredSSP централизирано. Прилагайте ги по OU или група за сигурност в зависимост от ролите на устройствата, като производствени сървъри срещу тестови лаборатории. Стандартизацията намалява отклонението в конфигурацията и прави отстраняването на проблеми много по-бързо, когато възникнат проблеми.

Активирайте регистрационния дневник на събития и мониторинг на сигурността

Наблюдавайте Event Viewer на RDP хостове, особено:

• Windows Logs → Сигурност
• Windows Logs → Система
• Приложения и услуги Логове → Майкрософт → Уиндоус → TerminalServices

Корелирайте повторни неуспешни влизания, неуспехи при TLS ръкостискане или грешки в CredSSP с вашия SIEM, където е възможно. Това наблюдение помага да се разграничат проблемите с конфигурацията от активните атаки.

Изолирайте RDP зад сигурни входни точки

Дори с NLA, излагането на RDP директно в интернет е с висок риск. Поставете RDP зад сигурен шлюз, VPN или прокси в стил ZTNA. Добавете MFA, където е възможно. Инструменти като TSplus Advanced Security могат допълнително да ограничат къде, кога и как потребителите се свързват, намалявайки вероятността инциденти, свързани с NLA, да достигнат до сървъра изобщо.

Укрепете сигурността на RDP с TSplus Advanced Security

NLA решава само част от уравнението на риска с RDP. TSplus Advanced Security добавя допълнителни слоеве на защита около вашите Windows сървъри и отдалечени работни станции без сложността на пълноценни VDI стекове. Функции като динамична защита от брутфорс, ограничения на базата на IP и държава, политики за работно време и правила за достъп на ниво приложение помагат да се предотврати достъпът на нападателите, докато легитимните потребители остават продуктивни.

За организации, които разчитат на RDP, но искат по-силни и по-прости мерки за сигурност, комбинирането на NLA с TSplus Advanced Security предлага практичен начин за укрепване на отдалечения достъп и намаляване на работното натоварване при реагиране на инциденти.

Заключение

Грешките NLA в RDP са разочароващи, особено когато се появяват без очевидни промени в средата. В действителност, те почти винаги сочат към конкретни проблеми в версиите на ОС, свързаността с домейна, коригирането на CredSSP, конфигурацията на TLS или политиките за сигурност. Чрез работа с организиран списък за проверка можете да възстановите сигурен достъп, без да прибягвате до рискови постоянни решения.

Третирайте NLA като основен контрол на сигурността, а не като опционална функция. Дръжте го активиран, валидиран и наблюдаван като част от общата ви позиция за отдалечен достъп. Когато наистина трябва да го деактивирате, ограничете обхвата на въздействие, решете основния проблем и включете отново NLA възможно най-скоро.