Nasazujeme Direct Access

Tento seriál popisuje základní konfiguraci a požadavky pro nasazení technologie Direct Acess na Windows Serveru 2008 R2. Ucelená verze seriálu bude v závěru ke stažení ve formátu PDF.

DirectAccess je zcela nová technologie Windows 7 a Windows 2008 R2, díky které můžete přistupovat a využívat tak prostředků ve vaší organizaci bez VPN klienta. DirectAccess vytvoří zabezpečené obousměrné spojení mezi každým klientem, který má dostatečné síťové připojení do internetu. Technologie DirectAccess je zcela závislá na protokolu IPv6.

V tomto dokumentu si popíšeme základní prvky instalace a konfigurace jednotlivých komponent DirectAccess technologie. Určitě zde nemohou být pokryty veškeré možnosti konfigurace, nicméně konfigurace a instalace DirectAccess komponent není nikterak složitá, ale je velmi důležité vše velmi dobře připravit a rozmyslet. Nasazení DirectAccess je velkým zásahem do stávajících infrastruktury, hlavně z důvodu nutnosti využívání a nasazení IPv6 protokolu do vaší infrastruktury.

Komponenty Direct Access

V následujícím odstavci se podíváme blíže na jednotlivé komponenty, na kterých je DirectAccess závislý. Tuto technologii můžeme nasadit v různých scénářích, mezi které patří následující:

Full Intranet access – V tomto případě jsou ustaveny 2 IPSEC tunely mezi klientem a DA serverem. Jeden je tzv. infrastrukturní, který slouží pro komunikaci s doménovými řadiči a DNS servery a druhý tunel je využíván pro přístup do interní sítě obecně
Full Intranet access with Smart Cards – Stejně konfigurované IPSEC tunely jako v předchozím případě, ale druhý tunel pro komunikaci do interní sítě je ustavován za pomoci Smart karty
Selected Servers access – Také zde jsou vytvořeny 2 IPSEC tunely, jeden je infrastrukturní a druhý je ustavován přímo proti serverům v interní síti. Druhý tunel tedy není terminován na DirectAccess Serveru, ale je pouze „propuštěn“ na servery v interní síti
End-to-End Access – V tomto případě je IPSEC ustavován mezi klientem a servery v interní síti vždy. V tomto případě není používán infrastrukturní tunel a IPSEC tunely jsou propouštěny přes DirectAccess server.

V našem dokumentu se zaměříme na první zmiňovaný scénář, který je pro demonstraci DirectAccess technologie asi nejlepší.

Jak již bylo napsáno v úvodu, tato technologie vyžaduje nasazení IPv6. V tomto případě máte na výběr ze dvou možností:

Využití automatického tunelovacího mechanizmu ISATAP
Nasazení IPv6 na stávající síti bez využití tunelování

Obě varianty jsou použitelné pro nasazení DirectAccess a jsou tedy funkční. Využívání ISATAP adaptérů a tunelování obchází některé požadavky, které jsou nutné při plné implementaci IPv6 na interní síti. Na druhé straně je ISATAP protokolu vyčítána závislost na protokolu vyšší vrstvy, což může v některých případech způsobovat problémy.

Technologie DirectAccess dále vyžaduje nasazení následujících služeb, požadavky na jejich přesnou konfiguraci rozebereme níže v dalších kapitolách tohoto dokumentu.

Certifikační autorita
Active Directory a GPO
NLS – Network Location Service
ISATAP router v případě využívání technologie ISATAP

Tyto služby mohou být nasazeny ve zhuštěné konfiguraci na dvou serverech, nebo může být infrastruktura distribuovaná ve výrazně složitější konfiguraci. Obě varianty jsou znázorněny na následujících obrázcích. V případě, že se rozhodnete pro nasazení pouze jednoho serveru pro DA a další služby, důrazně doporučuji využívat alespoň virtualizačních technologií k dosažení požadované dostupnosti celého řešení.

Volitelnou součástí je implementace NAP technologie, se kterou DirectAccess dokáže velmi úzce spolupracovat. V poslední řadě bych zmínil možnost využívání čipových karet k zabezpečení celého procesu.

Jedna z možných variant distribuovaného řešení

