How to Setup a Remote Desktop Session Host Farm using NLB on Server 2008 R2 (Part 2)

In a earlier post I went through installing a single remote desktop session host server. The post can be found here. The screenshots shown below overview the installation of the RDSH role.
As this is a test lab, I will not be installing a Licensing Server.

VIEW SLIDE SHOW DOWNLOAD ALL

So, install the RDSH role on both servers and add ‘Domain Users’ to the local ‘Remote Desktop Users’ group.
RDSH Certificates Template
We now need to configure the RDSH servers to use machine certificates obtained from an enterprise CA. All servers involved in the provision of remote applications to connecting clients require machine certificates. Each server will obtain its own machine certificate from an Enterprise CA. This will be used for remote desktop connections. However, I have found that you will need to share a signing certificate amongst both RDSH and RDCB servers (this certificate originated from RDSH1). I will show you how to create a suitable certificate template on the CA which we will use to enrol a needed certificate on each RDSH server.

1. On the Enterprise CA, under the Certificate Template Node, select Manage and duplicate a Web Server certificate. Select Windows 2008.
2. Give the certificate an appropriate name.
3. On the Security tab, ensure that all servers involved are placed on the security ACL tab with 'Read' and 'Enrol' permissions.
4. On the Request Handling tab, ensure that the Allow Private Key to be Exported is selected
5. On the Subject Name tab, ensure the Supply in the Request radio button is selected.
6. Select the Certificate Template Node, right click and select New. Locate the duplicated certificate just created and ensure that it is listed in the Certificate Template list.

VIEW SLIDE SHOW DOWNLOAD ALL

 
Now that you have created a new certificate template that will be used by the Remote Desktop servers, you should define revocation information on certificates your CA will publish. This is detailed in an earlier post (See Step 1 Configure Enterprise CA to Support AIA Extension to Support OCSP). This post will also explain the importance of OSCP in overcoming any revocation errors that you might receive when connecting externally.

---

The next logical step would be to obtain suitable machine certificates for the RDS servers.
Manually Obtain Machine Certificates on Your RDS Servers
Now that the RDS certificate template and the correct revocation settings have been made, you can now obtain the necessary machine certificates. Use the following procedure:

1. On your RDS servers, log on as Administrator
   
2. Type MMC in Run
   
3. Select File, Add Remove Snap-in
   
4. Under Available snap-ins, select Certificates and click Add
   
5. Select Computer account and click next
   
6. Select Local computer and click finish and click Ok
   
7. On the Certificates snap-in, select the Personal node, right click and select All Tasks, Request New Certificate
   
8. Click Next on the Before You Begin window and click Next again
   
9. Select the certificate template created above and select the blue hyperlink
   
10. Under the Subject tab type a suitable Common Name. If the certificate is to be used and sent externally (on the Internet) then you should use a public DNS name. Click Add.
    
11. Under Alternative name, select DNS and add names corresponding to both public DNS and any private FQDNs. The DNS name should also include the name of the farm that you intend to use (plan wisely!). At this point, you should add the host record (mapping farm name to an IP address) to your internal DNS server. The IP address used will be the IP used for your NLB cluster (more on this later!)
    
12. Under General tab, write a suitable name and description for the certificate.
    
13. Under Private Key select make Private Key Exportable. You may need to copy the certificate to other servers at some point (that is certificate and private key)
    
14. Click Apply and OK to finish the wizard
    
15. You should repeat this procedure on both RDSH, RDCB servers and for the RDWA server (with suitable external and internal names).

Once you complete the certificate request, you should see your certificate in your certificate MMC personal store. Now you have them, now you need to assign them correctly.
Configuration of Remote Desktop Session Host Configuration and its Certificate (Do this on each RDS server)

1. Select Admin Tools, RDS and then open Remote Desktop Session Host Configuration.
   
2. Under Connections select RDP-TCP properties
   
3. On the General tab you will probably find the Certificate is set to Default. Using the select key make sure you define the certificate you installed above.

