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 ...

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


<ul><li><p>Tech Editor: Toby Phipps MVP, Remote Desktop Services </p><p>Microsoft Windows Server 2012 R2 </p><p>Remote Desktop Services - How to Set Up </p><p>(Mostly) Seamless Logon for RDP </p><p>Connections KRISTIN L. GRIFFIN MVP, REMOTE DESKTOP SERVICES </p></li><li><p>One of the most common questions I get from people implementing RDS is I want a seamless logon </p><p>process but I am not getting it. How do I provide access to my RD Session Host Session Collection(s) with </p><p>the least amount of pop-up windows / SSL certificate warnings, and requiring the user to enter their </p><p>credentials only once? </p><p>The short answer is that you can attain a seamless logon, but you have to configure your environment </p><p>correctly (in multiple places, and on multiple servers) in order to make this happen. To achieve secure </p><p>connections and simple sign-on experience to an RDS environment you will need to enable server </p><p>authentication for all servers in the connection chain, and enable some form of single sign-on. </p><p>First I will explain how the core RDS security technologies work to secure the RDS environment and the </p><p>incoming session connections. Then I will show you how to configure security settings and SSL </p><p>certificates on all servers in order to both achieve a secure connection and also minimize pop-ups and </p><p>logon prompts. </p><p>Before we dive in, Id like to explain two assumptions I make in this paper: youre using RDP 8.1 and all </p><p>examples use wildcard certificates. </p><p>Unless you have a really good reason not to use RDP 8.1, then I strongly recommend that you get the </p><p>latest version of RDP, available back to Windows 7 SP1. RDP 8.1 gets you the latest and greatest </p><p>performance. It also radically simplifies what you must do to enable SSO. If you cant, then refer to </p><p>Appendix A. </p><p>Second, Im using wildcard certificates because this is the simplest way to use the same certificate for all </p><p>servers. The names you use on your certificates must match the name the server uses to identify itself. </p><p>The wildcard certificate takes the guess work out of this. You dont have to use wildcard certificates, but </p><p>if you dont then youll need to be very careful about which certs you install on which servers. </p><p>Enable Server Authentication One danger of communicating with a remote computer that requires you to supply your credentials is </p><p>that the server might not be what you think it is. If its a malicious server impersonating a real one, you </p><p>could inadvertently provide your credentials to an attacker. Server authentication checks to ensure that </p><p>youre connecting to the server you think youre connecting to. </p><p>If the servers you communicate with dont pass the server authentication check, you will get pop-ups </p><p>telling you that the server could not be identified, as shown in Figure 1. </p></li><li><p>Figure 1 - If an RDS server does not pass a server authentication check, youll get a warning dialog. </p><p>Server authentication must succeed on all of the servers youre using to connect to virtualized </p><p>applications or desktops. The specific server roles you need to authenticate depend on how youre </p><p>accessing the resources. </p><p> RD Connection Broker The Connection Broker routes connection requests to the appropriate </p><p>Session Collection and RD Session Host server, so it needs to pass a server authentication check </p><p>because all incoming connections get routed through the broker(s). </p><p> RD Web Access: Enables web single sign-on (Web SSO) for users accessing RemoteApps via the </p><p>RD Web Access website and via RemoteApp and Desktop Connection (RADC). </p><p> RD Gateway: Server Authentication for connections to the RDS environment from outside the </p><p>corporate network. </p><p>The technology youll use for server authentication depends on whether youre on the local network or </p><p>connecting via the Internet. If you are connecting to your RDS deployment from domain-joined clients </p><p>located on your corporate network, you will authenticate servers using Kerberos. But to authenticate </p><p>servers from connections for connections form the internet, and when Kerberos cannot be used, youll </p><p>use TLS (and thus, SSL certificates). To enable server authentication: </p><p> The client and server must use SSL (TLS 1.0) as the Security Layer. You choose the encryption </p><p>level on a per collection basis in Windows 2012 R2. (You can choose the option Negotiate </p><p>here, which means the security layer used is determined by the maximum capability of the </p><p>client. If the client can use SSL, it will. Otherwise it will use RDP Security Layer.) </p></li><li><p> The connection between server and client must use High or FIPS encryption. Low encryption </p><p>only encrypts the traffic from client to server, not server to client, so its not a secure way to </p><p>send security capabilities or shared secrets. You choose the encryption level on a per </p><p>collection basis in Windows 2012 R2. To be clear, you can choose the option client </p><p>compatible, which encrypts communications at the maximum key strength supported by the </p><p>client. It just means that your client needs to support high encryption for server </p><p>authentication to work. </p><p> For connections coming over the internet, you must deploy an SSL certificate on each server for </p><p>which you will be performing a server authentication check. The name listed on the certificate </p><p>must match the name that the server uses to identify itself, and (in some cases) must also be </p><p>resolvable via DNS. </p><p> The client must trust the certificate authority (CA) that signs the RDS servers SSL certificate that </p><p>verifies its identity. </p><p>The following sections explain how to accomplish this. </p><p>Securing the RDP stream </p><p>You can configure security settings on a per-collection basis by editing the Session Collection Properties </p><p>Security section as shown in Figure 2 below. </p></li><li><p>Figure 2- To enable server authentication, set the Security Layer and Encryption Level appropriately. </p><p>Deploying SSL Certificates </p><p>Youll need to deploy SSL certificates to the roles that youre using to allow people to connect to Remote </p><p>App programs or desktops: RD Connection Broker for sure, possibly RD Web Access, and RD Gateway if </p><p>youre using it to enable connections via the Internet. </p><p>You can deploy certificates to your RDS servers using PowerShell or RDMS (Server Manager/ Remote </p><p>Desktop Services on your management server). To deploy certificates via RDMS, open the RDS </p><p>Deployment Properties and select Certificates, shown in Figure 3. </p></li><li><p>Figure 3 - Manage your deployment SSL certificates in RDMS. </p><p>Add certificates to each of the roles services (one at a time) by highlighting the role service and clicking </p><p>Select Existing Certificate. Browse to your certificate file, enter the file password, and check the Allow </p><p>the certificate to be added to the Trusted Root Certification Authorities certificate store on the </p><p>destination computers box as shown in Figure 4. </p></li><li><p>Figure 4 -Add your certificate file. </p><p>RD Connection Broker Enable Single Sign-On </p><p>In Windows Server 2012 R2, RD Connection Broker receives all incoming connection requests and </p><p>determines what session host server will host the connection. So, when an RDP 8 client tries to verify </p><p>the identity of the server it is connecting to, it is really verifying the identity of the RD Connection </p><p>Broker. </p><p>When thinking about how youre going to set up the certificates on RD Connection Broker, consider the </p><p>following: </p><p> For Single Sign-On, RD Connection Broker identifies itself by its Client Access Name. </p><p> The Client Access Name must be listed on the installed SSL certificate. </p><p> The brokers name must be resolvable in DNS that RD Connection Broker uses. </p><p> Here is where things get a little tricky. You know the name on the certificate must match the name RD </p><p>Connection Broker uses to identify itself. If you make your RD Connection Broker highly available, you </p><p>set the client access name yourself, so you can choose a name that is listed on your certificate and </p><p>resolvable in your company DNS. But if you have only one RD Connection Broker, by default the client </p><p>access name is set as the computer name of the server and there is no obvious way to change it. </p><p>How much this matters depends on the domain suffix of your internal domain. You can no </p><p>longer get certificates for private domain suffixes from public CAs, so companies that use a </p></li><li><p>private (e.g. .local) suffix for their internal domain have a dilemma: how to make the certificate </p><p>name match the client access name, which also has to resolve in your corporate internal DNS. I </p><p>will explain how to reconcile a server name with a private suffix with the need to map the Client </p><p>Access Name to the certificate in the Connecting Through RD Gateway - Private Domain Suffix </p><p>section. For now, just remember that this is something youll need to be careful of. </p><p>RD Connection Broker - Publishing </p><p>Once you have server authentication taken care of, theres signing RemoteApp files. You sign your </p><p>RemoteApps both so that your clients know its safe to open them and because its required to enable </p><p>Web SSO. </p><p>Microsoft Internet Information Services (IIS) doesnt use CredSSP, so you cant use CredSSP to pass </p><p>credentials to RD Web Access. Users will need to authenticate against the RD Web Access server and </p><p>store their credentials in the site. After users are authenticated, they dont need to authenticate again </p><p>to start RemoteApp programs. </p><p>The name on the certificate does not need to resolve in DNS. Your clients just need to trust the CA </p><p>certificate used to sign your SSL certificate. </p><p>If you do not sign your RemoteApps then Web SSO will not work (you will get multiple credential </p><p>prompts) and you will get a pop-up like the one shown in Figure 5. Notice that there is no option to not </p><p>receive the warning in the future; you will get this each time you open an unsigned RemoteApp. </p><p>Figure 5 -The publisher of this RemoteApp program cant be identified because the RemoteApp was not signed using an SSL </p><p>certificate. </p></li><li><p>RD Web Access </p><p>This certificate is required to secure the RD Web Access website. It also enables RemoteApp and </p><p>Desktop Connections (RADC) on clients running Windows 7 and above so this server needs to pass a </p><p>server authentication check. If you do not have a proper certificate installed, you wont be able to setup </p><p>RADC, and you will get the pop-up shown in Figure 6. </p><p>Figure 6 -You will receive this error when configuring RADC if you do not have a trusted certificate installed for RD Web Access. </p><p>RD Gateway </p><p>If your RDS connections are coming from outside the network, then they will connect to RD Gateway </p><p>first, so this server will need to pass a server authentication check.1 Enable server authentication for this </p><p>role by installing an SSL certificate on your RD Gateway server(s). The name on the certificate must </p><p>match the publicly resolvable name of your RD Gateway(s), for example: </p><p> 1 Windows clients insist on successful server authentication for RD Gateway; without it, your connection will fail. </p><p>Android clients will tell you the certificate is untrusted, but will allow you to choose to connect anyway. </p></li><li><p>Configure Single Sign-On for Local or Internet Connections Single Sign-On and Web SSO produce the same result: a user does not have to enter their credentials </p><p>multiple times to access a RemoteApp (for SSO this is also true for full desktop connections). The </p><p>difference is how these two technologies work to give you a single-sign on experience. SSO leverages </p><p>Group Policy, so it works for domain-joined clients. When a user starts an RDP connection, the </p><p>connection logs onto the RDS environment using the credentials the user used to log onto their </p><p>machine. Clients that arent domain joined can use Web SSO to access RemoteApps or full desktop </p><p>connections from either the RD Web Access website or from RADC. 2 </p><p>Credential caching, introduced in Windows Vista/Windows Server 2008, helps both the user and the </p><p>server the user connects to. Credential caching allows users to store credentials for a particular </p><p>connection so they dont need to provide them every time they connect to that server (SSO). It also </p><p>provides credentials to the server before it establishes a session, avoiding the overhead of creating a </p><p>session if the user is not authorized (network-level authentication, or NLA). The piece that makes </p><p>credential caching work is the Credential Security Service Provider (CredSSP). As its part of the operating </p><p>system, its not related to the version of RDP youre using. CredSSP is available on Windows XP SP3 and </p><p>above. </p><p>CredSSP delegates user credentials to a trusted server via a TLS-secured channel. After it has those </p><p>credentials, the trusted server can impersonate the user and log onto itself. </p><p>Enabling SSO </p><p>Typically, people implement SSO on intranets, but you can also use it with RD Gateway. </p><p>To make SSO work on your intranet, you must meet the following conditions: </p><p> Your clients must be domain joined and able to receive GPO policies. </p><p> Set the Security Layer on the RDP connection to either Negotiate or SSL (TLS 1.0), and encryption </p><p>to either High or FIPS. </p><p> The following Computer GPO must be applied to client computers: Computer Configuration / </p><p>Policies / Administrative Templates / System / Credentials Delegation / Allow Delegating Default </p><p>Credentials. Add your RDS servers to this list as TERMSRV/. You may use </p><p>wildcards to include many servers for example: </p><p>TERMSRV/* </p><p>Note: Dont use TERMSRV/* - this is a security risk as it means: ALL servers running </p><p>terminal services. </p><p>If you want to use RD Gateway with SSO, apply the following User GPO to your users: </p><p>User Configuration / Policies / Administrative Templates / Windows Components / Remote </p><p>Desktop Services / RD Gateway / Set RD Gateway Authentication Method </p><p> Choose: Use Locally Logged-On Credentials </p><p> 2 WebSSO now works for full desktop connections with Remote Desktop client 8.0 and above.. </p></li><li><p>Side note: This GPO has a checkbox option for Allow users to change this setting. If you check </p><p>this box, then if the following RDP file setting is present in the RDP file, it must be set to 0: </p><p>gatewayprofileusagemethod </p><p>Heres why: If SSO GPOs are not set (for example, a non-domain joined PC) then if the value of </p><p>this setting is set to 1, it allows the RD Gateway value to be used in an RDP connection. If it is </p><p>set to 0, then the RD Gateway value disappears. But, if it is present when trying to achieve SSO </p><p>and its set to 1, SSO will fail for users where the GPO applies. </p><p>(If you do not check the box for allow users to change this setting, then this setting is ignored if </p><p>it is included in the RDP file settings). </p><p>If for some reason you are sending all connections through RD Gateway (both internal and external </p><p>connections) then clients connecting from inside the corporate network will use Kerberos to verify the </p><p>authenticity of the RD Connection Broker. But to achieve SSO from outside your corporate network, you </p><p>cant use Kerberos for server authenticatio...</p></li></ul>


View more >