Active Directory 2012 R2 – Authentication policies and silos


Úvodem

Bohužel, jedním z nejčastějších bezpečnostních prohřešků AD administrátorů, se kterým se v praxi setkáváme, je nesprávné používání privilegovaných doménových účtů, zejména pak těch, jenž jsou členy "Domain Admins".

Takovéto privilegia, které členství v „Domain Admins“ poskytuje, by ideálně neměli být přidělena účtům, které se používají denně (myšleno ke každodenním běžným úkonům), nýbrž by se měli přidělit jen hrstce lidí z IT oddělení, a to ještě jako separátní účet pro administraci, který se použije v případě, kdy běžný administrátorský účet nedisponuje těmi extra oprávněními. V horším případě, se může toto členství dočasně propůjčit administrátorovi, potřebuje-li jednorázově zasáhnout do AD konfigurace, jako například instalace CA anebo Exchange, a po provedení úkonu mu tyto práva odebrat. Co bohužel doposud dost dobře nešlo omezit, bylo, aby tento privilegovaný účet byl použit pouze tam, kde to chceme, respektive vynutit, aby nebyl použit na systémech, kde to opravdu nechceme. Například, na uživatelských stanicích, které bývají přece jen snadnější terč útoků.

Zdá se, že si toho Microsoft všimnul, a do nové verze Windows Server 2012 R2 zakomponoval novou funkci „Authentication Policies and Silos“, která umožňuje implementovat určité restrikce použití doménových ať už běžných či servisních účtů na počítačích. Ale pozor, samostatné účty počítačů omezovat nelze, tím pádem ani služby, které běží pod lokální servisní identitou, jako např. SYSTEM či NETWORK SERVICE, a to proto, že se ověřují do sítě jako účet počítače.

Je to trochu podobné, jako když máme u platební karty různé limity pro různé použití. Věřím, že většina z nás má limit na výběr z bankomatu větší, než pro platby na internetu, kde zneužití přece jen stále nemůžeme úplně vyloučit. Tyto limity si pak můžeme představit jako Autentizační sila, která budou popsána dále v článku.

Pozn. Během psaní článku jsem vedl nejedenkrát dilema, které technické pojmy či termíny (ne)překládat. Osobně preferuji v IT angličtinu, ale protože předpokládám, že čtenář nemusí být „pokročilý“ angličtinář, tak jsem snad zvolil poměr překladu tak, aby neurazil ani našince. Smile

Požadavky a doporučení

Domain Functional Level
DFL musí být nastaven na Windows Server 2012 R2, a tudíž všechny DC v doméně musí běžet na Windows Server 2012 R2.

Protected Users, skupina
Neplést s pojmem „Protected Groups“, což jsou privilegované skupiny (např. Administrators, Server Operators, Account Operators…), jenž každou hodinu hlídá SDPROP proces běžící na PDC, a pro jejich členy zajišťuje správně nastavená ACL (Access Control List) podle objektu AdminSDHolder (jakoby šablona oprávnění).

Tato nová globální AD skupina (v USERS kontejneru) přidává další ochranu proti vykrádání hesel účtů (privilegovaných) tím, že zabraňuje např. ukládání hesel do mezipaměti. Tuto skupinu můžete mít, i pokud nemáte nejnovější DFL, podmínkou je, aby Windows Server 2012 R2 byl vlastníkem PDC FSMO role.

Omezení pro členy skupiny „Protected Users“ na systémech Windows 8.1 anebo Windows Server 2012 R2:

  • Default credential delegation (CredSSP) – plaintext přihlašovací údaje nelze nahrát do Cache
  • Windows Digest - plaintext přihlašovací údaje nelze nahrát do Cache
  • NTLM - NTOWF (NT one-way function) není Cached
  • Offline přihlášení - cached logon
  • Ověření přes NTLM protokol (při DFL Windows Server 2012 R2)
  • Použití DES (Data Encryption Standard) anebo RC4 šifrováni při Kerberos pre-authentication (při DFL Windows Server 2012 R2)
  • Delegace - unconstrained, constrained (při DFL Windows Server 2012 R2)
  • Obnovení Kerberos tiketu (TGTs) po 4h životnosti (při DFL Windows Server 2012 R2)

