Ondrej Sevecek's Blog

Ověřování uživatelů ve Windows je moje dlouholetý téma a přitom jsem zjistil, že tu k němu nemám moc článků. Tak pojďme na to :-)

A rovnou se mi to hodilo. Protože Martin Pavlis se nedávno vytahoval, že napsal nejdelší článek svého života, tak jsem ho chtěl trumfnout. Až to celé přečtete, dozvíte se, jestli se mi to povedlo.

Delegování

Delegování uživatelské identity (identity delegation) je základní potřeba různých služeb ve složitějším prostředí. Jedná se o různé technologie, v našem případě se budeme zabývat Basic ověřováním a různými formami Kerberos delegation. Základní představa je na následujícím obrázku:

Tedy uživatel z klientského počítače přistupuje na nějakou Front-End službu a používá k tomu svůj uživatelský účet, aby se ověřil. Tato Front-End služba jeho identitu potřebuje vzít a přeposlat dále dozadu, aby se za něho dostala do nějaké další Back-End služby. Tohle je rozdíl od druhého běžného scénáře, kdy Front-End služba používá jen nějakou jedinou servisní identitu - viz. obrázek:

Některé Front-End služby to dělají tak a některé jinak. Důvody k tomu mohou mít různé. Buď se programátoři prostě jen tak rozmysleli, protože jim to připadlo lepší, nebo to může být třeba kvůli Back-End službě, kterou nemají pod svou kontrolou apod. Příklady jsou například

Prostě jde jednoduše o to, jestli zadní služba (obvykle databáze, jak jste viděli), rozlišuje sama uživatele, nebo ne. Pokud je rozlišuje, proč bychom to komplikovali a vytvářeli nějaký další účet se super přístupem?

Basic authentication, bezpečnost a delegace

Pokud má přední služba (front-end) zapnuto ověřování Basic, tak je to jednoduché. Basic authentication umí zapnout vlastně všichni, kromě EFS. Terminal Services (RDP) ho naopak neumí vypnout. Přístup na RDP server vyžaduje, abyste mu zaslali svoje přihlašovací údaje v plné formě. RDP je tedy vždy Basic autentizace v principu (při použití čipové karty tam posíláte PIN, takže zase podobně).

Delegace pak funguje hladce, bez dalších komplikací. Front-End prostě zná vaše přihlašovací údaje v plné formě, takže je může použít vůči zadním serverům úplně podle své libovůle. Nemůžete mu to omezit jinak, než že byste ho blokovali nějakým firewallem, aby nemohl chodit jinam, než mu určíte. Na obrázku by to mělo být vidět (vepředu Basic, vzadu Kerberos):

Pro znalce Kerberosu je to na následujícím obrázku zobrazeno i s TGT (Ticket Granting Ticket, přihlašovací tiket) a TGS (Ticket Granting Service, servisní tiket). Prostě a jednoduše, na základě plného loginu a hesla (to co front-end dostane z Basic ověření) se vygeneruje TGT. Na základě TGT si front-end následně může vydávat libovolný počet dalších TGS servisních tiketů pro libovolné back-end služby:

A v tom je také riziko a zásadní nevýhoda Basic ověřování. Služba, ale hlavně lidé, kteří ji spravují, její programátoři a správci, dostávají do rukou plné přihlašovací údaje uživatelů, kteří na službu přistupují. Pokud jsou všichni členy Domain Admins, tak se zřejmě nic moc neděje. Ale v prostředích, kde je potřeba citlivě rozdělit přístupová a správcovská oprávnění, to problém je.

Vemte si například, že jste pouhými programátory nějaké webové aplikace. Dobrá, máte zřejmě slušný přístup na celou svoji databázi. Ok. Ale to je všechno. Nikam jinam byste se nedostali, pokud by vám tedy uživatelé neposílali svoje plné přihlašovací údaje přes Basic ověření. Tyto údaje chodí přímo do vaší aplikace, tak proč byste si je nevzali a nezačali s nimi podnikat nějaké zlobírny.

