Прозрачная авторизация на RDS с помощью SSO (Single Sign-On)

Single Sign-On (SSO — технология единого входа) это технология, позволяющая уже аутентифицированному (вошедшему в систему) пользователю получать доступ к другим сервисам без повторной аутентификации. Применительно к технологии терминальных серверов Remote Desktop Services, SSO позволяет избавить пользователя, выполнившего вход на доменном компьютере, от многократного ввода имени и пароля своей учетной записи в окне RDP клиента при подключении к RDS серверам или запуске опубликованных приложений RemoteApp.

В этой статье мы опишем особенности настройки прозрачной авторизации (Single Sign-On) пользователей на серверах RDS под управлением Windows Server 2016 и 2012 R2.

Требования к окружению:

• Сервер Connection Broker и все RDS сервера должны работать под управлением Windows Server 2012 или выше;
• SSO работает только в доменном окружении: должны использоваться учетные записи пользователей Active Directory, а RDS сервера и рабочие станции пользователей должны быть включены в домен;
• На RDP клиентах должна использоваться версия клиента RDP 8.0 и выше (не получится установить эту версию RDP клиента в Windows XP);
• На стороне клиента поддерживаются следующие версии Windows 10 / 8.1 / 7;
• SSO работает с парольной аутентификацией (смарт карты не поддерживаются);
• Уровень безопасности RDP (Security Layer) в настройках подключения должен быть установлен в Negotiate или SSL (TLS 1.0), а шифрование High или FIPS Compliant.

Процедура настройки Single Sign-On состоит из следующих этапов:

• Необходимо выпустить и назначить SSL сертификат на серверах RD Gateway, RD Web и RD Connection Broker;
• Включить Web SSO на сервере RDWeb;
• Настроить групповую политику делегирования учетных данных;
• Через GPO добавить отпечаток сертификата в доверенные издатели .rdp.

Итак, в первую очередь нужно выпустить и назначить SSL сертификат. В EKU (Enhanced Key Usage) сертификата должно обязательно присутствовать идентификатор Server Authentication. Мы опускаем процедуру получения сертификата, т.к. это она выходит за рамки статьи (можно сгенерировать самоподписанный SSL сертификат, но его придется добавлять в доверенные на всех клиентах через GPO).

SSL сертификат привязывается в свойствах RDS Deployment в подразделе Certificates.

Далее на всех серверах c ролью Web Access для каталога IIS RDWeb нужно включать “Windows Authentication” и отключить анонимную проверку подлинности (Anonymous Authentication).

После сохранения изменений, IIS нужно перезапустить: iisreset /noforce

Если используется шлюз RD Gateway, убедитесь, что он не используется для подключения внутренних клиентов (должна стоять галка Bypass RD Gateway server for local address).

Следующий этап – настройка политики делегирования учетных данных. Создайте новую доменную GPO и привяжите ее к OU с пользователями (компьютерами), которым нужно разрешить SSO доступ на RDS сервера. Если вы хотите разрешить SSO для всех пользователей домена, допустимо редактировать Default Domain Policy.

Эта политика находится в разделе GPO Computer Configuration -> Administrative Templates -> System -> Credential Delegation -> Allow delegation defaults credential (Конфигурация компьютера -> Административные шаблоны -> Передача учетных данных -> Разрешить передачу учетных данных, установленных по-умолчанию). Политика разрешает определенным серверам доступ к учетным данным пользователей Windows.