Pozor:

  • do této skupiny se nevkládají servisní účty, protože to způsobuje zamítání požadavků na ověření (authentication requests).
  • Než vložíte do této skupiny nějaký účet, musíte mít všechny DC alespoň na Windows Server 2008 a ujistěte se, že heslo k tomuto účtu bylo nastaveno na DC, o minimálně této verzi. Heslo z předchozích verzí OS nemusí být AES, a jelikož DES anebo RD4 šifrování není podporováno, účet nebude povolen pro přihlášení.
  • Členové „Protected groups“ jsou brány úplně stejně jako jakýkoli jiný člen, proto není doporučeno dát do této skupiny úplně všechny privilegované účty, pokud si to velmi dobře neotestujete. Osobně bych v jakémkoli případě vyjmul alespoň jeden účet (např. bulit-in Administrator).
  • Kerberos bude vynucen i pří RDP, takže např. přihlášení přes IP adresu se Vám nezdaří.

„Authentication policies“ jsou závislá na ověření Kerberos. Proto by se privilegované účty měli vložit i do AD skupiny „Protected Users“, která při ověření vynucuje Kerberos AES šifrování (a zabraňuje přihlášení přes NTLM). Jinými slovy, toto je spíše doporučení a doplněk pro samotné Autentizační politiky, ne podmínka.

Povolit podporu na doménových řadičích

Dále je potřeba připravit doménu a doménové řadiče na tuto další úroveň bezpečnosti.

Default Domain Controllers Policy (anebo máte-li ekvivalent)

 

  • KDC support for claims, compound authentication, and Kerberos armoring
    (Computer Configuration > Policies > Administrative Templates > System > KDC )
    Nastavit na Always provide claims

Obrázek 1 – Povolení claimů a Kerberos armoring přes GPO

k1

Následující tabulka popisuje rozdíly mezi jednotlivými možnostmi.

Always provide claims

generovat claimy v každém případě umožní uživatelům přístup na claim-based služby ze systému, který claimy nepodporuje

Supported

generovat claimy jen pokud systém claimy podporuje

Fail unarmored authentication requests

systémy, které nepodporují Kerberos Armoring se již nebudou moci ověřit (Windows 7 a nižší)

Povolit podporu na členech domény

Dále je potřeba připravit (všechny anebo vybrané) členy (Windows 8 and Windows Server 2012 a novější) domény na tuto další úroveň bezpečnosti.

Default Domain Policy

  • Kerberos client support for claims, compound authentication, and Kerberos armoring.
    (Computer Configuration > Policies > Administrative Templates > System > Kerberos)
    Nastavit na Enabled

Obrázek 2 – Povolení podpory claimů a Kerberos armoring na členech domény

k2

Logování

Není podmínkou, ale spíše mým doporučením. Při implementaci se dá narazit na spousty problému, a mít se kam podívat při troubleshootingu může být k nezaplacení J .

Nově existující „operační administrativní logy“ (operational administrative logs) v „Prohlížeči událostí“ (Event Viewer) jsou ve výchozím stavu vypnuty (Disabled). Doporučuji Zapnout jak na doménových řadičích, tak členech domény.

Nacházejí se pod:

  • Applications and Services Logs\Microsoft\Windows\Microsoft\Authentication.

Obrázek 3 – Povolení Authentication logů. Ukázka pro „Protected Users“

k3

Obrázek 4 – Ukázka logování pro členy skupiny „Protected User“, pokud se hlásí přes NTLM

k4

Obrázek 5 - Ukázka logování pro členy skupiny „Protected User“

k5

Postup pro nastavení politik ověření

Tvorba Authentication Policy a Silo

