Настройте NLA, чтобы не использовать проверку учетных данных на стороне клиента
Ситуация: при использовании рабочей станции Windows 10, которая находится в домене OFFICE Я инициирую RDP-соединение с использованием входа в систему с помощью смарт-карты и сертификатов к шлюзу RDS в чужом домене REMOTE, Зарубежный домен принимает сертификаты от CA OFFICE-CA которые выдали сертификаты на используемую смарт-карту, которая находится в том же домене, где находится рабочая станция. Аутентификация RDP приводит к ошибке 0xc000006d/0xc000006a (неизвестное имя пользователя). Журналы событий сервера сообщают, что была предпринята попытка аутентификации с явными учетными данными, которые использовали исходный домен OFFICE вместо домена назначения REMOTE, Если я проверяю вход в систему локально на ПК, который подключен к REMOTE домен, использующий ту же смарт-карту, DC предоставляет доступ пользователю user@office.com который равен REMOTE\user, Итак, авторизация на основе сертификатов настроена правильно.
Я пошел немного вперед и включил "Разрешить пользовательские подсказки" в OFFICE Политика домена, позволяющая клиенту RDP в Windows 10 предоставлять ожидаемый домен \ имя пользователя удаленному серверу RDS, инициировала сеанс RDP и предоставила ожидаемую строку REMOTE\user как подсказка пользователя, чтобы помочь авторизовать соединение. На этот раз RDP успешно выполняется с авторизацией на основе журналов сервера, однако клиент RDP выдает ошибку "неизвестный пользователь" и принудительно закрывает соединение RDP с локальной стороны. Раскрывая проблему, я наткнулся на эту статью, объясняющую, что NLA, помимо прочего, содержит следующее:
Когда вы вводите свои учетные данные в это диалоговое окно, даже если вы не хотите сохранять их, они переходят в CredSSP. Затем он передает учетные данные на сервер узла сеансов удаленных рабочих столов через защищенный канал.
Следовательно, проверка должна пройти в любом случае, подсказка пользователя или нет. Видимо, клиент Windows 10 RDP mstsc.exe сначала пытается проверить учетные данные (сертификат) на локальной стороне, определяет домен \ имя пользователя и отправляет ТО на удаленную сторону, которая, очевидно, имеет другой домен \ имя пользователя и не авторизует соединение. Если я включаю и предоставляю подсказку для пользователя, подсказка, по-видимому, также проверяется на локальной стороне и, очевидно, дает сбой, тогда как удаленная сторона правильно проверяет учетные данные на основе сертификатов.
Вопрос в следующем:
- Когда изменилось исходное поведение NLA?
- Как я могу контролировать, будет ли использоваться проверка учетных данных на стороне клиента до их проверки на удаленной стороне, и отключить ее?
- Нужно ли что-то настраивать на удаленной стороне, чтобы одновременно поддерживать NLA и разрешать RDP-соединение от RDP-клиента, расположенного в любом месте, который предоставил сертификат смарт-карты в качестве учетных данных, при условии, что сертификат действителен?