This should be done for each RDS server (each server should use its own certificate obtained from the Enterprise CA).
To configure a certificate used to digitally sign the RDP file (Do this on both RDSH servers farm members)
I have found that it helps to use the same machine certificate across both RDSH servers and on the RDCB server. You will have to export the certificate with private key (therefore a .pfx file) from RDSH1 to RDSH2 and to RDCB. To export the certificate, just right click on the personal machine certificate in a MMC and select Export. Then import the certificate onto the other machines using a MMC once more. Once the certificate has been  exported/imported you can now deal with configuring that certificate to digitally sign the RDP file.
First, configure a certificate used to digitally sign the RDP file by using RemoteApp Manager.

1. Log on to RDSH1 as Domain\Administrator.
   
2. Click Start, point to Administrative Tools, point to Remote Desktop Services, and then click RemoteApp Manager.
   
3. Under the Overview section, click Change next to Digital Signature Settings.
   
4. Select the Sign with a digital certificate check box.
   
5. Click Change.
   
6. On the Confirm Certificate page, select the appropriate certificate, and then click OK.
   
7. Click OK to close the RemoteApp Deployment Settings dialog box.

Certificates and Domain Joined Clients
Domain joined clients will automatically have the CA root certificates stored in their trusted root store. They will not need personal machine certificates only the trusted root certificate in order to validate certificates received from the RDSH servers.

Configure the RD Connection Broker server (RDCB server)

On a separate member server, install the RD Connection Broker role service. Import the digital certificate used by RDSH server to the Personal certificate store of the computer (remembering to import a PFX file). Then configure the imported certificate used to digitally sign the RDP file.

1. Open Remote Desktop Connection Manager. To open Remote Desktop Connection Manager, click Start, point to Administrative Tools, point to Remote Desktop Services, and then click Remote Desktop Connection Manager.
   
2. Under the Virtual Desktops: Resources and Configuration heading, click Specify next to Digital Certificate.
   
3. On the Digital Signature tab, select the Sign with a Digital Certificate check box.
   
4. Click Select.
   
5. In the Confirm Certificate dialog box, click the certificate that you want to use for signing the RDP files, and then click OK.

Configure the RD Web Access server (RDWA server)

On a separate member server, install the RD Web Access role service.You will need to obtain a certificate for this server like you obtained a certificate for the RDSH server from the Enterprise CA. 

---

Setting Up Authorization
A chain of authorization needs to be set up. The RDSH servers needs to authorize the RDCB and in turn the RDCB will authorize the RDWA server. You must add Web Access and Connection Broker Servers to TS Web Access Group on Session Host Servers (RDSH1 & RDSH2)

• On each of your RD Session Hosts go to Start > Administrative Tools > Computer Management.

• Open Local Users and Groups and select the Groups sub-folder on the left, then double click the “TS Web Access Computers”  group in the center.
  
• Add the names of your RD Web Access and Connection Broker servers.

Add Web Access Servers to TS Web Access Group on Connection Broker Server.
Now on the Connection Broker add the Web Access servers to the TS Web Access group.  You can do this through Computer Management like above or you can do it using the RD Connection Manager. 

• Go to Start > Admin Tools > Remote Desktop Services > Remote Desktop Connection Manager.

• On the Actions pane, click Add RD Web Access Server.

• Enter the FQDNs of any RDWA servers

Add Session Hosts to Session Broker Computers Group on Connection Broker
Now we need to add our Session Hosts to a group to give them the ability to use the Connection Broker.  Add them to the local group in Computer Management.

• Add each RDSH server to the list

---

Configure Session Hosts to Use Connection Broker (RD1 & RD2)
Now all of our Session Hosts need to be configured to use the Connection Broker’s services.  On each RDSH:

• Select Admin Tools, Remote Desktop Service, Remote Desktop Session Host Configuration.

• Double-click ‘Member of Farm in RD Connection Broker’ which is under ‘RD Connection Broker’

• Under the RD Connection Broker tab click the Change Settings button.

• In the resulting RD Connection Broker Settings window, you specify how this RD Session Host server will interact with RD Connection Broker—that is, what the relationship is. Choose Farm Member and then enter the RD Connection Broker server FQDN and the farm name in the input boxes (see above). You should use the FQDN rather than flat NetBIOS name. This name should be one of the subject names used in the certificate created.
  