Takže Basic je zlo, které obecně nechceme. Nevadí mi, že to chodí v plné formě po síti. To se dá zašifrovat TLS/SSL. Vadí mi, že slabí uživatelé dostávají přihlašovací údaje velké skupiny lidí. Na druhé straně je to nejjednodušší a výborné na testování.

Chceme něco jiného, například Kerberos nebo TLS/SSL certifikáty, v nejhorším případě i NTLM

Chceme tedy, aby se uživatelé ověřovali vůči front-end aplikaci pomocí něčeho bezpečnějšího. Tedy například Kerberos, klientských certifikátů (TLS/SSL Client Authentication certificate), nebo třeba i NTLM, pokud už to musí být. Tady se nedá říct, že by to byl jen Kerberos, ten potřebuje přímou konektivitu s DC (Domain Controller) a tu bohužel nemáte z internetu. Certifikáty jsou nejbezpečnější možné, takže super, ale zase je musíte složitě spravovat a lidé možná musí mít čipové karty. Pokud to navíc třeba aplikace ani neumí (jako Outlook 2007 ani Outlook 2010), musíte se spokojit s NTLM.

Dobrá, takže na front-end se takto ověříte. Výhoda je, že tento server nedostává vůbec vaše přihlašovací údaje ve formě, ve které by je mohl použít dále. Takže proti jeho programátorům a lokálním adminům jsme v bezpečí. No hurá. Blbé je, že když je nemůže dostat admin, tak je nemůže použít ani sám front-end server. Jak by je tedy mohl sám použít vůči nějakému zadnímu back-endu?

Tři formy delegace

Na straně klient vs. front-end se tedy může použít Kerberos, pokud jste uvnitř své sítě s nějakým Domain Controllerem. Podle obrázku by to potom vypadalo takto - klient pošle na front-end jenom TGS. TGS neobsahuje uživatelovy přihlašovací údaje, takže front-end vlastně nemá nic v ruce, kromě TGS určeného právě pro něho samotného. Tím pádem se front-end nikam dozadu nedostane. No a my bychom mu to rádi nějak povolili. K tomu slouží první dvě formy delegace - unconstrained delegation a constrained delegation. Obrázek je v obou případech stejný:

Na obrázku vidíte, že klient i front-end musí hovořit se svým DC. Každý se svým, tedy ne nutně s tím stejným. Front-end dostane (tady trošku zjednoduším vysvětlení, abych to už víc nekomplikoval) TGS pro front-end od klienta. Na základě tohoto tiketu si vydá "pokračovací" tiket pro zadní službu, tedy TGS pro back-end.

Uvědomte si, že to je dost bezpečnostně citlivá operace, kterou by měl správce domény povolit. Takže ano, na účtu front-endu se toto musí povolit. A to jsou právě ty možnosti delegace.

První delegace fungovala už při Domain Functional Level Windows 2000 Native. Jmenuje se to dneska unconstrained Kerberos delegation (tedy něco jako neomezená delegace). Zapne se to pro účet front-end služby (samozřejmě ne nutně účet počítače, to může být klidně servisní účet) v Active Directory na záložce Delegation. Na obrázku se díváte na účet počítače s Threat Management Gateway (TMG1) firewallem.

Povšiměte si, že to prostě jenom zapnete. Takže není žádná možnost, jak omezit seznam zadních back-end služeb, na které se to dá udělat, proto se tu taky píše Trust this computer for delegation to any service. Takže vlastně jsme zase zpátky jako u Basic ověřování. Front-end se dostane kamkoliv dozadu bude chtít. No, úplně zpátky nejsme, protože:

1. front-end nezná přímo uživatelovo heslo a nemůže ho tedy zneužít jinými způsoby
2. uživatel nemusí zadávat heslo ručně při každém přístupu - rovnou ho ověří jeho klient pomocí SSO (single-sign-on)

Takže Windows 2003 přišli s vylepšením. Pokud si přepnete doménu alespoň do režimu Domain Functional Level Windows 2003, dostanete tuto další možnost, ve které už lze omezit seznam zadních služeb. Nazývá se to Kerberos constrained delegation (omezená delegace):

