Dneska jsem si uvědomil zajímavou věc. Pokud ve vlastnostech účtu v Active Directory zapnete zaškrtávátko Do not require Kerberos preauthentication - tedy efektivně pro ten účet vypnete Kerberos pre-authentication, tak to potom znamená, že se daný účet nezamkne bez ohledu na počet špatných pokusů o zadání hesla. Nejenom, že se nezamkne, ale ani na řadičích domény (DC, domain controller) neuvidíte události failure audit pro account logon kategorii.
Co znamená Kerberos pre-authentication
Někdy se to vypíná kvůli různým linux-Kerberos integracím apod. Viděl jsem jednou kdysi, že to kdosi měl vypnuto na všech účtech.
Kerberos pre-authentication je ve skutečnosti možno považovat za skutečnou authentication :-) Domain controller (KDC) vydává Kerberos přihlašovací tikety (TGT ticket). Tyto tickety jsou zašifrovány heslem (odvozenina z heše ve skutečnosti) daného účtu, pro který se TGT vydává. Tedy uživatelovým heslem.
Výchozí nastavení AD účtů říká, že se pro vydání TGT vyžaduje preauthentication (v network monitoru se to projevuje stavovým kódem KDC_ERR_PREAUTH_REQUIRED - hodnota 25). To znamená, že KDC nevydá TGT jenom tak anonymně zadarmo komukoliv, ale musíte mu dokázat, že jste ten uživatel, jehož TGT chcete.
Znamená to, že k vydání TGT musí uživatel zaslat svým heslem zašifrované časové razítko (PA-ENC-TIMESTAMP). DC vydá TGT jenom pokud to heslo sedí a časové razítko je v povoleném časovém rozsahu, výchozí je známých +/- 5 minut.
Takže ve výchozím stavu, díky této pre-authentication - což je jak asi sami vidíte vlastně spíš normální authentication, tak to jak to člověk běžně chápe - má DC kontrolu, že vydává TGT jenom uživateli, který ho opravdu má právo dostat.
Pokud preauthentication vypnete, DC/KDC vydá TGT komukoliv anonymně a jeho heslo vůbec neověřuje.
Je to bez preauthentication nějaké bezpečnostní riziko?
Jakési ano. TGT je sice zašifrované uživatelovým heslem (pořád říkám heslo, ale myslím samozřejmě hash hesla, kterou má DC ve své AD databázi). Takže i když by se vydalo komukoliv anonymně, tak pokud ten "útočník" nezná heslo uživatele, je mu to TGT skoro na nic, protože si jeho obsah nepřečte a dále ho použít stejně nemůže.
Ale.
Jak jsem psal na začátku, není jak na DC vidět, nebo počítat pokusy o zkoušení špatného hesla. Ten účet se nikdy nezamkne. Jeho atributy badPasswordCount a badPasswordTime se nikdy nezmění. Anonymně je tedy možno dostat TGT zašifrované uživatelovým heslem, vzít si ho domů a tam ho offline krekovat. Pokud by heslo bylo slabé (typicky méně než 10-12 znaků), půjde to kreknout ve smysluplném čase při smysluplném hardware.
Další možností je dráždit DC velkým počtem takových požadavků a snažit se DOS útok. KDC bude muset při každém takovém (jde to i přes UDP) požadavku najít uživatelovu hash a zjistit jeho skupiny a vygenerovat TGT ticket. Takže ani to není úplně zanedbatelné.
Další problém mě napadl spíše provozní - při změne hesla takového účtu by mohly AD replikační prodlevy (replication latency) způsobovat ověřovací problémy tohoto účtu nebo služby.
Máte nějaké takové účty?
Zjistíte jednoduše. Je to bitová hodnota ADS_UF_DONT_REQUIRE_PREAUTH = 0x400000 = 4194304 v atributu userAccountControl. Takže přítel PowerShell:
dsquery * domainRoot -filter "(userAccountControl:1.2.840.113556.1.4.803:=4194304)"
nebo
Get-AdObject -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=4194304)'