Terminal Services Gateway beveiligen met ISA Server 2006

Met ISA Server 2006 kan je een Terminal Services Gateway voorzien van extra beveiliging door deze te publishen via een Web Listener. Daar TSG gewoon gebruik maakt van RPC over HTTPs zoals Exchange met Outlook Anywhere dat ook doet, gaat het publishen hiervan net zo gemakkelijk.

Om te beginnen moeten we SSL certificaten hebben voor zowel de ISA server als de TSGateway. Aangezien de ISA Server draait op Windows Server 2003 hebben we nog niet de mogelijkheid om vanuit de Certificates Snap-in een Certificate Signing Request (CSR) te maken. Veelal moet er een offline request gemaakt worden, omdat dat bijvoorbeeld naar een Public Certificate Authority zoals Verisign gestuurd moet worden. Op Windows Server 2003 hebben we beperkte mogelijkheden. Zo kunnen we een request maken via IIS, maar een webserver installeren voor een CSR is een beetje overdone. Ook kunnen we gebruik maken van een Microsoft CA via de certificate Server Website, maar ook die is niet altijd voor handen. De laatste mogelijkheid is om een certificaat aan te vragen op een Windows 2008 machine met de mogelijkheid de private key te exporteren en dan vervolgens het complete keypair te exporteren en importeren. Dat is echter minder secure, want als het systeem gecompromitteerd wordt, kan het complete keypair gestolen worden, in plaats van alleen de public key.
Dan blijft er dus eigenlijk alleen CertReq.exe over, wat onderdeel is van de Administration Toolkit http://www.microsoft.com/downloads/details.aspx?familyid=86b71a4f-4122-44af-be79-3f101e533d95&displaylang=en

Hiervoor moet een INF bestand aangemaakt worden volgens de syntax op http://technet.microsoft.com/en-us/library/cc736326.aspx

Nu lijkt dit heel moeilijk, maar als je het even goed doorleest valt het allemaal wel mee. Mijn INF bestand ziet er als volgt uit:

[NewRequest]
Subject = "CN=rdp.home.com"
PrivateKeyArchive = FALSE
KeySpec = 1
KeyLength = 1024
Exportable = FALSE
UserProtected = FALSE
MachineKeySet = TRUE
Silent = TRUE
ProviderName = "Microsoft Enhanced Cryptographic Provider v1.0"
ProviderType = 1
UseExistingKeySet = FALSE
RequestType = PKCS10
KeyUsage = 0x30
EncipherOnly = TRUE
[RequestAttributes]
CertificateTemplate = "WebServer"

Nu sign ik mijn eigen certificaten, maar Internet CAs hebben vaak bepaalde eisen over de opmaak van het CSR (voornamelijk rondom het Subject en usage attributen). Op de internetsites van deze bedrijven is vaak meer informatie te vinden. Zorg dus dat je aan deze voorwaarden voldoet.

Na het aanmaken van de INF, kan ik een CSR creëren met het volgende commando:"

    Certreq.exe –new <padnaarinf.inf> <padnaarcsr.req>8

Met het CSR kan je vervolgens het certificaat aanvragen. Wanneer je het certificaat terugkrijgt van de CA (mocht je een Windows 2008 CA hebben zoals ik, kan je via de Certificate Authority MMC snapin het request honoreren, en het certificaat opslaan), dien je het als keypair op te slaan door het volgende commando te draaien:

    Certreq.exe –accept <padnaarcertificaat.cer>8

De keypair wordt nu opgeslagen in de Computer > Personal certificate store. Vergeet dit laatste commando niet, want je kunt prima het certificaat opslaan via andere wegen, maar dan wordt het niet gekoppeld aan de private key die gebruikt is bij het vervaardigen van het request. Je hebt dan geen keypair en kan het certificaat dus niet gebruiken voor SSL/TLS doeleinden. Nutteloos dus.

Het tweede CSR is een stuk simpeler. Daar Terminal Services Gateway een Windows Server 2008 service is, kunnen we heel simpel een Custom Request maken vanuit de Certificates MMC snapin.

