Настройте NLA, чтобы не использовать проверку учетных данных на стороне клиента

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

Я пошел немного вперед и включил "Разрешить подсказки пользователей" в OFFICE доменная политика, позволяющая RDP-клиенту Windows 10 предоставлять ожидаемый домен \ имя пользователя удаленному RDS-серверу, инициировала сеанс RDP и предоставила ожидаемую строку REMOTE\user в качестве подсказки для авторизации подключения. На этот раз RDP проходит успешно с авторизацией на основе журналов сервера, однако клиент RDP выдает ошибку «пользователь неизвестен» и принудительно закрывает соединение RDP с локальной стороны. Разбираясь в проблеме, я наткнулся на это статья, объясняющая NLA это, среди прочего, содержит следующее:

Когда вы вводите свои учетные данные в это диалоговое окно, даже если вы не выбираете их сохранение, они попадают в CredSSP. Затем он передает учетные данные на сервер узла сеансов удаленных рабочих столов по защищенному каналу.

Следовательно, проверка должна быть успешной в любом случае, подсказка пользователя или нет. Судя по всему, клиент Windows 10 RDP mstsc.exe сначала пытается проверить учетные данные (сертификат) на локальной стороне, определяет домен \ имя пользователя и отправляет ТО на удаленную сторону, которая, очевидно, имеет другой домен \ имя пользователя и не авторизует соединение. Если я включаю и предоставляю подсказку пользователю, подсказка, по-видимому, также проверяется на локальной стороне и, очевидно, не работает, в то время как удаленная сторона правильно проверяет учетные данные на основе сертификата.

Вопрос в следующем:

1. Когда изменилось первоначальное поведение NLA?
2. Как я могу контролировать, будет ли использоваться проверка учетных данных на стороне клиента до их проверки на удаленной стороне, и отключить ее?
3. Нужно ли мне настраивать что-то дополнительное на удаленной стороне, чтобы поддерживать NLA и разрешать RDP-соединение от клиента RDP, расположенного в любом месте, который предоставил сертификат смарт-карты в качестве учетных данных, при условии, что сертификат действителен?