Varianta s nejjednodušší možnou konfigurací

Další možné varianty jsou pro nasazení DirectAccess v topologiích s více pobočkami. V těchto případech je možné nasadit více DirectAccess serverů, které jsou klienty vybrány pomocí tzv. geo-locator služby. Popis těchto konfigurací je už nad rámec tohoto dokumentu a v případě potřeby můžete využít následující odkaz: http://technet.microsoft.com/en-us/library/ff625682(WS.10).aspx

Požadavky

Nároky na software

DirectAccess vyžaduje edice Windows 7 Enterprise, nebo Ultimate na straně klienta a Windows 2008 R2 na straně serveru.

DNS servery a globální katalog musí běžet na Windows 2008 nebo R2. Pro Windows 2008 je nutná instalace hotfixu - 958194 http://go.microsoft.com/fwlink/?LinkId=159951.

Veškeré servery nebo aplikace, které mají být dostupné přes technologii DirectAccess musí být schopné komunikovat přes IPv6. Pozor tedy na aplikace běžící výhradně na IPv4 síťovém stacku. Typickým příkladem takových aplikací mohou být např. staré aplikace provozované na Windows NT, nebo UNIX systémech. Takové aplikace mohou být dále dostupné přes technologie jako je NAT64 a podobné, ale jejich nasazení je většinou dost náročné. Můžete případně sáhnout po instalaci klientů na Terminálové servery Windows Serveru, což je v mnoha případech nejlepší možné řešení.

Nároky na síťovou infrastrukturu

V závislosti na zvolené topologii pro instalaci je nutná podpora pro IPV6 na síťových prvcích uvnitř organizace, nebo alespoň nasazení ISATAP pro tunelování IPv6 na vnitřní síti.

Dále jsou nutné dvě veřejné (po sobě jdoucí v abecedním pořadí) IPv4 adresy, které budou sloužit pro přístup klientů přes DirectAccess.

Stručně o IPv6

V následujících odstavcích se velmi stručně seznámíme s protokolem IPv6, ukážeme si různé druhy adres a možností tunelování IPv6 přes IPv4 sítě. Pro fungování DirectAccess je tato technologie naprosto klíčová, proto je velmi důležité se seznámit s tímto protokolem. Toto téma je natolik složité že jej zde nebudeme rozebírat do hloubky, nicméně v poslední kapitole je obsaženo několik odkazů na externí zdroje, kde se k této problematice můžete dozvědět podstatně více.

IP verze 6 je nástupcem stávajícího protokolu IPv4. Tento protokol by měl do budoucna odstranit problém s vyčerpáním IPv4 adresního prostoru a tímto umožnit další rozvoj. Protokol IPv6 není zpětně kompatibilní s protokolem IPv4. Díky tomuto problému vzniklo mnoho podpůrných technologií, které umožnují převod či postupný přechod k protokolu IPv6.

Adresy v IPv6
Adresy v IPv6 jsou 128 bitové, tak aby nedošlo k podobným problémům jako u IPv4. Díky tomu, že jsou adresy dlouhé a jen těžko zapamatovatelné, se přešlo ke zjednodušení zápisu k hexadecimální soustavě, kde se každá čtveřice odděluje pomocí znaku dvojtečky. I takto upravený zápis je velmi složitě zapamatovatelný.

Příklad IPv6 adresy: 2001:4860:8009:0000:0000:0000:0000:0068

Stejnou IP můžeme zapsat také ve zjednodušeném formátu, kdy se mohou vypustit nulové skupiny v adrese, ty jsou pak nahrazeny dvojicí dvojteček. Stejná IP adresa pak ve zjednodušeném formátu vypadá takto: 2001:4860:8009::68

Zápis prefixů je stejný nebo obdobný jako u IPv4 tedy adresa/délka.

Stejně jako u IPv4 jsou vybrány druhy adres (prefixů), které jsou vymezeny pro různé účely.

prefix	Použití
::1/128	loopback
fe80::/10	Lokální linkové adresy.Link-local
fc00::/7	Unikátní individuální lokální adresy (Unique lolcal address (ULA))
2001::/32	Prefix využívaný pro Teredo
2002:/16	Prefix vyhrazený pro 6to4.

