Соединение RDWeb TS прервано для некоторых пользователей после изменения сертификата RemoteApp
Недавно мы переиздали наш подстановочный сертификат GoDaddy с помощью алгоритма подписи SHA256 (к вашему сведению, он все еще отзывает старый сертификат через 72 часа, даже если вы не вводите его повторно, поэтому вам все равно придется вводить его заново). Мы используем этот сертификат для наших RemoteApps, RDP терминальных серверов, RDGateway и RDWeb (IIS).
Когда я переключаюсь на новый подстановочный сертификат в "Диспетчере удаленных приложений"->"Настройки цифровой подписи" на данном сервере терминалов (сервере узла сеансов AKA), соединения из RDWeb для приложений, опубликованных на этом сервере терминалов, не работают для некоторых пользователей, но соединения, использующие файл.rdp отлично работает для всех пользователей. Кроме того, и это самая странная вещь, которую я когда-либо видел, неправильный пользователь регистрируется как лишенный доступа к шлюзу. Если я изменю сертификат на старый, отозванный сертификат для этого параметра, то все будет работать.
Рабочая настройка:
- Все серверы Windows 2008 R2 Datacenter
- RDGateway+RDWeb - rdsgateway.contoso.com (новый подстановочный сертификат установлен как для IIS, так и для rdgateway)
- TS - ts1.contoso.com (новый групповой сертификат установлен только для RDP, старый сертификат установлен для RemoteAPP)
Нерабочая настройка:
- Все серверы Windows 2008 R2 Datacenter
- RDGateway+RDWeb - rdsgateway.contoso.com (новый подстановочный сертификат установлен как для IIS, так и для rdgateway)
- TS - ts1.contoso.com (новый сертификат подстановки установлен для RDP, новый сертификат установлен для RemoteAPP)
При запуске из RDWeb с использованием пользователя "CONTOSO\bob" выдается следующая ошибка:
Удаленный рабочий стол не может подключиться к удаленному компьютеру "ts1.contoso.com" по одной из следующих причин: 1) Ваша учетная запись пользователя не указана в списке разрешений шлюза удаленных рабочих столов 2) возможно, вы указали удаленный компьютер в формате NetBIOS...
Когда я просматриваю журнал событий "Microsoft-Windows-TerminalServices-Gateway/Operational", я вижу следующую ошибку:
Пользователь "CONTOSO\alice" на клиентском компьютере "123.123.123.123" не соответствует требованиям политики авторизации ресурса и поэтому не авторизован для ресурса "ts1.contoso.com". Произошла следующая ошибка: "23002".
Что здесь происходит? Почему изменение сертификата подписи RemoteApp заставляет шлюз думать, что это другой пользователь, подключающийся?
1 ответ
Нашел эту страницу после того, как испытал ту же проблему. Для нас решением было добавить порт 3389 в loopback (иначе известный как Hairpin NAT) на нашем брандмауэре.
Некоторые дополнительные детали:
Замена сертификата была сложнее, чем его установка в первый раз, но я думаю, что мы сделали это правильно, и приложения работали в течение дня или двух. Пользователи начали получать ошибки при запуске, и мы завершили работу с помощью скрипта powershell здесь https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80 чтобы повторно опубликовать полное доменное имя сервера.
Я думаю, что этот сценарий должен был установить полное доменное имя в части конфигурации, которая никогда не была указана ранее, в результате чего шлюз удаленных рабочих столов ссылается на себя через свое полное доменное имя для передачи запросов. Эти запросы не были выполнены, поскольку наш пограничный межсетевой экран разрешил только 80 и 443 для входящих и петлевых запросов.
Добавление порта 3389 к правилу обратной связи на брандмауэре немедленно решило проблему.