Программе подключения к удаленному рабочему столу не удается проверить удостоверение компьютера, к которому осуществляется подключение.
В связи с недавними обновлениями безопасности Windows, закрывающее уязвимости в протоколе CredSSP, парочка маков (mac mini середины 2007 года) потеряли доступ к терминальному серверу на базе Windows Server 2008R2.
Программе подключения к удаленному рабочему столу не удается проверить удостоверение компьютера, к которому осуществляется подключение.
Дело в том, что старая версия маковского rdp client 2.1.1 от Microsoft, ставшая последней доступной для Mac OS X 10.7 (Lion), не работает не только с Windows Server 2012, но после вышеупомянутого обновления перестала подключаться и к WinServer 2008R2. В природе существует и неофициальная версия rdp-клиента 2.1.2, однако разыскивать её, нет особого резона — результат будет аналогичным.
Актуальные, на данный момент, клиенты Microsoft Remote Desktop 8.0 (совместима с OS X 10.9 и выше) и Microsoft Remote Desktop 10.0 (macOS 10.10 и выше) поставить на старую систему OS X не представляется возможным. Из вменяемых альтернатив, можно выделить, пожалуй, только Parallels Client. и вроде вот оно счастье, ведь в минимальных требованиях значится Mac OS X 10.7.3, однако не стоит верить всему что пишут. Хоть программа и благополучно устанавливается, позволяет внести данные о вашем подключении, однако вылетает на попытке соединения с сервером вываливая кучу ошибок.
От безысходности можно пойти от обратного, изменив работу службы удаленных рабочих столов на сервере (метод работает и на Windows Server 2012), однако лучшим вариантом станет замена клиентской машины.
Подключения старой версии rdp client 2. 1 к Windows Server 2012
Нам понадобится запустить редактор групповых политик. В командной строке набираем gpedit. Переходим в раздел настроек безопасности RDP:
Здесь следует поменять значение двух параметров:
Теперь даже старые версии Microsoft Remote Desktop будут подключаться к терминальному серверу, правда только по дефолтному порту 3389. Замечен и побочный эффект — Windows клиенты, которые ставили галочку «сохранить пароль» лишились такой возможности. В общем, данная статья носит скорее познавательный характер, приделывать подобные костыли рабочим серверам я бы не стал.
Если считаете статью полезной,не ленитесь ставить лайки и делиться с друзьями.
Комментариев
Добрый день. Не ожидал что в 2018 найду свежую информацию для старых маков. Вот мне как раз актуально, так как подключаюсь по удалёнке не к серверу, а к своему рабочему компьютеру на Windows 10, обновился недавно. Теперь 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). При просмотре сведений о файле, он преобразуется в локальное время. Чтобы узнать разницу между временем по Гринвичу и местным временем, следует использовать Часовой поясвкладке Дата и времяэлемент панели управления.
При подключении к серверу терминала, который работает Windows Server 2008 или Windows Server 2008 R2, вы получаете различные сообщения об ошибках, связанных с сертификатом.
В этой статье предоставляется решение для различных сообщений об ошибках, связанных с сертификатом, при подключении к серверу терминала.
Применяется к: Windows Server 2012 R2 Исходный номер КБ: 2000960
При подключении к серверу терминала, который работает Windows Server 2008, или удаленному настольному серверу, который работает Windows Server 2008 R2, вы получаете одно из следующих сообщений об ошибке.
Подключение удаленного рабочего стола не удалось из-за невозможности проверки подлинности удаленного компьютера
Удаленный компьютер не удалось проверить подлинность из-за проблем с сертификатом безопасности. Продолжить работу может быть небезопасно.
Несоответствие имен Запрашивается удаленный компьютер Имя в сертификате
Ошибки сертификата При проверке сертификата удаленного компьютера были допущены следующие ошибки: имя сервера в сертификате неверно.
Невозможно продолжить, так как требуется проверка подлинности.
Невозможно проверить удостоверение удаленного компьютера. Вы хотите подключиться в любом случае?
Ошибки сертификата Имя сервера в сертификате неверно сертификат не из доверенного органа сертификации.
Вы хотите подключиться, несмотря на эти ошибки сертификата?
Проблема возникает из-за неправильного сертификата, который используется для сеанса сервера терминала или удаленного рабочего стола.
Ниже ниже 1000 действий по проверке выбранного сертификата.
Устранение ошибки проверки подлинности RDP
8 мая 2018 г. Microsoft выпустило обновление, которое предотвращает удаленное выполнение кода с помощью уязвимости в протоколе CreedSSP.
После установки данного обновление пользователи не могут подключиться к удаленным ресурсам посредством RDP или RemoteApp. При подключении происходит такая ошибка:
Появление ошибки обусловлено установкой данных обновлений безопасности:
В данной статье мы рассмотрим варианты исправления данной ошибки.
Вариант №1: Убираем проверку подлинности.
Заходим в свойства компьютера, переходим на вкладку Удаленный доступ и снимаем галку с чекбокса.
Вариант №2 (рекомендуемый): Обновление клиентских и серверных ОС.
Устанавливаем специально выпущенные патчи обновления, которые закрыли уязвимость в RDP-клиенте. Данные обновления можно посмотреть на сайте Microsoft. После установки данного обновления, мы обновляем CredSSP.
Вариант №3: Через групповые политики.
В свойствах данной политики выбираем пункт Включено и ниже в параметрах выбираем уровень защиты Оставить уязвимость.
После того, как данные действия выполнены, необходимо зайти в командную строку от имени администратора и выполнить данную команду:
Вариант №4. Редактирование реестра.
Локально заходим на устройство, к которому пытаемся подключиться и нажимаем Win+R. Вводим regedit. После того, как откроется редактор реестра идем по следующему пути:
После выполнения данных действий с реестром выполняем перезагрузку устройства.
Нужна помощь в настройке RDP-подключений? Обращайтесь к нам!
Компьютеру не удается проверить удостоверение шлюза удаленных рабочих столов windows 7
Итак, сертификат 61619b9c000000000013
а что у вас ссылка на CRT делает в расширении OCSP? Как минимум из-за этих ошибок у вас неполная цепочка сертификатов.
корневой сертификат этой цепочки (сервера DGET-CA) у вас не установлен в доверенные центры сертификации компьютерного хранилища.
61619b9c000000000013 — нужно удалить. Корректно настроить расширение AIA на издающем CA и выпустить новый сертификат.
61fb04be000000000017 — сертификат сервера DGET-CA нужно установить в доверенные центры сертификации компьютерного хранилища.
на самом деле, не знаю, чего она там делает =) сертификат сервера стоял и стоит в доверенных центрах удалённой машины.
переделал сертификаты. собственно, ничего не поменялось, ошибка та же:
Ошибка подключения к удаленному рабочему столу из-за невозможности проверить подлинность удаленного компьютера. Не удалось проверить подлинность удаленного компьютера из-за проблем с сертификатом безопасности. Продолжение может быть небезопасным. Имя в сертификате от удаленного компьютера: msk-db01.msk.dget.ru. Не удалось проверить, не был ли отозван сертификат. Продолжение невозможно из-за серьезных ошибок сертификатов.
Поставщик: CN=DGET-CA DC=msk DC=dget DC=ruСубъект: CN=compas.myftp.orgСерийный номер сертификата: 613796c600000000001d
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)SimpleChain.dwErrorStatus = CERT_TRUST_IS_UNTRUSTED_ROOT (0x20)SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
Поставщик: CN=DGET-CA DC=msk DC=dget DC=ruСубъект: CN=msk-db01.msk.dget.ruСерийный номер сертификата: 613f693700000000001e
Вопрос
Здравствуйте. Пытаюсь поднять RDS, столкнулся с проблемой.
Все необходимые роли службы удаленных рабочих столов заведены на одном сервере. Доменное имя сервера внутри сети server.mydomen.com совпадает с «внешним» доменным именем. Настроил веб-доступ к удаленным рабочим столам, личные рабочие столы для пользователей и тд.
Если так же заходить снаружи, не из домена, ошибка следующая:
Удаленному рабочему столу не удалось подключиться к удаленному компьютеру «server.mydomen.com» по одной из этих причин: 1) Данной учетной записи пользователя не предоставлены права на доступ к шлюзу удаленных рабочих столов «server.mydomen.com» 2) Данный компьютер не авторизован для доступа к шлюзу удаленых рабочих столов «server.mydomen.com» 3) Используется несовместимый метод проверки подлинности (например, шлюз удаленных рабочих столов ожидает смарт-карту, а предоставлен пароль)
Ответы
Переустановил роль rdg, перенастроил точно так же. В итоге получил ещё одну ошибку (в дополнение к трём существующим):
4. В группе «Пользователи удаленного рабочего стола» на сервере узла сеансов удаленных рабочих столов должны присутствовать пользователи или группы домена.
После этого на клиенте через rdweb появилась уже другая ошибка:
«При отправке данных на сервер шлюза удаленных рабочих столов произошла ошибка. Сервер временно недоступен или не работает сетевое подключение.»
Нашел в интернете про CredSSP (ОС MS WinXp SP3) и установил _http://support.microsoft.com/kb/951608 Всё заработало.
ПС: давно не работал с виндовс, совсем забыл про актуальность шутки:
Едут в машине таксист, бизнесмен и программист. Вдруг машина ломается. Таксист говорит: — Давайте мотор смотреть. Бизнесмен: — Да ладно, давай тачку поймаем. Программист: — А давайте все выйдем и снова войдем, может, она заработает?
Все ответы
При этом политики диспетчера шлюза удаленных рабочих столов:
Политики авторизации подключений
Если пользователь является членом любой из перечисленных ниже групп пользователей:
mydomen.comАдминистраторы предприятия, mydomen.comГости домена, mydomen.comСотрудники mydomen.com Если клиентский компьютер является членом любой из следующих групп компьютеров: mydomen.comГости домена, mydomen.comКомпьютеры домена Если пользователь использует следующие поддерживаемые методы проверки подлинности Windows: Пароль Разрешить пользователю подключение к этому серверу шлюза удаленных рабочих столов и отключить перенаправление устройств для следующих клиентских устройств: Неприменимо (перенаправление устройств включено для всех клиентских устройств) По истечении времени ожидания в режиме простоя: — Не применяется (без времени ожидания простоя) По истечении времени ожидания сеанса: — Не применяется (без времени ожидания простоя)
Политики авторизации ресурсов
PROGRESS-MАдминистраторы предприятия, mydomen.comГости домена, mydomen.comСотрудники mydomen.com
Сетевой ресурс: разрешить подключение пользователей к любому сетевому ресурсу
1. Проверьте наличие учетной записи RDG в группе безопасности RAS and IAS Servers в Active Directory.
1. Что вы имеете в в виду под «учетной записью RDG»? Группу RAS and IAS Servers нашел. Вот список моих групп:
2. Настройку осуществил, выбрал уровень безопасности RDP. Только в статье тип подключения 6.1, а у меня 7.1. Немного изменился ход подключения, но ошибка в итоге та же самая.
Никто ещё что-нибудь не подскажет?
бывает если подключаться к члену фермы через имя компьютера, а не фермы. У вас случайно не включена эта фича?
Вот она по-моему где включается. Видимо нет.
Таким образом настроено.
Про виртуальные машины ранее информации не было, то есть это физическая машина одна. Может быть еще информация какая-нибудь будет? Где стоит Web-Access и что происходит на виртуальных машинах?
Да, всё на одной машине. Чтобы наружу не пробрасывать кучу портов на вирт. машины. Да и безопаснее.
Физическая машина вообще одна. На ней 11 виртуальных машин. Все роли установлены на хостовой системе. Домен active directory mydomen.com. Сервер (хостовая система) server.mydomen.com. Всем пользователям назначены виртуальные рабочие столы (например vm1.mydomen.com). При заходе в rdweb (без разницы извне или снаружи) пользователи авторизуются и нормально видят свои опубликованные столы. При попытке подключения ошибка в первом посте. Сертификат используется самоподписанный, один для всех служб, занесённый на сервере и на клиентах в доверенные. Ещё какая информация, вроде всё описал? Сейчас в службах удаленных рабочих столов обнаружил три ошибки: 1. Cервер шлюза удаленных рабочих столов должен иметь возможность подключения к доменным службам Active Directory. 2. На сервере шлюза удаленных рабочих столов необходимо включить хотя бы одну политику авторизации подключений к удаленным рабочим столам. 3. На сервере шлюза удаленных рабочих столов следует настроить использование действительного SSL-сертификата
1. RDG стоит на контроллере домена. Каким образом он не может достучаться до AD?
2. Политики есть и они включены.
3. Сертификат действительный. http://s017.radikal.ru/i415/1211/22/687a1425a3e0.png
Точно такие же проблемы на форуме видел, но решения там не было.
Как выглядит ошибка 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.