Teredo
Teredo je automatický tunelovací mechanizmus, který využívá přenosu přes IPv4. Jeho obrovskou výhodou je možnost automaticky se vypořádat s NAT na IPv4. K přenosu využívá velmi složitý systém adres. Přenos dat mezi Teredo klientem a IPv6 světem zajišťuje tzv. Teredo relay. Výhodou protokolu je, že můžeme téměř všude komunikovat pomocí IPv6, ale na druhou stranu jsou přenosy dosti pomalé, právě z důvodů využívání Teredo serverů.

ISATAP
Tunelovací mechanizmus, který je určen pro provoz na interních sítích. Je odvozen od zkratky Intra Site Automatic Tuneling Adapter. Adresy jsou odvozovány od IPv4 adres a jejich formát tedy je:

UnicastPrefix:0:5EFE:w.x.y.z, nebo UnicastPrefix:200:5EFE:w.x.y.z, kde w.x.y.z je IPv4 adresa.

6to4
Tunelovací mechanizmus, který umožňuje propojit dvě nebo více IPv6 sítí. V tomto případě mají adresy prefix 2002:XXXX:XXXX::/48, kde XXXX:XXXX je IPv4 adresa.

6over4
Přenos paketů přes IPv4 využívající multicast. Jeho použití je velmi limitované.

NAT-64
Technologie určená k usnadnění přechodu mezi IPv4 a IPv6. Díky této technologii je možné přistupovat k IPv4 prostředkům přes IPv6 síť. NAT64 je novější variantou od NATPT, ale je pouze jednosměrný.

NAT-PT
Obdobná technologie jako NAT-64, která je starší a měla spousty nevýhod. Obecným problémem byla obousměrnost komunikace, kterou tato technologie chtěla zaručit.

Seriál: Nasazujeme Direct Access – instalace WS 2008 R2 (část 2.)

Pro potřeby technologie DirectAccess je vyžadována běžná instalace Windows Server 2008 R2 serveru. Jen je dobré dodržet některé běžné zásady pro instalaci. Pro přehlednost doporučuji pojmenovat jednotlivá síťová rozhraní jednoznačnými jmény, např. Internal a External. Dále nastavte statické adresy na jednotlivých síťových kartách. Pokud je nutné nastavit routovací pravidla, pak je nastavte.

Pokud budete veškeré potřebné komponenty instalovat na jeden server, pak po instalaci přidáme IIS pomocí konfigurace rolí na serveru.

V konfiguraci IIS přidáme pouze IP and Domain Restrictions. Tuto součást využijeme při konfiguraci NLS.

Dále si připravíme adresář a webovou aplikaci pro distribuci CRL. Spustíme IIS Manager a zvolíme „Default Web Site“ a kontextovém menu zvolíme Add –> Virtual Directory. Samozřejmě si můžeme vytvořit samostatnou webovou aplikaci, pokud je to vyžadováno. V následujícím okně zapíšeme název virtuálního adresáře, v našem případě CRLD. V položce Physical Path, zvolíme požadovanou cestu a následně vytvoříme nový adresář CRLDist, který budeme využívat pro kopírování CRL.

Po vytvoření virtuálního adresáře, je nutné nakonfigurovat volbu allowDoubleEscaping. Toto provedeme tak, že v levé části vybereme nově vytvořený adresář a v části Management spustíme Configuration Editor. Ve vrchním stromečku vybereme sekci system.webServer\security\requestFiltering – vybereme allowDoubleEscaping a změníme z False na True.

Po konfiguraci IIS je ještě nutné pro adresář CRLDist nastavit sdílení. Najdeme si adresář pomocí průzkumníka, zvolíme z kontextového menu Properties - > záložka Sharing -> Advanced Sharing. K názvu adresáře přidáme znak $ a následně přidáme práva pro počítačový účet naší certifikační autority. V mém případě se Certifikační autorita jmenuje DC1. Celý postup potvrdíme OK.

Příprava Active Directory

Úpravy, které jsou nutné provést v ActiveDirectory nejsou nikterak složité. Při konfiguraci DirectAccess vznikají v ActiveDirectory dva GPO objekty. Tyto objekty jsou následně využívány pro konfiguraci DirectAccess Serveru. Pokud pro konfiguraci DirectAccess budeme využívat průvodce, pak nám tyto objety vytvoří Direct Access průvodce sám.

