Windows Server 2012 R2 Remote Desktop – сертификаты. Внутренние или публичные?

Модель использования сертификатов в Remote Desktop Deployments реализованная в Windows Server 2012/R2 имеет одну особенность, которая иной раз выходит боком.

Большинство современных клиентов RDP жёстко соблюдают требования безопасности: если клиент не смог проверить всю цепочку доверия и отзыва сертификатов, то подключение не выполняется (в лучшем случае возникают дополнительные окна с вопросами, не работает SSO). Поэтому операции проверки доверия и CRL становятся критическими.

Когда большинство компьютеров, с которых производится доступ к RD коллекциям, являются доменными, то использование внутренних сертификатов очень удобно: центр сертификатов доступен, корневой сертификат приезжает автоматически, проверки отзыва сертификатов (CRL) и доверие – всё работает прозрачно.

Но как только появляются пользователи, которые подключаются извне к опубликованным корпоративным ресурсам с недоменных компьютеров (домашние компьютеры, планшеты, мобильные устройства), появляется проблема: на эти устройства нужно установить корневой доменный сертификат и обеспечить проверку CRL; обеспечение проверки CRL требует публикации этого сервиса в Интернет. Сама операция распространения корневого доменного сертификата достаточно затратная: пользователю нужны специальные знания, нужно где-то найти этот сертификат, правильно установить, при этом скорее всего пользователю придётся обращаться в техническую поддержку. С учётом того, что пользователи меняют мобильные устройства намного чаще, чем обычные компьютеры, но не так часто, чтобы выучить процедуру назубок, то затраты на техническую поддержку ощутимо возрастают. Всего этого можно избежать, если использовать для публикации корпоративных ресурсов публичный сертификат. (Описанный сценарий можно считать типичным и массовым; из него, конечно, выпадают случаи, когда компания реализует специальные схемы повышенной безопасности.)

И вот тут возникают интересные нюансы. Если Sharepoint Server и Exchange Server позволяют использовать в корпоративной сети доменные сертификаты и при этом наружу могут быть опубликованы с публичным сертификатом, то в случае RD инфраструктуры это не работает. Так вы можете опубликовать наружу RD Web с публичным сертификатом, но это нас не спасает, т.к. далее есть ещё три места, где используется сертификат. Первое, RDP файл предоставляемый RD Web сервисом должен быть подписан сертификатом. Второе, RD Gateway использует сертификат для построения TLS туннеля с внешним клиентом. И наконец, третье, клиент аутентифицирует брокер с помощью сертификата. Все три последних сертификата (физически это может быть один сертификат) одновременно работают как для внутренних клиентов, так и для внешних. И это невозможно изменить.

Таким образом в случае RD инфраструктуры целесообразно использовать либо только внутренние сертификаты, либо только публичные. И как только компания принимает новую политику безопасности и разрешает доступ к корпоративным ресурсам извне, мы обречены на использование публичных сертификатов в RD инфраструктуре.

При этом внутренние клиенты также будут использовать внешние сертификаты, должны доверять этим сертификатам и должны иметь возможность проверять CRL. Если клиент не имеет доступа к Интернет, либо доступ в сеть Интернет сильно ограничен, а такое вполне может быть для некоторых корпоративных компьютеров, то возникает проблема: клиент не сможет работать с публичными сертификатами. Вот и проблема: внутренние сертификаты использовать дорого, публичные невозможно. Решение у этой проблемы есть.

1. Если корневой сертификат публичного удостоверяющего центра отсутствует на клиенте, то его можно туда доставить через групповые политики
2. Как быть с CRL? Учитывая изолированность рабочего места, допустимо отключить проверку CRL. Если вы это не сделаете, то у вас не будет работать SSO. Отключить проверку можно добавив ключ реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors со значением равным 1. (Это описано тут)

Теперь вы знаете, как правильно планировать сертификаты для RD Deployment в Windows Server 2012/R2.

Полезные ссылки:

Windows Server 2012 R2 Remote Desktop – Single Sign-On в RD Deployment

Windows Server 2012 R2 Remote Desktop – сертификаты

Реклама