• Включите политику (Enabled);
• В список серверов нужно добавить имена RDS серверов, на которые клиент может автоматически отправлять учетные данные пользователя для выполнения SSO авторизации. Формат добавления сервера: TERMSRV/rd.contoso.com. (обратите внимание, что все символы TERMSRV должны быть в верхнем регистре). Если нужно предоставить такое право всем терминальным системам домена (менее безопасно), можно воспользоваться такой конструкцией: TERMSRV/*.contoso.com .

Далее, чтобы избежать появления окна с предупреждением о надежности издателя удаленного приложения, нужно с помощью GPO на клиентских компьютерах добавить адрес сервера с ролью Connection Broker в доверенную зону с помощью политики «Список назначений зоны безопасности для веб-сайтов» (по аналогии со статьей Как убрать предупреждение системы безопасности при открытии файла в Windows):

User/Computer Configuration -> Administrative Tools -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page-> Site to Zone assignment list (Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Internet Explorer -> Панель управления браузером -> Вкладка безопасность)

Укажите FQDN имя сервера RDCB и зону 2 (Trusted sites).

Далее нужно включить политику Logon options (Параметры входа) в разделе User/Computer Configuration -> Administrative Tools -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security -> Trusted Sites Zone (Административные шаблоны -> Компоненты Windows -> Internet Explorer -> Панель управления браузером -> Вкладка безопасность -> Зона надежных сайтов) и в выпадающем списке выбрать ‘Automatic logon with current username and password‘ (Автоматический вход в сеть с текущим именем пользователя и паролем).

После обновления политик на клиенте, при попытке запустить RemoteApp приложение, запрос пароля не появится, но появится окно с предупреждением о доверии к издателю данной программы RemoteApp:

Do you trust the publisher of this RemoteApp program?

Чтобы это сообщение не выводилось каждый раз при подключении пользователя, вам нужно получить отпечаток SSL сертификата (certificate thumbprint) RD Connection Broker и добавить его в список доверенных издателей rdp. Для этого на сервере RDS Connection Broker выполните команду PowerShell:

Скопируйте значение отпечатка сертификата и добавьте его в список отпечатков политики Specify SHA1 thumbprints of certificates representing RDP publishers (Указать отпечатки SHA1 сертификатов, представляющих доверенных издателей RDP) в секции Computer Configuration -> Administrative Templates -> Windows Components -> Windows Desktop Services -> Remote Desktop Connection Client (Административные шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Клиент подключения к удаленному рабочему столу).

На этом настройка SSO закончена, и после применения политик, пользователь должен подключатся к ферме RDS по протоколу RDP без повторного ввода пароля.

Теперь при запуске клиента mstsc.exe (Remote Desktop Connection), если вы укажете имя RDS сервера, в поле UserName автоматически подставится имя пользователя в формате (user@domain.com).

Your Windows logon credentials will be used to connect.

Чтобы использовать RD Gateway с SSO нужно для пользователей включить политику Set RD Gateway Authentication Method (User Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> RD Gateway) и установить ее значение на Use Locally Logged-On Credentials.

Для использования Web SSO на RD Web Access, обратите внимание, что рекомендуется использовать Internet Explorer с включенным Active X компонентом MsRdpClientShell (Microsoft Remote Desktop Services Web Access Control).

Enterprise Single Sign-On Basics

To understand Enterprise Single Sign-On (SSO), it is useful to look at the three types of Single Sign-On services available today: Windows integrated, extranet, and intranet. These are described in the following sections, with Enterprise Single Sign-On falling into the third category.

Windows Integrated Single Sign-On

These services enable you to connect to multiple applications within your network that use a common authentication mechanism. These services request and verify your credentials after you log into the network, and use your credentials to determine the actions that you can perform based on your user rights. For example, if applications integrate using Kerberos, after the system authenticates your user credentials, you can access any resource in the network that is integrated with Kerberos.

Extranet Single Sign-On (Web SSO)

These services enable you to access resources over the Internet by using a single set of user credentials. The user provides a set of credentials to log on to different Web sites that belong to different organizations. An example of this type of Single Sign-On is the Windows Live ID for consumer-based applications. For federated scenarios, Active Directory Federation Services enables Web SSO.

Server-Based Intranet Single Sign-On

These services enable you to integrate multiple heterogeneous applications and systems in the enterprise environment. These applications and systems might not use common authentication. Each application has its own user directory store. For example, in an organization, Windows uses Active Directory directory service to authenticate users, and mainframes use IBM’s Resource Access Control Facility (RACF) to authenticate the same users. Within the enterprise, middleware applications integrate the front-end and back-end applications. Enterprise Single Sign-On enables users in the enterprise to connect to both the front end and back end while using only one set of credentials. It enables both Windows Initiated Single Sign-On (in which the initial request is made from the Windows domain environment) and Host Initiated Single Sign-On (in which the initial request is made from a non-Windows domain environment) to access a resource in the Windows domain.

In addition, Password Synchronization simplifies administration of the SSO database, and keeps passwords in sync across user directories. You can do this by using password synchronization adapters, which you can configure and manage using the Password Synchronization tools.

Enterprise Single Sign-On System

Enterprise Single Sign-On provides services to store and transmit encrypted user credentials across local and network boundaries, including domain boundaries. SSO stores the credentials in the Credential database. Because SSO provides a generic single sign-on solution, middleware applications and custom adapters can take advantage of SSO to securely store and transmit user credentials across the environment. End users do not have to remember different credentials for different applications.

SSO System Components

The Single Sign-On system consists of a Credential database, a master secret server, and one or more Single Sign-On servers.

The SSO system contains affiliate applications that an administrator defines. An affiliate application is a logical entity that represents a system or sub-system such as a host, back-end system, or line-of-business application to which you are connecting using Enterprise Single Sign-On. Each affiliate application has multiple user mappings; for example, it has the mappings between the credentials for a user in Active Directory and their corresponding RACF credentials.

The Credential database is the SQL Server database that stores the information about the affiliate applications, as well as all the encrypted user credentials to all the affiliate applications.

The master secret server is the Enterprise Single Sign-On server that stores the master secret. All other Single Sign-On servers in the system obtain the master secret from the master secret server.

The SSO system also contains one or more SSO servers. These servers do the mapping between the Windows and back-end credentials and look up the credentials in the Credential database. Administrators use them to maintain the SSO system.

You can have only one master secret server and only one Credential database in your SSO system. The Credential database can be remote to the master secret server.

Enterprise Single Sign-On has limited functionality in a workgroup environment, supporting only config store scenarios. A domain environment is required for Single Sign-On scenarios, and Password Sync scenarios.

Использование единого входа (SSO) через VPN-подключения и беспроводную сеть How to use single sign on (SSO) over VPN and Wi-Fi connections

В этом разделе объясняются требования, необходимые для Sign-On единого доступа (SSO) к локальному домену через Wi-Fi или VPN-соединения. This topic explains requirements to enable Single Sign-On (SSO) to on-premises domain resources over WiFi or VPN connections. Сценарий: The scenario is:

• Подключение к сети с помощью Wi-Fi или VPN. You connect to a network using Wi-Fi or VPN.
• Вы хотите использовать учетные данные, которые вы используете для проверки подлинности WiFi или VPN, чтобы также проверить подлинность запросов на доступ к подключаемой к нему доменной ресурс, без запроса отдельного запроса на учетные данные домена. You want to use the credentials that you use for the WiFi or VPN authentication to also authenticate requests to access a domain resource you are connecting to, without being prompted for your domain credentials separately.

Например, необходимо подключиться к корпоративной сети и получить доступ к внутреннему веб-сайту, который требует комплексной проверки подлинности Windows. For example, you want to connect to a corporate network and access an internal website that requires Windows integrated authentication.

На высоком уровне это работает так, что учетные данные, используемые для проверки подлинности подключения, помещаются в Диспетчер учетных данных в качестве учетных данных по умолчанию для сеанса logon. At a high level, the way this works is that the credentials that are used for the connection authentication are put in Credential Manager as the default credentials for the logon session. Диспетчер учетных данных — это место, где учетные данные в ОС можно хранить для определенных доменных ресурсов на основе целевого имени ресурса. Credential Manager is a place where credentials in the OS are can be stored for specific domain resources based on the targetname of the resource. Для VPN стек VPN сохраняет учетные данные как по умолчанию сеанса. For VPN, the VPN stack saves its credential as the session default. Для WiFi это делает EAP. For WiFi, EAP does it.

Учетные данные помещаются в диспетчер учетных данных в качестве учетных данных «*Session». The credentials are put in Credential Manager as a «*Session» credential. Учетные данные «*Session» предполагают, что он действителен для текущего сеанса пользователя. A «*Session» credential implies that it is valid for the current user session. Учетные данные также очищаются при отключении подключения к Wi-Fi или VPN. The credentials are also cleaned up when the WiFi or VPN connection is disconnected.

Если пользователь пытается получить доступ к ресурсу домена, например с помощью Edge, у Edge есть право на корпоративную проверку подлинности, поэтому WinInet может освободить учетные данные, которые он получает от диспетчера учетных данных, в запрашиваемую службу SSP. When the user tries to access a domain resource, using Edge for example, Edge has the right Enterprise Authentication capability so WinInet can release the credentials that it gets from the Credential Manager to the SSP that is requesting it. Дополнительные сведения о возможностях корпоративной проверки подлинности см. в декларациях о возможностях приложения. For more information about the Enterprise Authentication capability, see App capability declarations.

Местный орган безопасности будет смотреть на приложение устройства, например приложение Универсальной платформы Windows (UWP), чтобы узнать, имеет ли оно нужные возможности. The local security authority will look at the device application, such as a Universal Windows Platform (UWP) application, to see if it has the right capability. Если приложение не UWP, это не имеет значения. If the app is not UWP, it does not matter. Но если это приложение UWP, оно будет смотреть на возможности устройства для проверки подлинности предприятия. But if it is a UWP app, it will look at the device capability for Enterprise Authentication. Если у него есть такие возможности и если ресурс, к который вы пытаетесь получить доступ, находится в зоне Интрасети в Internet Options (ZoneMap), то учетные данные будут освобождены. If it does have that capability and if the resource that you are trying to access is in the Intranet zone in the Internet Options (ZoneMap), then the credential will be released. Это поведение помогает предотвратить неправильное использование учетных данных сторонними лицами. This behavior helps prevent credentials from being misused by untrusted third parties.

Зона Интрасети Intranet zone

Для зоны Интрасети по умолчанию разрешается только одноклейка имен, таких как Http://finance . For the Intranet zone, by default it only allows single-label names, such as Http://finance. Если ресурс, к который необходимо получить доступ, имеет несколько меток домена, то обходным решением является использование CSP реестра. If the resource that needs to be accessed has multiple domain labels, then the workaround is to use the Registry CSP.

Настройка ZoneMap Setting the ZoneMap

ZoneMap управляется с помощью реестра, который можно установить через MDM. The ZoneMap is controlled using a registry that can be set through MDM. По умолчанию однометные имена, http://finance например, уже находятся в зоне интрасети. By default, single-label names such as http://finance are already in the intranet zone. Для нескольких имен меток, таких как http://finance.net ZoneMap, необходимо обновить. For multi-label names, such as http://finance.net, the ZoneMap needs to be updated.

Политика MDM MDM Policy

Пример OMA URI: OMA URI example:

./Vendor/MSFT/Registry/HKU/S-1-5-21-2702878673-795188819-444038987-0 2781/Software/Microsoft/Windows/CurrentVersion/Internet%20Settings/ZoneMap/Domains/ /* в качестве значения 1 для каждого из доменов, которые вы хотите в SSO с вашего устройства. ./Vendor/MSFT/Registry/HKU/S-1-5-21-2702878673-795188819-444038987-2781/Software/Microsoft/Windows/CurrentVersion/Internet%20Settings/ZoneMap/Domains/ /* as an Integer Value of 1 for each of the domains that you want to SSO into from your device. Это добавляет указанные домены в зону Интрасети браузера Edge. This adds the specified domains to the Intranet Zone of the Edge browser.

Требования к учетным данным Credential requirements

Для VPN после проверки подлинности в диспетчер учетных данных будут добавлены следующие типы учетных данных: For VPN, the following types of credentials will be added to credential manager after authentication:

• Имя пользователя и пароль Username and password
• Проверка подлинности на основе сертификата: Certificate-based authentication:
  • Сертификат KSP TPM TPM KSP Certificate
  • Сертификаты KSP программного обеспечения Software KSP Certificates
  • Сертификат смарт-карты Smart Card Certificate
  • Сертификат Windows Hello для бизнеса Windows Hello for Business Certificate

Имя пользователя также должно включать домен, который можно получить по подключению (VPN или WiFi). The username should also include a domain that can be reached over the connection (VPN or WiFi).

Шаблоны сертификатов пользователей User certificate templates

Если учетные данные основаны на сертификатах, элементы в следующей таблице необходимо настроить для шаблонов сертификатов, чтобы убедиться, что они также могут использоваться для проверки подлинности клиентов Kerberos. If the credentials are certificate-based, then the elements in the following table need to be configured for the certificate templates to ensure they can also be used for Kerberos client authentication.

Элемент Template Template element	Настройка Configuration
SubjectName SubjectName	Отличительное имя пользователя (DN), в котором компоненты домена отличимого имени отражают внутреннее пространство имен DNS, когда SubjectAlternativeName не имеет полностью квалифицированного upN, необходимого для поиска контроллера домена. The user’s distinguished name (DN) where the domain components of the distinguished name reflects the internal DNS namespace when the SubjectAlternativeName does not have the fully qualified UPN required to find the domain controller. Это требование особенно актуально в многолесных средах, так как обеспечивает местонахождение контроллера домена. This requirement is particularly relevant in multi-forest environments as it ensures a domain controller can be located.
SubjectAlternativeName SubjectAlternativeName	Полностью квалифицированный upN пользователя, в котором компонент доменного имени пользователя upN совпадает с пространством имен DNS внутреннего домена организаций. The user’s fully qualified UPN where a domain name component of the user’s UPN matches the organizations internal domain’s DNS namespace. Это требование особенно актуально в многолесных средах, так как гарантирует, что контроллер домена может быть расположен, если в SubjectName не требуется DN для поиска контроллера домена. This requirement is particularly relevant in multi-forest environments as it ensures a domain controller can be located when the SubjectName does not have the DN required to find the domain controller.
Поставщик ключей для хранения данных (KSP) Key Storage Provider (KSP)	Если устройство присоединяется к Azure AD, используется дискретный сертификат SSO. If the device is joined to Azure AD, a discrete SSO certificate is used.
EnhancedKeyUsage EnhancedKeyUsage	Требуется один или несколько следующих EKUs: One or more of the following EKUs is required: — Проверка подлинности клиента (для VPN) — Client Authentication (for the VPN) — OID фильтрации EAP (для Windows Hello для бизнеса) — EAP Filtering OID (for Windows Hello for Business) — SmartCardLogon (для устройств, присоединив Azure AD) — SmartCardLogon (for Azure AD joined devices) Если контроллерам домена требуется EKU смарт-карты: If the domain controllers require smart card EKU either: — SmartCardLogon — SmartCardLogon — id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4) — id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4) В противном случае: Otherwise: — Проверка подлинности клиентов TLS/SSL (1.3.6.1.5.5.7.3.2) — TLS/SSL Client Authentication (1.3.6.1.5.5.7.3.2)

Конфигурация сервера NDES NDES server configuration

Сервер NDES необходимо настроить таким образом, чтобы входящие запросы SCEP можно было сопопооставить с нужным шаблоном, который будет использоваться. The NDES server is required to be configured so that incoming SCEP requests can be mapped to the correct template to be used. Дополнительные сведения см. в справке Настройка инфраструктуры сертификатов для SCEP. For more information, see Configure certificate infrastructure for SCEP.

Требования Active Directory Active Directory requirements

Необходимо подключение IP к DNS-серверу и контроллеру домена через сетевой интерфейс, чтобы проверка подлинности также была успешной. You need IP connectivity to a DNS server and domain controller over the network interface so that authentication can succeed as well.

Контроллеры домена должны иметь соответствующие сертификаты KDC, чтобы клиент доверял им в качестве контроллеров домена, и так как телефоны не соединены с доменом, корневой ЦС сертификата KDC должен быть в сторонней корневой ЦС или магазине доверенных корневых корней смарт-карт. The domain controllers will need to have appropriate KDC certificates for the client to trust them as domain controllers, and since phones are not domain-joined, the root CA of the KDC’s certificate must be in the Third-Party Root CA or Smart Card Trusted Roots store.

Контроллеры домена должны использовать сертификаты на основе обновленного шаблона сертификата KDC Kerberos Authentication. The domain controllers must be using certificates based on the updated KDC certificate template Kerberos Authentication. Это потому, что Windows 10 Mobile требует строгой проверки KDC для включения. This is because Windows 10 Mobile requires strict KDC validation to be enabled. Это требует, чтобы все контроллеры проверки подлинности домена запускали Windows Server 2016, или вам необходимо включить строгую проверку KDC на контроллерах домена, которые запускают предыдущие версии Windows Server. This requires that all authenticating domain controllers run Windows Server 2016, or you’ll need to enable strict KDC validation on domain controllers that run previous versions of Windows Server. Дополнительные сведения см. в дополнительных сведениях о включаемой строгой проверке KDC в Windows Kerberos. For more information, see Enabling Strict KDC Validation in Windows Kerberos.