Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз мы с вами решили проблему «Произошла внутренняя ошибка RDP» при попытке входа на RDS ферму. Сегодня мы вновь столкнемся с трудностями авторизации на RDS ферме, ошибка звучит так «Код ошибки 0x907. Расширенный код ошибки 0x0». Ловить я ее начал буквально вчера 27 ноября, до этого все прекрасно работало. Из пострадавших, это операционные системы Windows 10 и Windows 11, а вот на Windows 8.1, все отрабатывало на ура. Давайте разбираться в чем дело.
Диагностика ошибки 0x907
Опишу немного инфраструктуру, есть большая RDS ферма из 50 хостов RDSH. Клиенты Windows 10/11, доменные и не доменные стали получать ошибки:
Код ошибки: 0x907. Расширенный код ошибки: 0x0
Ранее я встречал проблему с сертификатом, но не с кодом 0x907, тем более ничего не менялось в самой конфигурации.
Диагностика и устранение ошибки для Windows клиентов
Раз при подключении на прямую к хосту RDSH мы получаем ошибку сертификата, то дело вероятнее в нем. На своем клиентском месте, где вы пытаетесь подключаться, вы должны запустить реестр Windows. Вам нужно перейти в ветку:
Тут у вас будут папки с названиями всех серверов, к которым вы подключались по RDP. В каждой папке будет ключик CertHash, в котором будет отпечаток сертификата.
Можете спокойно удалить полностью папку Servers, это почистит историю подключений
сертификат выдан не имеющим доверия центром сертификации
С вероятностью 99% мой RDSH хост использует самоподписный сертификат, но раньше этого хватало для подключений, давайте посмотрим сертификат. В сведениях о сертификате, видно, что наша операционная система ему не доверяет, так как нет такого корневого центра сертификации, кто его выпустил и был доверенным. Если у вас один такой хост, то можете просто установить данный сертификат, но если как и у меня их 50, то тут выкручиваться нужно иначе.
Для установки сертификата нажмите соответствующую кнопку. В мастере импорта я всегда советую корневые сертификаты устанавливать в расположение локального компьютера.
Выбираем пункт «Переместить все сертификаты в следующее хранилище» и указываем доверенные корневые центры сертификации.
Завершаем импорт корневого сертификата
Теперь если посмотреть состав вашего сертификата, то ваша система ему доверяет.
Теперь подключение к текущему хосту будет без ошибок
Но так как у меня 50 RDSH хостов, то ставить от каждого сертификат в корневые это бред. Для этого вы можете поступать двумя методами:
- 1️⃣Выпустить сертификаты на все RDSH хосты из вашего внутреннего Active Directory CA, если он есть, не все его устанавливают
- 2️⃣Заказать внешний Wildcard сертификат на домен от внешнего CA, что проще на мой взгляд
У меня уже есть такой сертификат в формате PFX. Задача у нас такая, нам нужно на всех участниках RDS фермы поменять самоподписный сертификат на новый. Алгоритм тут такой:
- 1️⃣Вы устанавливаете на нужные хосты PFX сертификат в локальное хранилище компьютера
- 2️⃣Проверяете текущий отпечаток сертификата, что используется для RDP сессий
- 3️⃣Подменяете сертификат на новый
- 4️⃣Проверяете, что теперь используется новый сертификат
Установка PFX архива дело тривиальное
В результате у вас в контейнере личное, будет ваш сертификат.
Чтобы массово установить сертификат на большое количество серверов, можете воспользоваться моим кодом:
# Задаем переменные $sourceCert=»\TS102.pyatilistnik.orgTemp
ew.pfx» #Тут лежит pfx сертификат $certPassword=ConvertTo-SecureString «1234436» -AsPlainText -Force #Пароль для доступа к сертификату $servers=Get-Content «c:Temp erm.txt» #Файл со списком серверов
Запустите теперь PowerShell ISE в режиме администратора. Введите команду, чтобы посмотреть текущие настройки сертификата для RDP.
Get-WmiObject «Win32_TSGeneralSetting» -Namespace rootcimv2 erminalservices -Filter «TerminalName=’RDP-tcp'»
Нас будет интересовать поле SSLCertificateSHA1Hash, тут будет отпечаток самоподписного сертификата.
Теперь выясните отпечаток вашего Wildcard сертификата. После этого выполните команду.
Теперь у вас будет все отлично, с подключением по RDP к данному участнику RDS фермы и ошибка 0x907 пропадет.
Смена клиента RDP в Windows
В качестве обходного варианта, если вы не хотите заморачиваться с сертификатами, вы можете просто выбрать другие RDP клиенты, например:
Диагностика и устранение ошибки для MacOS клиентов
Пользователи Windows не одиноки, ошибку 0x907 вы можете встретить и в MacOS. После обновления RD Client до 10.3.0 так же стала отображаться ошибка 0x907, когда я хочу подключиться по RDP. На предыдущей версии RD Client все работало.
Как я и написал все началось с версии 10.3.0. Тут вы можете либо откатиться на предыдущую версию или поставить более свежую бетта версию. Я за второй вариант. Перейдите по ссылке:
Как видите уже есть версия Version 10.8.0 (2032). Установите ее и будет вам счастье.
На этом у меня все. Надеюсь, что вы смогли подключиться и продолжить работу. С вами был Иван Сёмин, автор и создатель IT портала Pyatilistnik.org.
Добрый день! Уважаемые читатели и гости компьютерного блога pyatilistnik.org. В последнее время я очень часто пишу, об ошибках которые встречаю в работе подключения к терминальному серверу или фермам RDS. Технология отличная, но как водится у Microsoft, имеет ряд сложностей. Сегодня я хочу с вами поделиться, каким образом решается ошибка при попытке пользователем подключиться к удаленному серверу для повседневной работы и звучит она вот так «Не удается установить подключение, так как проверка подлинности не включена, а удаленный компьютер требует, чтобы проверка подлинности для подключения была включена». Ниже будет описан метод моего решения.
Как выглядит ошибка подключения
Клиентский компьютер работает на операционной системе Windows 10 1709, терминальная ферма собрана из Windows Server 2012 R2, выступающих в роли хостов для подключения, в качестве посредников подключения (Connection Broker) выступают два сетевых балансировщика Kemp LoadMaster. И все как обычно, вчера работало, сегодня нет.
Варианты устранения проблемы с подключением по RDP
можно сделать вывод, что порт 3389 отвечает и его не нужно проверять с помощью Telnet. Далее алгоритм такой:
nslookup имя вашего терминального сервера
Как видим имя ts4.pyatilistnik.org разрезолвилось в два ip адреса, и применив команду ping мы видим, что сервер отвечает и его TTL 64, что говорит, что в роли Connection Broker выступает, что-то на операционной системе Linux. Проверьте по записям, правильно ли разрешается имя, в нужные ли ip адреса.
Как я и писал выше в моем случае в роли посредником по подключению выступают две сетевые железки Kemp LoadMaster. Заходим в веб интерфейс, переходим в пункт «View/Modify Services». В данном пункте будут описаны правила, которые обрабатывает Kemp LoadMaster. Вижу, что у меня есть правило TS4. В столбце Real Servers я вижу на какие сервера оно применяется. Тут логика какая, создается виртуальный интерфейс отвечающий по нужному порту, в данном случае 3389, и идет форвардин на список Real Servers по разным критериям, коих у Kemp много.
Проверяем список Real Servers на соответствие актуальности. В моем случае выяснилось, что один из ip адресов был передан другому серверу, так как его предшественника вывели из эксплуатации, а так как на нем не было развернуто служб удаленных рабочих столов, то у меня и валилась ошибка «Не удается установить подключение, так как проверка подлинности не включена, а удаленный компьютер требует, чтобы проверка подлинности для подключения была включена».
Редактируем правило, через кнопку Modify. Находим в списке IP Address нужный вам сервер и выключаем/Удаляем его соответствующей кнопкой.
Посмотреть список шаблонов на Kemp LoadMaster можно на вкладке Manage Template, они подгружаются сюда отдельно с официального сайта
После этих манипуляций ошибка ушла.
Для этого зайдите в свойства системы, на вкладке «Удаленный доступ» проверьте наличие галки:
NLA: Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети
Такая галка, запрещает старым клиентам служб удаленных рабочих столов производить подключение, актуально для Windows XP или не обновленных Windows 7, если у вас есть такие клиенты, то либо их обновите, либо снимите галку.
Так же в такой ситуации, когда был конфликт в версиях RDP клиента и вам отвечает не Session Host являющийся членом фермы, а как в моем случае левый сервер, то выскакивала ошибка: Подключение было разорвано, поскольку был получен непредусмотренный сертификат проверки подлинности сервера от удаленного компьютера. Повторите попытку подключения. Если проблема сохранится, обратитесь к владельцу удаленного компьютера или сетевому администратору
PS. Советую сделать на каждом сервере, что входит в состав терминальной фермы команду RSOP в командной строке, чтобы понять какие групповые политики прилетают и посмотрите, что у вас там
Как отключить NLA (Network Level Authentication)
Если у вас еще много не обновленных клиентов со старыми версиями RDP, то можете отключить пока NLA: Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети. Либо вручную, как я показывал, выше, но правильнее это сделать централизованно.
- На Connection Brokers
- Через групповую политику (Конфигурация компьютераПолитикиАдминистративные шаблоныКомпоненты WindowsСлужбы удаленных рабочих столовУзел сеансов удаленных рабочих столовБезопасность. Политика «Требовать проверку подлинности на уровне сети для удаленных подключений»)
- Через реестр Windows и политику
- Понизить требование к шифрованию.
На посреднике к подключению, зайдите в свойства коллекции и на вкладке безопасности снимите соответствующую галку.
Если захотите воспользоваться реестром Windows, а потом раскидать ключик, через тужу политику. то вам нужна ветка HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp. В ней найдите ключ SecurityLayer и поставьте ему значение 0. Это отключит NLA (Network Level Authentication).
Обновление 28. 2022
Еще данная ошибка может возникать из-за самоподписного сертификата, который нужно добавить либо в доверенные центры сертификации, или же подменить на доверенный. Это я выяснил при ошибке 0x907, там я так же мог попасть на свою RDS ферму.
Уверен, что вы смогли устранить ошибки: Подключение было разорвано, поскольку был получен непредусмотренный сертификат проверки подлинности сервера от удаленного компьютера. Повторите попытку подключения. Если проблема сохранится, обратитесь к владельцу удаленного компьютера или сетевому администратору и «Не удается установить подключение».
Если вам известны еще какие-либо методы решения, то просьба написать о них в комментариях.
Как выглядит ошибка credssp
An authentication error has occurred. The function requested is not supported. Remote computer name. This coild be to CredSSP encryption oracle remediation.
Ну и конечно в русском исполнении:
Произошла ошибка при проверке подлинности. Указанная функция не поддерживается. Удаленный компьютер имя. Причиной ошибки может быть исправление шифрования CredSSP
Получается двоякая ситуация, что RDP как бы работает, но вот по какой-то причине ваши учетные данные на принимающей стороне не соответствуют, каким-то критериям, давайте разбираться, что это за зверь CredSSP.
Назначение CredSSP
Что такое CredSSP — это Win32 API, используемый системами Microsoft Windows для выполнения различных операций, связанных с безопасностью, таких как аутентификация. SSPI функционирует, как общий интерфейс для нескольких поставщиков поддержки безопасности (SSP). Поставщик поддержки безопасности — это библиотека динамической компоновки (DLL), которая делает один или несколько пакетов безопасности доступными для приложений.
CredSSP позволяет приложению делегировать учетные данные пользователя от клиента целевому серверу для удаленной аутентификации. CredSSP предоставляет зашифрованный канал протокола безопасности транспортного уровня . Клиент проходит проверку подлинности по зашифрованному каналу с использованием протокола SPNEGO (Simple and Protected Negotiate) с Microsoft Kerberos или Microsoft NTLM.
После проверки подлинности клиента и сервера клиент передает учетные данные пользователя на сервер. Учетные данные дважды шифруются с использованием ключей сеанса SPNEGO и TLS. CredSSP поддерживает вход в систему на основе пароля, а также вход в систему с использованием смарт-карт на основе X.509 и PKINIT.
Подробнее на Microsoft https://docs.microsoft.com/en-us/windows/desktop/secauthn/credential-security-support-provider
Следующие поставщики общих служб устанавливаются вместе с Windows:
- NTLM (Представлено в Windows NT 3.51 ) (msv1_0.dll) — обеспечивает проверку подлинности NTLM с запросом/ответом для клиент-серверных доменов до Windows 2000 и для не доменной аутентификации (SMB /CIFS).
- Kerberos (Представлен в Windows 2000 и обновлен в Windows Vista для поддержки AES ) (kerberos.dll). Предпочтителен для взаимной аутентификации клиент-серверного домена в Windows 2000 и более поздних версиях.
- Согласование (введено в Windows 2000) (secur32.dll) — выбирает Kerberos и, если не доступно, протокол NTLM. SSP обеспечивает возможность единого входа , иногда называемую встроенной аутентификацией Windows (особенно в контексте IIS). В Windows 7 и более поздних версиях представлен NEGOExts, в котором согласовывается использование установленных пользовательских SSP, которые поддерживаются на клиенте и сервере для аутентификации.
- Безопасный канал (он же SChannel) — Представлен в Windows 2000 и обновлен в Windows Vista и выше для поддержки более надежного шифрования AES и ECC. Этот поставщик использует записи SSL/TLS для шифрования полезных данных. (Schannel.dll)
- PCT (устарел) реализация Microsoft TLS/SSL — криптография SSP с открытым ключом, которая обеспечивает шифрование и безопасную связь для аутентификации клиентов и серверов через Интернет. Обновлено в Windows 7 для поддержки TLS 1.2.
- Digest SSP (Представлено в Windows XP ) (wdigest.dll) — Обеспечивает проверку подлинности HTTP и SASL на основе запросов/ответов между системами Windows и не-Windows, где Kerberos недоступен.
- Учетные данные (CredSSP) (Представлено в Windows Vista и доступно в Windows XP с пакетом обновления 3 (SP3)) (credssp.dll) — обеспечивает SSO и проверку подлинности на уровне сети для служб удаленных рабочих столов.
- Аутентификация с распределенным паролем (DPA) — (Представлено в Windows 2000) (msapsspc.dll) — Обеспечивает аутентификацию через Интернет с использованием цифровых сертификатов.
- Криптография с открытым ключом «пользователь-пользователь» (PKU2U) (представлена в Windows 7 ) (pku2u.dll) — обеспечивает одноранговую аутентификацию с использованием цифровых сертификатов между системами, которые не являются частью домена.
Причины ошибки шифрования CredSSP
В марте 2018 года, компания Microsoft выпустила обновление безопасности для устранения уязвимостей для протокола поставщика поддержки безопасности учетных данных (CredSSP) под именем CVE-2018–0886 (https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018), используемого подключениями по протоколу удаленного рабочего стола (RDP) для клиентов Windows и Windows Server. Как только пользователи и системные администраторы произвели установку апдейтов, то по всему миру начались массовые жалобы, что люди не могут подключаться по протоколу RDP к серверам, компьютерам, получая ошибку, что причиной ошибки может быть шифрование CredSSP.
К сожалению 99% людей и администраторов совершают одну и туже ошибку, они сразу ставят обновления, не дождавшись пары дней после их выхода. Обычно этого времени хватает, чтобы вендор определил проблемы и отозвал глючное обновление.
Уязвимость в протоколе Credential Security Support Provider (CredSSP — провайдер поддержки безопасности учетных данных) допускала удаленный запуск произвольного кода на уязвимой системе и 8 мая 2018 г. Microsoft изменила уровень безопасности подключения с Vulnerable на Mitigated и начались проблемы подключения к удаленному рабочему столу по RDP. Ранее вы могли удаленно подключаться с обновленной машины к машинам без обновления безопасности, так сказать в мягком режиме. Однако с последним обновлением, Microsoft усилила безопасность, и вы больше не можете подключаться к компьютерам без обновления закрывающего брешь CVE-2018–0886.
Под раздачу попали буквально все, клиентские ОС Windows 7, Windows 8.1, Windows 10 с которых были попытки подключиться к RDS ферме или RemoteApp приложениям работающим на Windows Server 2008 R2 и выше. Если бы вы читали ветки обсуждений в эти дни, то вы бы поняли все негодование людей, особенно с запада.
Варианты исправления ошибки CredSSP
На самом деле вариантов много, есть правильные, есть и временные и обходные, которые нужно сделать быстро, чтобы хоть как-то работало, так как бизнес может в этот момент простаивать и терять деньги.
- Вы можете удалить новое обновление безопасности, самый плохой вариант, но в ответственные моменты, иногда используется, чтобы перенести работы на вечер или ночь
- Если нужно быстро получить доступ к серверу и избежать проверку подлинности credssp, то я вам советую отключить на принимающем подключении сервере галку NLA (Network Level Authentication) в русском варианте «Разрешить подключение только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети»
- То же быстрый метод и на массовое применение, это использование групповой политики, которая изменит шифрование Oracle Remediation
- Ну и самый правильный метод, это установка обновлений на все ваши системы
Отключаем credssp в Windows через NLA
Данный метод выхода из ситуации я бы рассматривал, как быстрое, временное решение, до того, как вы установите обновления безопасности. Чтобы разрешить удаленное подключение к серверу и избегать ситуации, что произошла ошибка при проверке подлинности credssp, сделайте вот что. Откройте свойства моего компьютера, попав в систему, так же можно нажать одновременно WIN+Pause Breake или как вариант в командной строке ввести control /name Microsoft.System. В окне «Система» находим пункт меню «Настройка удаленного доступа»
Снимите галку «Разрешить подключение только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети»
После этого вы легко сможете подключиться к данному компьютеру или серверу, но как быть что вы не можете туда попасть и снять эту галку, тут нам на помощь придет реестр Windows. Вы можете удаленно создать нужные ключи реестра, которые отключат галку NLA или политику CredSSP. Для этого вы можете пойти двумя путями:
- Использовать сетевой реестр Windows
- Использовать удаленное управление компьютером, например PsExec.exe, я вам с помощью него уже показывал, как открывать порты в брандмауэре, удаленно.
Давайте попробуем через удаленный реестр, для этого открываем Regedit, через окно «Выполнить».
Из меню «Файл» выберите пункт «Подключить сетевой реестр», далее найдите нужный вам сервер.
У вас подключится дополнительный реестр с двумя кустами. Переходите по пути (Если у вас не будет CredSSPParameters, то нужно будет их создать):
Тут вам необходимо создать REG_DWORD ключ с именем AllowEncryptionOracle и значением 2. В данном варианте политика CredSSP выставит Уязвимый уровень — это самый низкий уровень защиты. Это позволит вам подключаться к серверам удаленно, используя RDP. Однако это подвергнет серверы атакам.
Или можно так же отключить NLA, для этого найдите ветку реестра:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl Terminal ServerWinStationsRDP-Tcp
Найдите там ключ SecurityLayer и выставите ему значение 0, чтобы деактивировать Network Level Authentication.
Теперь то же самое вы можете выполнить и через PsExec.exe, выставив для CredSSP минимальный уровень защиты или же отключить NLA, для этого находясь в cmd в режиме администратора введите команду:
PsExec.exe \w10-cl01 -u rootАдминистратор -p пароль cmd
w10-cl01 — это имя компьютера.
Далее имея запущенный сеанс cmd для удаленного компьютера, выполните команду:
Аналогично можно сделать и для отключения Network Level Authentication, команда будет такой:
Еще раз обращаю ваше внимание, что данный метод временный и самый не безопасный, применяемый в случаях, когда уже ничего сделать нельзя или дольше, а нужно уже вчера, обязательно установите все нужные обновления.
Отключаем шифрование credssp через GPO
Если у вас большая инфраструктура, в которой сотни компьютеров и сотни серверов, то вы можете до установки нужных обновлений в вечернее время, временно отключить новый уровень шифрования CredSSP и убрать ошибку «Удаленный компьютер имя. Причиной ошибки может быть исправление шифрования CredSSP». Для этого мы можем воспользоваться всеми плюсами доменной инфраструктуры Active Directory. Тут два варианта, вы можете создать массовую политику для распространения ее на нужные OU или если у вас требование для одного или двух локальных компьютеров, то на них можно запустить локальный редактор групповых политик, тем самым внеся изменения только на них.
Напоминаю, что оснастку управление групповой политикой вы можете найти на контроллере домена или компьютере с установленным пакетом RSAT, открыть ее можно через команду в окне «Выполнить» gpmc.msc. Если нужно открыть локальный редактор групповых политик, то в окне «Выполнить» введите gpedit.msc.
Вам необходимо перейти в ветку:
Открываем настройку «Исправление уязвимости шифрующего оракула (Encryption Oracle Remediation)». Включаем политику, у вас активируется опция «Уровень защиты», на выбор будет три варианта:
- Принудительно применять обновленные клиенты (Force Updated Clients) — она будет стоять по умолчанию из-за максимального уровня защиты, вам данную опцию нужно сменить. Это так сказать максимально безопасный уровень взаимодействия клиент, он должен быть в идеале, после установки обновлений на все сервера и компьютеры.
- Оставить уязвимость (Vulnerable) – клиенты могут подключаться на уязвимые машины.
- Уменьшить риск (Mitigated) – клиенты не могут подключаться к уязвимым серверам, но серверы могут принимать уязвимые клиенты.
Выбираем на время пункт «Оставить уязвимость (Vulnerable)». Сохраняем настройки.
После чего вам нужно обновить политику, для этого откройте командную строку и введите gpupdate /force. Если у вас не доменный компьютер, да и еще Windows 10 Home, которая не имеет встроенного локального редактора политик, то вам как я описывал выше, нужно производить правку реестра
На просторах интернета ходит скрипт PowerShell, который поможет включить данную политику на всех компьютерах в Active Directory
Самый правильный метод, это установка обновлений
Раньше были вот такие KB, но они со временем могут меняться свой номер, поэтому пройдите по ссылке выше, так будет надежнее.
- Windows Server 2012 R2 / Windows 8: KB4103715
- Windows Server 2008 R2 / Windows 7: KB4103712
- Windows Server 2016 / Windows 10 1607 — KB4103723
- Windows Server 2016 / Windows 10 1703 — KB4103731
- Windows Server 2016 / Windows 10 1709 — KB4103727
- Windows Server 2016 / Windows 10 1803 — KB4103721
На этом у меня все, надеюсь, что вы разобрались в работе CredSSP и научились ей управлять. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.
Произошла ошибка проверки подлинности. Указанная функция не поддерживается
После установки обновления KB4103718 на моем компьютере с Windows 7 я не могу удаленно подключится к серверу c Windows Server 2012 R2 через удаленный рабочий стол RDP. После того, как я указываю адрес RDP сервера в окне клиента mstsc.exe и нажимаю «Подключить», появляется ошибка:
Произошла ошибка проверки подлинности.
Указанная функция не поддерживается. Удаленный компьютер: computername
После того, как я удалил обновление KB4103718 и перезагрузил компьютер, RDP подключение стало работать нормально. Если я правильно понимаю, это только временное обходное решение, в следующем месяце приедет новый кумулятивный пакет обновлений и ошибка вернется? Можете что-нибудь посоветовать?
Ответ
Вы абсолютно правы в том, что бессмысленно решать проблему удалением обновлений Windows, ведь вы тем самым подвергаете свой компьютер риску эксплуатации различных уязвимостей, которые закрывают патчи в данном обновлении.
В своей проблеме вы не одиноки. Данная ошибка может появится в любой операционной системе Windows или Windows Server (не только Windows 7). У пользователей английской версии Windows 10 при попытке подключится к RDP/RDS серверу аналогичная ошибка выглядит так:
Remote computer: computername
Ошибка RDP “An authentication error has occurred” может появляться и при попытке запуска RemoteApp приложений.
Почему это происходит? Дело в том, что на вашем компьютере установлены актуальные обновления безопасности (выпущенные после мая 2018 года), в которых исправляется серьёзная уязвимость в протоколе CredSSP (Credential Security Support Provider), использующегося для аутентификации на RDP серверах (CVE-2018-0886) (рекомендую познакомится со статьей Ошибка RDP подключения: CredSSP encryption oracle remediation). При этом на стороне RDP / RDS сервера, к которому вы подключаетесь со своего компьютера, эти обновления не установлены и при этом для RDP доступа включен протокол NLA (Network Level Authentication / Проверку подлинности на уровне сети). Протокол NLA использует механизмы CredSSP для пре-аутентификация пользователей через TLS/SSL или Kerberos. Ваш компьютер из-за новых настроек безопасности, которые выставило установленное у вас обновление, просто блокирует подключение к удаленному компьютеру, который использует уязвимую версию CredSSP.
Что можно сделать для исправления эту ошибки и подключиться к вашему RDP серверу?
Отключение NLA для протокола RDP в Windows
Если на стороне RDP сервера, которому вы подключаетесь, включен NLA, это означает что для преаутентификации RDP пользователя используется CredSPP. Отключить Network Level Authentication можно в свойствах системы на вкладке Удаленный доступ (Remote), сняв галку «Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети / Allow connection only from computers running Remote Desktop with Network Level Authentication (recommended)» (Windows 10 / Windows 8).
В Windows 7 эта опция называется по-другому. На вкладке Удаленный доступ нужно выбрать опцию «Разрешить подключения от компьютеров с любой версией удаленного рабочего стола (опасный) / Allow connections from computers running any version of Remote Desktop (less secure)».
Также нужно в политике «Требовать использования специального уровня безопасности для удаленных подключений по протоколу RDP» (Require use of specific security layer for remote (RDP) connections) выбрать уровень безопасности (Security Layer) — RDP.
Для применения новых настроек RDP нужно обновить политики (gpupdate /force) или перезагрузить компьютер. После этого вы должны успешно подключиться к удаленному рабочему столу сервера.
Ошибка при подключении по RDP (Исправление шифрования CredSSP)
13 марта Microsoft опубликовал описание уязвимости CVE-2018-0886 в протоколе проверки подлинности CredSSP, который в частности используется при подключении по RDP к терминальным серверам. Позже Microsoft опубликовал, что будет блокировать подключения к необновлённым серверам, где присутствует данная уязвимость. В связи с чем многие заказчики столкнулись с проблемами подключения по RDP.
В частности, в Windows 7 можно увидеть ошибку: «Произошла ошибка проверки подлинности. Указанная функция не поддерживается»
В Windows 10 ошибка расписана более подробно, в частности сказано «Причиной ошибки может быть исправление шифрования CredSSP»:
Для обхода ошибки со стороны клиента многие советуют отключить групповую политику, путём установки значения Encryption Oracle Remediation в Vulnerable: с помощью gpedit.msc в Конфигурация компьютера / Административные шаблоны / Система / Передача учётных данных, слева выбрать «Исправление уязвимости шифрующего оракула» (забавный конечно перевод), в настройках поставить «Включено» и выбрать «Оставить уязвимость».
или через реестр (т.к., например, в Windows Home нет команды gpedit.msc):
НО! Так делать не нужно! Т.к. таким образом вы оставляете уязвимость и риски перехвата вашего трафика и пр. конфиденциальные данные, включая пароли. Единственный случай, когда это может быть необходимо, это когда у вас вообще нет другой возможности подключиться к удалённому серверу, кроме как по RDP, чтобы установить обновления (хотя у любого облачного провайдера должна быть возможность подключения к консоли сервера). Сразу после установки обновлений, политики нужно вернуть в исходное состояние.
Если доступ к удалённому серверу есть, то ещё, как временная мера, можно отключить требование NLA (Network Level Authentication), и сервер перестанет использовать CredSSP. Для этого достаточно в Свойствах системы, на вкладке удалённые подключения снять соответствующую галку «Разрешить подключения только с компьютеров, на которых работает удалённый рабочий стол с проверкой подлинности на уровне сети»:
Но, это тоже неправильный подход.
Настройка доверенных SSL/TLS сертификатов для защиты RDP подключений
В этой статье мы покажем, как использовать доверенные SSL/TLS сертификаты для защиты RDP подключений к компьютерам и серверам Windows в домене Active Directory. Эти сертфикаты мы будем использовать вместо самоподписанных RDP сертификатов (у пользователей появляется предупреждение о невозможности проверки подлинности при подключению к RDP хосту с таким сертификатом). В этом примере мы настроим специальный шаблон для выпуска RDP сертификатов в Certificate Authority и настроим групповую политику для автоматического выпуска и привязки SSL/TLS сертификата к службе Remote Desktop Services.
Предупреждение о самоподписанном сертификате RDP
По умолчанию в Windows для защиты RDP сессии генерируется самоподписанный
сертификат. В результате при первом подключении к RDP/RDS серверу через клиента mstsc.exe, у пользователя появляется предупреждение:
Чтобы продолжить установление RDP подключении пользователь должен нажать кнопку Да. Чтобы RDP предупреждение не появлялось каждый раз, можно включить опцию “Больше не выводить запрос о подключениях к этому компьютеру».
Создаем шаблон RDP сертификата в центре сертификации (CA)
Попробуем использовать для защиты RDP подключений доверенный SSL/TLS сертификат, выданный корпоративным центром сертификации. С помощью такого сертификата пользователь может выполнить проверку подлинности RDP сервера при подключении. Предположим, что у вас в домене уже развернут корпоративной центр сертификации (Microsoft Certificate Authority), в этом случае вы можете настроить автоматическую выдачу и подключение сертификатов всем компьютерам и серверам Windows в домене.
Н на вашем CA нужно создать новый тип шаблона сертификата для RDP/RDS серверов.
Настройка групповой политики для выдачи RDP сертификатов
Теперь нужно настроить доменную политику, которая будет автоматически назначать RDP сертификат компьютерам/серверам согласно настроенного шаблона.
Для применения нового RDP сертификата, перезапустите службу Remote Desktop Services:
Теперь при RDP подключении к серверу перестанет появляться запрос на доверие сертификату (чтобы появился запрос о доверии сертификату, подключитесь к серверу по IP адресу вместо FQDN имени сервера, для которого выпущен сертификат). Нажмите кнопку “Посмотреть сертификат”, перейдите на вкладку “Состав”, скопируйте значение поля “Отпечаток сертификата”.
Также можете в консоли Certification Authority в секции Issued Certificates проверить, что по шаблону RDPTemplate был выдан сертификат определённому Windows компьютеру/серверу. Также проверьте значение Thumbprint сертификата:
Теперь, при подключении к удаленном столу любого сервера или компьютера, на который действует эта политика, вы не увидите предупреждения о недоверенном RDP сертификате.
Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата
Если у вас отсутствует CA, но вы хотите, чтобы при подключении к RDP/RDS серверу у пользователей не появлялось предупреждения, вы можете добавить сертификат в доверенные на компьютерах пользователей.
Как описано выше получите значение отпечатка (Thumbprint) RDP сертификата:
Чтобы работал прозрачных RDP вход без ввода пароля (RDP Single Sign On), нужно настроить политику Allow delegation defaults credential и указать в ней имена RDP/RDS серверов (см. статью).
Устранение неполадок с подключениями к Удаленному рабочему столу
Выполните приведенные ниже действия, если клиенту Удаленного рабочего стола не удается подключиться к удаленному рабочему столу, и отсутствуют сообщения или другие признаки, по которым можно определить причину.
Проверка состояния протокола RDP
Сведения о том, как проверить и изменить состояние протокола RDP на локальном компьютере, см. в разделе How to enable Remote Desktop (Как включить удаленный рабочий стол).
Проверка состояния протокола RDP на удаленном компьютере
В точности следуйте инструкциям из этого раздела. Неправильное изменение реестра может вызвать серьезные проблемы. Прежде чем редактировать реестр, создайте резервную копию реестра, чтобы вы могли восстановить его в случае ошибки.
Чтобы проверить и изменить состояние протокола удаленного рабочего стола на удаленном компьютере, используйте подключение сетевого реестра:
Проверка блокировки объектом групповой политики протокола RDP на локальном компьютере
Если не удается включить протокол RDP в пользовательском интерфейсе или для fDenyTSConnections возвращается значение 1 после его изменения, объект групповой политики может переопределять параметры на уровне компьютера.
Чтобы проверить конфигурацию групповой политики на локальном компьютере, откройте окно командной строки с правами администратора и введите следующую команду:
Когда команда будет выполнена, откройте файл gpresult.html. Выберите Конфигурация компьютераАдминистративные шаблоныКомпоненты WindowsСлужбы удаленных рабочих столовУзел сеансов удаленных рабочих столовПодключения и найдите политику Разрешить пользователям удаленное подключение с использованием служб удаленных рабочих столов.
Если для параметра этой политики задано значение Включено, групповая политика не блокирует подключения по протоколу RDP.
Если же для параметра этой политики задано значение Отключено, проверьте результирующий объект групповой политики. Ниже показано, какой объект групповой политики блокирует подключения по протоколу RDP.
Проверка блокировки объектом групповой политики протокола RDP на удаленном компьютере
Чтобы проверить конфигурацию групповой политики на удаленном компьютере, нужно выполнить почти такую же команду, что и для локального компьютера.
Изменение блокирующего объекта групповой политики
Эти параметры можно изменить в редакторе объектов групповой политики (GPE) и консоли управления групповыми политиками (GPM). Дополнительные сведения об использовании групповой политики см. в статье Advanced Group Policy Management (Расширенное управление групповыми политиками).
Чтобы изменить блокирующую политику, используйте один из следующих методов.
Проверка состояния служб RDP
На локальном компьютере (клиентском) и удаленном компьютере (целевом) должны быть запущены следующие службы:
Для локального или удаленного управления службами можно использовать оснастку MMC. Вы также можете использовать PowerShell для управления службами в локальном или удаленном расположении (если удаленный компьютер настроен для приема удаленных командлетов PowerShell).
На любом компьютере запустите одну или обе службы, если они запущены.
Если вы запускаете службу удаленных рабочих столов, нажмите кнопку Да, чтобы служба перенаправителя портов пользовательского режима служб удаленного рабочего стола перезапустилась автоматически.
Проверка состояния прослушивателя протокола RDP
Для выполнения этой процедуры используйте экземпляр PowerShell с разрешениями администратора. На локальном компьютере также можно использовать командную строку с разрешениями администратора. Но для этой процедуры используется PowerShell, так как одни и те же командлеты выполняются локально и удаленно.
Чтобы подключиться к удаленному компьютеру, выполните следующий командлет:
Экспортируйте конфигурацию прослушивателя RDP с рабочего компьютера.
Чтобы импортировать конфигурацию прослушивателя протокола RDP, откройте окно PowerShell с разрешениями администратора на затронутом компьютере (или откройте окно PowerShell и подключитесь к этому компьютеру из удаленного расположения).
Чтобы создать резервную копию для существующей записи реестра, воспользуйтесь таким командлетом:
Чтобы удалить резервную копию для существующей записи реестра, воспользуйтесь таким командлетом:
Чтобы импортировать новую запись реестра и перезапустить службу, воспользуйтесь такими командлетами:
Замените именем экспортированного REG-файла.
Проверьте конфигурацию, попытавшись еще раз подключиться к удаленному рабочему столу. Если подключиться все равно не удается, перезагрузите затронутый компьютер.
Проверка состояния самозаверяющего сертификата протокола RDP
На локальном компьютере (клиентском) и удаленном компьютере (целевом) прослушиватель протокола RDP должен ожидать передачи данных через порт 3389. Другие приложения не должны использовать этот порт.
Чтобы проверить или изменить порт протокола RDP, используйте редактор реестра:
Для управления службами удаленного рабочего стола можно использовать другой порт. Но мы не рекомендуем делать это. В этой статье не описано, как устранять проблемы, связанные с этим типом конфигурации.
Проверка того, что другое приложение не пытается использовать тот же порт
Найдите запись для TCP-порта 3389 (или назначенного RDP-порта) с состоянием Ожидает вызова.
Идентификатор процесса службы или процесса, использующих этот порт, отобразится в столбце «Идентификатор процесса».
Чтобы определить, какое приложение использует порт 3389 (или назначенный порт протокола RDP), введите следующую команду:
Найдите запись для номера процесса, связанного с портом (в выходных данных netstat). Службы или процессы, связанные с этим идентификатором процесса, отобразятся в столбце справа.
Если порт используется приложением или службой, отличающейся от служб удаленных рабочих столов (TermServ.exe), устранить конфликт можно с помощью одного из следующих методов:
Проверка блокировки порта протокола RDP брандмауэром
Откройте окно командной строки с правами администратора, перейдите в каталог, где установлено средство psping, и введите следующую команду:
Проверьте выходные данные команды psping на наличие таких результатов:
Запустите psping на нескольких компьютерах, чтобы проверить возможность подключения к затронутому компьютеру.
Проверьте, блокирует ли этот компьютер подключения от всех остальных компьютеров, некоторых других компьютеров или только одного компьютера.
Рекомендуемые дальнейшие действия:
Устранение ошибки проверки подлинности RDP
8 мая 2018 г. Microsoft выпустило обновление, которое предотвращает удаленное выполнение кода с помощью уязвимости в протоколе CreedSSP.
После установки данного обновление пользователи не могут подключиться к удаленным ресурсам посредством RDP или RemoteApp. При подключении происходит такая ошибка:
Появление ошибки обусловлено установкой данных обновлений безопасности:
В данной статье мы рассмотрим варианты исправления данной ошибки.
Вариант №1: Убираем проверку подлинности.
Заходим в свойства компьютера, переходим на вкладку Удаленный доступ и снимаем галку с чекбокса.
Вариант №2 (рекомендуемый): Обновление клиентских и серверных ОС.
Устанавливаем специально выпущенные патчи обновления, которые закрыли уязвимость в RDP-клиенте. Данные обновления можно посмотреть на сайте Microsoft. После установки данного обновления, мы обновляем CredSSP.
Вариант №3: Через групповые политики.
В свойствах данной политики выбираем пункт Включено и ниже в параметрах выбираем уровень защиты Оставить уязвимость.
После того, как данные действия выполнены, необходимо зайти в командную строку от имени администратора и выполнить данную команду:
Вариант №4. Редактирование реестра.
Локально заходим на устройство, к которому пытаемся подключиться и нажимаем Win+R. Вводим regedit. После того, как откроется редактор реестра идем по следующему пути:
После выполнения данных действий с реестром выполняем перезагрузку устройства.
Нужна помощь в настройке RDP-подключений? Обращайтесь к нам!
Не удаётся подключиться к RDP через шлюз?
Пробовал подключаться с двух разных компьютеров, которые территориально находятся совсем в разных местах (разные провайдер, IP и пр.). На обеих стоит Windows 7 x64 uk-UA (без SP, без обновлений), оба настраивались и используются мной. Нет даже предположений, в чём проблема. Какой-то софт, либо сделанные мной настройки, или ещё что.
Ну и, собственно, вопрос. Что не так и что делать? Как локализовать проблему? Чем мои компьютеры так уникальны и не нравятся шлюзу?
Симптомы
Рассмотрим следующий сценарий:
Установить службу шлюза удаленных рабочих столов (шлюз RD) на компьютере под управлением Windows Server 2008 R2.
Существует несколько привязок сертификат на порт 443 этого компьютера.
В этом случае шлюз удаленных рабочих Столов может работать неправильно. Некорректное поведение зависит от привязки выбранного сертификата имя хранилища сертификатов. Имя различные проблемы привязки вызывает хранилища сертификата следующие значения:
Имя хранилища сертификатов не равно NULL для привязки
В этом случае все соединения проходят за исключением в следующих случаях:
Проверка подлинности смарт-карты настраивается на стороне шлюза удаленных рабочих Столов.
Проверки работоспособности защиты доступа к сети применяются на стороне клиента.
Имя хранилища сертификатов для привязки равно NULL
В этом случае все соединения друг с другом сбой и появляется следующее сообщение об ошибке:
Компьютеру не удается подключиться к удаленному компьютеру, так как отсутствует сертификат, настроенный для использования на сервере шлюза удаленных рабочих столов. Обратитесь к сетевому администратору за помощью.
В то же время добавляется следующее событие шлюза службы терминалов с 306 идентификатор журнала шлюза службы терминалов:Примечание. Чтобы проверить, установлено ли значение NULL имя хранилища сертификатов, выполните следующие действия.
В командной строке введите следующую команду и нажмите клавишу ВВОД:
netsh http show sslcert
Причина
Проблемы возникают потому, что служба шлюза удаленных рабочих Столов получает привязку неверный сертификат.
Решение
Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте это исправление только в тех случаях, когда наблюдается проблема, описанная в данной статье. Это исправление может проходить дополнительное тестирование. Таким образом если вы не подвержены серьезно этой проблеме, рекомендуется дождаться следующего пакета обновления, содержащего это исправление.
Если исправление доступно для скачивания, имеется раздел «Пакет исправлений доступен для скачивания» в верхней части этой статьи базы знаний. Если этот раздел не отображается, обратитесь в службу поддержки для получения исправления.
Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Чтобы получить полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание, посетите следующий веб-сайт корпорации Майкрософт:
http://support.microsoft.com/contactus/?ws=supportПримечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.
Предварительные условия
Для установки этого исправления компьютер должна быть запущена Windows Server 2008 R2.
Необходимость перезагрузки
После установки исправления компьютер необходимо перезагрузить.
Сведения о замене исправлений
Это исправление не заменяет других исправлений.
Сведения о файлах
Английская версия данного исправления содержит атрибуты файла (или более поздние атрибуты файлов), приведенные в следующей таблице. Дата и время для этих файлов указаны в формате общего скоординированного времени (UTC). При просмотре сведений о файле, он преобразуется в локальное время. Чтобы узнать разницу между временем по Гринвичу и местным временем, следует использовать Часовой поясвкладке Дата и времяэлемент панели управления.