Ondrej Sevecek's Blog

Sice už jsem několikrát 802.1x implementoval, ale vždycky to bylo jen za pomoci certifikátů počítačů. Vždycky jsem ověřoval jen identitu počítače. Nikdy jsem neověřoval uživatele, protože to s Windows XP fungovalo podivně, chovalo se to nestabilně, občas se to odpojovalo a většinou to děsně dlouho trvalo, než se síťovka "chytla".

Takže jsem byl moc rád, když jsem byl požádán o implementaci 802.1x pro čistě Windows 7 prostředí a mohl si vyzkoušet, jak to funguje při ověřování obojího, počítače i uživatelů. A nikdy jsem si vlastně ani neuvědomil, jak je to uživatelské ověřování pěkné :-) Hlavně to s Windows 7 funguje hladce! Následují detaily a fakta, která jsem ověřil že fungují, takže to třeba někomu pomůže rychle s tím začít, aniž by musel procházet tím, čím já, protože s nějakými výchozími parametry rozhodně nepočítejte :-)

Co je vlastně 802.1x

Nebudeme se tu zabývat příliš vysvětlováním funkce, jen detaily potřebné pro implementaci ve Windows. Jedná se o technologii, která omezuje přístup neznámých počítačů, případně uživatelů, do sítě. Jednoduše řečeno, síťové switche (Ethernet, WiFi) vypnou daný port, pakliže připojený počítač nedokáže prokázat svoji identitu. Znamená to, že se vám do sítě nemůže připojit cizí počítač. Ověření identity se provádí ve Windows pomocí loginu a hesla uživatele nebo počítače do domény, nebo pomocí SSL klientského certifikátu (SSL Clien Certificate, Client Authentication).

Ověřovat tedy můžete buď počítač, bez ohledu kdo je na něm přihlášen. Buď to jsou všechno vaše doménové počítače a používá se prostě jejich heslo, nebo jim vydáváte certifikáty. Ověřovat můžete ale i jednotlivé uživatele. To by znamenalo, se se síťová karta odpojuje a připojuje až v okamžiku, kdy je někdo přihlášen.

Jak to funguje

Potřebujete switche, nebo WiFi AP, které tenhle protokol umí. V případě switchů to znamená, že musí být spravovatelné, tedy dražší. Je to o to horší, že každý kabel musí být připojen do spravovatelného switche. Jakmile k nějaké spravované zásuvce připojíte nespravovatelný switch (který tedy zřejmě neumí 802.1x), přes tento switch se nebudou počítače ani uživatelů už dále ověřovat. Zřejmě tedy budete muset mít všechny switche spravovatelné.

Dále potřebujete RADIUS server, který bude ve skutečnosti uživatele ověřovat. Switch ani AP sám tohle nedělá, jen přeposílá ověřovací komunikaci mezi uživatelem a RADIUS serverem. V případě Microsoft implementace budeme mít buď IAS (Internet Authentication Service), nebo novější NPS (Network Policy Server).

Jakmile se zastrčí kabel do switche, prvek si sám řekne klientskému počítači, že požaduje ověření. Počítač mu pošle ověřovací informace, které daný prvek přeposílá s RADIUS serverem. Pokud RADIUS řekne, že je to v pořádku, switch povolí další komunikace na dané zásuvce.

Výhoda je, že RADIUS server může switchi říct nejenom "ok, pusť ho", ale může mu také přidělit číslo VLAN, do které má být daný port přehozen. Můžete tedy mít více různých politik. Například určitá skupina počítačů může být pouze ve VLAN s lokálním přístupem, jiné stroje s přístupem do internetu, nebo někdo třeba jen s velmi omezeným přístupem. Upozorňuju, že VLAN znamená samostatný IP rozsah!

Výhody počítačového ověření

Ověřování počítačů je jasné. Pokud se nejedná o autorizovaný stroj, prostě se do sítě nedostane. Případně můžete mít třeba více skupin počítačů, které rozhazujete do různých VLAN, podle různých požadavků. Třeba obyčejné klientské stroje vs. notebooky správců vs. neověřené počítače, které se musí nějak nainstalovat apod.

