Ошибка CredSSP: не подключается удаленный доступ

Причины и история появления ошибки

Возникновение ошибки «Не удается подключиться к удаленному компьютеру» после ввода логина и пароля говорит о том, что порт доступен. Проблема началась с 2014 года, после того, как было выпущено обновление KB2992611. Этот пакет обновлений существенно ужесточил параметры безопасности.

Уровень безопасности и шифрования поднялся, но при этом появились непредвиденные последствия вроде этой ошибки. Последующие обновления ситуацию не исправили, а только ухудшали. Усиление безопасности Windows приводило к новым программным конфликтам между разными версиями ОС и сторонним ПО. К примеру, конкретно эта ошибка имеет одинаковые шансы появиться на Windows XP, 7, 8, 10, Windows Server 2012 и даже менее популярных версиях системы.

Причины возникновения ошибки:

— Установка обновления KB2992611 и последующих.
— Установка программного обеспечения, использующего шифрование — КриптоПро, VipNet.
— Использование другого ПО, так или иначе связанного с шифрованием данных.

Это основные, но не единственные причины, по которым Windows вступает в конфликт с ПО и выдает ошибку с сообщением «Не удается подключиться к удаленному компьютеру. Повторите попытку подключения. Если проблема повторится, обратитесь к владельцу удаленного компьютера.»

Если начать просматривать логи Windows, то можно увидеть следующее системное предупреждение: «Возникло следующее неустранимое предупреждение: 80 (или 36888). Внутренне состояние ошибки: 1250.»

Помимо этого, можно найти информацию об ошибке в компоненте протокола: «Компонент X.224 RDP-протокола обнаружил ошибку в потоке протокола и отключил этого клиента.» Именно эта ошибка ответственна за то, что не удается установить соединение с удаленным компьютером по RDP-клиенту.

Если причиной появления проблемы стала конкретная программа, установленная недавно, самым простым способом будет ее удаление с компьютера. Практически всегда можно найти аналогичное по функционалу ПО, которое не будет вступать в конфликт с операционной системой. Если это невозможно, либо возникновение ошибки не связано с недавно установленным софтом, можно попробовать исправить ситуацию при помощи одного из советов ниже.

Не появляется запрос пароля для L2TP VPN подключения

Такое ощущение, что в этом диалоге VPN подключения почему-то блокируется вывод окна с запросом данных пользователя. В результате VPN подключение никак не может завершиться

Есть обходное решение этой проблемы. Попробуйте использовать для установления VPN подключения старую-добрую Windows утилиту rasphone.exe, которая все еще присутствует в современных версиях Windows 10 (эта утилита должна быть знакома всем тем, кто пользовался dial-up подключением в Windows).

Запустите утилиту: Win+R ->
Выберите ваше VPN подключение и нажмите кнопку “Подключить”;
После этого появится стандартное окно с указанием имени пользователя и пароля для VPN подключения;
VPN туннель должен успешно подняться.

Для удобства пользователей вы можете вынести ярлык на rasphone.exe на рабочий стол. Для автоматического подключения вы можете указать в настройках ярлыка имя вашего VPN подключения так: (название VPN подключения можно взять из Control Panel -> Network Adapters и взять его в кавычки, если оно содержит пробелы в имени).

Что интересно, проблема возникает только c L2TP подключением (даже при включенном настроенном параметре реестра AssumeUDPEncapsulationContextOnSendRule = 2). Другое VPN подключение на этом же компьютере, но с протоколом PPTP и типом аутентификации MS-CHAP v2 работает нормально

Перед устранением неполадок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:

ПричинаCause

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

Причина 1Cause 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.

Причина 2Cause 2

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

Причина 3Cause 3

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

Причина 4Cause 4

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

Причина 5Cause 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.

Назначение 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 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) — обеспечивает одноранговую аутентификацию с использованием цифровых сертификатов между системами, которые не являются частью домена.

Подробнее на https://en.wikipedia.org/wiki/Security_Support_Provider_Interface

Невозможно подключиться по RDP с Windows XP к Windows Server 2016/2012R2 и Windows 10

Пользователи XP жаловались на такие ошибки rdp клиента:

