An authentication error has occurred

После установки обновления 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 серверу аналогичная ошибка выглядит так:

The function requested is not supported.

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 серверу?

1. Самый правильный способ решения проблемы – установка последних кумулятивных обновлений безопасности Windows на компьютере / сервере, к которому вы подключаетесь по RDP;
2. Временный способ 1 . Можно отключить проверку подлинности на уровне сети (NLA) на стороне RDP сервера (описано ниже);
3. Временный способ 2 . Вы можете на стороне клиента разрешить подключение к RDP серверам с небезопасной версией CredSSP, как описано в статье по ссылке выше. Для этого нужно изменить ключ реестра AllowEncryptionOracle (команда REG ADD
   HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2 ) или изменить настройки локальной политики Encryption Oracle Remediation / Исправление уязвимости шифрующего оракула), установив ее значение = Vulnerable / Оставить уязвимость).

Отключение 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)».

Также можно отключить проверку подлинности на уровне сети (NLA) с помощью редактора локальной групповой политики — gpedit.msc (в Windows 10 Home редактор политик gpedit.msc можно запустить так) или с помощью консоли управления доменными политиками – GPMC.msc. Для этого перейдите в разделе Конфигурация компьютера –> Административные шаблоны –> Компоненты Windows –> Службы удаленных рабочих столов – Узел сеансов удаленных рабочих столов –> Безопасность (Computer Configuration –> Administrative Templates –> Windows Components –> Remote Desktop Services – Remote Desktop Session Host –> Security), отключите политику Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети (Require user authentication for remote connections by using Network Level Authentication).

Также нужно в политике «Требовать использования специального уровня безопасности для удаленных подключений по протоколу RDP» (Require use of specific security layer for remote (RDP) connections) выбрать уровень безопасности (Security Layer) — RDP.

Для применения новых настроек RDP нужно обновить политики (gpupdate /force) или перезагрузить компьютер. После этого вы должны успешно подключиться к удаленному рабочему столу сервера.

Эта статья поможет устранить ошибки аутентификации, возникающие при использовании подключения по протоколу удаленного рабочего стола (RDP) к виртуальной машине Azure. This article can help you troubleshoot authentication errors that occur when you use Remote Desktop Protocol (RDP) connection to connect to an Azure virtual machine (VM).

Проблемы Symptoms

Вы создали снимок экрана виртуальной машины Azure, на котором виден экран приветствия и все указывает на то, что операционная система запущена. You capture a screenshot of an Azure VM that shows the Welcome screen and indicates that the operating system is running. Тем не менее при попытке подключиться к удаленному рабочему столу виртуальной машины появляется одно из следующих сообщений об ошибке. However, when you try to connect to the VM by using Remote Desktop Connection, you receive one of the following error messages.

Сообщение об ошибке 1 Error message 1

Произошла ошибка проверки подлинности. The Local Security Authority cannot be contacted (Произошла ошибка аутентификации. Не удается связаться с локальным администратором безопасности). An authentication error has occurred. The Local Security Authority cannot be contacted.

Сообщение об ошибке 2 Error message 2

The remote computer that you are trying to connect to requires Network Level Authentication (NLA), but your Windows domain controller cannot be contacted to perform NLA. If you are an administrator on the remote computer, you can disable NLA by using the options on the Remote tab of the System Properties dialog box (Для подключения к удаленному компьютеру требуется проверка подлинности на уровне сети, однако не удалось подключиться к контроллеру домена Windows для ее выполнения. Если вы являетесь администратором удаленного компьютера, то можете отключить проверку подлинности на уровне сети, воспользовавшись параметрами на вкладке "Удаленные" диалогового окна "Свойства системы"). The remote computer that you are trying to connect to requires Network Level Authentication (NLA), but your Windows domain controller cannot be contacted to perform NLA. If you are an administrator on the remote computer, you can disable NLA by using the options on the Remote tab of the System Properties dialog box.

Сообщение об ошибке 3 (универсальная ошибка подключения) Error message 3 (generic connection error)