Pro ověření si vyberete jen účet a heslo stroje do domény, pokud jsou všechny počítače v doméně. Jinak byste zřejmě použili certifikáty. Ty vyžadují určitou, i když jen velmi jednoduchou správu, takže je to nejspíš až druhé řešení. Ale pro stroje, které nejsou v doméně, to jinak nepůjde.

Uživatelské ověření

Proč bych ověřoval uživatele? Jsou různé důvody, které se někdy hodí a někdy ne, podle toho co přesně chcete:

• Ne-doménové počítače - budu ověřovat uživatele pomocí jejich loginu a hesla do domény. Každý si bude moci donést i třeba svůj domácí počítač, ale když zadá svoje doménové heslo, do sítě se dostane.
• Individuální VLAN podle uživatelských skupin - chtěl bych dávat počítače do různých VLAN podle toho, kdo je tam zrovna přihlášen. Možná se vám to nezdá úplně potřebné. Ale představte si například scénář - skupina správců sítě s maximálně neomezeným přístupem vs. ostatní doménoví uživatelé vs. lokální uživatelé.

Vyberete si ověření heslem, nebo certifikátem? Heslo ti lidé znají a mohou ho zadávat i na počítačích, které nejsou v doméně. Jde o to, jestli tohle chcete, nebo nechcete. Sice možná nebudu vědět co to je za počítač, ale možná mi to také nevadí, protože vím, že tam pracuje uživatel se "zodpovědností".

S certifikátem to bude možné více navázat na doménové počítače. Certifikáty se normálně ukládají v profilu uživatele (pokud nepoužívají čipové karty). Profily máte jen na doménových počítačích. Certifikáty mohou být označeny jako ne-exportovatelné. Tím se dá poměrně pohodlně uživatelům ztížit připojování z cizích strojů (říkám ztížit, protože to půjde nějak komplikovaně obějít, ale může to být nad schopnosti normálních lidí).

Ověření uživatelů i počítačů

Klient 802.1x ve Windows bohužel neumí současné ověření obojího. To znamená, že buď je na kabelu ověřen uživatel, nebo počítač. Můžete si zapnout "oboje", ale bude to fungovat tak, že při startu stroje se ověří počítač a jakmile se někdo přihlásí, ověří se to podle toho uživatele. Je také možné, že když se náhodou přihlásí uživatel, který nelze ověřit (například lokální uživatel), tak bude stroj bez konektivity.

Tuhle poslední možnost jsme použili my. Požadavkem zákazníka bylo, aby doménoví uživatelé mohli všude, zatímco lokání nemohli vůbec nikam.

Ještě jedním faktem je, že pokud se použije tato "přepínaná kombinace", bude nutné ověřovat všechny identity (počítače i uživatele) stejným typem, tzn. oba buď certifikátem, nebo oba jen heslem. Nelze to kombinovat, protože Windows klient má pouze jednu nastavení, kde se to musí vybrat natvrdo.

Náš složitý a ověřený scénář

Požadavkem bylo zařídit, aby:

• ne-doménové stroje se do sítě nedostaly - z toho plyne, že musíme ověřovat počítače, ale můžeme prozatím použít buď certifikáty nebo loginy.
• ne-doménové stroje se musí nějak nainstalovat a připojit - pokud se stroj neověří, bude muset být v nějaké, byť velmi omezené, VLAN s přístupem alespoň na jedno DCčko (Domain Controller)
• doménové počítače musí mít přistup do lokální sítě - okej, po ověření budou v nějaké méně omezené VLAN.
• doménoví uživatelé musí mít přístup i do internetu, lokální nesmí nikam - to znamená, že musíme ověřovat i uživatele. Bude to znamenat také další VLAN s přístupem do internetu. Aby byla splněna podmínka "jen doménové stroje", budeme potřebovat certifikáty (ne-exportovatelné). Hesla nemůžeme nechat lidi zadávat, protože by si je mohli zadávat i na libovolných přinesených počítačích.
• pokud mají uživatelé na počítači jeden cizí certifikát, musí je ověřit jiný RADIUS server, než ten náš. Pozná se to tak, že v tom jejich certifikátu je jiné jméno uživatele, tedy přesněji řečeno jiná doména za zavináčem @.