In het request, kies je voor het Web Server template. Behoudt de default settings, welke automatisch de common name als Subject neemt. Dit is voldoende voor ons scenario, tenzij je dit interne certificaat ook door een publieke CA wilt laten aanmaken, waardoor je weer met bepaalde eisen te maken kan hebben. Voor een interne CA –bijvoorbeeld de Windows 2008 CA – is dit meestal voldoende. Genereer het certificaat bij de CA (voor Windows 2008 CA via de Certificate Authority MMC Snapin > New Request) en importeer het certificaat in de Computer > Personal certificate store.

Na het installeren van de certificaten gaan we een Web Listener aanmaken. Dit doe je vanuit de Network Objects in de ISA Console.

  1. Kies voor New Web Listener.
  2. Geef een naam voor de Web Listener.
  3. Kies er vervolgens voor Secure verbindingen te gebruiken
  4. Geef de netwerken op waar de Listener, moet 'Listenen' J. Ik heb een 3-leg configuratie dus ik kies voor het External Network.
  5. Kies vervolgens het certificaat dat we zojuist hebben aangemaakt.
  6. Authentication moet op basic HTTP staan, met als directory Active Directory of LDAP. Voor meer informative over LDAP authenticatie, zie http://www.isaserver.org/tutorials/LDAP-Pre-authentication-ISA-2006-Firewalls-Part1.html
  7. SSO kan niet met HTTP basic, dus selecteer Next en Finish om af te sluiten.

Vervolgens moet er een Publishing Rule aangemaakt worden. Dit gaat als volgt:

  1. Vanuit de ISA Console ga je naar Firewall Policy > New > Exchange Web Client Access Publishing Rule.
  2. Kies vervolgens voor Exchange 2007, Outlook Anywhere (RPC/HTTPs) en deselecteer Publish additional folders…
  3. Kies voor Publish a single Web site or Load balancer.
  4. Kies voor een SSL connectie richting de backend.
  5. Geef de interne FQDN van de Terminal Services Gateway en de machinenaam of ip adres op:
  6. Kies vervolgens voor This domain name only (type below:) en geef de externe FQDN op die we bij de certificaat aanvraag hebben opgegeven (de CN in het subject, in mijn voorbeeld rdp.home.com).
  7. Selecteer de Web Listener die we zojuist hebben aangemaakt.
  8. Kies voor No Delegation, but client may authenticate directly.
  9. Selecteer een user set en maak de installatie af.

Verder kan het zijn dat het CA certificaat in de Trusted Certificate Root Authorities store van het Computer Account opgeslagen moet worden. Dit moet gebeuren op de server machines, maar ook op de client machines. Ik gebruik een interne CA, dus ik heb het op alle non-domainjoined machines en mijn client machines handmatig moeten toevoegen. Het certificaat is te vinden in de Computer > Personal store van de CA (veelal bevat deze er minimaal twee, dus controleer goed dat je het CA certificaat te pakken hebt, en niet het computer certificaat of enig ander certificaat)

Als Laatste vraag je de properties op van de Rule, en selecteer je Test Rule (vanaf ISA 2006 Service Pack 1). Dit controleert de configuratie. Als er iets mis is met certificaten, zal je dat nu zien.

Nu alles geconfigeerd is, is het tijd om het te testen met een terminal services client. In de advanced properties van de client, geef je de externe FQDN op van de ISA server:

Op de terminal services gateway geef je in je Connection Policy op, welke users connectie kunnen maken met de Gateway. In de Resource Policy geef je de users op die verbinding mogen maken met de resources, en je geeft de machines op die als resource mogen dienen. Als je nu een verbinding maakt, krijg je eerst een prompt voor Connectie, en vervolgens voor de resource. Ik vind het persoonlijk fijn om slechts een enkel account rechten te geven voor de connectie; deze verder geen rechten te geven op enig andere resource, en via AD Auditing te tracken; En vervolgens een ander account te gebruiken voor de connectie naar de resource.

Mocht je tegen problemen aanlopen, check dan de Terminal Services Gateway logs op de TS gateway en de ISA Logs. Verder is er nog enige informatie te vinden op: http://technet.microsoft.com/en-us/library/cc731353.aspx