Ошибка клиента RDP - произошла ошибка аутентификации (0x609)
У меня есть компьютер с именем ws24 (192.168.1.168) и другой с именем srvPPassTest2.
Я написал программу, работающую на ws24, которая является "RDP-прокси". Он принимает подключения от клиентов RDP через порт 7070 (настраивается) и перенаправляет их в srvPPassTest2. Чтобы настроить компьютеры для использования прокси-сервера, я делаю следующее:
- Я создаю сертификат для Прокси с помощью следующей команды:
./makecert -n "CN=ws24.pleasant.local" -pe -ss Root -sr localMachine -sky exchange -m 120 -r -a sha1 -eku 1.3.6.1.5.5.7.3.1
- Затем я экспортирую его с закрытым ключом, чтобы создать файл.pfx, который будет использовать прокси.
- Я также экспортирую его без закрытого ключа и импортирую его в папку Сертификаты srvPPassTest2 (Локальный компьютер) - Trusted Root Certification Authorities/Certificate.
- я бегу
Enable-WSManCredSSP -role client -DelegateComputer srvPPassTest2 Enable-WSManCredSSP -role client -DelegateComputer ws24 Enable-WSManCredSSP -role client -DelegateComputer 192.168.1.168
на ws24. Я уверен, что они не все необходимы, но это еще не работает, поэтому я пробую все. - На ws24 я делаю следующие изменения в реестре:
- HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa \ Security Packages - добавить tspkg
- HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders - добавить credssp.dll
- я бегу
Enable-WSManCredSSP -role Server
на srvPPassTest2.
Если вы получаете какие-либо ошибки в вызовах WSManCredSSP, попробуйте сначала вызвать Enable-PSRemoting.
Вот что происходит, когда я запускаю прокси-сервер rdp и использую RDP-клиент для подключения к нему:
- На ws24 я использую RDP-клиент для подключения к 192.168.1.168:7070. Использование IP-адреса вместо имени не позволяет клиенту ответить, что вы не можете подключиться к себе.
- Прокси-сервер получает и изменяет (при необходимости) сообщение ConnectionRequestPDU протокола RDP, чтобы убедиться, что для флагов SupportedProtocol установлены значения ProtocolHybrid и ProtocolSSL. Это обеспечит использование CredSSP. Это пересылается в srvPPassTest2.
- Прокси-сервер - это рукопожатие TLS.
- Прокси-сервер получает клиентское сообщение NTLMNegotiate, получает от него некоторую информацию и создает новую для пересылки целевому srvPPassTest2.
- Аналогично с NTLMChallenge и NTLMAuthentication.
- На этом этапе клиент и сервер RDP работают нормально. Они не возвращают ошибок и не демонстрируют странное поведение.
- Машины обмениваются открытыми ключами сертификатов, зашифрованными ключом от обмена NTLM.
- Клиент отправляет TSRequest с TSCredential. Прокси-сервер получает его, проверяет информацию и создает его с разными учетными данными для отправки в srvPPassTest2.
- Переслать сообщение от клиента, длина 462
- Переслать сообщение от srvppasstest2, длина 108
- Переслать сообщение от клиента, длина 12
Затем я получаю всплывающее сообщение об ошибке от клиента rdp:
Произошла ошибка аутентификации (код: 0x609)
Удаленный компьютер: 192.1.168.1.168
Единственный релевантный результат при поиске ошибки 0x609 - здесь, и я выполнил эти шаги. Одно важное замечание: у меня этот прокси работал 3 месяца назад. Затем srvPPassTest2 был возвращен в предыдущее состояние, и теперь прокси не работает. Я не могу вернуть srvPPassTest2 в состояние, когда оно работало, что vm не мое и снимок не был сохранен IT >:(
Где найти информацию о коде 0x609?
Какие другие возможные настройки на ws24 или srvPPassTest2 я пропускаю? Я думаю, что сертификат должен быть в дополнительной папке на srvPPassTest2, но я не знаю, какой именно.
Есть ли что-нибудь, что я могу сделать, чтобы устранить неполадки? Обмены NTLM и TSCredential все работают безупречно.
1 ответ
Ошибка была в этом шаге:
- Прокси-сервер получает и изменяет (при необходимости) сообщение ConnectionRequestPDU протокола RDP, чтобы убедиться, что для флагов SupportedProtocol установлены значения ProtocolHybrid и ProtocolSSL. Это обеспечит использование CredSSP. Это пересылается в srvPPassTest2.
Как оказалось, мне также пришлось установить флаг ProtocolHybridEx в ConnectionRequestPDU. Я предполагаю, что это потому, что перенаправленные сообщения, те, что после TSCredential, заботятся об этом флаге.
В таком случае я решил просто переслать флаги, используемые клиентом, а не создавать их самому. Если флаг ProtocolHybrid не установлен, я аккуратно выведу ошибку, так как мы требуем использовать проверку подлинности на уровне сети (NLA).