Pro aplikaci GPO je doporučeno vytvořit skupinu, kterou budeme využívat pro filtrování GPO objektů.

Vytvořte tedy obdobně jako na následujícím obrázku bezpečnostní skupinu. Bude sloužit pro klienty DirectAccess.

Konfigurace certifikační autority

Jak již bylo napsáno pro korektní fungování DirectAccess je nezbytné využívání certifikátů. Zapotřebí je hned několik certifikátů. Než se ovšem pustíme do generování a konfigurování certifikátů, je nutná úprava distribuce revokačních listů certifikační autority (CRL). Revokační listy musí být pro korektní fungování DirectAccess dostupné přímo z internetu. Bez tohoto by nebyl funkční tunel přes HTTPS.

Úprava publikace CRL

Otevřeme konzolu Certifikační autority, označíme naší certifikační autoritu a z kontextového menu volíme Properties.

Na záložce Extensions musíme dokonfigurovat distribuci CRL na náš DirectAccess server, nebo jiný server, který bude dostupný z internetu přes HTTP. Pro přidání distribučního bodu CRL zvolme Add. A do políčka Location napíšeme adresu pro CRL např. http://crl.organizace.cz/crld/ . Dále pomocí tlačítka insert postupně zvolíme <CAName> , <CRLNameSuffix>, <DeltaCRLAllowed>. Na konec řádky Location připíšeme .crl a potvrdíme tlačítkem OK.

Na záložce extensions máme nyní o jeden řádek více. Tento řádek si označíme a nastavíme tyto dvě položky:

Include in CRLs. Clients use this to find Delta CRL locations
Include in the CDP extension of issued certificates

Znovu zvolíme Add a přidáme UNC cestu k distribuci CRL. V následujícím dialogu do políčka Location napíšeme UNC cestu k distribuci CRL. Dále pomocí tlačítka insert postupně zvolíme <CAName> , <CRLNameSuffix>, <DeltaCRLAllowed>. Na konec řádky Location připíšeme .crl a potvrdíme tlačítkem OK.

Na záložce extensions máme nyní o další řádek více. Tento řádek si označíme a nastavíme tyto dvě položky:

Publish CRLs to this location
Publish Delta CRLs to this location

Potvrdíme tlačítkem OK a restartujeme službu certifikační autority.

Seriál: Nasazujeme Direct Access – automatická distribuce klientských certifikátů (část 3.)

Prvním a nejjednodušším procesem je vystavování počítačových certifikátů pro klienty. Pokud již nemáte nastaveno automatické vystavování certifikátů přes službu ActiveDirectory, je nutné jej donastavit.

K automatickému vystavování využijeme služeb Active Directory. Nejdříve je nutné se přesvědčit, zda máme publikován tzv. Certificate Template pro tento druh certifikátů a zda máme nastavena oprávnění pro automatickou distribuci. Otevřeme si tedy konzolu od certifikační autority. Na položce Certificate Templates pod kontextovým menu zvolíme Manage.

V následující obrazovce vyhledáme Template Computer, v kontextovém menu zvolíme Properties a na záložce Security ověříme, že Domain Computers mají povoleno Enroll (Allow enroll). Tímto jsme ověřili, že Domain computers mají právo na vystavení certifikátu.

Dalším krokem, je vytvoření doménové politiky, kterou zařídíme automatické vydání certifikátů pro všechny klienty DirectAccess. Otevřeme si konzolu na správu doménových politik. Přejdeme na záložku Group Policy Objects.

V kontextovém menu zvolíme New a politiku pojmenujeme dle vašich jmenných konvencí. V tomto případě DA_NastaveniKlientu.

V GPO nastavíme automatické vydávání certifikátů pro klienty. Přejdeme tedy na vytvořenou politiku a z kontextového menu zvolíme Edit. V následující MMC konzoli vyhledáme Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies -> Automatic Certificate Request Settings.

V kontextovém menu vybereme New Automatic Certificate Request a Next. V dalším okně průvodce vybereme předem připravený Certificate Template Computer a zvolíme Next a v posledním okně průvodce Finish.