This computer can’t connect to the remote computer. Try connecting again, if the problem continues, contact the owner of the remote computer or your network administrator (Не удается подключиться к удаленному компьютеру. Попробуйте подключиться снова. Если проблема не исчезнет, ​​обратитесь к владельцу удаленного компьютера или к администратору сети). This computer can’t connect to the remote computer. Try connecting again, if the problem continues, contact the owner of the remote computer or your network administrator.

Причина: Cause

Существует несколько причин, по которым проверка подлинности на уровне сети (NLA) может блокировать доступ по протоколу RDP к виртуальной машине. There are multiple reasons why NLA might block the RDP access to a VM.

Причина 1 Cause 1

Виртуальная машина не может обмениваться данными с контроллером домена. The VM cannot communicate with the domain controller (DC). Эта проблема может помешать сеансу RDP обращаться к виртуальной машине с помощью учетных данных домена. This problem could prevent an RDP session from accessing a VM by using domain credentials. Тем не менее вы можете войти в систему, используя учетные данные локального администратора. However, you would still be able to log on by using the Local Administrator credentials. Эта проблема может возникнуть в следующих ситуациях. This problem may occur in the following situations:

Нарушен защищенный канал Active Directory между этой виртуальной машиной и контроллером домена. The Active Directory Security Channel between this VM and the DC is broken.

Виртуальная машина использует устаревшую копию пароля учетной записи, а контроллер домена использует новый пароль. The VM has an old copy of the account password and the DC has a newer copy.

Контроллер домена, к которому подключается эта виртуальная машина, находится в неработоспособном состоянии. The DC that this VM is connecting to is unhealthy.

Причина 2 Cause 2

Уровень шифрования виртуальной машины выше уровня, который используется клиентским компьютером. The encryption level of the VM is higher than the one that’s used by the client computer.

Причина 3 Cause 3

На виртуальной машине отключены протоколы TLS 1.0, 1.1 или 1.2 (сервер). The TLS 1.0, 1.1, or 1.2 (server) protocols are disabled on the VM.

Причина 4 Cause 4

На виртуальной машине было отключено ведение журнала с помощью учетных данных домена, и локальная система безопасности настроена неправильно. The VM was set up to disable logging on by using domain credentials, and the Local Security Authority (LSA) is set up incorrectly.

Причина 5 Cause 5

Виртуальная машина была настроена для принятия только подключений, использующих алгоритмы, соответствующие Федеральному стандарту обработки информации (FIPS). The VM was set up to accept only Federal Information Processing Standard (FIPS)-compliant algorithm connections. Обычно для этого используются политика Active Directory. This is usually done by using Active Directory policy. Эта конфигурация встречается редко, но FIPS можно настроить для использования только подключений к удаленному рабочему столу. This is a rare configuration, but FIPS can be enforced for Remote Desktop connections only.

Перед устранением неполадок Before you troubleshoot

Создание моментального снимка резервной копии Create a backup snapshot

Чтобы создать моментальный снимок резервной копии, выполните действия, описанные в статье Создание моментального снимка. To create a backup snapshot, follow the steps in Snapshot a disk.

Удаленный вход на виртуальную машину Connect to the VM remotely

Чтобы удаленно подключиться к виртуальной машине, используйте один из методов, описанных в статье Use remote tools to troubleshoot Azure VM issues (Использование удаленных средств для устранения проблем с виртуальными машинами Azure). To connect to the VM remotely , use one of the methods in How to use remote tools to troubleshoot Azure VM issues.

Службы клиента групповой политики Group policy client service

Если это виртуальная машина, присоединенная к домену, необходимо сначала остановить службу клиента групповой политики, чтобы предотвратить перезапись изменений какой-либо политикой Active Directory. If this is a domain-joined VM, first stop the Group Policy Client service to prevent any Active Directory Policy from overwriting the changes. Для этого выполните следующую команду: To do this, run the following command:

После устранения проблемы восстановите возможность виртуальной машины взаимодействовать с доменом, чтобы получить последний объект групповой политики из домена. After the problem is fixed, restore the ability of this VM to contact the domain to retrieve the latest GPO from the domain. Для этого выполните следующие команды. To do this, run the following commands:

Если изменение отменено, это означает, что проблема вызвана политикой Active Directory. If the change is reverted, it means that an Active Directory policy is causing the problem.

