Посочената функция не се поддържа. Възникна грешка при удостоверяване

Сигурността и скоростта на сървърите винаги са били проблем и всяка година тяхното значение само нараства. Поради това Microsoft премина от оригиналния модел за удостоверяване от страна на сървъра към удостоверяване на ниво мрежа.

Каква е разликата между тези модели?
Преди това, когато се свързваше с терминални услуги, потребителят създаваше сесия със сървъра, чрез която последният зареждаше екран за въвеждане на идентификационни данни за потребителя. Този метод изразходва ресурси на сървъра, дори преди потребителят да е потвърдил своята легитимност, позволявайки на нелегален потребител напълно да претовари ресурсите на сървъра с множество заявки за влизане. Сървър, който не може да обработи тези заявки, отказва заявки на законни потребители (DoS атака).

Удостоверяването на ниво мрежа (NLA) принуждава потребителя да въведе идентификационни данни в диалогов прозорец от страна на клиента. По подразбиране, ако няма сертификат на ниво мрежа за проверка на удостоверяване от страна на клиента, тогава сървърът няма да позволи връзката и тя няма да се случи. NLA изисква от клиентския компютър да предостави своите идентификационни данни за удостоверяване, преди да създаде сесия със сървъра. Този процес се нарича още удостоверяване отпред.

NLA беше въведен още в RDP 6.0 и първоначално се поддържаше Windows Vista. От версия RDP 6.1 - поддържа се от сървъри, работещи с операционната система Windows сървър 2008 и по-нови, а клиентската поддръжка се предоставя за операционни системи Windows XP SP3 (трябва да активирате новия доставчик на защита в системния регистър) и по-нови. Методът използва доставчика на сигурност CredSSP (Credential Security Support Provider). Когато използвате клиент за отдалечен работен плот за друга операционна система, трябва да разберете за неговата поддръжка на NLA.

• Не изисква значителни сървърни ресурси.
• Допълнително ниво за защита срещу DoS атаки.
• Ускорява процеса на посредничество между клиент и сървър.
• Позволява ви да разширите технологията на NT "single login" за работа с терминален сървър.

• Други доставчици на сигурност не се поддържат.
• Не се поддържа от клиентски версии, по-ниски от Windows XP SP3 и сървърни версии, по-ниски от Windows Server 2008.
• Задължително ръчна настройкарегистър на всеки Windows клиент XP SP3.
• Като всяка схема за „едно влизане“, тя е уязвима за кражба на „ключовете на цялата крепост“.
• Няма опция за използване на функцията „Изискване на промяна на паролата при следващо влизане“.

Отворете редактора на системния регистър.

Разклонение HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Отворете параметъра Пакети за сигурност и потърсете думата tspkg там. Ако не е там, добавете го към съществуващите параметри.

Клон HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders

Отворете параметъра SecurityProviders и добавете credssp.dll към съществуващите доставчици, ако липсва.

Затворете редактора на системния регистър.

Сега трябва да рестартирате. Ако това не е направено, компютърът ще ни поиска потребителско име и парола, но вместо отдалечения работен плот ще отговори със следното:

Това е всичко.

Сървърните администратори на Windows 2008 могат да срещнат следния проблем:

Свързването чрез rdp протокол към вашия любим сървър от Windows XP SP3 станция е неуспешно със следната грешка:

Отдалеченият работен плот е деактивиран.

Отдалечен компютъризисква удостоверяване на ниво мрежа, което този компютърне поддържат. Свържете се с вашия системен администратор или техническа поддръжка за помощ.

И въпреки че обещаващият Win7 заплашва в крайна сметка да замени баба си WinXP, проблемът ще остане актуален още година-две.

Ето какво трябва да направите, за да активирате удостоверяването на мрежовия слой:

Отворете редактора на системния регистър.

Клон HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Отворете параметъра Пакети за сигурност и потърсете думата там tspkg. Ако не е там, добавете го към съществуващите параметри.

Клон HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders

Отворете параметъра Доставчици на сигурност и добавете към съществуващи доставчици credssp.dll, ако няма такъв.

Затворете редактора на системния регистър.

Сега трябва да рестартирате. Ако това не е направено, тогава когато се опитаме да се свържем, компютърът ще ни поиска потребителско име и парола, но вместо отдалечения работен плот ще отговори със следното:

Връзка с отдалечен работен плот

Грешка при удостоверяване (код 0x507)

Това е всичко.

След като инсталирах актуализацията KB4103718 на моя компютър с Windows 7, не мога да се свържа дистанционно към сървър, работещ под Windows Server 2012 R2 чрез RDP. След като посоча адреса на RDP сървъра в прозореца на клиента mstsc.exe и щракна върху „Свързване“, се появява грешката:

Връзка с отдалечен работен плот

Възникна грешка при удостоверяване.

Посочената функция не се поддържа.
Отдалечен компютър: име на компютър

След като деинсталирах актуализацията KB4103718 и рестартирах компютъра, RDP връзката започна да работи добре. Ако разбирам правилно, това е само временно решение, следващия месец ще пристигне нов пакет с кумулативна актуализация и грешката ще се върне? Можете ли да препоръчате нещо?

Отговор

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

Не сте сами в проблема си. Тази грешкаможе да се появи във всеки операционна система Windows или Windows Server (не само Windows 7). За потребители на английски Windows версии 10, когато се опитвате да се свържете с RDP/RDS сървър, подобна грешка изглежда така:

Възникна грешка при удостоверяване.

Исканата функция не се поддържа.

Отдалечен компютър: име на компютър

RDP грешката „Възникна грешка при удостоверяване“ може също да се появи при опит за стартиране на приложения на RemoteApp.

Защо се случва това? Факт е, че вашият компютър има най-новите актуализации за защита (издадени след май 2018 г.), които коригират сериозна уязвимост в протокола CredSSP (Credential Security Support Provider), използван за удостоверяване на RDP сървъри (CVE-2018-0886) (препоръчвам да прочетете статията). Въпреки това, от страната на RDP / RDS сървъра, към който се свързвате от вашия компютър, тези актуализации не са инсталирани и протоколът NLA (Удостоверяване на мрежово ниво) е активиран за RDP достъп. Протоколът NLA използва механизми CredSSP за предварително удостоверяване на потребителите чрез TLS/SSL или Kerberos. Вашият компютър, поради новите настройки за сигурност, въведени от инсталираната от вас актуализация, просто блокира връзката с отдалечен компютър, който използва уязвима версия на CredSSP.

Какво можете да направите, за да коригирате тази грешка и да се свържете с вашия RDP сървър?

1. Повечето правилноначин за решаване на проблема - инсталация последни актуализации Защита на Windowsна компютъра/сървъра, към който се свързвате чрез RDP;
2. Временен метод 1 . Можете да деактивирате удостоверяването на мрежово ниво (NLA) от страната на RDP сървъра (описано по-долу);
3. Временен метод 2 . Можете, от страна на клиента, да разрешите връзки към RDP сървъри с несигурна версия на CredSSP, както е описано в статията, свързана по-горе. За да направите това, трябва да промените ключа на системния регистър AllowEncryptionOracle(Команда REG ADD
   HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle /t REG_DWORD /d 2) или променете настройките местна политика Криптиране Oracle Remediation/ Коригиране на уязвимост на оракул за криптиране), задаване на стойността му = Уязвимост / Оставяне на уязвимост).

   Това е единственият начин за достъп до отдалечен сървър чрез RDP, ако нямате възможност да влезете в сървъра локално (чрез конзолата на ILO, виртуална машина, облачен интерфейс и др.). В този режим ще можете да се свържете с отдалечен сървър и да инсталирате актуализации за защита, като по този начин преминете към препоръчания метод 1. След като актуализирате сървъра, не забравяйте да деактивирате правилата или да върнете стойността на ключа AllowEncryptionOracle = 0: REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle /t REG_DWORD /d 0

Деактивиране на NLA за RDP в Windows

Ако NLA е активиран от страната на RDP сървъра, към който се свързвате, това означава, че CredSPP се използва за предварително удостоверяване на RDP потребителя. Можете да деактивирате удостоверяването на мрежово ниво в свойствата на системата в раздела Отдалечен достъп (Дистанционно) , като премахнете отметката от квадратчето „Разрешаване на връзка само от компютри, работещи с отдалечен работен плот с удостоверяване на мрежово ниво (препоръчително)“ (Windows 10 / Windows 8).

В Windows 7 тази опция се нарича по различен начин. В раздела Отдалечен достъптрябва да изберете опцията " Разрешаване на връзки от компютри, работещи с всяка версия на отдалечен работен плот (опасно)/ Разрешаване на връзки от компютри, работещи с всяка версия на отдалечен работен плот (по-малко защитена)".

Можете също да деактивирате удостоверяването на мрежово ниво (NLA) с помощта на локалния редактор групова политика - gpedit.msc(в Windows 10 Home може да се стартира редакторът на правилата gpedit.msc) или чрез конзолата за управление на правилата на домейна - GPMC.msc. За да направите това, отидете в раздела Компютърна конфигурация –> Административни шаблони –> КомпонентиWindows–> Услуги за отдалечен работен плот – Хост на сесия на отдалечен работен плот –> Сигурност(Компютърна конфигурация –> Административни шаблони –> Компоненти на Windows –> Услуги за отдалечен работен плот – Хост на сесия на отдалечен работен плот –> Сигурност), изключиполитика (Изискване на потребителско удостоверяване за отдалечени връзки чрез използване на удостоверяване на мрежово ниво).

Необходим и в политиката " Изисквайте специално ниво на сигурност за отдалечени RDP връзки» (Изискване на използване на специфичен защитен слой за отдалечени (RDP) връзки) изберете Защитен слой - RDP.

За да приложите новите настройки на RDP, трябва да актуализирате правилата (gpupdate /force) или да рестартирате компютъра. След това трябва успешно да се свържете със сървъра за отдалечен работен плот.