• Click OK and you will be back on the RD Connection Broker Properties tab. The check box next to Participate in Connection Broker Load Balancing is selected by default. Leave it selected.
  
• The weight describes its capacity relative to the other RD Session Host servers in the farm. Although all RD Session Host servers should be configured identically, not all will necessarily have the same amount of
  memory or the same number of processor cores. For example, if a server is only 75% as powerful as other servers in the farm, then you can reduce its weight to allow it only 75% as many connections as the other servers. The default value is 100.
  
• Also by default, the redirection method—how a client connects to the RD Session Host server once RD Connection Broker decides which server should accommodate the connection—is set to Use IP Address Redirection. If the initial load balancer allows clients to connect directly to RD Session Host servers in the farm, keep this default
  setting. Unless you have a good reason, you should leave Use IP Address Redirection.
  
• In the bottom section of this page, select the IP address that will be used for reconnections to this server. NOTE If you have more than one network adapter that you want to use, you can choose them all by checking the box next to each network adapter.
  
• Perform this process for each member of the farm, taking care to use the same farm name and the same redirection method on all farm members.

---

Configure RemoteApp to Connect to RD Server Farm
We need to provide the RD farm address so that clients will connect to it when running RemoteApps.  On each Session Host:

• Select Start, Admin Tools, Remote Desktop Services and RemoteApp Manager

• Next to RD Session Host Server Settings click Change.

• In the RD Session Host Server tab type the FQDN of the farm then click OK.
  

---

Configure Connection Broker for RemoteApp Programs Source
Now it’s time to configure a RemoteApp source for the Connection Broker.  On the Connection Broker :

• Select Start Admin Tools, Remote Desktop Services, Remote Desktop Connection Manager.

• Click RemoteApp Sources in the left hand tree, then choose Add RemoteApp Source in the right Actions pane.

• Type the DNS name for the RD server farm then click Add.

---

Configure Web Access Servers to Use Connection Broker RemoteApp Source
If you have come this far your doing well! We need to make sure the Web Access Server is configured to use Connection Broker as the source for our RemoteApps.  On each Web Access server :

• Select Start, Admin Tools, Remote Deskt0p Services, Remote Desktop Web Access Configuration.

• Supply Domain Admin credentials and sign-in.

• Click the Configuration tab heading.  Then for “Select the source to use:” choose “An RD Connection Broker server”.  Then type in the Connection Broker server name in the “Source name:” field.  Click OK. Remember, the RD Connection Broker server has been added to the TS Web Access Computers group on each farm member (RDSH1 and RDSH2).Also we have added the RD Web Access computer account to the TS Web Access Computers group on the RD Connection Broker.

---

Configuration of NLB
We now need to consider our method of initial load balancing. Remember, clients don’t talk to the RD Connection Broker role service directly; they connect to a farm, which sends this connection to the RD Connection Broker to let it find the right endpoint. So, the farm is connected to first  (lets call it the initial connection) and then the connection broker, and then to RD Session Host server in the farm! We will use NLB as our method of load balancing the initial connection to the RDSH farm.
NLB distributes incoming connections evenly across each load-balanced server on the principle that if the incoming requests are evenly distributed, the traffic should be, too. NLB is best for load-balancing servers when the connections are very short, like web servers, or in this case, the initial connection in a farm that is participating in RD Connection Broker load balancing. NLB is more complicated to set up than RR DNS, but it’s capable of detecting when a server is no longer available and will not attempt to send connections to it.
To configure an NLB cluster, you need to complete the following steps.

1. If you have a network adapter dedicated to NLB, you need to configure it with static IP and subnet mask
2. Install the NLB Manager on a host node or other management machine. To do
   this, open Server Manager and select the Features section. Click Add Features, select the check box next to Network Load Balancing, and click Install.
3. Configure the NLB cluster.

• Open NLB Manager on one of the farm members from Start, All Programs, Administrative Tools, Network Load Balancing Manager or by typing nlbmgr in the Run text box on the Start menu. Right-click Network Load Balancing Clusters and choose New Cluster.
• In the Host input box, enter the name of one of the NLB hosts (one of the RD Session Host server farm members) and click Connect. All available network adapters on that server show up in the lower pane. Select the NLB network adapter and click Next (I am using only a single adapter on each RDSH machine)
• The IP address and subnet mask assigned to the network adapter will show up in the next window. The priority number is a unique number that differentiates the servers. Accept the default value. If you need to make any changes to the address, click Edit and make your changes. Leave the Initial Host State as Started, and click Next.
• On the next screen, click Add and add a unique IP address and subnet mask that will be shared by all cluster members, and then click OK. When users request access to the farm, they will be sent to this address instead of a specific RD Session Host server. This is the ‘Cluster Address’
• On the Cluster Parameters page, accept the defaults, including Unicast for the Cluster Operation Mode setting, and click Next. All cluster host adapters must use the same operation mode or NLB will not function.
• On the New Cluster: Port Rules page, you need to make a few changes to the default settings. Click Edit, and then change the starting and ending port range to 3389 (in both the To and From fields) because you will be using this cluster to load-balance RDP traffic only. In the Protocols section, select TCP. In the Filtering Mode section, choose
  Multiple Hosts to allow multiple hosts to handle traffic for this port rule. For Affinity, you have three choices; none, single and network. Choose Affinity: None so that incoming connections can be sent to any member of the farm. (There’s no reason to set affinity when the connections are being redirected, and doing so could make your load-balancing efforts useless by sending repeated connection requests to the same server.)

     4.  Add a DNS entry mapping the farm name to the cluster IP address.

How to Setup Server 2008 R2 Online Responder Service - Avoid the Dreaded 0x80092013 with SSTP VPN

In most cases, applications that depend on X.509 certificates, such as Secure/Multipurpose Internet Mail Extensions (S/MIME), Secure Sockets Layer (SSL), and smart cards, are required to validate the status of the certificates used when performing authentication, signing, or encryption operations. The certificate status and revocation checking is the process by which the validity of certificates is verified based on two main categories: time and revocation status.

• Time. Certificates are issued for a fixed period of time and considered valid as long as the expiration date of the certificate is not reached, unless revoked before that date.
  
• Revocation status. Certificates can be revoked before their expiration date because of multiple reasons such as key compromise or suspension. Before performing any operation, applications often validate that the certificate was not revoked.

Revocation can be made by using Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) and is used when we VPN with SSTP.

Step One
Configure Enterprise CA to Support AIA Extension to Support OCSP

To advertise that revocation status information for a particular CA can be obtained via OCSP, the CA must include a pointer to the OCSP Responder in the certificate. This is done by adding an OCSP URI to the AIA extension of the certificate. This is a configuration made on the CA and will be applied to certificates issued by the CA.

1. Open the Certification Authority Snap-in on the CA, as an Enterprise Administrator

2. Right click on the CA name, and select Properties

3. Click on the Extension Tab. From the Select Extension drop down Box, select Authority Information Access (AIA). This is shown below. For Internet clients,  select Add  and enter a public DNS entry e.g http://www.compulinxtraining.com/ocsp

4. Check the Checkbox for Include in the online certificate status protocol (OCSP) extension.

5. Click OK, to close the CA Properties.


Step Two
Configure Enterprise CA with OSCP Signing Template

1. On the Enterprise CA, select Certificate Templates, right click and select Manage. This will open a complete list of the CAs templates in the Certificate Template Console.

2. Locate the OCSP Certificate Template, Right-click, and select Properties

3. On the Security Tab, add the hostname of the soon to be OCSP Server, and give the server Read and Enroll permissions to the template. Click OK.


4. In the Certification Authority management console, Right-click on the Certificates Templates node, and from the context menu, select New and then "Certificate Template to issue.

5. Select the OCSP Response Signing Template, and select OK.

Step Three
Installing and Configuring the OCSP Responder Role

1. To install the OCSP Responder, add the Online Responder role found under Active Directory Certificate Services

2. Open the Online Responder snapin in Administrative Tools

