Configuring certificates and single sign-on
When you deploy RDS, each server in the deployment has a digital certificate that is used to implement Secure Sockets Layer (SSL) and prove its identity to clients. The default certificates are self-signed certificates that aren't trusted by clients. You need to change the certificates to certificates that are trusted by clients.
Obtaining certificates
When you obtain a certificate from a public certification authority (CA), you need to pay the public CA for that service. The price of certificates varies widely depending on the public CA. Typical prices range from $20 to $400. Functionally, the certificates provide the same service, so there is no technical advantage to using more expensive certificates. The more expensive certificates may be considered more trustworthy by some clients and also may include insurance. A certificate obtained from a public CA is trusted automatically by all computers.
If your organization has an internal CA, the domain likely has been configured to automatically trust certificates issued by your internal CA. So, if all your clients are domainjoined computers, a certificate from an internal CA is a good choice. Now, however, many deployments of RDS include devices and external computers that aren't part of the domain and won't automatically trust a certificate from an internal CA. If your deployment of RDS might be accessed by anything but domain-joined computers, then you should get a certificate from a public CA.
When a client device accesses an RDS server, the domain name used to access the RDS server must match a name in the certificate. For example, if the domain name used to access the RD Connection Broker is broker.adatum.com, then the certificate on the RD Connection Broker servers needs to include that name. If the name isn't included on the certificate, then the connection isn't trusted and the behavior is the same as using a self-signed certificate.
You can use the following certificate types:
- Server:
A standard server certificate has a single name. A multiserver RDS deployment will require multiple server certificates. - Wildcard:
A wildcard certificate allows any name in a domain. For example, *.adatum.com is valid for any name in the adatum.com domain. This type of certificate can be used on multiple servers. This can simplify certificate management. - Subject alternative names:
(SAN) A SAN certificate includes multiple names. You could create a SAN certificate that includes all of the names for your RDS deployment and manage only one certificate. A SAN certificate typically is less expensive than a wildcard certificate and can include names from multiple domains if required.
Note:
A unified communications certificate (UCC) is the same thing as a SAN certificate. Different certificate vendors refer to it as either a UCC or SAN certificate.
Understanding RDS certificates
You can configure certificates for RDS deployments in Server Manager. You should not configure RDS-related certificates on individual servers, because you would need to configure them again after each change, for example, after replacing or adding a server. When you configure RDS certificates on the Manage Certificates page for the RDS deployment properties, RD Connection Broker will ensure that those certificates automatically propagate to the appropriate servers in the RDS deployment. It also will apply them after each configuration change.
There are four certificates used by RDS:
- RD Connection Broker - Publishing
- RD Connection Broker - Enable Single Sign On
- RD Web Access
- RD Gateway
RD Connection Broker - Publishing
This certificate is used when clients connect to the RD Connection Broker to be directed to an RD Session Host server. When you connect to RDS resources by using RD Web Access, the .rdp file that downloads from the portal includes the RD Connection Broker fully qualified domain name (FQDN) as a remote server. If you have configured the FQDN correctly in the RD Connection Broker - Publishing certificate, there is no security warning when you connect to the broker.
If you implement high availability for the RD Connection Broker role service, then a DNS round robin name is created. The certificate needs to include the DNS round robin name instead of individual server names.
The RD Connection Broker - Publishing certificate also is used for signing .rdp files that download from the RD Web Access portal. If the .rdp file isn't signed or is signed with an untrusted certificate, you need to review the connection settings and manually initiate the connection. If the .rdp file is signed, a connection automatically initiates.
Note:
Even if RD Connection Broker is configured with a publishing certificate that clients trust, users will receive a prompt that the RemoteApp program could harm their computers. If you want to avoid prompts when starting a RemoteApp program, you need to specify trusted publishers. You can do that by configuring the Specify SHA1 Thumbprints Of Certificates Representing Trusted .rdp Publishers policy setting in Group Policy. This setting is in User Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client.
RD Connection Broker - Enable Single Sign On
When you initiate a remote desktop connection to an RD Session Host in a collection or start a RemoteApp program, you need to provide user credentials, even when you already have signed in with domain credentials. By configuring the RD Connection Broker - Enable Single Sign On certificate, a user's current credentials will be used for accessing the RDS resource, and the user won't have to reenter credentials. This certificate should have the RD Connection Broker FQDN in its common name. You can use the same certificate as for RD Connection Broker - Publishing.
RD Web Access
This certificate is used for the RD Web Access portal and RD Web Feed. If this certificate isn't trusted, users accessing the portal will be given a warning in their web browser. RemoteApp and Desktop Connections fails to connect to RD Web Feed if the certificate isn't trusted.
In an RDS deployment with only one RD Web Access server, the certificate should have the FQDN of the RD Web Access server. If you have configured RD Web Access for high availability, you should use the load-balanced name in the certificate.
RD Gateway
When clients access RDS resources from the Internet, the RD Gateway role service acts as an entry point to an organization's network, which encapsulates RDP traffic into HTTPS envelopes. By default, an RD Gateway server uses a self-signed SSL certificate. You should replace that certificate with a certificate from a trusted CA.
The certificate must use the common name that matches the FQDN that clients use to connect to the RD Gateway role service. For a highly available deployment of the RD Gateway role service, the load-balanced name should be used.
Requesting and configuring RDS certificates
In Server Manager for RDS, you can create self-signed certificates, but you can't create certificate requests. In a production environment, you typically use certificates issued by a public CA. To obtain a certificate from a public CA, you need to do the following:
- Generate a certificate request with the correct name(s).
- Provide the certificate request to the public CA.
- Import the response from the public CA.
To generate a certificate request and import the response, you can use either of the following:
- IIS Manager:
You can use IIS Manager to create server or wildcard certificate requests. For a server certificate, enter the appropriate FQDN in the Common Name box. For a wildcard certificate, enter the appropriate wildcard name such as *.adatum.com in the Common Name box. - Certificates snap-in:
You can use the Certificates snap-in in the Microsoft Management Console (MMC) to create server, wildcard, and SAN certificates. To ensure that you can define all of the necessary options, you can create a custom request.
After you have completed creating the certificate, you need to export it as a Personal Information Exchange - PKCS #12 (.pfx) file. This type of file includes the private key for the certificate. The .pfx file is imported when you configure certificates for RDS.
Common Mistakes Creating Certificates
When you generate a certificate request, you need to configure a key size for the request. Many of the user interfaces default 1,024 bits, but public CAs now require the key size to be a minimum of 2,048 bits to increase security of the certificate. If you have created a certificate request with a key size that is less than 2,048 bits, just re-create the request with the correct key size.
Another common mistake is creating a certificate for which the private key can't be exported. You need to be able to export the private key to a .pfx file. When you are creating a custom request in the Certificates snap-in, this option is located on the Private Key tab in the properties of the certificate
You configure certificates for an RDS deployment in the Deployment Properties on the Manage Certificates page. For each type of certificate, you can choose Create New Certificate or Select Existing Certificate. If you choose Create New Certificate, a new self-signed certificate is created. For most deployments, you should choose Select Existing Certificate.
When you choose Select Existing Certificate, you are prompted for the location of the certificate. If you have a .pfx to import, select the Choose A Different Certificate option and enter the path to the .pfx file and the password for it.
You must select the Allow The Certificate To Be Added To The Trusted Root Certification Authorities Certificate Store On The Destination Computers check box when adding a certificate. Selecting this option verifies that you understand the certificate will be copied to all servers performing that role. It doesn't mean that the certificate is configured as a trusted root certificate on the servers.
The Apply The Certificate That Is Stored On The RD Connection Broker Server option allows you to copy the certificate from the RD Connection Broker role service to other role services. This is appropriate when another role service such as the RD Web Access role is on the same server as the RD Connection Broker role service. This also is appropriate when you have a wildcard or SAN certificate that you have prepared for use on multiple RDS role services.
After importing and applying certificates, the Level and Status for the role services on the Manage Certificates page of the Deployment Properties will update. The Level is updated to Trusted and the Status is updated to OK.
Understanding single sign-on
SSO for RDS allows users to access RemoteApp programs and virtual desktops without authenticating a second time. Instead, the credentials from the local workstation are passed to the RD Connection Broker role service. You typically use SSO when you deploy LOB applications or centralized applications and publish them as RemoteApp programs.
Before configuring SSO for an RDS deployment, you should be aware of the following requirements:
- The client computer and RDS deployment must be members of the same AD DS forest.
- If the server to which you are connecting can't authenticate via the Kerberos protocol or with an SSL certificate, SSO won't work.
- If the RD Session Host is configured to always prompt for credentials, SSO won't work.
The process for enabling SSO differs depending on how clients access RemoteApp programs and virtual desktops. If the client is using the RD Web Access portal, then you need to configure the RD Connection Broker - Single Sign On certificate. As long as clients trust that certificate, they aren't prompted for credentials after clicking an icon in the RD Web Access portal.
For clients that are using RemoteApp and Desktop Connections, you need to configure the Allow Delegating Default Credentials setting. This setting can be configured locally on each computer, but it typically is done by using Group Policy. The path for the setting is Computer Configuration\Policies\Administrative Templates\System\Credentials Delegation. After you have enabled this setting, you need to add the RD Connection Broker role service FQDN as a server in the following format:
TERMSERV/RDConnectionBrokerFQDN
Note:
It's possible to use wildcards when specifying the FQDN for the Allow Delegating Default Credentials setting. For example, you could enter TERMSERV/*.adatum.com. Be aware that this would allow credential delegation to all computers in the domain and may be a security risk.