Prvně je potřeba vytvořit autentizační politiku, a ta se pak bude linkovat na ověřovací silo. Tato politika definuje podmínky přihlášení a životnost TGT (Kerberos Ticket Granting Ticket), výchozí hodnota je 4h, po této hodnotě se musí uživatel znovu ověřit. Lze nastavit přes ADAC anebo Powershell.

New-ADAuthenticationPolicy -Name TGT_Admin_3h -Description 'TGT for admins, 3h' -UserTGTLifetimeMins 180 -Enforce -ProtectedFromAccidentalDeletion $true

Audit a Enforce mód

  • Pokud je autentizační politika v AUDIT módu, tak v případě, že DC obdrží AS_REQ (authentication service request) požadavek, DC provede kontrolu, zda je ověření povoleno pro daný systém, a provede pouze zápis do LOGu v případě chyby, avšak proces ověření nezpůsobí, že by se ověření nezdařilo.
  • Dá se nastavit pro Politiku i Silo později, např. přes Set-ADAuthenticationPolicy a Set-ADAuthenticationPolicySilo a parametr –Enforce $true

Obrázek 6 – Tvorba autentizační politiky (ADAC)

k6

Ověřovací silo v podstatě zastřešuje účty (Users, Computers, Services), na které se budou vázat autentizační politiky, a limituje, kde tyto účty mohou být použity. Pokud jsou navíc účty v "Procted Users" skupině, další kontrolní mechanismy jsou zahrnuty, například vynucení Kerberosu.

Takže můžeme limitovat použití privilegovaných účtů na privilegované servery. Například můžeme tedy vytvořit Forest-Admin Silo, které bude obsahovat Enterprise, Schema, a Domain Admins. Toto Silo pak může být nakonfigurováno tak, že ověření s heslem anebo smart-kartou budou zamítnuta ze systému jiných, než doménových řadičů.

Před-vytvořená Autentizační politika je podmínkou pro tvorbu Autentizačního sila.

New-ADAuthenticationPolicySilo -Name Restrict_Logon_for_Admin -Description 'This Silo restrict Admin accounts to log only to DCs' -UserAuthenticationPolicy TGT_Admin_3h -ComputerAuthenticationPolicy TGT_Admin_3h -ServiceAuthenticationPolicy TGT_Admin_3h -Enforce -ProtectedFromAccidentalDeletion $true

Obrázek 7 – Tvorba Authentication policy a Silo (PowerShell)

k7

Tímto se omezí systémy, které mohou požádat o TGT pro účty přiřazeny do naší politiky. Uživatelské účty nebudeme linkovat do „autentizační politiky“ (authentication policy) napřímo, nýbrž nepřímo přes Silo. Je tedy nutné navázat na Silo na Autentizační politiku a naše „Restricted“ účty.

Obrázek 8 – Propojení politiky se Silem (ADAC)

k8

Kontrola konfigurace autentizační politiky se přes PowerShell dá zkontrolovat takto (UserAllowedToAuthenticateFrom, UserTGTLifetimeMins):

Get-ADAuthenticationPolicy -identity TGT_Admin_3h

Obrázek 9 – Kontrola nastavení autentizační politiky (PowerShell)

k9

Když víme, jak vypadá atribut „UserAllowedToAuthenticateFrom“, který má trošku speciální syntaxi s SDDL, můžeme do budoucna pak pro přiřazování použít i PowerShell, celkově pak vypadá příkaz následovně:

Set-ADAuthenticationPolicy -Identity TGT_Admin_3h -UserAllowedToAuthenticateFrom 'O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == "Restrict_Logon_for_Admin"))'

Dále je potřeba do našeho Autentizačního Sila přidat účty správců a počítačů, které chceme svázat.

Obrázek 10 – Svázaní účtů s autentizačním silem (ADAC)

k10

Pokud jsme líní, můžeme to nastavit i přes PowerShell, následující příkaz to provede pro všechny řadiče domény:

Get-ADDomainController -Filter {IsReadOnly -eq $False} | ForEach-Object {Grant-ADAuthenticationPolicySiloAccess -Identity Restrict_Logon_for_Admin -Account $_.ComputerObjectDN}