Na obrázku vidíte, že front-end si může požádat o TGS tikety pouze pro HTTP službu běžící na počítači DCEX1. To je v mém případě Exchange CAS (Client Access Server), takže webové služby jako je OWA, ActiveSync, nebo OutlookAnywhere. A máme to krásně omezeno, nápis Trust this computer for delegation to specified services only tomu odpovídá. Takže také ideálně bezpečné (noooo, ještě bych věděl jak to vylepšit - viz. dále).

Problém tu je pořád v tom, že z klienta musí přijít TGS tiket. To tedy znamená, že klientovi musí fungovat Kerberos ověření. A to mu bude fungovat jenom uvnitř sítě. Když bude ten chlápek v internetu, máme smůlu.

Proto je tu ještě třetí možnost, Trust this computer for delegation to specified services only (any authentication protocol):

Vypadá to stejně, krom nápisu any authentication protocol. A to je taky po pravdě řečeno úplně jakýkoliv, třeba právě NTLM, nebo SSL Client Authentication certifikát. Na obrázcích to vidíte znázorněné piktograficky:

Z obrázku by mělo být zřejmé, že front-end nepotřebuje dostat od klienta TGS sám pro sebe. Stačí mu, když se mu klient ověří pomocí NTLM, nebo třeba právě toho certifikátu. Výhoda (a nevýhoda) je, že by se mohl ověřit klidně třeba otiskem prstu, nebo několika kontrolními otázkami a fungovalo by to taky.

Princip je prostě ten, že Active Directory (tedy její správce) věří službě tak moc, že jí prostě vydá TGS pro back-end úplně zadarmo. Stačí když si ta služba pěkné požádá. Ale pořád to jde jenom pro ten vyjmenovaný seznam zadních služeb, takže zas až tak moc strašlivé to není. Protože se přechází z jednoho autentizačního protokolu na druhý, tato metoda se nazývá Kerberos constrained delgation with protocol transition, nebo obvykle jen Protocol Transition.

Nebezpečí Protocol Transition

Uvědomte si, že protocol transition nevyžaduje vlastně ani žádné ověření na straně klienta. Správce domény prostě věří natolik front-end službě. Front-end služba by tedy mohla klienty ověřit čímkoliv ji napadne, čímkoliv, co ani není uložené v Active Directory. To jsou právě ty případy různých otisků prstů, otázek, různých jiných biometrických metod, věštění z koule, šudlení po obrázku (Windows 8) atd. Super, ale s citem :-)

Mám na to dokonce zkušební prográmek příhodně nazvaný Kerberos Hell (přímo .EXE verze dostupná zde) (používá to .NET Framework funkci WindowsIdentity s jediným parametrem, kterým je právě login). Když si ho spustíte pod účtem, který má tako povolenou delegaci, a má na lokále SeTCBPrivilege, tedy právo (user right) Act as part of operating system, stačí zadat login nějakého uživatele. Po kliknutí na čudlík můžete vyzkoušet přístup dozadu na nějakou ze tří služeb - sdílené soubory (SPN cifs), HTTP (SPN http), nebo SQL Server (SPN mssqlsvc).

Shrňme tedy tyto tři metody Kerberos Delegation

do přehlednější tabulečky:

Poznámky k požadavkům na Constrained delegation a Protocol Transition

Na to, aby služba mohla provozovat ty dvě metody označené Trust this computer for delegation to specified services only, musíte mít:

1. domain function level (DFL) alespoň na hodnotě Windows 2003. Tedy všechna DC musí být alespoň Windows Server 2003.
2. účet front-end služby (tedy té, která má právě tu delegaci povolenu) musí mít schopnost číst atributy tokenGroups a tokenGroupsGlobalAndUniversal na všech účtech klientů, pro které má tu delegaci provádět. Toho se dá dosáhnout buď tak, že prostě front-end účet dáte do skupiny Windows Authorization and Access Group, nebo jí to povolíte individuálně. Pomocí oprávnění (permissions) na všech účtech klientů. A to je samozřejmě také to nejbezpečnější, viz. dále.
3. pokud chcete protocol transition, účet front-end služby musí mít na svém serveru, kde služba běží, přiděleno uživatelské právo (user right) zvané Act as part of operating system (tedy SeTCBPrivilege).

