Случай из практики — 9

Случай с сертификатом для RD Gateway.

На этот раз случай небольшой, но интересный.  Один из клиентов попросил настроить удаленный доступ к приложению на второстепенном сервере. Вооружившись чаем и моим контрольным списком(я сам в него регулярно «подглядываю») я приступил к работе. Основная часть работы была сделана менее чем за 40 минут. Все было настроено, сертификат выпущен, RemoteApp приложение опубликовано в виде rdp-файла. Однако получить  доступ к RemoteApp приложению через RD Gateway я не смог. В ошибке были явные указания на проблему с сертификатом на сервере RD Gateway. В оснастке RD Gateway Manager я увидел следующую картину

Я попытался еще раз принудительно назначить нужный сертификат, однако результата это не дало.

Изучение журнала ошибок показало такую вот ошибку:

Event ID: 103
Task Category: (1)
Level: Critical
User: NETWORK SERVICE
Computer: brok-rodc-01
Description:
The Remote Desktop Gateway service does not have sufficient permissions to access the Secure Sockets Layer (SSL) certificate that is required to accept connections. To resolve this issue, bind (map) a valid SSL certificate by using RD Gateway Manager. For more information, see "Obtain a certificate for the RD Gateway server" in the RD Gateway Help. The following error occurred: "2148081675".

Она и помогла решить проблему, в ошибке явно указывалось на проблему с  недостаточностью прав у учетной записи NETWORK SERVICE. Я открыл оснастку «Сертификаты» для учетной записи локального компьютера(имеется в виду сервер RD Gateway, так что корректнее было бы сказать для учетной записи сервера), зашел в персональные сертификаты. Выделил нужный мне сертификат, и через контекстное меню добрался до пункта «Mange Private Keys». Там меня ожидал вот такой вот сюрприз:

Учетной записи NETWORK SERVICE не было в списке ACL посему доступа она и не получала. После того как я добавил эту УЗ  и дал ей необходимые права- у меня все заработало. Меня только беспокоила незнакомая учетная запись, которую я удалил.  По ее номеру я понял, что это не УЗ пользователя, а т.н. «Хорошо известный SID», что и подтвердил technet:

SID: S-1-5-5-X-Y
 Название: Сеанс входа в систему
 Описание: Сеанс входа в систему. Значения X и Y для этих идентификаторов SID меняются в каждом сеансе.

Если кому интересно может самостоятельно почитать здесь. Как я понял многие вещи имеют такой SID, в том числе Рабочий стол, обычно при выходе из системе этот SID удаляется.

Не понятным осталось почему для NETWORK SERVICE не были заданны нужные права.

P.S. Что касается доменной среды, когда центр сертификации работает в режиме Enterprise, возможна проблема с выпуском сертификата, когда в оснастке центра сертификации нет шаблона «Web Server». Для этого необходимо зайти в «Certeficete Template Console» и опубликовать сертификат в AD. Кроме того надо не забыть там же на вкладе безопасность дать права группе Authenticated Users право Enroll.

P.S.#2 В данном сценарии как в домене, так и во вне доменной среде начинает появляться ошибка Schanell

 

Log Name: System
Source: Schannel
Event ID: 36888
User: SYSTEM
Description:
The following fatal alert was generated: 10. The internal error state is 1203.

Как я понял из справки, ошибка генерируется  IIS когда клиент пытается получить доступ по протоколу HTTP вместо HTTPS. Возможно, это как то связанно с сертификатом с полями SAN, но Майкрософт предлагает отключить логирование ошибок Schanell. Если разберусь обновлю статью.

Метки: сертификат для RDGateway, PKI, RDG