A následující příkaz pro všechny členy „Domain Admins“:

Get-ADGroupMember „Domain Admins“ | ForEach-Object {Grant-ADAuthenticationPolicySiloAccess -Identity Restrict_Logon_for_Admin -Account $_.distinguishedName}

Příkaz v PowerShellu na kontrolu přiřazení vypadá pak následovně:

(Get-ADAuthenticationPolicySilo -Identity Restrict_Logon_for_Admin).Members | Get-ADObject -Properties msDS-AuthNPolicySiloMembersBL

Nyní máme pro účty nastaveno pouzeoprávnění k používání našich vytvořených politik a Sil, ovšem je potřeba je jim teď i explicitně povolit (viz sloupeček „Assigned“ v předchozím obrázku)

Obrázek 11 – Povolení politiky na účtu správce k restrikci (ADAC)

k11

Obrázek 12 – Povolení politiky na účtu DC (ADAC)

k12

To, že jsou tyto politiky již správně přiřazeny a povoleny pro naše účty v Silu, se nám pak ukáže zelenými fajfkami ve sloupečku „Assigned“.

Důležitá poznámka, na otázku, která vám možná vyvstala při pohledu na přiřazení sila v ADAC, ANO, účet může patřit pouze do jednoho autentizačního sila!

Obrázek 13 – Kontrola svázaní účtů s autentizačním silem (ADAC)

k13

Pokud jsme stále líní, můžeme pro nastavení opět použít PowerShell, následující příkaz to provede pro všechny řadiče domény:

Get-ADDomainController | ForEach-Object {Set-ADAccountAuthenticationPolicySilo –identity $_.ComputerObjectDN –AuthenticationPolicySilo Restricted_Logon_for_Admin}

A následující příkaz pro všechny členy „Domain Admins“:

Get-ADGroupMember -Identity 'Domain Admins' | ForEach-Object {Set-ADAccountAuthenticationPolicySilo –identity $_.DistinguishedName –AuthenticationPolicySilo Restricted_Logon_for_Admin }

Příkaz v PowerShellu na kontrolu svázání účtů vypadá pak následovně:

(Get-ADAuthenticationPolicySilo -Identity Restricted_Logon_for_Admin).Members | Get-ADObject -Properties msDS-AuthNPolicySiloMembersBL,msDS-AssignedAuthNPolicySilo

Obrázek 14 – Kontrola svázaní účtů s autentizačním silem (PowerShell)

k14

Nyní, když máme vše připraveno, můžeme se pustit do otestování našeho autentizačního sila. Pro úplnost si ukážeme, že testovací účet správce je členem „Domain Admins“. S tímto účtem se pak budeme hlásit na členský server (INFRA-VM02), který je členem domény „INFRA.LOCAL“.

Obrázek 15 – Skupinové členství testovaného účtu správce

k15

Obrázek 16 – Přihlášení testovaným účtem na členský server, který je mimo „silo“

k16

Obrázek 17 – Odmítnuté přihlášení testovaným účtem na členský server, který je mimo „silo“

k17

Pokud jsme postupovali správně, tak se k tomuto členskému serveru naším testovacím doménovým adminem nepřihlásíme, ovšem pokud se pokusíme přihlásit na doménový řadič, k přihlášení dojde bez potíží.

Závěr

Pro správce AD přináší Microsoft svými „Authentication policies“ další nástroj na zvýšení zabezpečení privilegovaných účtů, a výrazně tím umožňuje redukovat riziko útoků typu PtH (Pass the Hash). Použití pro restrikce „Domain Admin“ účtů je pouze jednou z možností, jak se dají tyto politiky aplikovat, tedy za předpokladu, že podnikoví správci používají takový delegační model, který odděluje účty pro běžné AD úlohy od těch zásadních. Tam kde tyto role odděleny nejsou, bych takovýto bezpečnostní model doporučil zvážit.