Возможное решение Workaround

Чтобы обойти эту проблему, выполните следующие команды в командном окне, чтобы отключить NLA. To work around this problem, run the following commands in the command window to disable NLA:

Затем перезапустите виртуальную машину. Then, restart the VM.

Чтобы снова включить NLA, выполните приведенную ниже команду, а затем перезапустите виртуальную машину. To re-enable NLA, run the following command, and then restart the VM:

Устранение неполадок Troubleshooting

Для виртуальных машин, присоединенных к домену For domain-joined VMs

Чтобы устранить эту проблему, сначала проверьте, может ли виртуальная машина подключиться к контроллеру домена и находится ли контроллер домена в работоспособном состоянии, позволяющем обрабатывать запросы от виртуальной машины. To troubleshoot this problem, first check whether the VM can connect to a DC, and whether the DC has a status of "healthy" and can handle requests from the VM.

Чтобы проверить работоспособность контроллера домена, можно использовать другую виртуальную машину в той же одной виртуальной сети и подсети, которая использует тот же сервер входа в систему. To test the DC health, you can use another VM on the same VNET and Subnet that share the same logon server.

Подключитесь к виртуальной машине, на которой возникла проблема, с помощью Серийной консоли, удаленного сеанса командной строки или удаленного сеанса PowerShell. Следуйте инструкциям в разделе "Удаленный вход на виртуальную машину". Connect to the VM that has the problem by using Serial console, remote CMD, or remote PowerShell, according to the steps in the “Connect to the VM remotely” section.

Чтобы определить, к которому контроллеру домена подключается виртуальная машина, выполните в консоли следующую команду. To determine which DC the VM is connecting to, run the following command in the console:

Затем проверьте работоспособность защищенного канала между виртуальной машиной и контроллером домена. Then, check the health of the secure channel between the VM and the DC. Для этого в экземпляре сеанса PowerShell с повышенными привилегиями выполните следующую команду. To do this, run the following command in an elevated PowerShell instance. Эта команда возвращает логический флаг, который указывает, активен ли защищенный канал. This command returns a Boolean flag that indicates whether the secure channel is alive:

Если канал не работает, выполните следующую команду для его восстановления. If the channel is broken, run the following command to repair it:

Убедитесь, что пароль учетной записи компьютера в Active Directory обновлен в виртуальной машине и контроллере домена. Make sure that the computer account password in Active Directory is updated on the VM and the DC:

Если контроллер домена и виртуальная машина успешно взаимодействуют, но контроллер домена недостаточно работоспособен, чтобы запустить сеанс RDP, можно попытаться перезапустить контроллер домена. If the communication between the DC and the VM is good, but the DC is not healthy enough to open an RDP session, you can try to restart the DC.

Если указанные выше команды не привели к устранению неполадки связи с доменом, можно повторно присоединить эту виртуальную машину к домену. If the preceding commands did not fix the communication problem to the domain, you can rejoin this VM to the domain. Для этого выполните следующие действия. To do this, follow these steps:

Создайте сценарий Unjoin.ps1, используя приведенное ниже содержимое. Затем разверните этот сценарий как расширение пользовательских сценариев на портале Azure. Create a script that’s named Unjoin.ps1 by using the following content, and then deploy the script as a Custom Script Extension on the Azure portal:

Этот сценарий принудительно удаляет виртуальную машину из домена и перезапускает его через 10 секунд. This script takes the VM out of the domain forcibly and restarts it 10 seconds later. Затем нужно очистить объект-компьютер на стороне домена. Then, you have to clean up the Computer object on the domain side.

После завершения очистки вновь присоедините эту виртуальную машину к домену. After the cleanup is done, rejoin this VM to the domain. Для этого создайте сценарий JoinDomain.ps1, используя приведенное ниже содержимое. Затем разверните этот сценарий как расширение пользовательских сценариев на портале Azure. To do this, create a script that’s named JoinDomain.ps1 by using the following content, and then deploy the script as a Custom Script Extension on the Azure portal:

Виртуальная машина присоединится к домену с помощью указанных учетных данных. This joins the VM on the domain by using the specified credentials.

