Внезапно удалённый рабочий стол через RDP перестал подключаться к компьютерам, находящимся в домене ActiveDirectory. Симптомы: при подключении, после ввода учётных данных, постоянно запрашивает пароль, хотя всё вводится верно. Такое происходит при подключении по имени удалённой машины сокращенном или FQDN, но если подключаться по IP адресу, то проблемы нет.
В логах в ветке TerminalServices-ClientActiveXCore в журнале Microsoft-Windows-TerminalServices-RDPClient/Operational при этом появляются сообщения об ошибке следующего содержания
RDPClient_SSL: An error was encountered when transitioning from TsSslStateHandshakeInProgress to TsSslStateDisconnecting in response to 7 (error code 0x80004005).
RDPClient_SSL: произошла ошибка при переходе из TsSslStateHandshakeInProgress в TsSslStateDisconnecting в ответ на 8. (Код ошибки: 0x80004005).Долго думал что к чему, читал, от версии Windows не зависело, компьютеры абсолютно разные, объединяло их только то, что они все находятся в домене.
У меня развернут AD CertificateAuthority, но крайне беспечно. Гуляя по журналу я наткнулся на то, что сертификат для LDAPS просрочен довольно давно. С помощью статьи https://winitpro.ru/index.php/2014/10/02/aktiviruem-ldap-over-ssl-ldaps-v-windows-server-2012-r2/ выпустил новые сертификаты и о чудо, ошибка при подключении исчезла! Очень странно что проблема с RDP вылезла буквально недавно.
UPD 2024.10.21
Снова вылезла проблема с проблемой входа через RDP при подключении через FQDN имя с последующим сообщением «Попытка входа в систему неудачна». Через IP адрес машины данных проблем нет. Начал разбираться дальше.
При попытке авторизации в журнале клиента TerminalServices-ClientActiveXCore в журнале Microsoft-Windows-TerminalServices-RDPClient/Operational сообщения:
RDPClient_TCP: произошла ошибка при переходе из TcpStateConnectingTransport в TcpStateDisconnected в ответ на TcpEventConnectionTimeout. (Код ошибки: 0x80004004).
RDPClient_SSL: произошла ошибка при переходе из TsSslStateHandshakeInProgress в TsSslStateDisconnecting в ответ на TsSslEventHandshakeContinueFailed. (Код ошибки: 0x80004005).
Проверил все цепочки сертификатов и прочее — всё отлично. Полез на контроллер домена. У меня их два равноправных, один на Windows Server 2008 R2, другой на Windows Server 2019. Прочитав активные журналы событий Windows Server 2008 R2 проблем не увидел, а вот в Windows Server 2019 удалось обнаружить сообщение в Kerberos-Key-Distribution-Center Event ID 37
Беглым поиском был найден рецепт и необходимые обновления для починки данного безобразия: https://www.linuxshop.ru/forum/f5/t41634—resheno-error-37-kerberos-key-distribution-center-bileta-obnaruzhil-bilet-kotoryj-ne-soderzhal-svedenij-ob-uchetnoj-zapisi-zaprosivshej-bilet.html
Из перечисленных симптомов:
- Вход пользователя домена может завершиться ошибкой. Это также может влиять на аутентификацию Active Directory Federation Services (AD FS).
- Аутентификация может не работать при использовании Group Managed Service Accounts (gMSA) для таких служб, как Internet Information Services (IIS Web Server).
- Подключения к удаленному рабочему столу с использованием пользователей домена могут не работать.
- Возможны проблемы с получением доступа к общим папкам на рабочих станциях и файловым ресурсам на серверах.
- Печать, требующая аутентификации пользователя домена, может завершаться с ошибкой.
Итого меня интересовал патч для Windows Server 2008 R2 SP1: KB5021651
(released November 18, 2022). В примечании написано что нужно поставить все обновления до 8 ноября 2022 г. ESU я ещё не использовал на данном сервере, так как не было необходимости. Благодаря видео https://www.youtube.com/watch?v=EdEqJUUTvBI&ab_channel=TecAdam активировал ESU и установил около 80 обновлений, после чего скачал KB5021651 и установил. Необходимо подождать некоторое время, пока тикеты Керберос обновятся. И, вроде бы, эффект достигнут — проблемы с входом по RDP через FQDN имя исчезли, как и Event ID 37 в журнале контроллера домена.