I was invited by my good friend Scotty McLeod to the inaugural meeting of the Windows Server Team and to give a talk on WS08 Terminal Services Gateway Server. I felt if it was going to be anything like the Powershell user group meetings we both attend, then it would be well worth it. I find these meets great opportunities to learn and share ideas with likeminded folk. And It was that. I do hope we have many more of these meets and keep them as interesting as the first one was.
My bit in it was to give a talk on the WS08 TS gateway Service role. Scotty has uploaded the presentation To the Server team site and Mark Wilson, who attended, has blogged it as well. Nice to hear folks enjoyed it as much as I did as well.
Unfortunately, Microsoft Security kicked us out at 10 pm and one of the issues I felt I did not adequately cover in my presentation were the "Gotchas" as I like to call them. As I now have a blog on the team site, I'd like to start by sorting that out and use the blog as an avenue to rant on general Windows issues and techie stuff that catch my fancy.
With regard to the TS gotchas, as most people will find out, installing the TS Gateway role is the easiest part of the process. What usually gets you stumped if you are setting it up in a lab is how well you know your certificate trust chaining, certificate signing, and general certificate configuration principles, and if you are using the AD Certificate services role on a WS08 server, the differences between a W2K or WS03 CA and a WS08 CA with respect to certificate enrolment.
In our lab scenario we had 2 WS08 servers and a vista client. 1st server was DC, DNS Server and an Enterprise root CA; 2nd server held the TS Gateway role.
First thing you notice when installing the TS Gateway role is that it expects you to have a web server cert in the computer store of the local computer.
This is where the first hurdle usually occurs.
Administrative rights are required to request a computer certificate and in Vista and WS08, IE does not use administrative rights to run. The option to store a computer certificate in the computer store was also removed from the Windows Server "Longhorn" certificate enrolment pages and the easiest way I have found is to use the cerreq.exe command line utility with an .inf file containing the particulars of the request which comply with the certificate requirements for the TS Gateway Server which are:
- The name in the Subject line of the server certificate (certificate name, or CN) must match the DNS name that the client uses to connect to the TS Gateway server.
- The certificate is a computer certificate.
- The intended purpose of the certificate is server authentication. The Extended Key Usage (EKU) is Server Authentication (1.3.6.1.5.5.7.3.1).
- The certificate has a corresponding private key.
- The certificate has not expired. Microsoft recommends that the certificate be valid one year from the date of installation.
- The certificate must be trusted on clients. That is, the public certificate of the CA that signed the TS Gateway server certificate must be located in the client's Trusted Root Certification Authorities store.
A sample .inf file that fulfils these requirements to be used for a request is:
[Version]
Signature="$Windows NT$
[NewRequest]
Subject = "CN=FQDN of TSGW Server" ; FQDN here
KeySpec = 1
KeyLength = 2048
Exportable = TRUE ; Indicates a private key should be included in the certificate
MachineKeySet = TRUE ; Indicates a machine certificate
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication OID
For example, having saved the .inf file as SSLrequest.inf, from the TS gateway server, run from the command line, in the path of the saved file:
"Certreq –new SSLrequest.inf RequestFile.txt"
The certreq utility can be used to further submit this request file to the CA and obtain the issued certificate but from this point on, I prefer to use the certificate server web interface.
The gotcha with doing this is that with the longhorn CAs, SSL needs to be enabled on the web server hosting the certsrv page.
Once this is done, requesting the certificate, downloading it and importing it into the TS Gateway Servers computer store is pretty straightforward.
You then need to start and use the TS Gateway Manager to map the certificate to the TS Gateway Server.
You might also find that after you have done all this, especially if there is a greater than 20 minute interval between when you set up the TSGW IIS site and when you try to connect, the client connection fails with a "gateway server not available" error.
The fix for this is to change the idle time-out for the default application pool on the IIS server from its default of 20 minutes to 1440 minutes. This prevents the worker process from shutting down if idle.
With these out of the way, the Gateway Server should now be able to demonstrate the application of the CAPs and RAPs and allow you to continue exploring the use of NAP to assess the health of connecting client and placing the Gateway Server behind ISA.
No doubt these will be future blog topics and I hope I'll actively contribute.