3. Select Revocation Configuration, right click and select Add Revocation Configuration. A wizard will open.

4. Name the configuration with a friendly name

5. Select a certificate for an existing Enterprise CA

6. Select Browse CA certificate published in Active Directory. Click Browse. You should see your CA certificate so select it and click OK.

7. Next you will need to select a certificate that will be used for signing OCSP responses. For a particular Revocation Configuration, the OCSP Signing certificate must be issued by the CA for which the OCSP Responder will answer revocation status requests. Select Automatically select a signing certificate and select the OCSP template you configured in step two above. Click Next.

8. The OCSP responder will obtain its CRL from the CA so you do not have to add any other provider. Finish the wizard.

How to Setup Server 2008 SSTP VPN Server Introduction

Hope you all had a good Christmas! In the next couple of posts I will showing you how to build SSTP VPN servers on server 2008 R2. The process is a little involved and will cover not only how RRAS configuration, but CA configuration and how to use the new Online Responder Service.
VPN technology has moved on in Windows Server 2008. Now we can use SSTP (as far as I can see just for 'Client to Router' connections). This means you can still VPN to a network in situations where the traditional technologies have been blocked (TCP 1723 PPTP for example). SSTP uses TCP 443.

A big problem I have found in the SSTP VPN is the certificate revocation check. Before a client manages to connect to the VPN server, a certificate revocation check needs to be made. The client will need to access the certificate revocation list (CRL) which is on the CA but could be hosted on another server. This check uses http not https. This can complicate things because you dont want Internet based clients connecting to an internal CA to check for revocation using unsecured http. You can publish the CRL to a Certificate Distribution Point (CDP) away from the CA. This can be to a web server. The client then receives the VPN certificate sent from the SSTP VPN server and will need to determine if its been revoked (by the way, depending on the method of client authentication, the client will need the CA root certificate and perhaps a user certificate - more on this later). The client can determine the CDP by referencing the CDP extension on the VPN certificate (which is usually an Internet registered DNS address). An HTTP connection is made to the CRL Web Server and the client downloads the full CRL. The client can check for revocation status and then VPN to the SSTP VPN server.

Server 2008 supports not only the traditional CRL method of revocation but also the Online Responder Service OCSP. The main advantage here is that the client does not require periodic downloading of a CRL. The client gets an accurate point-in-time status check to determine the validity of the certificate sent by the VPN server. A downside to OCSP is that it is supported by Windows 7 and Vista clients only.

How to Obtain an Exchange Certificate (SAN) from a 2008 StandAlone CA

This post will help you obtain a SAN certificate from a StandAlone CA (on Server 2008). You will need this for correct configuration of autodiscovery and outlookanywhere/availability service.

1. On your Exchange 2007 server (CAS), type the following cmdlet to make the necessary SAN certificate request which will be stored in the root of c:\. Notice the use of multiple names in the request.

[PS] New-ExchangeCertificate -GenerateRequest -Path c:\certrequest.txt -KeySize 2048 -SubjectName "c=UK, s=London, l=London, o=CompulinxTraining, ou=ExchangeServers, cn=mail.compulinxtraining.com" -DomainName compulinxtraining.com, srv1.compulinxtraining.local, srv1, autodiscover.compulinxtraining.com -PrivateKeyExportable:$True

It should be noted that Exchange 2010 does NOT use the -path parameter as mentioned in step one. You will need to establish a variable. You could try the following:

$Data=New-ExchangeCertificate -GenerateRequest -KeySize 2048 -SubjectName "c=UK, s=London, l=London, o=CompulinxTraining, ou=ExchangeServers, cn=mail.compulinxtraining.com" -DomainName compulinxtraining.com, srv1.compulinxtraining.local, srv1, autodiscover.compulinxtraining.com -PrivateKeyExportable:$True
Set-Content -path "C:\req.req" -Value $Data
2. Once you have generated the request, visit your CA by opening a browser and type http://TheCAName/certsrv. Select 'Request a Certificate' and then select 'Advanced Certificate Request'. Then select 'Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file'. Copy and paste the contents of the request (all of it... even the lines!) into the 'Saved Request field and 'Submit' the request to your CA.

