Вопрос или проблема
У меня возникла проблема с развертыванием веб-клиента. Изначально, когда мы настраивали систему VDI, у нас всё работало на одном сервере в качестве демонстрации, и веб-клиент функционировал безупречно.
С тех пор мы разделили его на отдельные шлюз/брокер и более мощный виртуализационный хост, и теперь я получаю ошибку “ваша сессия завершилась, потому что был получен неожиданный сертификат аутентификации сервера от удаленного ПК”.
Я думал, что это будет работать так же, как и раньше, я экспортирую сертификат из брокера подключений, который хостит управление веб-клиентом/брокером/шлюзом, и импортирую его для веб-клиента следующим образом:
Import-RDWebClientBrokerCert C:\RDBrokerCert.cer
но это не работает.
Под “удаленным ПК” имеется в виду виртуализационный хост? Я мог бы поклясться, что это не имеет значения, но, возможно, имеет? Очевидно, у него другой сертификат, чем у брокера, но этот сертификат был выдан нашим ЦА и он доверен. Есть ли журнал, который я могу проверить, чтобы увидеть, о каком сертификате идет речь?
Я следовал стандартным процедурам устранения неполадок для этой ошибки, проверил, что сертификат веб-доступа и сертификат, который был импортирован в веб-клиент, одинаковы, выглядит хорошо, один и тот же отпечаток. Убедился, что FQDN сервера находится в CN И в альтернативных именах субъекта. Я в полном замешательстве, что еще может быть не так.
Я подтвердил, что использование фактического RDP-файла работает, так что клиенты по крайней мере смогут получить доступ, но я действительно хотел бы, чтобы веб-клиент заработал, потому что некоторым сотрудникам нравится более удобный интерфейс.
Ответ или решение
Проблема с веб-клиентом RDS: отдельный шлюз/брокер и хост виртуализации
Вы столкнулись с проблемой, которая часто возникает при переходе от демонстрационной среды к полноценной архитектуре виртуализированных рабочих мест. Давайте подробно рассмотрим вашу ситуацию и предложим возможные решения.
Описание проблемы
Ваше первоначальное развертывание работало на одном сервере, что, скорее всего, обеспечивало простоту конфигурации и легкость в устранении неполадок. Однако при переходе на архитектуру с отдельным шлюзом и брокером, которая теперь отвечает за управление доступом и маршрутизацию соединений, вы столкнулись с ошибкой: "ваша сессия завершилась, поскольку от удаленного ПК был получен неожиданный сертификат аутентификации сервера".
Анализ проблемы
-
Сертификаты аутентификации: Ошибка указывает на то, что веб-клиент не может подтвердить сервер, к которому он подключается. Это может быть связано с тем, что сертификат, используемый на хосте виртуализации, отличается от сертификата, импортированного в веб-клиент. Сертификат, выданный вашим центром сертификации (CA), должен быть доверенным на всех слоях инфраструктуры, включая как шлюз / брокер, так и виртуальный хост.
-
Кто является "удаленным ПК": В вашем случае "удаленный ПК" может действительно относиться к хосту виртуализации, так как именно на нем разворачиваются сессии пользователей. На большинстве платформ терминального доступа проверка сертификата выполняется для всех промежуточных и конечных точек.
-
Логи и диагностика: Для получения точной информации о том, с каким сертификатом возникли проблемы, вы можете обратиться к журналам событий на сервере терминации сессий. Логи находятся в Event Viewer, в разделе "Applications and Services Logs" -> "Microsoft" -> "Windows" -> "TerminalServices-Session". Это даст представление о том, какие ошибки возникают и какие сертификаты проверяются.
-
Сравнение сертификатов: Вы упомянули, что проверили соответствие сертификатов (fingerprint и т.д.), однако имеет смысл также проанализировать, что в CN и Subject Alternative Name (SAN) сертификата указаны все необходимые FQDN. Убедитесь, что имя, по которому вы обращаетесь к брокеру и виртуализационному хосту, присутствует в SAN.
Рекомендации по устранению неполадок
-
Импорт сертификата хоста виртуализации: Если у вас есть сертификат на виртуальном хосте, его также стоит импортировать в доверенные корневые центры сертификации на брокере и шлюзе. Это поможет убедиться, что все участники процесса аутентификации "знают" друг друга и доверяют сертификациям.
-
Конфигурация RDP: Поскольку вы можете подключаться с помощью RDP файла, можно использовать это как временное решение, пока вы не устранили проблему с веб-клиентом.
-
Проверка настроек шифрования: Убедитесь, что настройки шифрования, указанные в групповой политике, соответствуют требованиям безопасности вашего сертификата. Использование неподдерживаемых алгоритмов шифрования может вызвать проблемы с аутентификацией.
Заключение
Вы на правильном пути к решению проблемы, столкнувшись с нюансами конфигурации системы. Не стесняйтесь обращаться к официальной документации Microsoft или к сообществу поддержки RDS для поиска информации по аналогичным проблемам. Полная уверенность в совместимости всех сертификатов на всех уровнях вашей инфраструктуры – это основной путь к решению этой задачи.