Назад | Перейти на главную страницу

Соединение RDWeb TS прервано для некоторых пользователей после изменения сертификата RemoteApp

Недавно мы перевыпустили наш сертификат с подстановочными знаками GoDaddy с алгоритмом подписи SHA256 (к вашему сведению, они по-прежнему отзывают старый сертификат через 72 часа, даже если вы не переключаете его заново, так что вам все равно следует повторно ввести ключ). Мы используем этот сертификат для наших RemoteApps, RDP терминальных серверов, RDGateway и RDWeb (IIS).

Когда я перехожу на новый подстановочный сертификат в «RemoteApp Manager» -> «Настройки цифровой подписи» на заданном сервере терминалов (сервер узла сеанса AKA) Соединения из RDWeb для приложений, опубликованных на этом сервере терминалов, не работают для некоторых пользователей, но соединения, использующие файл .rdp отлично работает для всех пользователей. Более того, и это самая странная вещь, которую я когда-либо видел, не тот пользователь регистрируется как отказанный в доступе на шлюзе. Если я изменю сертификат обратно на старый, отозванный сертификат для этого параметра, все будет работать.

Рабочая настройка:

Нерабочая установка:

При запуске из RDWeb с использованием пользователя "КОНТОСО \ боб" генерируется следующая ошибка:

Удаленный рабочий стол не может подключиться к удаленному компьютеру «ts1.contoso.com» по одной из следующих причин: 1) ваша учетная запись пользователя не указана в списке разрешений шлюза удаленных рабочих столов 2) вы могли указать удаленный компьютер в формате NetBIOS. ..

Когда я смотрю журнал событий «Microsoft-Windows-TerminalServices-Gateway / Operational», я вижу следующую ошибку:

Пользователь "КОНТОСО \ Алиса"на клиентском компьютере «123.123.123.123» не соответствовал требованиям политики авторизации ресурсов и поэтому не был авторизован для ресурса «ts1.contoso.com». Произошла следующая ошибка: «23002».

Что происходит? Почему изменение сертификата подписи RemoteApp заставляет шлюз думать, что это подключается другой пользователь?

Нашел эту страницу после того, как столкнулся с той же проблемой. Для нас решение состояло в том, чтобы добавить порт 3389 к шлейфу (он же Hairpin NAT) на нашем брандмауэре.

Некоторые дополнительные детали:

Заменить сертификат оказалось сложнее, чем установить его в первый раз, но я думаю, что мы сделали это правильно, и приложения работали нормально день или два. Пользователи начали получать ошибки при запуске, и мы закончили использовать скрипт PowerShell здесь https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80 повторно опубликовать полное доменное имя сервера.

Я думаю, что этот сценарий должен был установить полное доменное имя в части конфигурации, которая никогда не была указана раньше, в результате чего шлюз удаленных рабочих столов ссылался на себя по своему полному доменному имени для передачи запросов. Эти запросы не удались, поскольку наш пограничный брандмауэр разрешил только 80 и 443 как для входящих, так и для запросов обратной связи.

Добавление порта 3389 к правилу обратной связи на брандмауэре немедленно решило проблему.