V politice dále nakonfigurujeme položku Auto-Enrollment Properties. Obdobně jako na následujícím obrázku.

Tímto máme tuto část politiky hotovou a konzolu můžeme uzavřít. Dále nastavíme ještě základní parametry aplikace GPO. Politiku označíme a v pravé části se nám zobrazí detaily k naší vytvořené politice. V nastavení politiky provedeme dvě změny. Na záložce Scope v části security Filtering odebereme Authenticated Users a přidáme skupinu, kterou jsme si pro tento účel dříve připravili.

Dále na záložce Details vybereme z kontextové nabídky „User configuration settings disabled“ (vybereme proto, že v této politice nebude nic v uživatelských nastavení).

Posledním krokem je nastavení aplikace této politiky. V mém případě tuto politiku aplikuji na celou doménu, ale můžete ji připojit na některé níže položené OU. Na konkrétním OU z kontextového menu zvolíme Link existing GPO a vybereme naší připravenou politiku. Tímto zajistíme její aplikaci.

Vytvoření nového template

Dále je nutné vygenerovat certifikát pro NLS (Network Location Server). Pro tento certifikát je nutné vytvořit nový Template. Spustíme konzolu od certifikační autority, vybereme Certificate Template a z kontextového menu vybereme Manage. V seznamu vybereme Template Web Server a z kontextového menu vybereme Duplicate Template. Z následujícího výběru vybereme Windows Server 2008 Enterprise.

Duplikovaný Template pojmenujeme opět dle vašich jmenných konvencí, v tomto případě ji pojmenujeme DAWebServer.

Na záložce Request Handling zaškrtneme volbu „Allow private to be exported“.

Poslední nastavení, které je nutné změnit je na záložce Security. Povolíme Enroll pro Authenticated Users. Potvrdíme OK a okno Certificate Template Console můžeme zavřít.

Nyní povolíme Certificate Template, který jsme v předchozím kroku vytvořili. Vybereme Certificate Templates a z kontextového menu vybereme New -> Certificate template to issue. Ze seznamu vybereme náš vytvořený template.

Seriál: Nasazujeme Direct Access – vygenerování certifikátů na DirectAccess Serveru (část 4.)

Na certifikační autoritě máme vše připravené a můžeme přistoupit k vygenerování certifikátů pro NLS a DirectAccess. Na DirectAccess serveru si spustíme konzolu na správu certifikátů.

V následujícím dialogu vybereme publikovanou šablonu, kterou jsme si připravili v předchozích krocích.

Pro konfiguraci Common Name a DNS jména v certifikátu zvolíme vlastnosti a v položce Subject Name vybereme Common Name a napíšeme FQDN našeho NLS serveru a zvolíme Add. Do části Alternative Name vybereme DNS a napíšeme opět FQDN jméno našeho serveru. Ostatní části necháme bez změn a potvrdíme tlačítkem OK.

Následuje už jen poslední krok a tím je samotné vyžádání certifikátu, podle parametrů které jsme nastavili.

Nyní máme připraven certifikát pro NLS, který by měl být uložen včetně privátního klíče v Personal úložišti našeho DA serveru.

Obdobně vygenerujeme další certifikát pro IP-HTTPS, který bude využíván pro HTTPS tunel. Spustíme tedy opět průvodce Request new certificate. Opět zvolíme náš upravený Certificate Template. Ve vlastnostech žádosti k certifikátu vyplníme Common Name a DNS na externí jméno DirectAccess serveru. Ještě zapíšeme Friendly Name na záložce General.

Seriál: Nasazujeme Direct Access – nastavení firewallu (část 5.)

Pro korektní fungování DirectAccess jsou nutné některé síťové prostupy, které jsou dány spíše technologií kterou DirectAccess využívá. Rozdělme tedy síťové požadavky na několik částí:

Jak již bylo popsáno dříve, pro korektní fungování jsou nutné dvě po sobě jdoucí IP adresy. Dále je nutné povolit pro IPv4 :

Konfigurace ISATAP