3. On the CA select 'Pending Request' and 'issue' the certificate. 

4. Back on the Exchange Server, visit the home page again and check for the pending request. Save the the .cer file to a easy to find location on the server.

5. Create an MMC and add your Local Computer Certificate snap-in. Under personal 'import' your saved certificate. Once imported you will probably find that if you open it that it will not be trusted. You will have to download the root CA and import it to the trusted root store on the Exchange Certificate.
You may also find that the certificate has no private key. This will cause problems later on so you should repair the certificate by following these steps:

>Open MMC and add the Certificate Snap-In for the Local Computer account.

>Double-Click on the recently imported certificate. Note: In Windows Server 2008 it will be the certificate missing the golden key beside it.

>Select the Details tab.

>Click on the Serial Number field and copy that string.Note: You may use CTRL+C, but not right-click and copy.

>Open up a command prompt session. (cmd.exe aka DOS Prompt)

>Type: certutil -repairstore my "SerialNumber" (SerialNumber is that which was copied down in step 4.)

>After running the above command, go back to the MMC and Right-Click Certificates and select Refresh (or hit F5 in the MMC)

>Double-Click on the problem certificate. At the bottom of this window (General tab) it should state: "You have a private key that corresponds to this certificate."Note: In Windows Server 2008 there will be a golden key to the left of the certificate, so there is no need to double-click the certificate.

Now that the Private Key is attached to the certificate, please proceed to enable Exchange Services via Enable Exchange Certificate (Courtesy of comodo.com)

6. Now you need to enable your certificate and bind it to the correct exchange services. Type the following cmdlet:
[PS] Get-ExchangeCertificate -Thumbprint ABCDEFetc. | Enable-ExchangeCertificate -Services IIS,SMTP

Exchange Servers and Certificates

In a previous post I detailed how to configure Outlook Anywhere which relies on HTTPS. This must use a certificate infrastructure and this post I hope will instruct you on how to configure your CA, distribute the necessary Exchange certificate and how to configure Exchange and clients.

1. Install the Active Directory Certificate Services role on a member server or a domain controller. During installation of the service make sure that you choose an enterprise server.

2. Create a duplicate version 3 template of the web certificate. This version will allow you to create a certificate with multiple subject alternative names (a SAN certificate). Make sure that the CAS machine that is Internet facing is defined on the templates security tab (ACL).

3. Ensure that the template created is defined in the list of templates provided by your CA.

4. On the defined CAS, using an elevated MMC with added computer certificate, request a computer certificate from the CA.

5. During the request you can define multiple subject alternative names by adding different DNS names. The names I suggest are based on the following public (compulinx.com) and private (compulinx.local) DNS names.

   •Mail.compulinx.com
   •Compulinx.com
   •Autodiscover.compulinx.com
   •Ex1.compulinx.local
   •Compulinx.local
   •Autodiscover.compulinx.local

6. As you can see from point 5, multiple DNS names are included. These represent both public and private names (where mail is public and ex1 represents your exchange server NetBIOS name). The same certificate can be used for internal and external clients. You can choose not to include the internal names for security (personally I wouldn’t worry considering that if a hacker can make an intrusion using a NetBIOS name then you might as well give them a domain account!). However, you should include an SRV record in your DNS where autodiscover _TCP port 443 maps to the CAS machine.


7. Once the CAS machine has any Exchange certificate check in the trusted root folder for the root CA certificate. Copy this certficate to any workgroup client that will make use of Outlook and Outlook Anywhere.

8. You will need to establish that Exchange uses the requested certificate. First, determine what certificates are on board by using the following command:

[PS] Get-ExchangeCertificate -DomainName EX1 | fl subject,thumbprint

You will most likely find 2 certificates in the list; the certificate just requested and an original certificate which is self signed. You can delete this from the MMC personal certificates snap-in. We need to enable the certificate for use with various Exchange services.

[PS] Get-ExchangeCertificate -Thumbprint abcdef  | Enable-ExchangeCertificate -Services "IIS,SMTP"