microsoft directaccess mit forefront uag

Microsoft DirectAccess

mit Forefront UAGJörg Riether

Micrsoft DirectAccess - Das VPN der

Zukunft?

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

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.

DirectAccess - mal eben installiert

und alles funktioniert?

Annahme

•Im Unternehmensnetzwerk kommt zum aktuellen Zeitpunkt reines IPv4 zum Einsatz

•DNS Server sind mindestens auf Windows 2003 und dynamische DNS-Aktualisierungen sind zugelassen

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

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

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)

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.

Ein paar Dinge im Detail

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)

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.

All diese Schritte müssen komplett

erledigt sein.

Erst dann hat es Sinn, den UAG-DA

Assistenten überhaupt

auszuführen.

Es geht los.

“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)

Und was hat das für Konsequenzen

für unser Netzwerk?

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.

“...naja, das muss ja nichts bedeuten.”

Pingen wir doch mal irgendeinen (IPv4)

Rechner…

...na also, alles ganz normal. Oder etwa doch

nicht?

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

oh.

...war das etwa gerade IPv6-ISATAP-

Kommunikation? Das sah aber bis vor einer Minute noch ganz anders aus!

“Ach, das ist sicher nichts. Das muss sicher

irgendwas mit dieser lokalen Auto-

Konfiguration zu tun haben…..”

oh.

“Na ja. Macht ja nichts weiter. Meine Vista,

Windows 7, Windows 2008 Systeme

kommunizieren ab jetzt eben untereinander

über IPv6.”

Ist doch super!

Das war ja einfach.

Oder etwa doch nicht?

“Warum funktionieren auf einmal einige

Programme im Netzwerk nicht mehr? Spontan fällt uns hier Ontrack Powercontrols

auf.”

“Die werden doch sicher so schlau

sein, IPv4 zu benutzen, wenn sie mit IPv6 noch

nicht klarkommen?!”

“Und wenn ich nach nur einem Tag schon

einen Fall im Testlabor bemerke,

wie viele sind es dann in meinem ganzen

Netzwerk?”

Fragen wir doch mal den Hersteller....

http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/

thread/fc13f4b7-80fc-476c-8e99-22ced474102a

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“

Aha. Und nun?

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.

Sie wollen aber ISATAP unbedingt im DNS

haben?•Man kann ISATAP pro Rechner

selektiv deaktiveren. „netsh interface isatap set state disbabled“ deaktiviert ISATAP auf dem entsprechenden Rechner, auch, wenn ISATAP via DNS, WINS oder hosts aufgelöst werden kann.

„....das will ich aber nicht bei allen

meinen Clients machen müssen!“

Beispiel Powercontrols

•Es reicht aus, auf dem Windows 2008 Server, ISATAP zu deaktivieren. Ab dann werden auch ISATAP-aktivierte Clients automatisch in IPv4 zurück gezwungen, wenn Sie versuchen mit dem Server zu sprechen.

MUSS ich ISATAP im Netzwerk

zwingend aktivieren, wenn ich DirectAccess

mit UAG benutzen möchte?

Nein.

•Dank UAG´s NAT64 und DNS64 müssen Sie das nicht unbedingt. Behalten Sie aber die Performance bei hohen DA-Clientzahlen im Auge. Das sagt Microsoft. Ich selbst habe dazu keine Erfahrungswerte

•Es gibt aber zu diesem Thema einen Thread von mir: http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/94863ffa-7880-4552-a32a-1b89435ec39f

Empfehlung für die ersten Versuche mit

DA•Legen Sie ganz am Anfang noch keinen

A Eintrag für ISATAP in Ihrem AD-DNS an.

•Fangen Sie klein an. Aktvieren Sie nur auf den Rechnern, welche Sie zum Testen aktiv nutzen wollen einen ISATAP-Eintrag in der lokalen hosts Datei.

...na dann weiter mit dem

DirectAccess Assistenten...

Ein DA-Client nimmt Verbindung

auf...

DA-Client (Windows 7 Enterprise &

Ultimate)startet irgendwo

extern, hinter einem NAT-Router.

Der UAG/DA Client geht diese Schritte:

1. Bin ich etwa intern? Prüfe via NLS.

2. Nein? Schön, dann bin ich extern.

3. direkt im Internet / kein NAT: nutze 6to4

4. hinter NAT und UDP geht: nutze Teredo

5. hinter NAT, aber UDP blockiert: nutze HTTPS-Tunnel über reines TCP-443

Der erste IPsec Tunnel wird bereits vor der

Benutzeranmeldung etabliert.

DA-ClientDA-Client

Tunnel 1: DA-ClientTunnel 1: DA-Client

UAGUAG

Auth: Computerzertifikat + ComputeraccountGPOs, Patches, komplettes Client-Management

Benutzeranmeldung...

Der externe DA-Client macht einen

Ping auf einen IPv4-Host im

Corpnet.

...zu kryptisch?- nein, eigentlich gar

nicht!

c2=194, 19=25, 74=116, 8d=141...macht zusammen:

194.25.116.141

8001= NAT64/DNS64 ist am Werk

ac=172, 10=16, 64=100, 01=1...macht zusammen:

172.16.100.1

Direkt vom UAG Team-Blog

Ping auf einen ISATAP-Host

(Vista, Win7 oder W2008)

ISATAP ist am Werk.Kein NAT64/DNS64 notwendig.

