Creating a Remote Desktop Protocol Access Rule.
In Part 1 of this series we configured our Windows Server 2008 R2 server with the proper networking requirements and installed UAG Server. In Part 1 I also explained that UAG is based on the firewall technology of TMG server and stated that GENERALLY speaking you should not modify any firewall policies using the TMG Management console. This is one point where we will break that rule. You may have realized by now that you can't RDP into the machine this is because TMG is doing is job as a firewall and not allowing that connection so let's add an exception.
First open the TMG Management Console.
Next right click on the Firewall Policy, select New, Access Rule.
Call the rule RDP access to localhost
Select Allow for the rule action
In the Protocols window select "Selected Protocols", Add, RDP (Terminal Services), and click Add, Close, Next.
In the Access Rule Sources section, Click Add. Now depending on where you are accessing the UAG server from you may want to use a different network set. For the purposes of this demo I will select the "Internal" networks which will be the Internal Networks we defined in Part 1 during the Setup wizard. This will prevent connections from the External networks i.e. Public Internet.
In the Access Rule Destinations tab select "Local Host" as the destination. Because… well, we want to make RDP connections to the local server! J
Select "All Users" for the user set since the user will need to authenticate to Windows in order to gain RDP Access.
Now that the wizard has completed, you'll see our rule should be #1 in the priority order. Next let's apply this policy by clicking the "Apply" button. Note after clicking apply you may have to wait a minute or two for the policy take effect.
Not that we've created our Allow RDP rule test a Remote Desktop Connection to the internal IP address of the UAG server. If you're successful then close out the TMG Management Console not, then take a look at the Logs & Reporting, and follow the packet Logging.
Ok Certificates are probably the thing that most Exchange Admins absolutely hate. I guess I'm the exception because I like working with them aside from the fact that Microsoft actually made it harder to request and import certs from the Shell in Exchange 2010, but that's a Remote Powershell thing and I'm digressing…
Anyway, since this is an Exchange-oriented series, let's use the process that Exchange Admins should be familiar with to generate and export the Exchange Certificate. In short, we'll generate a Certificate Signing Request (CSR) on the Exchange Server, import the certificate, then export the public and private keys to a .PFX file and finally import the certificate on the UAG server but first let's check what namespaces we'll need for the UAG certificate. In short we only need the namespaces used for Internet connectivity. They will typically be one or all of the following:
- The FQDN for Outlook Web App.
- The FQDN for Activesync.
- The FQDN for the Outlook Anywhere Endpoint.
- If you are configuring a site-resiliancy model then you'll also want to include any site specific namespaces for the site that will be using UAG during the normal Business As Usual (BAU) times AND other AD sites/Datacenters that will use this UAG server during a site failover.
- The FQDN of the Legacy Exchange Environment.
For our lab environment we're using the domain name "exchange.capaxglobal.net" and we'll setup our certificate (and UAG) to cover all of the above. So let's review our Cert. namespaces:
Certificate Principal Name (Subject Name): mail.exchange.capaxglobal.net
Now that we've got our Internet facing namespaces outlined lets generate the certificate using the Exchange 2010 Shell.
$csr = New-ExchangeCertificate -GenerateRequest -SubjectName "CN=mail.exchange.capaxglobal.net, OU=Capax Global Labs, O=Capax Global, L=New York, S=NY, C=US" -DomainName mail.exchange.capaxglobal.net, autodiscover.exchange.capaxglobal.net, datacenter1.exchange.capaxglobal.net, datacenter2.exchange.capaxglobal.net, legacy.exchange.capaxglobal.net -PrivateKeyExportable $true
Set-Content -Path "C:\UAG-CSR.req" -Value $csr
Now we'll open the CSR in Notepad, cut and submit the CSR to our 3rd party Internet Certificate Authority (for the purposes of this series, I'll use an internal PKI).
Next we'll submit the CSR to the Certificate Authority (I'll skip the details here as there are plenty of resources out on the net on this process). Once we get our Certificate back from the CA let's import it.
Import-ExchangeCertificate –FileData([Byte]$(Get-Content –Path c:\UAG-CSR.cer –Encoding byte –ReadCount 0))
Now let's export the Certificate with its private key so that we can import it on the UAG server.
$file = Export-ExchangeCertificate –Thumbprint 8650A93C02226AC663A31A5762EEBEF82BEE5CED
Set-Content –Path C:\UAG-CERT.pfx –Value $file.FileData –Encoding Byte
When you export the Certificate you'll be prompted to enter a password that must be used when the public/private key pair is imported.
You should now have a file c:\UAG-CERT.pfx that you need to copy to your UAG server.
Back over on the UAG server let's open the Local Computer Certificate Store (Start, Run, MMC, Add/Remote Snap-In, Certificates, Select Computer Account, Manage the Local Computer). Expand the Certificates (Local Computer)\Personal\Certificates Node. Then Right Click, select All Tasks, Import.
Open the Cert Import Wizard, and to the PFX file we copied from our Exchange Server.
NOTE: Depending on your Certificate Authority you may need to first import the Root CA and then Intermediate CA certificates before importing the exported PFX file. Review this procedure with your Certificate Authority. Failure to properly install the Root CA and, if applicable, Intermediate CA certificates may result in a broken Certificate chain.
IMPORTANT SECURITY NOTE: In your production deployment. I would highly recommend not marking the key as exportable on your production UAG server (or any Internet facing server). If the server is compromised then the public and private key can be exported using the above process and used on another server.
Once you complete the wizard let's just double-check that we have a private key.
Next let's double check the Properties of the certificate (Principal Name and Subject Alternate Names)
And finally the Certification Path. If there is a bad Cert Path a red X will appear on the Root or Intermediate Certificate Authority. If this happens review the process for importing the Root and/or Intermediate Certificate Authority's certificates with the CA.
IMPORTANT SECURITY NOTE: Do not leave PFX files on your UAG server (or any web server for that matter). There are many tools that can quickly bypass the password that is used to import the PFX file which means the bad guys will have your public and private keys. Thanks to Roger Grimes of the Microsoft ACE team for this tip!
Congratulations! Our certs are now installed.
Configuring AD as an UAG Authentication Servers
Now let's get back to the task at hand – configuring UAG! First let's configure our global Authentication and Authorization Servers. In this part of the series we'll just use Active Directory. In a future part of the series we'll add RSA SecurID authentication.
First let's create a service account in AD that will be used to access AD Attributes and change passwords for users.
I'll skip the steps on creating an AD user account but quickly review the delegation of changing passwords. Open Active Directory Users and Computers, right click at the OU or root OU where your Exchange recipients are located. Note: If you intend to expand the use of UAG to other products like Sharepoint you'll want to include users in those OU's. For the purposes of this article, I'll delegate at the root of our AD domain.
Selecting the UAG Authorization and Password Account I just created, delegate the "Reset user passwords and force password change at next logon" task.
Next let's go back to our UAG Management console.
From the UAG Management Console click Admin, Authentication and Authorization Servers.
Add an Authentication Server.
Select Active Directory from the Server Type. In the Server Name enter a FRIENDLY Name that your users will be able to relate to. This is what they will be prompted for when asked for their user name. It should NOT be the name of a domain controller.
Select "Use local AD forest authentication". This is reason number two why it helps to join UAG to the domain (but again, not the most critical – that's coming… I know you can't wait! )
Specify the search root and scope that UAG will search for users. Again this might be limited to the base DN that you store Exchange Recipients but remember that UAG can also do lots of other remote access tasks. For the purposes of this article, we'll just use the root of our domain.
Enter the number of nested groups for authorization purposes. I entered 4. The higher the number the longer it may take for UAG to recurse through group membership.
Finally enter the AD Authorization and Password user account that we created along with its password.
Congratulations! We've now created our Active Directory Authentication Server.
Adding an UAG Trunk
If you've used ISA server you're probably familiar with a Web Listener. In UAG this concept is known as a Trunk. The Trunk then has applications associated with it like Exchange, Sharpoint, Communicator Web Access, etc.
Open the UAG Management Console, Right Click on the HTTPS connections node and select New Trunk.
We're going to create a Portal Trunk. Note at this point you have the option of taking the easy way and Publishing Exchange Applications via this portal. However, I want to cover each Exchange application in a little more detail so let's leave this unchecked and we'll publish Exchange in later steps.
Name your trunk, enter the Subject Name (Principal Name) from the certificate and select the External IP address from the IP Address pull down.
Next click Add on the Authentication Servers tab, Choose your Active Directory Authentication Server. Leave the checkbox "Show Server Names" checked and click Next.
Select the certificate that we created and imported in the above steps.
For Endpoint Security you can choose NAP policies but to keep things simple here we'll just use the UAG Access policies.
Leave the default access policies selected and click Next and then finish the trunk wizard.
Congratulations! We've now built our Portal Trunk. In the next part we'll begin to publish Exchange Applications.
Other parts of this series: