Configuring SSO (Single Sign-On) Authentication on Windows Server RDS

Single Sign-On (SSO) is the technology that allows an authenticated (signed on) user to access other domain services without re-authentication. Applied to the Remote Desktop Service, SSO allows a user logged on to the domain computer not to re-enter account credentials (username and password) when connecting to the RDS servers or launching published RemoteApps.

In this article, we’ll describe the peculiarities of configuring the transparent SSO (Single Sign-On) authentication on RDS servers running Windows Server 2016 and 2012 R2.

System requirements:

• The Connection Broker server and all RDS servers must be running Windows Server 2012 or later;
• SSO works only in the domain environment: Active Directory user accounts must be used, the RDS servers and user’s workstations must be included in the AD domain;
• The RDP 8.0 or later must be used on the rdp clients (it won’t be possible to install this version of the RDP client in Windows XP);
• The following OS versions are supported on the rdp-client side: Windows 10, 8.1 or 7;
• SSO works only with password authentication (smart cards are not supported);
• The RDP Security Layer in the connection settings should be set to Negotiate or SSL (TLS 1.0), and encryption mode to High or FIPS Compliant.

The procedure of Single Sign-On configuration consists of the following steps:

• You need to issue and assign an SSL certificate on RD Gateway, RD Web and RD Connection Broker servers;
• Web SSO has to be enabled on RDWeb server;
• The group policy for credentials delegation has to be configured;
• The certificate thumbprint has to be added to the trusted .rdp publishers using GPO.

Firstly, you need to issue and assign an SSL certificate. In the EKU (Enhanced Key Usage) certificate property, the Server Authentication identifier must be present. We won’t describe the procedure of obtaining the SSL certificate since it goes beyond the scope of this article (you can generate a self-signed SSL certificate yourself, but you will have to deploy it to the trusted cert on all clients using the group policy).

The certificate is assigned in the Certificates section of RDS Deployment properties.

Then you have to enable “Windows Authentication” on all servers with Web Access role for IIS RDWeb directory and disable “Anonymous Authentication”.

After you save the changes, restart IIS:

iisreset /noforce
If you are using RD Gateway, make sure that it is not used for connection of the internal clients (Bypass RD Gateway server for local address option has to be checked).

The next step is the configuration of the credentials delegation policy. Create a new domain GPO and link it to the OU with users (computers) who need to allow SSO access to the RDS server. If you want to allow SSO for all domain users, it is acceptable to edit the Default Domain Policy.

This policy is located in the following GPO section: Computer Configuration -> Policies -> Administrative Templates -> System -> Credential Delegation -> Allow delegation defaults credential. The policy allows certain servers to access the credentials of Windows users:

• The policy has to be enabled (Enabled);
• You have to add the names of RDS servers to the list of servers to which the client can automatically send user credentials to perform SSO authentication. The format of adding a server is as follows: TERMSRV/rd.contoso.com (note that all TERMSRV characters must be in upper case). If you have to give this permission to all terminal servers in the domain (less secure), you can use this construction: TERMSRV/*.contoso.com .

Then, to prevent a window warning of the remote application publisher being untrusted to appear, add the address of the server with the Connection Broker role to the trusted zone on the client computers using the policy “Site to Zone Assignment List” (similar to the article How to disable Open File security warning on Windows 10): User/Computer Configuration -> Administrative Tools -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page.

Specify FQDN server name RDCB and Zone 2 (Trusted sites).

Then enable Logon options policy in User/Computer Configuration -> Administrative Tools -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security -> Trusted Sites Zone and in the dropdown list select “Automatic logon with current username and password”.

After updating the group policies on the client, if you try to start the RemoteApp, a password prompt won’t appear, but a warning window will appear:

Do you trust the publisher of this RemoteApp program?

To prevent this message from being displayed each time at user logon, you need to get the SSL certificate thumbprint on the RD Connection Broker and add it to the list of trusted rdp publishers. To do this, run the PowerShell command on the RDS Connection Broker server:

Copy the value of the certificate thumbprint and add it to the list of thumbprints in the policy Specify SHA1 thumbprints of certificates representing RDP publishers (Computer Configuration -> Administrative Templates -> Windows Desktop Services -> Remote Desktop Connection Client).

Now the SSO configuration is over, and after the policies have been applied, the user can connect to the Windows Server RDS farm using RDP without re-entering password.

Now, when you start mstsc.exe (Remote Desktop Connection client) and specify the name of the RDS server, the UserName field will automatically display the user name in the format (user@domain.com) with the caption:

Your Windows logon credentials will be used to connect.

To use RD Gateway with SSO, you need to enable the policy “Set RD Gateway Authentication Method” (User Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> RD Gateway) and set its value to “Use Locally Logged-On Credentials”.

To use Web SSO on RD Web Access, please note that it is recommended to use Internet Explorer with enabled Active X component named Microsoft Remote Desktop Services Web Access Control (MsRdpClientShell).

Oh, MSBRO !

Сетевые заметки системного администратора

Прозрачная авторизация на терминальных серверах (SSO)

Одним из основных неудобств для пользователя при запуске удаленного рабочего стола или опубликованного на терминальном сервере приложения является необходимость ввода своих учетных данных.

Ранее для решения этой проблемы использовался механизм сохранения учетных данных в настройках клиента удаленного рабочего стола.

Однако данный способ имеет несколько существенных недостатков.

Например, при периодической смене пароля приходилось изменять его вручную в настройках терминального клиента.

В связи с этим, для упрощения работы с удаленным рабочим столом в Windows Server 2008 появилась возможность использования технологии прозрачной авторизации Single Sign-on (SSO). Благодаря ей пользователь при входе на терминальный сервер может использовать учетные данные, введенные им при логине на свой локальный компьютер, с которого происходит запуск клиента удаленного рабочего стола.

В статье приведен обзор алгоритма работы технологии прозрачной авторизации Single Sign-On и поставщика услуг безопасности Credential Security Service Provider (CredSSP). Рассмотрен способ настройки клиентской и серверной частей. Также освещен ряд практических вопросов связанных с прозрачной авторизацией для служб удаленных рабочих столов.

Теоретическая информация

Технология SSO позволяет сохранение учетных данных пользователя и автоматическую передачу их при соединении с терминальным сервером. С помощью групповых политик можно определить сервера, для которых будет использоваться данный способ авторизации. В этом случае, для всех остальных терминальных серверов вход будет осуществляться традиционным образом: посредством ввода логина и пароля.

Впервые механизмы прозрачной авторизации появились в Windows Server 2008 и Windows Vista. благодаря новому поставщику услуг безопасности CredSSP. С его помощью кэшированные учетные данные передавались через безопасный канал (используя Transport Layer Security (TLS)). Впоследствии Microsoft выпустила соответствующие обновления для Windows XP SP3.

Рассмотрим это более подробно. CredSSP может использоваться в следующих сценариях:

• для сетевого уровня аутентификации (NLA), позволяя пользователю быть узнанным до полной установки соединения;

• для SSO, сохраняя учетные данные пользователя и передавая их на терминальный.

При восстановлении сеанса внутри фермы, CredSSP ускоряет процесс установки соединения, т.к. терминальный сервер определяет пользователя без установки полноценного соединения (по аналогии c NLA).

Процесс аутентификации происходит по следующему алгоритму.

1. Клиент инициирует установку безопасного канал с сервером, используя TLS. Сервер передает ему свой сертификат, содержащий имя, удостоверяющий центр и публичный ключ. Сертификат сервера может быть самоподписанным.
2. Между сервером и клиентом устанавливается сессия. Для неё создается соответствующий ключ, который в дальнейшем будет участвовать в шифровании. CredSSP использует протокол Simple and Protected Negotiate (SPNEGO) для взаимной аутентификации сервера и клиента так, чтобы каждый из них мог доверять друг другу. Этот механизм позволяет клиенту и серверу выбрать механизм аутентификации (например, Kerberos или NTLM).
3. Для защиты от перехвата, клиент и сервер поочередно шифруют сертификат сервера, используя ключ сессии, и передают его друг другу.
4. Если результаты обмена и исходный сертификат совпадают, CredSSP на клиенте посылает учетные данные пользователя на сервер.

Таким образом, передача учетных данных происходит по зашифрованному каналу с защитой от перехвата.

Настройка

Поставщик услуг безопасности CredSSP является частью операционной системы и входит в состав Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2. Кроме того, он может быть установлен в качестве отдельного обновления на Windows XP SP3. Этот процесс подробно описан в статье «Description of the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3 ». Для установки и включения CredSSP на Windows XP SP3 необходимо выполнить следующие действия.

1. Запустить редактор реестра regedit и перейти в ветку:

Remote Desktop Services/Terminal Services — Настройка прозрачной доменной авторизации (Single Sign-On)

02.03.2010
Основное требование для SSO на стороне клиента:
Клиентская ОС: Microsoft Windows XP SP3, Microsoft Windows Vista SP1, Microsoft Windows 7

Для клиентов на базе Windows Vista никаких дополнительных настроек не требуется, т.к. данная функциональность уже присутствует в операционной системе, минимальное требование это наличие SP1. Для Windows 7 необходимый функционал работает в RTM.

Для клиентов на базе Windows XP SP3 требуется правка системного реестра:

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders
!Дописать! (не заменить а именно дополнить) значение параметра SecurityProviders строкой: credssp.dll

HKLM\SYSTEM\CurrentControlSet\Control\Lsa
!Дописать! (не заменить а именно дополнить) значение параметра Security Packages строкой: tspkg

Вся информация по этому поводу изложена в статье Microsoft — Description of the Credential Security Service Provider (CredSSP) in Windows XP Service Pack 3
Также привожу ссылку на пошаговую инструкцию по настройке доменных групповых политик для включения на клиентских компьютерах функции Single Sign-On — How to enable Single Sign-On for my Terminal Server connections
Если в трёх словах — то для того чтобы у клиентских компьютеров работала прозрачная авторизация требуется в доменных групповых политиках настраивающих клиентские ПК изменить следующие параметры:

Внимание! Перечисленные ниже параметры GPO доступны только при просмотре оснастки gpedit.msc в операционных системах Windows Vista / Windows Server 2008 и выше.

Конфигурация компьютера > Административные шаблоны > Система > Передача учетных данных

«Разрешить передачу учетных данных, настроенных по умолчанию» – Включить.
«Связать настройки системы по умолчанию с введенными ранее» – Включить и в список серверов (по кнопке «Показать») добавить запись типа:

TERMSRV/* (разрешена передача учётных данных любым терминальным серверам)
или
TERMSRV/*.mydom.com (разрешена передача учётных данных только к терминальным серверам домена mydom.com)

«Разрешить сохраненные учетные данные с проверкой подлинности сервера «только NTLM» – Включено
Список серверов в этом параметре настроить аналогично.

Замечание: для того чтобы это действительно работало при подключении к серверу имя сервера необходимо указывать полностью (FQDN).
После написания полного имени сервера клиент RDP в поле имя пользователя автоматически подставит имя в формате user@domain .
Сохранив таким образом на рабочем столе пользователя RDP ярлык мы предоставим ему возможность одним кликом мыши попасть на терминальный сервер без дополнительного ввода его учётных данных.

Update 23.12.2011

При попытке заставить работать SSO на Windows XP SP3 с фермой RD Connection Broker можно столкнуться с ситуацией когда после входа на сервер возникает запрос ввода учетных данных. Для разрешения этой проблемы нужно установить обновление, доступное в статье KB953760 — When you enable SSO for a terminal server from a Windows XP SP3-based client computer, you are still prompted for user credentials when you log on to the terminal server. Через WSUS данное обновление не доступно и поэтому нужно его скачивать и устанавливать отдельно.