Microsoft DirectAccess mit Forefront UAG

1. Microsoft DirectAccessmit Forefront UAG • Jörg Riether

2. Micrsoft DirectAccess - Das VPN der Zukunft?

3. DirectAccess • Immer online - kein „VPN“ mehr nötig • komplett via GPO´s administrierbar • Kommunikation läuft über IPv6-over-IPsec • Externe Win7 Ent/Ult Maschine ist von Corporate aus erreichbar, noch bevor sich ein Benutzer anmeldet

4. DirectAccess mit Forefront UAG • NAT64 und DNS64 kommen zum Einsatz • Kein W2008R2 DC/DNS im Netzwerk nötig, nur die UAG Maschine muss W2008R2 sein. Ohne UAG ist das anders, siehe http://technet.microsoft.com/en-us/library/dd637780(WS.10).aspx • Native IPv4-Clients können von extern aus via IPv6 erreicht werden.

5. DirectAccess - mal eben installiert und alles funktioniert?

6. Annahme • Im Unternehmensnetzwerk kommt zum aktuellen Zeitpunkt reines IPv4 zum Einsatz • DNS Server sind mindestens auf Windows 2003 und dynamische DNS-Aktualisierungen sind zugelassen

7. Vorbereitungen • DA/UAG W2008R2 Maschine mit zwei NICs bereitstellen • interne PKI muss ausgerollt werden • spezielle Zertifikatsvorlagen müssen erstellt werden • Zertifikatssperrliste muss konfiguriert und extern wie intern verfügbar gemacht werden

8. Vorbereitungen (2) • Maschinenzertifikate für DA-Clients ausrollen • SSL-Zertifikat für DA/UAG-Server ausrollen • hochverfügbaren Network Location Server (NLR) bereitstellen (ein IIS mit HTTPS reicht aus) • SSL-Zertifikat für NLS Server ausrollen

9. Vorbereitungen (3) • zwei öffentliche IPv4 IP-Adressen auf dem öffentlichen NIC bereitstellen (Teredo bedingt, um die Art des NAT zu bestimmen, http://www.faqs.org/patents/app/20080240132#ixzz0eqN70TBH) • ...diese IPv4 IP-Adressen müssen numerisch aufeinander folgend sein (Windows Teredo-Implementations bedingt) • ...und mussten anfangs auch nach lexikographischen Regeln aufeinander folgend gültig sein (zumindest zur „early adopter“-Zeit)

10. Vorbereitungen (4) • Die öffentliche NIC muss ein Gateway besitzen, sollte aber keinen öffentlichen DNS Server eingetragen haben (DNS64 Konflikt, http://technet.microsoft.com/en-us/library/dd857262.aspx) • Etwaige interne Routen müssen ergo manuell via ,route -p add ...‘ oder ,netsh inerface ipv4 add route..‘ hinzugefügt werden.

11. Ein paar Dinge im Detail

12. PKI • eine erreichbare Zertifikatssperrliste ist ein K.O.-Kriterium für DA und muss sauber konfiguriert sein (http://technet.microsoft.com/en-us/library/ee649168(WS.10).aspx) • Spezielle Vorlagen für DA-Clients und SSL-Server müssen angelegt werden (http://technet.microsoft.com/en-us/library/ee649249(WS.10).aspx)

20. NLS • Der Network Location Server ist ein Instrument des DA-Clients. Der DA-Client versucht, den NLS zu erreichen um zu testen, ob er sich intern oder extern von Corporate befindet. Der NLS muss einfach nur eine Website aktiviert haben (Inhalt völlig egal) und ein von der CA vertrautes SSL Zertifikat besitzen.

21. All diese Schritte müssen komplett erledigt sein.

22. Erst dann hat es Sinn, den UAG-DA Assistenten überhaupt auszuführen.

23. Es geht los.

28. “Aha, wir möchten also gemäß Anleitung jetzt mal eben ISATAP aus der globalen DNS-Sperrliste entfernen und einen A-Eintrag erstellen?”(http://technet.microsoft.com/en-us/library/ee649158(WS.10).aspx)

29. Und was hat das für Konsequenzen für unser Netzwerk?

30. Jeder Vista, Windows 7 und Windows 2008 Rechner im gesamten Netzwerk fährt seine virtuellen ISATAP Interfaces hoch und benutzt sie auch, wenn er kann.

32. “...naja, das muss ja nichts bedeuten.” Pingen wir doch mal irgendeinen (IPv4) Rechner…

33. ...na also, alles ganz normal. Oder etwa doch nicht?

34. Na dann pingen wir mal einen anderen IPv4 Rechner. Diesmal zufällig einen, wo Windows Vista, Windows 7 oder Windows 2008 installiert ist.

35. oh.

36. ...war das etwa gerade IPv6-ISATAP-Kommunikation? Das sah aber bis vor einer Minute noch ganz anders aus!

37. “Ach, das ist sicher nichts. Das muss sicher irgendwas mit dieser lokalen Auto-Konfiguration zu tun haben…..”

38. oh.

39. “Na ja. Macht ja nichts weiter. Meine Vista, Windows 7, Windows 2008 Systeme kommunizieren ab jetzt eben untereinander über IPv6.”

40. Ist doch super!

41. Das war ja einfach.

42. Oder etwa doch nicht?

43. “Warum funktionieren auf einmal einige Programme im Netzwerk nicht mehr? Spontan fällt uns hier Ontrack Powercontrols auf.”

44. “Die werden doch sicher so schlau sein, IPv4 zu benutzen, wenn sie mit IPv6 noch nicht klarkommen?!”

45. “Und wenn ich nach nur einem Tag schon einen Fall im Testlabor bemerke, wie viele sind es dann in meinem ganzen Netzwerk?”

46. Fragen wir doch mal den Hersteller....

47. http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/fc13f4b7-80fc-476c-8e99-22ced474102ahttp://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/fc13f4b7-80fc-476c-8e99-22ced474102a

48. Yaniv Naor, Microsoft, 10. Januar 2010„Hi,Legally we are not allowed to explicitly publish which applications are compatible and which are not.As to Microsoft products, I know that Office Communication Server doesn't work with IPv6“

49. Aha. Und nun?

50. ISATAP • muss nicht zwangsläufig über DNS aktiviert werden • Der entsprechende Testlabor-Client für ISATAP muss lediglich den Host „ISATAP“ irgendwie auflösen können, völlig egal, wie. Dies kann auch über einen einfachen hosts Eintrag passieren.