Pokud nemáte nasazenou IPv6 uvnitř vaší organizace, pak je nutné nakonfigurovat protokol ISATAP. Konfiguraci IPv6 prefixu a konfiguraci ISATAP routeru za nás provedl průvodce konfigurací DirectAccessu. ISATAP je trochu zvláštní protokol, jedna z věcí která je mu vyčítána, je jeho závislost na protokolu vyšší vrstvy. Všichni klienti, kteří mají zapnutý tunelovací adaptéry ISATAP, hledají při startu záznam v DNS se jménem ISATAP. Pokud tento záznam najdou, automaticky adaptér nakonfigurují a spustí.

Z bezpečnostních důvodů je záznam ISATAP v Microsoft DNS blokován. Pokud tedy chceme začít využívat ISATAP adaptérů a tunelování IPv6 na interní síti musíme tento záznam odblokovat. A vašich DNS serverech musíte spustit nástroj regedit. Přejdeme do této cesty v registrech: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

Najdeme klíč GlobalQueryBlockList a uvnitř vymažeme záznam isatap. Následně restartujeme DNS službu. Stejný postup zopakujeme na dalších DNS serverech, pokud jej máme.

Pokud vaše infrastruktura obsahuje více doménových řadičů a více různých IPv4 subnetů, nezapomeňte nakonfigurovat i IPv6 subnety pro jednotlivé AD Sites.

Konfigurace DirectAccess

Nyní bychom měli mít vše potřebné ke konfiguraci DirectAccess serveru připraveno. V bodech pro jistotu ještě uvádím, tak aby si každý mohl překontrolovat:

Pokud máme vše připravené, můžeme přidat komponentu DirectAccess Management Console.

Po přidání DirectAccess Management konzole můžeme přistoupit ke konfiguraci. Přejdeme do části Setup. Pokud jsou splněny veškeré předpoklady k úspěšné konfiguraci, můžeme začít prvním krokem, volbou Remote Clients.

Pomocí tlačítka Configure zobrazíme dialogové okno k přidání skupiny klientů. Tlačítkem Add přidáme skupinu, kterou jsme si dříve připravili pro klienty DirectAccess.

Druhým krokem je konfigurace DirectAccess Serveru. V následujícím průvodci jen překontrolujeme korektní přiřazení síťových rozhraní. Podle těchto adres bude následně nakonfigurován ISATAP router.

Ve druhém kroku musíme vybrat dva certifikáty. První výběr obsahuje volbu certifikační autority, ze které musí být vydávány certifikáty pro klientské počítače. Druhá volba je výběr certifikátu pro HTTPS tunel.

Třetím průvodcem je průvodce nastavení infrastruktury. Pokud máte, obdobně jako já, NLS server umístěn na serveru, vyberte druhou volbu. Na funkčnosti této části závisí korektní fungování DirectAccess klientů, proto je zde doporučeno instalovat NLS na vysoce dostupný server. Pokud bude tato komponenta nedostupná, nemusí klientské počítače fungovat v interní síti. NLS komponenta slouží pro detekci interní sítě. NLS není nic jiného než web server, který je dostupný pouze v případě, že je klient na interní síti. Důležité je zde zmínit, že je kontrolován i certifikát, který je instalován na konkrétní webové aplikaci. Následně jsou podle této detekce používána pravidla pro NRPT (Name Resolution Policy Table).

Druhým krokem je nastavení DNS serverů a jejich IPv6 adres. IPv6 prefix je průvodcem vygenerován automaticky. Tento prefix je odvozen od vaší externí adresy, která je převedena do šestnáctkové soustavy a doplněna prefixem 2002.

Třetím krokem je nastavení management serverů. Pokud je u vás využíván nějaký vzdálený management ke správě počítačů, pak nastavte IPv6 adresu.

V případě, že byste požadovali, aby byla komunikace šifrována i při komunikaci s dalšími servery, pak použijte skupinu, kterou jste si k tomuto účelu připravili. V tomto případě nepožadujeme další šifrování provozu, stačí nám bezpečná komunikace mezi klientem a DirectAccess serverem.

Následuje už jen závěrečný přehled, který si můžete uložit pro pozdější použití. Po stisknutí tlačítka OK jsou vaše nastavení přenesena do ActiveDirectory a na DirectAccess Server.