Při nasazení bych důrazně doporučil nechat minimálně jeden účet mimo tyto politiky, abyste se vyhnuli tomu, že si odříznete přístupy pro všechny správcovské účty od přístupu k DC a konfiguraci AD, špatným nastavením. Osobně bych volil třeba výchozí účet administrátor, který používám pouze pro případy obnovy (Disaster Recovery), a jenž má dost silné a nelidské heslo, aby si jej správce nemohl zapamatovat.Smile

Dalším scénářem použití může být například ochrana doménových účtů, které se používají jako servisní a měli by mít přístup jen na některé servery síti. Respektive pokud máme servisní účet se silným oprávněním, zabráníme jiným serverům jakkoli obdržet toto heslo.

Je mi jasné, že struktura IT týmů bývá rozdílná, co společnost, ale ještě jsem se nesetkal s takovou, aby zmíněná doporučení rozdělení administrátorských úrovní nešla, v nějaké modifikaci na míru, praktikovat. Zprvu bývá při očistě argumentem, že tyto a tamty oprávnění ten daný správce potřebuje, a dokonce denně, ale nakonec jsme vždy při dialogu došli k závěru, že tomu vlastně tak úplně není a delegace AD oprávnění na potřebné AD objekty byla dostačující. Stejně jednoduché je to pro účty, které slouží k přístupům na členské servery, to se dá jednoduše vyřešit GPO takovou, která poskytne ADMIN přístup namísto „Domain Admins“ nové skupině, kterou pro tento účel vytvoříme (např. Member_Server_admins).

Appendix, aneb pár MS článků k tématu:

- Jiří Pavlík KPCS CZ

Comments (2)

  1. Borek says:

    "Co bohužel doposud dost dobře nešlo omezit, bylo, aby tento privilegovaný účet byl použit pouze tam, kde to chceme, respektive vynutit, aby nebyl použit na systémech, kde to opravdu nechceme. Například, na uživatelských stanicích, které bývají přece jen
    snadnější terč útoků."

    Máme nastaveno už roky pomocí GPO a Deny log on locally.

  2. Jiri Pavlik (KPCS) says:

    Borku, máte pravdu, je to jedna z možností, jak dosáhnout podobného efektu. A každý kdo implementoval alespoň tuto možnost si zaslouží pochvalu. 🙂

    Ale není to rozhodně to samé. Nejzásadnější rozdíl je v tom, že SILO se vyhodnocuje na úrovní řadiče, nýbrž GPO u člena domény. Z toho také vyplývá návaznost na OU strukturu, kde může být tato implementace skrze GPO docela výzva v rozsáhle OU struktuře, kde
    navíc k tomu může mít na určité OU v hierarchii práva i jiný IT tým, a tedy problém zajistit konzistenci. Toto nastavení, se navíc neslučuje s stejným nastavením v jiné GPO, takže téměř vždy vyhraje GPO linkováno nejblíže k objektu počítače, kde už může být
    v této politice definováno nastavení jiné, např. omezovat k přihlášení servisní účty.
    Aby toho nebylo málo, tak "Deny log on locally" nezakazuje přihlášení do Vzdálené plochy, a ani tomu, aby takový účet nebyl použit pod nějakou službou… Ano, i toto se dá ošetřit skrze další GPO nastavení, ale je to opět úroveň komplikací navíc. Ne každý podnik
    si může dovolit upravit OU strukturu podle potřeb AD týmu. Toto se dá také obejít skrze "Security filtering", ale opět, další úroveň komplexity.
    Použití pro omezení "Domain Admins" zde bylo jako jeden příklad aplikace. Osobně vidím větší využití v omezování, kam budou přistupovat Servisní účty, které mají poněkud vyšší práva, ale je potřeba je ověřit jen na omezeném počtu serverů, například Agenti pro
    zálohy, běžící na Exchange serveru. Anebo pokud delegujeme privilegovaný účet pro nějakého externistu, kterému běží aplikace pouze tam anebo tam.

Skip to main content