microsoft windows server 2012 r2 remote - ??tech editor: toby phipps – mvp, remote desktop...

Download Microsoft Windows Server 2012 R2 Remote -  ??Tech Editor: Toby Phipps – MVP, Remote Desktop Services Microsoft Windows Server 2012 R2 Remote Desktop Services - How to Set Up (Mostly) Seamless Logon

Post on 06-Mar-2018




4 download

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


  • 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

    logon prompts.

    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

    Appendix A.

    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

    corporate network.

    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

    Web SSO.

    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


View more >