Po aplikaci změn doporučuji restartovat jednotlivé DNS servery tak, aby mohl být nakonfigurován ISATAP adaptér. Po těchto změnách by měla být funkční IPv6 konektivita mezi DirectAccess serverem a DNS servery. Toto můžeme ověřit po restartu DirectAccess serveru na stránce DirectAccess Monitoring.

Seriál: Nasazujeme Direct Access – příprava a konfigurace DirectAccess Connectivity Assistant (část 6. – poslední)

Pro usnadnění diagnostiky ze strany klienta je zde Solution Accelerator pro DirectAccess ve kterém je obsažen tento nástroj. Obsahuje instalační balíček ve formátu MSI a GPO šablonu pro konfiguraci tohoto nástroje. Stáhněte tedy instalační balíček a rozbalte jej. Na doménový řadič si nakopírujte šablonu ADMX a ADML soubory. Soubor DirectAccess Connectivity Assistant GP.admx nakopírujte do %systemroot%\PolicyDefinitions a soubor DirectAccess Connectivity Assistant GP.adml do %systemroot%\PolicyDefinitions\en-us.

K instalaci DirectAccess Connectivity Assistant můžete využít GPO, nebo instalace pomocí různých management nástrojů.

Konfiguraci pro DirectAccess Connectivity Assistant přidáme do naší dříve vytvořené politiky pro klienty DirectAccess. Otevřeme si tedy již vytvořenou politiku a nastavíme základní části politiky.

Po úspěšné instalaci a konfiguraci Connectivity Assistent bude na klientském počítači v systém tray ikonka, která bude diagnostikovat stav připojení do korporátní sítě. Jednotlivé stavy jsou znázorněny v následující tabulce.

Příprava klientů k nasazení DirectAccess

Pokud máte provedeny veškeré kroky z předchozích kapitol, pak už je samotné povolení využívaní DirectAccess technologie jen otázkou aplikace korektních politik na klienty. Přidejme tedy testovací počítač do skupiny DirectAccess klientů, kterou jsme si vytvořili.

Testovaní DirectAccess

Po přidání testovacího počítač do skupiny DirectAccess klientů nezapomeňte počkat nebo obnovit doménové politiky na klientovi. Aplikaci můžete ověřit pomocí nástroje gpresult. Také by v počítačovém úložišti certifikátů měl být certifikát pro konkrétní počítač. Po úspěšné aplikaci politik můžete počítač připojit mimo interní síť a po několik málo vteřinách by DirectAccess Connectivity Assistant měl ukazovat, že korporátní síť funguje v pořádku. Nyní můžete otestovat ping na interní DNS servery, případně další servery, které již mají dostupnou IPv6 adresu.

Řešení problémů

Při řešení problémů s DirectAccess serverem je důležité zaměřit se na podpůrné technologie, na kterých je DirectAccess přímo závislý. Při řešení většiny problémů vám pomůže log, který získáte z nefunkčních klientů.

DirectAccess server

Při většině implementací nebyl problém v samotném DirectAccess serveru, ale v nefunkčních komponentách nebo špatné konfiguraci některé z komponent.

Klient DirectAccess

Pokud je problém na straně klienta, je důležité ověřit funkčnost tunelovacích adaptérů a síťovou konektivitu. Následně stav certifikátů a dostupnost CRL. Bez možnosti ověřit certifikát nebude možné uskutečnit spojení s DirectAccess serverem. Se spoustou těchto kroků nám pomůže log, který je možné vygenerovat přes DirectAccess Connectivity Assistant. Tento log můžeme vygenerovat přes pravé tlačítko na ikonce Connectivity Assistenta v části the Advanced Diagnostics. Logy jsou automaticky vytvořené a uložené do cab souboru. V tomto log souboru jsou veškeré potřebné informace, které jsou nutné ke zjištění příčiny nefunkčnosti připojení. Log je rozdělen do několika částí:

	DirectAccess je funkční.
	Není dostupná internetová konektivita.
	DirectAccess není dostupný nebo je problém s dostupností některé části sítě.
	Pokud je DirectAccess nasazen spolu s NAP technologií může být v některých případech vyžadováno nová kontrola NAP serveru.

Nasazujeme Direct Access – úvod a požadavky (část 1.)