Если канал Active Directory находится в работоспособном состоянии, пароль компьютера обновлен, а контроллер домена работает правильно, выполните следующие действия. If the Active Directory channel is healthy, the computer password is updated, and the domain controller is working as expected, try the following steps.

Если проблема не исчезла, проверьте, не отключены ли учетные данные домена. If the problem persists, check whether the domain credential is disabled. Для этого откройте окно командной строки с повышенными привилегиями и выполните следующую команду, чтобы определить, отключены ли на виртуальной машине учетные записи домена для входа на эту виртуальную машину. To do this, open an elevated Command Prompt window, and then run the following command to determine whether the VM is set up to disable domain accounts for logging on to the VM:

Если задано значение раздела 1, это означает, что на сервере запрещены учетные данные домена. If the key is set to 1, this means that the server was set up not to allow domain credentials. Измените значение раздела на 0. Change this key to 0.

Для изолированных виртуальных машин For standalone VMs

Проверка значения MinEncryptionLevel Check MinEncryptionLevel

В экземпляре командной строки выполните следующую команду, чтобы запросить значение реестра MinEncryptionLevel. In an CMD instance, run the following command to query the MinEncryptionLevel registry value:

Исходя из значения реестра, выполните следующие действия. Based on the registry value, follow these steps:

3 (128-разрядное шифрование). Задайте уровень серьезности 2, выполнив приведенную ниже команду. 3 (128-bit encryption): Set the severity to 2 by running the following command:

2 (Максимально возможный уровень шифрования в соответствии с клиентом). Можно попытаться установить минимальный уровень шифрования 1, выполнив приведенную ниже команду. 2 (Highest encryption possible, as dictated by the client): You can try to set the encryption to the minimum value of 1 by running the following command:

Чтобы изменения реестра вступили в силу, перезапустите виртуальную машину. Restart the VM so that the changes to the registry take effect.

Версия протокола TLS TLS version

В зависимости от системы протокол RDP использует протокол TLS 1.0, 1.1 или 1.2 (сервер). Depending on the system, RDP uses the TLS 1.0, 1.1, or 1.2 (server) protocol. Чтобы запросить параметры этих протоколов, настроенные на виртуальной машине, откройте экземпляр командной строки и выполните следующие команды. To query how these protocols are set up on the VM, open a CMD instance, and then run the following commands:

Если не все возвращенные значения равны 1, это означает, что протокол отключен. If the returned values are not all 1, this means that the protocol is disabled. Чтобы включить эти протоколы, выполните следующие команды. To enable these protocols, run the following commands:

Для других версий протокола можно выполнить следующие команды. For other protocol versions, you can run the following commands:

Версию x.x протоколов SSH и TLS можно получить из журналов гостевой ОС для ошибок SCHANNEL. Get the SSH/TLS version x.x from the Guest OS Logs on the SCHANNEL errors.

Проверка подключений, использующих FIPS-совместимые алгоритмы Check FIPs compliant algorithms connections

Удаленный рабочий стол можно настроить для использования только подключений, использующих FIPS-совместимые алгоритмы. Remote desktop can be enforced to use only FIPs-compliant algorithm connections. Это можно сделать, задав соответствующий раздел реестра. This can be set by using a registry key. Для этого откройте окно командной строки с повышенными привилегиями и запросите следующие разделы. To do this, open an elevated Command Prompt window, and then query the following keys:

Если команда возвращает 1, измените значение реестра на 0. If the command returns 1, change the registry value to 0.

Проверьте текущее значение MinEncryptionLevel виртуальной машины. Check which is the current MinEncryptionLevel on the VM:

Если команда возвращает 4, измените значение реестра на 2. If the command returns 4, change the registry value to 2

Чтобы изменения реестра вступили в силу, перезапустите виртуальную машину. Restart the VM so that the changes to the registry take effect.

Ошибка CredSSP, исправляем за минуту