Výsledný systém je tedy:

• Ověřování certifikáty
• Ověřování obojího, počítačů i uživatelů
• Certifikáty se vydávají automaticky (autoenrollment) doménovým počítačům i uživatelům
• Certifikáty jsou ne-exportovatelné (pozor, tohle je jen slabé omezení, ale aby to někdo obešel, musel by být dost zkušený a my to ještě navíc můžeme sledovat)
• Tři VLANy. Když se nikdo neověří, je v "instalační VLAN" s přístupem na jediné DC a AD CS (Active Directory Certificate Services), tedy certifikační autoritu. Když se ověří počítač, hned po svém startu je v "doménové VLAN", tedy s přístupem do intranetu. Jakmile se později přihlásí nějaký doménový uživatel, stroj se přepne do "internetové VLAN" s plným přístupem i ven. Pokud by se přihlásil lokální uživatel, neověří se, takže to zase spadne do té původní "instalační VLAN".

Certifikáty

Certifikáty vydáváme automaticky pomocí technologie autoenrollment. Když to budete implementovat, dávejte pozor na toto:

• certifikační autorita, která vydává certifikáty musí být v NTAuth store v Active Directory.
• chceme autoenrollment, takže potřebujeme, aby ta autorita byla nainstalována tzv. v režimu Enterprise. Nemusíte mít Enterprise Edition operačního systému, jen musíte tu autoritu nainstalovat do "režimu" Enterprise.
• ideálně si vytvořte na to novou CA, protože ji potom velmi jednoduše omezíte v politice pro uživatelské počítače (chápu, že to není jen tak, klidně použijte stávající :-))
• pokud použijete AD CS na Windows Server 2008 R2, tak můžete používat šablony certifikátů (Certificate Template) i když máte jen Standard Edition.
• musíte použít dvě šablony (Certificate Template). Udělejte si kopii výchozí User šablony pro uživatele a Computer šablony pro počítač. Pokud uděláte jenom jednu šablonu, buď počítač, nebo uživatel si ji sám nevydá - šablony jsou vždy typu buď User nebo Computer a ten druhý si ji nemůže vyžádat.
• kopii vytvořte pouze Windows Server 2003 a nikoliv 2008. Starší verze produkuje certifikáty do CSP, zatímco novější do CNG úložiště. Klient 802.1x (konkrétně obecně EAP klient) ale CNG nepodporuje ani na Windows 7, takže musíte použít starší CSP.
• v obou šablonách chcete, aby to nebylo exportovatelné, Subject vytvářet automaticky podle obsahu Active Directory. Dávat tam email nemá smysl a ani by to nemuselo někdy fungovat, pokud uživatel email nemá vůbec definován. Ujistěte se, že CSP je vybráno RSA and AES Cryptographic Services Provider. Tím zajistíte, že se to nebude dát vydat do čipové karty, kterou by si uživatel mohl přenášet.
• Application Policies, neboli EKU (Enhanced Key Usage) si nastavte na Client Authentication (1.3.6.1.5.5.7.3.2), ale můžete tam přidat i libovolné další OIDy. Tyto další OID čísla by bylo možné vynutit v politice na RADIUS serveru a omezit tak množství použitelných certifikátů.
• na záložce Security si nastavte pro příslušnou skupinu uživatelů nebo počítačů oprávnění Read, Enroll a Autoenroll.

S klientskými certifikáty je trošku problém, protože klient si musí vybrat certifikát ještě předtím, než se začne ověřovat vůči RADIUS serveru. Musí mu totiž poslat svoji identifikaci, tedy jméno toho certifikátu, podle které se RADIUS může například rozhodnout jestli ho bude vůbec ověřovat, nebo ten požadavek třeba přeposle apod. Znamená to, že jestliže má klient více možných certifikátů (prakticky rozlišuje pouze podle Client Authentication EKU), je nepříjemné, že si možná vybere nějaký nesprávný.

