microsoft windows server 2012 r2 remote - ??tech editor: toby phipps – mvp, remote desktop...
Post on 06-Mar-2018
Embed Size (px)
Tech Editor: Toby Phipps MVP, Remote Desktop Services
Microsoft Windows Server 2012 R2
Remote Desktop Services - How to Set Up
(Mostly) Seamless Logon for RDP
Connections KRISTIN L. GRIFFIN MVP, REMOTE DESKTOP SERVICES
One of the most common questions I get from people implementing RDS is I want a seamless logon
process but I am not getting it. How do I provide access to my RD Session Host Session Collection(s) with
the least amount of pop-up windows / SSL certificate warnings, and requiring the user to enter their
credentials only once?
The short answer is that you can attain a seamless logon, but you have to configure your environment
correctly (in multiple places, and on multiple servers) in order to make this happen. To achieve secure
connections and simple sign-on experience to an RDS environment you will need to enable server
authentication for all servers in the connection chain, and enable some form of single sign-on.
First I will explain how the core RDS security technologies work to secure the RDS environment and the
incoming session connections. Then I will show you how to configure security settings and SSL
certificates on all servers in order to both achieve a secure connection and also minimize pop-ups and
Before we dive in, Id like to explain two assumptions I make in this paper: youre using RDP 8.1 and all
examples use wildcard certificates.
Unless you have a really good reason not to use RDP 8.1, then I strongly recommend that you get the
latest version of RDP, available back to Windows 7 SP1. RDP 8.1 gets you the latest and greatest
performance. It also radically simplifies what you must do to enable SSO. If you cant, then refer to
Second, Im using wildcard certificates because this is the simplest way to use the same certificate for all
servers. The names you use on your certificates must match the name the server uses to identify itself.
The wildcard certificate takes the guess work out of this. You dont have to use wildcard certificates, but
if you dont then youll need to be very careful about which certs you install on which servers.
Enable Server Authentication One danger of communicating with a remote computer that requires you to supply your credentials is
that the server might not be what you think it is. If its a malicious server impersonating a real one, you
could inadvertently provide your credentials to an attacker. Server authentication checks to ensure that
youre connecting to the server you think youre connecting to.
If the servers you communicate with dont pass the server authentication check, you will get pop-ups
telling you that the server could not be identified, as shown in Figure 1.
Figure 1 - If an RDS server does not pass a server authentication check, youll get a warning dialog.
Server authentication must succeed on all of the servers youre using to connect to virtualized
applications or desktops. The specific server roles you need to authenticate depend on how youre
accessing the resources.
RD Connection Broker The Connection Broker routes connection requests to the appropriate
Session Collection and RD Session Host server, so it needs to pass a server authentication check
because all incoming connections get routed through the broker(s).
RD Web Access: Enables web single sign-on (Web SSO) for users accessing RemoteApps via the
RD Web Access website and via RemoteApp and Desktop Connection (RADC).
RD Gateway: Server Authentication for connections to the RDS environment from outside the
The technology youll use for server authentication depends on whether youre on the local network or
connecting via the Internet. If you are connecting to your RDS deployment from domain-joined clients
located on your corporate network, you will authenticate servers using Kerberos. But to authenticate
servers from connections for connections form the internet, and when Kerberos cannot be used, youll
use TLS (and thus, SSL certificates). To enable server authentication:
The client and server must use SSL (TLS 1.0) as the Security Layer. You choose the encryption
level on a per collection basis in Windows 2012 R2. (You can choose the option Negotiate
here, which means the security layer used is determined by the maximum capability of the
client. If the client can use SSL, it will. Otherwise it will use RDP Security Layer.)
The connection between server and client must use High or FIPS encryption. Low encryption
only encrypts the traffic from client to server, not server to client, so its not a secure way to
send security capabilities or shared secrets. You choose the encryption level on a per
collection basis in Windows 2012 R2. To be clear, you can choose the option client
compatible, which encrypts communications at the maximum key strength supported by the
client. It just means that your client needs to support high encryption for server
authentication to work.
For connections coming over the internet, you must deploy an SSL certificate on each server for
which you will be performing a server authentication check. The name listed on the certificate
must match the name that the server uses to identify itself, and (in some cases) must also be
resolvable via DNS.
The client must trust the certificate authority (CA) that signs the RDS servers SSL certificate that
verifies its identity.
The following sections explain how to accomplish this.
Securing the RDP stream
You can configure security settings on a per-collection basis by editing the Session Collection Properties
Security section as shown in Figure 2 below.
Figure 2- To enable server authentication, set the Security Layer and Encryption Level appropriately.
Deploying SSL Certificates
Youll need to deploy SSL certificates to the roles that youre using to allow people to connect to Remote
App programs or desktops: RD Connection Broker for sure, possibly RD Web Access, and RD Gateway if
youre using it to enable connections via the Internet.
You can deploy certificates to your RDS servers using PowerShell or RDMS (Server Manager/ Remote
Desktop Services on your management server). To deploy certificates via RDMS, open the RDS
Deployment Properties and select Certificates, shown in Figure 3.
Figure 3 - Manage your deployment SSL certificates in RDMS.
Add certificates to each of the roles services (one at a time) by highlighting the role service and clicking
Select Existing Certificate. Browse to your certificate file, enter the file password, and check the Allow
the certificate to be added to the Trusted Root Certification Authorities certificate store on the
destination computers box as shown in Figure 4.
Figure 4 -Add your certificate file.
RD Connection Broker Enable Single Sign-On
In Windows Server 2012 R2, RD Connection Broker receives all incoming connection requests and
determines what session host server will host the connection. So, when an RDP 8 client tries to verify
the identity of the server it is connecting to, it is really verifying the identity of the RD Connection
When thinking about how youre going to set up the certificates on RD Connection Broker, consider the
For Single Sign-On, RD Connection Broker identifies itself by its Client Access Name.
The Client Access Name must be listed on the installed SSL certificate.
The brokers name must be resolvable in DNS that RD Connection Broker uses.
Here is where things get a little tricky. You know the name on the certificate must match the name RD
Connection Broker uses to identify itself. If you make your RD Connection Broker highly available, you
set the client access name yourself, so you can choose a name that is listed on your certificate and
resolvable in your company DNS. But if you have only one RD Connection Broker, by default the client
access name is set as the computer name of the server and there is no obvious way to change it.
How much this matters depends on the domain suffix of your internal domain. You can no
longer get certificates for private domain suffixes from public CAs, so companies that use a
private (e.g. .local) suffix for their internal domain have a dilemma: how to make the certificate
name match the client access name, which also has to resolve in your corporate internal DNS. I
will explain how to reconcile a server name with a private suffix with the need to map the Client
Access Name to the certificate in the Connecting Through RD Gateway - Private Domain Suffix
section. For now, just remember that this is something youll need to be careful of.
RD Connection Broker - Publishing
Once you have server authentication taken care of, theres signing RemoteApp files. You sign your
RemoteApps both so that your clients know its safe to open them and because its required to enable
Microsoft Internet Information Services (IIS) doesnt use CredSSP, so you cant use CredSSP to pass
credentials to RD Web Access. Users will need to authenticate against the RD Web Access server and
store their credentials in the site. After users are authenticated, they dont need to authenticate again
to start RemoteApp progra