Ошибка CredSSP, исправляем за минуту

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org, в прошлый раз мы с вами чинили HDD с поврежденной файловой системой и состоянием RAW уверен, что вам удалось это сделать. Сегодня я в очередной раз переведу наш вектор траблшутера в сторону терминальных столов, а именно мы рассмотрим ситуацию, что когда вы пытаетесь подключиться к удаленному серверу по RDP протоколу, а у вас после ввода логина и пароля, выскакивает ошибка, что вы не прошли проверку подлинности и причиной ошибки может быть исправление шифрования CredSSP. Давайте разбираться, что за зверь, этот CredSSP и как вам получить доступ к вашему серверу.

Как выглядит ошибка credssp

Перед тем, как я покажу вам известные мне методы ее устранения, я бы как обычно хотел подробно описать ситуацию. Вчера при попытке подключиться к своему рабочему компьютеру, работающему на Windows 10 1709, с терминального стола, входящего в RDS ферму на Windows Server 2012 R2, я получил ошибку после ввода логина и пароля:

Ну и конечно в русском исполнении:

Получается двоякая ситуация, что RDP как бы работает, но вот по какой-то причине ваши учетные данные на принимающей стороне не соответствуют, каким-то критериям, давайте разбираться, что это за зверь CredSSP.

Назначение CredSSP

Что такое CredSSP — это Win32 API, используемый системами Microsoft Windows для выполнения различных операций, связанных с безопасностью, таких как аутентификация. SSPI функционирует, как общий интерфейс для нескольких поставщиков поддержки безопасности (SSP). Поставщик поддержки безопасности — это библиотека динамической компоновки (DLL), которая делает один или несколько пакетов безопасности доступными для приложений.

C redSSP позволяет приложению делегировать учетные данные пользователя от клиента целевому серверу для удаленной аутентификации. CredSSP предоставляет зашифрованный канал протокола безопасности транспортного уровня . Клиент проходит проверку подлинности по зашифрованному каналу с использованием протокола SPNEGO (Simple and Protected Negotiate) с Microsoft Kerberos или Microsoft NTLM.

После проверки подлинности клиента и сервера клиент передает учетные данные пользователя на сервер. Учетные данные дважды шифруются с использованием ключей сеанса SPNEGO и TLS. CredSSP поддерживает вход в систему на основе пароля, а также вход в систему с использованием смарт-карт на основе X.509 и PKINIT.

Windows SSP

Следующие поставщики общих служб устанавливаются вместе с 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% людей и администраторов совершают одну и туже ошибку, они сразу ставят обновления, не дождавшись пары дней после их выхода. Обычно этого времени хватает, чтобы вендор определил проблемы и отозвал глючное обновление.

Под раздачу попали буквально все, клиентские ОС 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. Для этого вы можете пойти двумя путями:

1. Использовать сетевой реестр Windows
2. Использовать удаленное управление компьютером, например PsExec.exe, я вам с помощью него уже показывал, как открывать порты в брандмауэре, удаленно.

Давайте попробуем через удаленный реестр, для этого открываем Regedit, через окно "Выполнить".

Из меню "Файл" выберите пункт "Подключить сетевой реестр", далее найдите нужный вам сервер.

У вас подключится дополнительный реестр с двумя кустами. Переходите по пути (Если у вас не будет CredSSPParameters, то нужно будет их создать):

Тут вам необходимо создать REG_DWORD ключ с именем AllowEncryptionOracle и значением 2. В данном варианте политика CredSSP выставит Уязвимый уровень — это самый низкий уровень защиты. Это позволит вам подключаться к серверам удаленно, используя RDP. Однако это подвергнет серверы атакам.

Или можно так же отключить NLA, для этого найдите ветку реестра:

Найдите там ключ SecurityLayer и выставите ему значение 0, чтобы деактивировать Network Level Authentication.

Теперь то же самое вы можете выполнить и через PsExec.exe, выставив для CredSSP минимальный уровень защиты или же отключить NLA, для этого находясь в 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

Import-Module ActiveDirectory
$PSs = (Get-ADComputer -Filter *).DNSHostName
Foreach ($computer in $PCs) <
Invoke-Command -ComputerName $computer -ScriptBlock <
REG ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2
>
>

Самый правильный метод, это установка обновлений

Когда вам удалось везде подключиться и подошло время обслуживания ваших серверов, быстренько производим установку обновлений закрывающих брешь (CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability).

Раньше были вот такие 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