Because of a security error, the client could not connect to the remote computer. Verify that you are logged on to the network, and then try reconnecting again.
The remote session was disconnected because the remote computer received an invalid licensing message from this computer.
The remote computer requires Network Level Authentication, which your computer does not support. For assistance, contact your system administrator or technical support.

Чтобы решить данную проблему, проверьте что на компьютерах с Windows XP обновлена версия клиента RDP. На текущий момент максимальная версия RDP клиента, которую можно установить на Windows XP — rdp клиент версии 7.0 (KB969084 — https://blogs.msdn.microsoft.com/scstr/2012/03/16/download-remote-desktop-client-rdc-7-0-or-7-1-download-remote-desktop-protocol-rdp-7-0-or-7-1/). Установить данное обновление можно только на Windows XP SP3. Установка RDP клиента версии 8.0 и выше на Windows на XP не поддерживается. После установки данного обновления у половины клиентов проблема с RDP подключением решилась. Осталась вторая половина….

Пользователю не удается выполнить вход с помощью смарт-картыUser can’t sign in using a smart card

В этом разделе рассматриваются три типичных сценария, когда пользователь не может войти на удаленный рабочий стол с помощью смарт-карты.This section addresses three common scenarios where a user can’t sign in to a remote desktop using a smart card.

Эта проблема возникает в развертываниях, в которых задействован сервер RDSH на сайте филиала, где используется RODC.This issue occurs in deployments that include an RDSH server at a branch site that uses a RODC. Сервер RDSH размещен в корневом домене.The RDSH server is hosted in the root domain. Пользователи на сайте филиала относятся к дочернему домену и используют смарт-карты для проверки подлинности.Users at the branch site belong to a child domain, and use smart cards for authentication. Контроллер домена RODC настроен на кэширование паролей и принадлежит к группе с разрешением реплицировать пароли RODC.The RODC is configured to cache user passwords (the RODC belongs to the Allowed RODC Password Replication Group). Когда пользователи пытаются выполнить вход в сеанс на сервере RDSH, они получают сообщение, например: «Неудачная попытка входа в систему.When users try to sign in to sessions on the RDSH server, they receive messages such as «The attempted logon is invalid. Указано неверное имя пользователя или другие неверные личные данные.»This is either due to a bad username or authentication information.»

Эта проблема связана с тем, как корневой контроллер домена и RDOC управляют шифрованием учетных данных пользователей.This issue is caused by how the root DC and the RDOC manage user credential encryption. Корневой контроллер домена использует ключ шифрования, чтобы зашифровать учетные данные, а RODC предоставляет ключ расшифровки клиенту.The root DC uses an encryption key to encrypt the credentials and the RODC gives the client the decryption key. Если пользователь получает ошибку «Недопустимо», значит два ключа не совпадают.When a user receives the «invalid» error, that means the two keys don’t match.

Чтобы решить эту проблему, выполните одно из указанных ниже действий:To work around this issue, try one of the following things:

измените топологию контроллера домена, отключив кэширование паролей на RODC, или разверните на сайте филиала контроллер домена с доступом на запись;Change your DC topology by turning off password caching on the RODC or deploy a writeable DC to teh branch site.
переместите сервер RDSH в тот же дочерний домен, где находятся пользователи;Move the RDSH server to the same child domain as the users.
разрешите пользователям выполнять вход без смарт-карты.Allow users to sign in without smart cards.

Учтите, что эти решения предполагают наличие компромисса между производительностью и уровнем безопасности.Be advised that all of these solutions require compromises in either performance or security level.

Эта проблема возникает, когда пользователи выполняют вход в систему компьютера Windows Server 2008 с пакетом обновления 2 (SP2), на котором установлено обновление KB4093227 (2018.4B).This issue occurs when users sign in to a Windows Server 2008 SP2 computer that has been updated with KB4093227 (2018.4B). Когда пользователи пытаются выполнить вход с помощью смарт-карты, они получают отказ в доступе с сообщениями, например: «Действительные сертификаты не найдены.When users attempt to sign in using a smart card, they are denied access with messages such as «No valid certificates found. Убедитесь, что эта карта вставлена правильно и плотно сидит в разъеме».Check that the card is inserted correctly and fits tightly.» В то же время на компьютере Windows Server регистрируется событие приложения с сообщением «При получении цифрового сертификата с вставленной смарт-карты произошла ошибка:At the same time, the Windows Server computer records the Application event «An error occurred while retrieving a digital certificate from the inserted smart card. неправильная подпись.»Invalid Signature.»

Чтобы устранить эту проблему, обновите на компьютере ОС Windows Server до повторного выпуска 2018.06 B (обновление KB4093227). См. статью Description of the security update for the Windows Remote Desktop Protocol (RDP) denial of service vulnerability in Windows Server 2008: April 10, 2018 (Описание обновления системы безопасности для защиты протокола RDP в Windows от уязвимости службы в Windows Server 2008 (10 апреля 2018 г.).To resolve this issue, update the Windows Server computer with the 2018.06 B re-release of KB 4093227, Description of the security update for the Windows Remote Desktop Protocol (RDP) denial of service vulnerability in Windows Server 2008: April 10, 2018.

Отключаем шифрование credssp через GPO

Если у вас большая инфраструктура, в которой сотни компьютеров и сотни серверов, то вы можете до установки нужных обновлений в вечернее время, временно отключить новый уровень шифрования CredSSP и убрать ошибку «Удаленный компьютер имя. Причиной ошибки может быть исправление шифрования CredSSP». Для этого мы можем воспользоваться всеми плюсами доменной инфраструктуры Active Directory. Тут два варианта, вы можете создать массовую политику для распространения ее на нужные OU или если у вас требование для одного или двух локальных компьютеров, то на них можно запустить локальный редактор групповых политик, тем самым внеся изменения только на них.

Напоминаю, что оснастку управление групповой политикой вы можете найти на контроллере домена или компьютере с установленным пакетом RSAT, открыть ее можно через команду в окне «Выполнить» gpmc.msc. Если нужно открыть локальный редактор групповых политик, то в окне «Выполнить» введите gpedit.msc.

Вам необходимо перейти в ветку:

Конфигурация компьютера — Административные шаблоны — Система — Передача учетных данных — Исправление уязвимости шифрующего оракула (Computer Configuration — Administrative Templates — System — Credentials Delegation — Encryption Oracle Remediation

Открываем настройку «Исправление уязвимости шифрующего оракула (Encryption Oracle Remediation)». Включаем политику, у вас активируется опция «Уровень защиты», на выбор будет три варианта:

Принудительно применять обновленные клиенты (Force Updated Clients) — она будет стоять по умолчанию из-за максимального уровня защиты, вам данную опцию нужно сменить. Это так сказать максимально безопасный уровень взаимодействия клиент, он должен быть в идеале, после установки обновлений на все сервера и компьютеры.
Оставить уязвимость (Vulnerable) – клиенты могут подключаться на уязвимые машины.
Уменьшить риск (Mitigated) – клиенты не могут подключаться к уязвимым серверам, но серверы могут принимать уязвимые клиенты.

Выбираем на время пункт «Оставить уязвимость (Vulnerable)». Сохраняем настройки.

После чего вам нужно обновить политику, для этого откройте командную строку и введите gpupdate /force. Если у вас не доменный компьютер, да и еще Windows 10 Home, которая не имеет встроенного локального редактора политик, то вам как я описывал выше, нужно производить правку реестра

REG ADD HKLM\Software\Microsoft\Windows\ CurrentVersion\Policies\System\CredSSP\Parameters\ /v AllowEncryptionOracle /t REG_DWORD /d 2 (0 вернет все как было)

На просторах интернета ходит скрипт PowerShell, который поможет включить данную политику на всех компьютерах в Active Directory

Ошибка RASMAN для Always on VPN

Другая проблема возникает с VPN подключением к корпоративной сети в режиме Always on VPN (AOVPN). При инициализации такого VPN подключения служба RASMAN (Remote Access Connections Manager) останавливается, а в журнале событий Application появляется событие с Event ID 1000 и текстом:

“Faulting application name: svchost.exe_RasMan…”, “Faulting module name: rasmans.dll”, и “Exception code: 0xc0000005”.

Эта проблема признана Microsoft и по последним данным исправлена в октябрьском обновлении для Windows 10 1903 — KB4522355 (https://support.microsoft.com/en-us/help/4522355/windows-10-update-kb4522355). Вы можете скачать и установить данное обновление вручную или через Windows Update/WSUS.

Если обновление не исправило проблему, попробуйте переустановите виртуальные адаптеры WAN miniports в диспетчере устройств.

Запустите Device manager (devmgmt.msc);
Разверните секцию Network Adapters
Последовательно щелкните правой кнопкой по следующим адаптерам и удалите их (Uninstall device): WAN Miniport (IP), WAN Miniport(IPv6) и WAN Miniport (PPTP).
После удаления выберите в меню Action -> Scan for Hardware changes и дождитесь, пока Windows не обнаружит и не установит драйвера для этих виртуальных устройств;
После этого сбросьте сетевые настройки Windows 10 : Settings -> Network & Internet -> Network Reset -> Reset now;
Теперь вам нужно пересоздать ваши VPN подключения (Руководство по VPN для начинающих) и проверить подключение.

Изначально проблема с режимом Always on VPN подключением была связана с тем, что пользователь отключил на компьютере телеметрию (эх, Microsoft). Для корректной работы Always on VPN подключения вам придется временного включить телеметрию на компьютере. Для включения телеметрии вы можете воспользоваться одним из способов, описанных ниже.

Способ 1. Откройте редактор локальных политики (gpedit.msc) и перейдте в секцию Computer Configuration -> Administrative Templates –> Windows Components -> Data Collection and Preview Builds.

Найдите и включите политику Allow Telemetry = Enabled. Установите один из следующих режимов: 1 (Basic), 2 (Enhanced) или 3 (Full).

Способ 2. Того же самого эффекта можно добиться, вручную изменив параметр реестра AllowTelemetry (тип REG_DWORD) в ветке HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection. Здесь также нужно установить одно из трех значение: 1, 2 или 3.

Вы можете изменить этот параметр с помощью редактора реестра (regedit.exe) или с помощью PowerShell-командлета New-ItemProperty:

После этого нужно перезапустить службу Remote Access Connection Manager (RasMan) через консоль services.msc или с помощью командлета Restart-Service:

При одключении от VPN пропадает Интернет

Также в Windows 10 был другой баг, когда после отключения от VPN переставал работать доступ в Интернет. Проблема решалась созданием маршрута по-умолчанию или отключением/включением виртуального адаптера WAN Miniport (IP).

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

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

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2018-0886

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.

#2 – Сброс сессии пользователя и завершение зависших процессов в RDS сессии

Сначала попробуем найти и принудительно сбросить сессию пользователя, который не может зайти на RDS сервер. В диспетчере задач, на вкладке Users найдите нужного пользователя и через контекстное меню кликаем “Log off”. В большинстве случаев, этого достаточно, но иногда в диспетчере задач вы можете обнаружить множество зависших сессий с именем “(4)” вместо имени пользователя. Как правило в зависшей сессии будет присутствовать 4 процесса:

Client Server Runtime Process (csrss.exe)
Desktop Windows Manager (dwm.exe)
Windows Logon Application (winlogon.exe)
Windows Logon User Interface

В первую очередь попробуйте завершить все зависшие сессии с (4) через диспетчер задач, как описано выше. Если это не поможет, то лучше всего перезагрузить сервер, но зачастую такой возможности нет, поэтому пробуем решить проблему без перезагрузки:

Запустите командную строку с правами администратора и введите: Она покажет всех пользователей и их сессии на терминальном сервере. В выводе команды есть 3 интересующих нас столбца: SESSIONNAME, USERNAME и ID. Найдите пользователя (4) и соответствующий ему ID, в данном примере ID 2. Нам нужно завершить процесс csrss.exe который работает под этой сессией, сначала найдем его.
В командной строке введите: Команда выведет все процессы, которые запущены в этой сессии. Нам нужно найти процесс csrss.exe и соответствующий ему PID. В моём случае PID будет 5140. Нам нужно завершить этот процесс.
Сверимся по диспетчеру задач. Откройте диспетчер задач, перейдите на вкладку Details и найдите нужный вам PID и процесс.Если нужный вам PID соответствует процессу csrss.exe, то завершите процесс через контекстное меню и End task, либо через командную строку:

Это нужно проделать с каждым пользователем “(4)”, если их несколько.