DNS

Name Resoltion Policy Table (NRPT)•Feature von Win7 / 2008

•DNS-Server-Policies werden ermöglicht (Welcher DNS-Server ist bei Anfrage X zu befragen und welcher bei Anfrage Y)

NRPT•kann Anfragen beispielsweise

an zsphaina.msft an den UAG-DNS, alle anderen Anfragen aber an den DNS des Clients übergeben.

•kann Ausnahmen zulassen (NLS)

NLS

...leiten wir doch mal eine 6to4-IPv6-Adresse aus einer IPv4-Adresse

ab.

Wenn das hier...

..Ihre IPv4 Adresse ist..

..so ist das hier (in 6to4 Notation)...

..Ihre IPv6 Adresse!

Konnektivität

Wie sehe ich aktive

Verbindungen auf dem UAG Server?

http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/f08439c6-5ada-

4ad0-9de8-f19f6c98aa84

Windows Advanced Firewall GUI auf dem UAG

Server

,netsh advfirewall monitor show

mmsa‘ auf dem UAG-Server

,netsh advfirewall monitor show

mmsa‘ auf dem DA-Client

Stolpersteine

HTTP/S Interface auf dem UAG kann

nicht starten. Timeout.

http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/e2589ac4-e225-

422a-a822-3d4975323199

Lösung: Server neu installieren.

Oh Ja. Natürlich. Nicht nur UAG.

Der ganze Server bitte einmal neu.

Externe DA Clients vom Corpnet aus verwalten. RDP,

Antivirus, AD, alles gut. Aber ich kann

keine c$ shares verbinden.

http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/

thread/a237fdab-887a-42c3-a7bf-b6c4d10c8442

Viele Roadwarriors, welche über WWAN

reinkommen, bekommen keinen

DirectAccess Aufbau zustande.

Warum das?

http://social.technet.microsoft.com/

Forums/en/windowsserver2008r2networking/thread/e036afe6-bf91-4bba-9d6f-

acea7fcf8436

Der DA-Client sieht sich direkt im Internet, kein

NAT, schaltet also direkt auf 6to4.

Prüft aber nicht, ob 6to4 eventuell blockiert wird.

Microsoft sagt dazu:

“The 6to4 protocol provides no way of discovering if it is blocked on a network: the interface comes online whenever a global IPv4 address is present. “

Viele WWAN Provider lassen

aber 6to4 Verkehr nicht zu. Und nun?

6to4 via GPO deaktivieren.

Oder selektiv mit ,netsh interface

6to4 set state disabled‘.

Performance

•Verglichen mit einer direkten PPTP Verbindung (auf einen Astaro 625 Cluster) ist eine direkte Teredo wie auch IP-HTTPS Verbindung zu DirectAccess bei einem SMB-Transfer ca. 40% langsamer. Dies muss natürlich nicht überall so sein. Aber bei uns ist es so.

http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/94863ffa-7880-4552-

a32a-1b89435ec39f

Performance

•Am UAG Server wird es kaum liegen (DELL R710, 15K-SAS-Platten, Raid 10, 16 Gig, Dual XEON 5520, auf dem Server läuft nur UAG, sonst nichts)

Sie wollen nur mit IP-HTTPS arbeiten und haben gerade eine Idee, etwaige

Performance betreffend?

...Sie denken daran, dass wir ja HTTPS

haben und theoretisch IPsec

deaktivieren könnten?

Durchaus machbar. Nicht via Assistent aber via

GPO (Windows Firewall mit erweiterter Sicherheit)

In diesem Fall würde die Authentifizierung

nach wie vor über IPsec laufen, die

Verschlüsselung im Tunnel aber nicht

mehr.

Aber...•Vergessen Sie diesen Tweak

auf keinen Fall jemals.

•Sollte in Zukunft jemand beispielsweise 6to4 aktivieren, würde ALLES unverschlüsselt über das Netz gehen.

Wir haben solch einen Tweak nicht

ausprobiert und können ergo auch

keine Benchmarkangaben

machen.

Die Idee an sich stammt ebenso wenig

von uns - John Craddock hat diese Möglichkeit auf der

TechEd Europe geäußert.

Unser Fazit

UAG mit DA ist sowohl für die IT als auch für die

Benutzer ein kleiner Segen.

Der Implementationsaufwand

darf aber keinesfalls unterschätzt werden.

Danke.

Ich verspreche, ich verlasse die

folgende Abendveranstaltung erst, wenn ich ALLE Fragen beantwortet

habe.

PS – sehr wichtige Links

• Deep dive into UAG DirectAccess (Tweaking the GPOs) http://blogs.technet.com/edgeaccessblog/archive/2010/02/18/deep-dive-into-uag-directaccess-tweaking-the-gpos.aspx

• When Good Network Location Servers Go Bad – Preparing Against NLS Failure http://blogs.technet.com/tomshinder/archive/2010/04/06/when-good-network-location-servers-go-bad-preparing-against-nls-failure.aspx

• Designing a DNS Infrastructure for Forefront UAG DirectAccess http://technet.microsoft.com/en-us/library/ee428856.aspx

• Designing Your Intranet for Corporate Connectivity Detection http://technet.microsoft.com/en-us/library/ee809088.aspx

• Network Location Awareness http://technet.microsoft.com/en-us/library/cc753545(WS.10).aspx