Omezení delegace pro citlivé účty správců a další skupiny

Delegace samozřejmě není nikdy úplně bezpečná. Co když se správci front-end služby, tedy nějakému webovému programátorovi, podaří přesvědčit nějakého silného admina (něco jako Domain Admins apod.), aby se mu připojil na jeho front-end službu. Řekněme pod záminkou testování. Nebo mu prostě pošle mail s linkem, nebo obrázkem ze své webové služby. Seznam zadních služeb může být sice omezen, ale stejně tam front-end leze pod účtem toho správce. A to nemusí být úplně košér.

Jak to u těchto citlivých účtů ochráníte? Samozřejmě počítejte s tím, že tyhle účty potom nemohou danou službu ani testovat, ale k tomu ani nejsou určeny. Ve vlastnostech uživatelských účtů je zaškrtávátko Account is sensitive and cannot be delegated:

No to je trošku absolutní. Takže poslední možnost by byla to řídit citlivě v kombinacích skupiny adminů vs. skupiny front-end služeb pomocí povolení/zakázání čtení na atributech tokenGroups a tokenGroupsGlobalAndUniversal a nervat ten front-end rovnou do skupiny Windows Authorization and Access Group.

Když už jsme u toho, které skupiny mohou číst ty dva atributy tokenGroups a tokenGroupsGlobalAndUniversal, tak by se slušelo doříct, že to taky umí skupiny Pre-Windows 2000 Compatible Access a RAS and IAS Servers. No dobrá, ale to jsou zbytečně silné skupiny. Speciálně skupina Pre-Windows 2000 Compatible Access je pekelná skupina, která umí číst skoro cokoliv, takže tahle by měla být normálně úplně prázdná.

Howgh.

A ne, howgh ještě ne. Dáme si ještě příklad

Příkladem může být samozřejmě právě třeba to NTLM ověřování pro OutlookAnywhere. Jenže tam je takové zřejmé, že probíhá ověření pomocí NTLM, takže z toho můžete mít pocit, že se jedná o jaké lepší "ověření". Tak si představte jak probíhá ověření pomocí SSL Client Authentication certifikátů do OWA (Outlook Web App) například přes Forefront Unified Access Gateway.

Obrázek je pořád velice podobný, jen tentokrát poněkud konkrétnější:

Mrkněte na to. Klient má svůj certifikát splňující následující požadavky:

• Subject - cokoliv, není podstatné. Můj uživatel se jmenuje Kamil, takže by tam mohlo být například Kamilek, nebo třeba "můj brácha", nebo cokoliv. Prostě tohle pole nikdo nekontroluje.
• Subject Alternative Name (SAN) - v tomhle políčku musí být naopak login uživatele. Tedy přesněji přímo obsah jeho userPrincipalName atributu. Bude to tam ve formě UPN=kamil@sevecek.com. Takže pozor, to není emailová adresa, ta by byla ve fromě E=kamil@sevecek.com.
• Enhanced Key Usage (EKU), Application Policies (AP) - SSL Client Authentication (OID 1.3.6.1.5.5.7.3.2), tedy prostě klientský certifikát.
• Key Usage - Digital Signature. Tohle stačí, jenom podepisujeme abychom prokázali identitu. Žádné šifrování nepotřebujeme (Key Encipherment), jak by tomu bylo při interaktivním přihlašování čipovou kartou do Windows.
• Issuer - vydavatelem musí být důvěryhodná certifikační autorita. Jak Unified Access Gateway, tak i Threat Management Gateway mají možnost přesně určit, kterou CA přijímáte, takže to je úplně bezpečně. Pokud by vám nějaká veřejná autorita byla ochotna vydat UPN do SAN, tak byste ji klidně mohli použít.
• CRL Distribution Point (CDP), Authority Information Access (AIA) - pokud jsou tahle pole přítomna a obsahují cestu na CRL, nebo na OCSP, potom budou UAG i TMG ověřovat revokaci (zneplatnění) certifikátu a musí se tedy na tyto cesty dostat.