Dále potřebujete certifikát pro RADIUS server. Stačí libovolný SSL serverový certifikát (Server Authentication, OID 1.3.6.1.5.5.7.3.1). Dá se zase vydávat pomocí technologie autoenrollment. V konfiguraci IAS/NPS serveru musíte vybrat nějaký konkrétní certifikát, ale jakmile ten vyexpiruje a je k dispozici novější, IAS/NPS si ho sám nahradí. Blbé na tom je, že nahrazuje libovolným novějším, který má stejný Subject (bez ohledu třeba i na CA). Tzn. opět platí, že jestliže na RADIUS serveru máte více platných certifikátů, můžete mít problémy.

Ideální je dávat pozor a mít jak na klientovi tak serveru vždy jen jeden platný certifikát.

Nastavení IAS/NPS serveru

Prostě vytvoříte příslušné RADIUS politiky. Na nich není nic speciálního. Uvedu jen několik ověřených faktů:

• lze použít PEAP s ověřováním pomocí Smart card or other certificate a to bez ohledu na to, jestli ověřujete počítač, uživatele, nebo oboje (jak někdo vyhrožoval na různých konferencích).
• měli byste vypnout b>Fast Reconnect.. Nevím sice proč přesně, ale dělalo mi to dříve problémy i s ověřováním počítačů, ale když to používáte při ověřování uživatelů, chová se to úplně divně - někdy se to neodpojí, někdy se to nepřipojí apod.
• pokud chcete přidělovat čísla VLAN, udělejte si více různých Network Access Policies a do nich dejte RADIUS atributy:
  • Tunnel Type = VLAN
  • Tunnel Medium Type = 802
  • Tunnel Private Group ID = konkrétní VLAN ID ddd
• pokud chcete limitovat přijatelné klientské certifikáty pomocí jejich OID, můžete použít podmínku Allowed-Certificate-OID. Nicméně tohle bohužel neovlivní klienta, pokud by měl více certifikátů. Bohužel, pokud si vybere z více možných ten, který nemá zrovna příslušný OID, prostě se neověří.

Pokud chcete sledovat nějaké logy na Windows 2008/R2 NPS serveru, zapněte si buď celé auditování kategorie Logon/Logoff a události uvidíte v Security logu, Event Source je Microsoft Windows Security Auditing a Task Cateogry je Network Policy Server. V událostech jsou krásně vidět všechny důvody, proč to nefunguje, jakou politiku to případně použilo a který uživatel se to vlastně ověřil. Můžete si ale zapnout i jen auditovací podkategorii Network Policy Server, což je super novinka na Windows 2008 a Windows 2008 R2. Buď pomocí GPO, nebo rovnou z příkazové řádky:

auditpol /set /subcategory:"network policy server" /success:enable /failure:enable

Nastavení klienta

Klienty nastavujte pomocí Group Policy, můžete samozřejmě ručně, ale přes GPO je to jednodušší a automatičtější. A nastavení (i když se jmenuje Windows Vista Policy) funguje i pro Windows XP SP3.

Takže stačí nový Group Policy Object (GPO), v jeho počítačové části je Windows Settings, Security Settings, Wired Network Policies. Vytvoříte novou Windows Vista Policy a nemusíte se bát, opravdu funguje i pro Windows XP. A do ní zopakujte to stejné, co jste zadali do pravidel v NPS. Takže rekapitulace:

• Authenticate User and Computer, bude se používat buď počítačova identity, dokud nebude nikdo přihlášen.
• PEAP, Smart card or other certificate
• Verify server identity - tady je zajímavé že mi to funguje, pokud to zapnu pouze na té první záložce (PEAP obal), ale nesmím to zapnout na té další, to už potom nefunguje. Netuším.
• vypnout Fast Reconnect
• zapnout Single-sign-on - zrychlíte přihlašování a přepínání uživatelů

A je to :-) Kdybyste s tím měli nějaké problémy, klidně napište :-)