Tak. Z toho předchozího si uvědomte, že prostě stačí, aby klient měl certifikát se svým loginem (user principal name) od důvěryhodné autority. Ten certifikát nemusí (a typicky ani nebude) být umístěn v Active Directory. Nebude nijak fyzicky svázán s uživatelovým účtem. Krom toho, že obsahuje jeho login.

Klient ho prostě "ukáže" UAGu a firewall si ten certifikát ověří vůči certifikační autoritě (CA). Vůbec přitom nehovoří s Active Directory. Tedy samozřejmě, pokud by jeho CRL bylo v AD uloženo, tak by s ní hovořil, ale to nemusí být vždycky ten případ. Takže prostě se UAG mrkne do certifikátu a ověří jeho platnost.

A pak už si jenom z něho vyndá uživatelův login. A podobně, jako v případě mého prográmku na Kerberos Hell si řekne DCčku, aby mu vydalo Kamilův TGS pro zadní Exchange CAS OWA server (SPN pro službu http). A pokud má povolenu tu nejsilnější možnost Trust this computer for delegation to specified services only (Any authentication protocol), tedy protocol transition, tak ho dostane a juchů, valí dozadu do OWA.

A ještě pár poznámek na závěr

Pokud zapnete někomu constrained delegation nebo protocol transition, tak ten počítač musíte restartovat. To v případě unconstrained delegation nemusíte - tam stačí klienta buď odhlásit, nebo pomocí KLIST PURGE (případně KERBTRAY) zlikvidovat všechny tikety z keše.

Druhá poznámka je k tomu, jak to funguje s tikety v případě těch tří delegací. Ono se to totiž technicky trošku liší mezi unconstrained delegation a těmi lepšími constrained delegation a protocol transition.

V případě unconstrained delegation si už klient sám vyrobí kopii svého TGT (ano, skutečně kopii svého přihlašovacího tiketu). Pozná se to podle příznaku (flag) Forwarded. Můžete se podívat pomocí KLIST, nebo KERBTRAY, že klient má Forwarded TGT pro každou službu rovnou v okamžiku, kdy si pro ni generuje TGS. Takže pro všechny služby, které mají povolenu delegaci, má klient dva tikety - TGS a Forwarded TGT. A prostě té službě pošle rovnou to Forwarded TGT. Tím pádem služba si sama prostě může říct o libovolný klientův tiket pro cokoliv vzadu.

V případě constrained delegation nebo protocol transition se takový Forwarded TGT negeneruje. Na klientovi se to teda vůbec nepozná. Tam si front-end služba řekne sama pomocí svého vlastního TGT o pokračovací (delegovaný) TGS tiket. Takže proto to taky chce restartovat front-end zatímco v případě unconstrained delegation to chtělo akorát vyhodit keš na klientovi.

A samozřejmě, zadní komunikace na back-end je vždycky Kerberos. Takže nikoliv NTLM. To je dobré si uvědomit. Kerberos nejede s IP adresami (ve stylu http://10.10.0.15) a může mít problémy s různými formami load balancing (NLB, network load balancing), nebo failover clustering. A samozřejmě vyžaduje, aby back-end služba prostě vůbec Kerberos podporovala a bylo to všechno dobře nastaveno. Jako jednoduchý příklad se dá uvést SQL Server běžící pod servisním účtem. Tomu musíte povolit zápis SPN, speciálně pokud používá dynamické TCP porty. Taky jsem párkrát zažil poškozenou konfiguraci IIS na Exchange Server 2007 a Exchange Server 2010, kdy byl vypnutý balíček Negotiate a zbylo tam jenom NTLM. Takže obecně žádná sranda to není.

Když to všechno chcete nasadit - začněte s Basic ověřením na straně klienta, zkontrolujte, že vám to funguje vzadu pomocí Kerberos. Tohle je to nejjednodušší, co můžete udělat.

A úúúúúž finální howgh.

A vítězem se stává...

Nepovedlo. Martin je lepší. Už nemám sílu pokračovat :-)

Ale rozhod sem se, že to ještě přeložím do angličtiny. Takže třeba, že by se to pak sečetlo?