Pozn.: Původně jsem chtěl dát dohromady stručný článek, který popíše, jak přestat používat RC4 šifru v Kerberos protokolu. Jaké provést kontroly a změny, aby po zablokování nenastaly problémy. Ale ukázalo se to mnohem komplikovanější. Pro pochopení řady situací je potřeba znát větší a větší detaily. Obzvláště pro řešení různých problémů. Bylo velmi náročné některé takové detaily zjistit. Článek je nyní dost rozsáhlý (rozdělil jsem jej na dvě části). Snažím se uvádět přesné údaje, přesto je řada věcí zjednodušená a zaměřuje se na princip.

Typy šifrování a šifra RC4 v Kerberos protokolu

Pro šifrování Kerberos ticketů se defaultně (pokud není nastaveno jinak) používá slabá šifra RC4, ačkoliv již od Windows Server 2008 a Windows 7 je podporováno AES (AES128 a AES256). Před Windows 7 (kde začal být defaultně blokovaný) byl podporován ještě DES. V praxi se RC4 používá v menším procentu případů, přesto je dobré tuto věc řešit a cílově RC4 zablokovat.

K určité změně došlo po instalaci aktualizace z listopadu 2022 (nebo novější, dále budeme označovat jako update 11/2022) na doménový řadič (Domain Controller - DC). Od té doby se pro Session Key používá jako výchozí AES256, ale pro Service Ticket to stále může být RC4 (více informací dále v článku).

Slabá šifra RC4

RC4 je již delší dobu považována za slabou šifru. Při použití s Kerberosem existuje známý útok Kerberoasting, kdy je prolomení asi 800x rychlejší než při použití AES. Když se použije RC4 pro Session Key, tak je možno zneužít zranitelnost CVE-2022-37966 - Windows Kerberos RC4-HMAC Elevation of Privilege Vulnerability.

Pozn.: Vždy je pro bezpečnost důležité mít dostatečně dlouhé (a složité) heslo.

Typy šifrování (Encryption Types)

Typ šifrování (Encryption Type, zkráceně etype) je specifická kombinace šifrovacího algoritmu (šifry) s algoritmem integrity (hashovací funkce) pro zajištění důvěrnosti a integrity dat. Stručné základní info je v článku Obecný úvod do šifrování dat.

Microsoft globálně podporuje typy šifrování:

• DES-CBC-CRC - etype 0x1 (1)
• DES-CBC-MD5 - etype 0x3 (3)
• RC4-HMAC - etype 0x17 (23)
• AES128-CTS-HMAC-SHA1-96 - etype 0x11 (17)
• AES256-CTS-HMAC-SHA1-96 - etype 0x12 (18)

Update 11/2022 přidává speciální variantu, která vynucuje AES Session Keys, když se používají staré šifry (RC4)

• AES256-CTS-HMAC-SHA1-96-SK

Seznamy šifer nalezneme u Microsoftu třeba v Network security: Configure encryption types allowed for Kerberos a nověji Supported Encryption Types Bit Flags.

Princip Kerberos protokolu a šifrování klíčů a ticketů

Pro pochopení dalších věcí je potřeba znát základy (a někde i detaily) fungování Kerberos protokolu. Řadu informací jsem kdysi napsal v sérii Kerberos protokol se zaměřením na SSO v AD DS, základní informace jsou v článcích Kerberos část 4 - hlavní termíny Kerberos protokolu a Kerberos část 5 - princip Kerberos autentizace. Najdeme tam důležité detaily, ale vůbec jsem se nevěnoval šifrovacím algoritmům, které nás zajímají v tomto článku.

Na webu Microsoft je populární článek, který se věnuje zakázání RC4 pro šifrování Kerberos ticketů, Decrypting the Selection of Supported Kerberos Encryption Types.

Oficiální Kerberos dokumentaci nalezneme v RFC4120, [MS-KILE]: Kerberos Protocol Extensions.

Základ Kerberosu

Základem Kerberos protokolu jsou tři komunikace / kroky / Kerberos výměny:

• centrální ověření uživatele - uživatel se ověří na doménovém řadiči (KDC - Key Distribution Center), komunikuje se službou Authentication Service (AS), získá TGT (Ticket-Granting Ticket)
• získání ticketu pro službu - ověřený uživatel chce přistupovat k určité službě registrované v doméně, komunikuje se službou Ticket-Granting Service (TGS) na doménovém řadiči, získá Service Ticket
• ověření u služby - uživatel se přihlásí (ověří) ke službě na určitém serveru, provádí se výměna Authentication Protocol (AP)

Šifrování objektů v Kerberos protokolu

V Kerberos protokolu se šifruje řada údajů (klíčů, ticketů, zpráv) a je potřeba, aby se různé strany (klient, server/služba, doménový řadič) dohodli (podporovali) na určitém typu šifrování. Používají se různé šifrovací algoritmy a různé šifrovací klíče, kterými se šifruje.

Pro Kerberos se (většinou) využívají symetrické klíče, takže stejný klíč slouží pro šifrování i dešifrování. Klíč znají pouze dvě strany, takže jedna může ověřit druhou tím, že zná stejný klíč. Provede se to zašifrováním zprávy, když ji příjemce dokáže rozšifrovat, musí znát stejný klíč. Obě strany musí použít stejný šifrovací algoritmus.

Níže jsou uvedeny základní Kerberos objekty, které se šifrují (přesněji používá se pro ně určitý typ šifrování, pro Session Key se používá hashovací funkce). Plus stručný princip a informace k šifrování, což je v dalších kapitolách více rozvedeno (nejvíce se věnujeme volbě typu šifrování).

• Authenticator - slouží k ověření uživatele, jde o šifrovaný systémový čas (časová známka - Timestamp), případně i identifikaci klienta, používá se pro získání TGT (šifruje se heslem uživatele, posílá na DC, podle operačního systému domlouvá typ šifrování klient a DC), získání Service Ticket (šifruje se pomocí Session Key, typ šifrování ze Session Key) a při ověření u služby (šifruje se pomocí Session Key, typ šifrování ze Session Key)
• TGT (Ticket-Granting Ticket) - slouží k ověření uživatele u DC (získání Service Ticket), aby se nemuselo používat heslo uživatele, klient po ověření získá TGT od DC služby krbtgt, který jej šifruje svým heslem (účet KRBTGT), obsahuje SID, Session Key a další údaje, rozšifrovat jej může pouze DC, od funkčního stupně domény 2008 se používá AES šifrování
• Session Key - slouží k šifrování komunikace mezi klientem a DC (při získání Service Ticket šifruje Authenticator a Session Key pro službu) a mezi klientem a službou (šifruje Authenticator), existuje unikátní Session Key pro TGT (klient jej získá z DC šifrovaný heslem svého účtu, šifru musí podporovat klient a DC, vyhodnocuje se klientský požadavek) a pro jednotlivé Service Ticket (typ šifrování musí podporovat klient a služba/server, vyhodnocuje se klientský požadavek a atribut msDS-SupportedEncryptionTypes cílového účtu / služby)
• Service Ticket - slouží k ověření uživatele u služby, klient posílá požadavek na DC, který obsahuje SPN (Service Principal Name) služby, TGT a Authenticator (šifrovaný pomocí TGT Session Key), DC vytvoří Service Ticket (obsahuje SID, jméno uživatele, Session Key pro službu) a šifruje pomocí hesla služby (může jít o účet počítače nebo uživatelský (servisní) účet nebo Group Managed Service Account), klient jej nemůže rozšifrovat (dostane Session Key v šifrované části odpovědi TGS-REP), ale pošle jej službě pro své ověření, DC volí šifru podle atributu  msDS-SupportedEncryptionTypes účtu (který má přiřazené požadované SPN)
• šifrovaná část odpovědi (Encrypted Response) - když DC odpovídá na žádosti (AS-REP, TGS-REP), tak je část zprávy šifrovaná, nachází se zde Session Key, který potřebuje klient získat, pro TGT se šifruje heslem uživatele, pro Service Ticket pomocí TGT Session Key, typ šifrování musí podporovat klient a DC, může být jiný než typ šifrování obsaženého Session Key

Pincip Kerberos autentizace (stručně)

Nejprve se klient autentizuje, posílá na doménový řadič (KDC AS) žádost o TGT (AS-REQ). Je (standardně) vyžadována Pre-Authentication, protože se (většinou) v žádosti nenachází, tak DC vrátí chybu KRB5KDC_ERR_PREAUTH_REQUIRED. Klient sestaví novou žádost, kam přidá Authenticator (šifrovaný pomocí hesla uživatele).  DC rozšifruje a porovná časovou známku (Authenticator), tím ověří uživatele. Vytvoří (TGT) Session Key a TGT (šifrovaný pomocí AES256 a hesla KRBTGT). Posílá odpověď klientovi (AS-REP), která obsahuje TGT (ten v sobě obsahuje Session Key) a Session Key v šifrované části odpovědi (šifruje se pomocí hesla uživatele).

Když se chce klient přihlásit ke službě, tak nejprve žádá doménový řadič (KDC TGS) o Service Ticket (TGS-REQ). Do žádosti vloží jméno služby, doménu, TGT, Authenticator (šifrovaný pomocí TGT Session Key) a další údaje. DC vytvoří (Service Ticket) Session Key a Service Ticket (šifrovaný heslem cílové služby), pro každé může použít jiný typ šifrování. Posílá odpověď klientovi (TGS-REP), která obsahuje Service Ticket (ten v sobě obsahuje Session Key) a Session Key v šifrované části odpovědi (šifruje se pomocí TGT Session Key).

Pro přihlášení ke službě klient posílá autentizační požadavek dané službě (AP-REQ). V něm se nachází Service Ticket a Authenticator (šifrovaný pomocí Service Ticket Session Key). Služba rozšifruje Service Ticket z něj získá Session Key a pomocí něj rozšifruje Authenticator. Když je vše v pořádku, tak získá jméno uživatele a odešle potvrzení (AP-REP), kde je část šifrovaná pomocí Service Ticket Session Key.

Šifrovací klíče (Encryption Keys)

Pro zjednodušení popisu je uvedeno, že pro šifrování se používá heslo uživatele, služby či účtu. Uživatele či službu vždy představuje účet uživatele, počítače nebo Group Managed Service Account (GMSA) v AD (neřešíme zde komunikaci mezi doménami pomocí Trust Account). Reálně se pro šifrování používá tajný symetrický klíč (Secret Key - Long-Term Key), který je pomocí hashovací funkce odvozený z hesla. Pro některé části se používá Session Key, který je také vytvořen pomocí hashovací funkce.

Standardně se při vytváření klíče z hesla přidává sůl (Salt), která je pro uživatele tvořená doménou (Realm DNS) a uživatelským jménem (user name). Příklad FIRMA.LOCALbouska. Detailní (ale komplikovaně popsané) informace jsou v oficiálních dokumentech na stránce [MS-KILE]: Kerberos Protocol Extensions a ještě popíšeme v druhé části (Keytab soubor - AES klíče a sůl). Cílem je, aby uživatelé se stejným heslem měli jiný klíč. Ale v případě RC4-HMAC (RFC4757) se používá MD4 hash a žádná sůl. Klíč je kompatibilní (stejný) s NTLM klíčem.

Hashovací funkce se volí podle nastavených/podporovaných typů šifrování pro daný účet. Pokud jich je k dispozici více, tak se vytvoří více klíčů, které se uloží k účtu v AD (Account keys) spolu s informací o použitém typu. Klíče se vytváří ve chvíli, kdy se mění/nastavuje heslo účtu. Standardně se vytváří všechny varianty (máme k dispozici AES256 klíč, AES128 klíč, RC4 klíč, DES klíč). Šifrovací klíč je tedy tvořen kombinací typu klíče a hodnoty klíče (při použití se z dostupných variant vybírá vhodný klíč podle typu).

Pokud máme starý účet, kterému se nastavilo heslo v době, kdy nebyla podpora AES. Tak i když je nyní AES podporováno, nepůjde použít (nebude fungovat), dokud se nezmění / nenastaví heslo. DC loguje do systémového logu událost ID 14 (AS-REQ) nebo ID 16 (TGS-REQ) ze zdroje Microsoft-Windows-Kerberos-Key-Distribution-Center, kde je informace Changing or resetting the password of <account name> will generate a proper key.

Řešením je tedy změnit heslo, při té příležitosti se vytvoří nové klíče, ale musíme to provést dvakrát za sebou. Narazil jsem na tuto informaci na fórech a ověřil ji v praxi. Po první změně DC stále tvrdilo, že účet (služba) má pouze RC4 klíč. Po druhé změně začalo fungovat AES. Více rozebereme v druhé části (Dvojí nastavení hesla - vytvoření klíčů).

Zjištění existujících klíčů účtu

Pro zjištění informací, jaké klíče má účet vygenerované, můžeme použít DSInternals PowerShell Module a cmdlet Get-ADReplAccount (Retrieving Active Directory Passwords Remotely).

Install-Module -Name DSInternals
Import-Module DSInternals
$cred = Get-Credential
Get-ADReplAccount -SamAccountName bouska -Server DC1 -Credential $cred

Účet KRBTGT a šifrování TGT

Pokud je Domain Functional Level Windows Server 2008 nebo vyšší, tak KRBTGT účet používá defaultní AES šifrování, ale musí mít vystaveny AES klíče.

Před zablokováním RC4 je dobré zkontrolovat, že se vystavují TGT s AES (pomocí výpisu příkazem klist). Pokud ne, tak je potřeba dvakrát změnit heslo účtu KRBTGT, třeba pomocí skriptu Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 (rotovat heslo bychom měli pravidelně).

Volba typu šifrování a šifrovacího klíče

Některé důležité detaily (jako je volba typů šifrování v různých situacích) se dost těžko hledají. RFC dokumenty jsou docela náročné ke studiu. Různé články na internetu obsahují nekompletní nebo i chybné informace. Řadu informací jsem čerpal z blogu vývojáře Steva Syfuhse, který vyvíjí autentizaci ve Windows. Ale i zde bych řekl, že se najdou nekorektní informace (a některé mi nepřijdou pochopitelné).

Třeba článek Kerberos Event ID 27. Z něho bych chápal, že volba typu šifrování (pro Session Key a Service Ticket) se provádí jako průnik typů v požadavku (Requested ETypes), existujících klíčů účtu (Account keys) a podporovaných (povolených) typů doménového řadiče (KDC supported ETypes).

Prováděl jsem praktické testy, zachytával Kerberos komunikaci (Wireshark) a z předchozích informací dal dohromady svoji představu. Dodatečně jsem narazil na článek (obecný popis non-Microsoft Kerberos) MIT Kerberos Documentation - Encryption types a RC4 Is Still Considered Harmful. Nejvíce mi nakonec pomohl značně starý Microsoft článek Encryption Type Selection in Kerberos Exchanges, díky kterému jsem doplnil pár chybějících detailů (pořád některé věci vynechávám nebo zjednodušuji).

Docela důležité je, že pro šifrování Session Key může být použit jiný typ šifrování než pro šifrování odpovědi z DC, kde se Session Key bezpečně předává klientovi (protože je tato část zašifrovaná, tak v Kerberos paketu není vidět použitý typ pro Session Key, ale pouze pro šifrovanou část odpovědi).

Podle čeho se volí typ šifrování

Je rozdíl, jestli jde o získání TGT, tedy AS-REQ, nebo získání Service Ticket, tedy TGS-REQ. Vždy by se měl použít nejsilnější společný typ šifrování.

Pro rozhodování se vždy uplatňuje:

• doménový řadič (přesněji KDC) - vystavuje a šifruje/hashuje Session Key i Service Ticket, musí tedy mít povolen typ šifrování (řeší se systémově plus pomocí Group Policy), který se použije
• klient (uživatel na určitém počítači) - chce přistoupit ke službě, posílá požadavek AS-REQ / TGS-REQ, v něm uvádí seznam typů šifrování (seřazený podle preference), které podporuje (záleží na počítači, ne uživateli), z odpovědi potřebuje rozšifrovat Session Key (pomocí něj šifruje Authenticator, který posílá DC / službě), ale ne TGT / Service Ticket (ten posílá originálně šifrovaný)

Při autentizaci a získání TGT se přidává:

• klient (reprezentovaný svým účtem v AD) - účet v AD musí mít uložené klíče pro různé typy šifrování (pomocí nich se šifruje Authenticator a odpověď, kde je Session Key)

Při získání Service Ticket se přidává:

• služba (reprezentovaná účtem uživatele, počítače nebo GMSA) - účet v AD musí mít uložené klíče pro různé typy šifrování (pomocí nich se šifruje Service Ticket) a v atributu msDS-SupportedEncryptionTypes má uvedené podporované typy šifrování

Doménový řadič musí v odpovědích zvolit typ šifrování pro Session Key, Service Ticket a část odpovědi.

Volba typu šifrování pro TGT

Pro získání TGT klient posílá žádost AS-REQ, kam dává také uživatelské jméno, doménu a jméno počítače. DC mu odpoví, že je potřeba Pre-Authentication a součástí je seznam akceptovatelných typů šifrování (pro které má u uživatele klíče), pro AES také sůl. Klient zvolí určitý typ a do žádosti přidá šifrovaný Authenticator (svým heslem).

Když DC sestavuje odpověď AS-REP, tak pro šifrování Session Key vychází z

• povolené typy šifrování na doménovém řadiči
• typy šifrování uvedené v požadavku (podporované klientem)

Pro zašifrování části odpovědi (se Session Key) použije stejný typ šifrování, který byl použit pro Authenticator (samozřejmě jej DC musí podporovat, jinak by jej nerozšifroval).

Pro TGT použije AES256 (pokud není na DC zakázané).

Níže je ukázka popsaných Kerberos paketů pro TGT. Jde o situaci (rozebírané v druhé části Přihlášení uživatele (TGT)), kdy klient podporuje AES, ale u účtu má uložen pouze RC4 klíč. DC odpovídá chybou na první požadavek AS-REQ, že je požadována Pre-Authentication, a uvádí jediný podporovaný typ šifrování RC4.

Druhý Kerberos AS-REQ požadavek s uvedenými typy šifrování, které podporuje klient. Obsahuje Authenticator šifrovaný pomocí RC4, což je jediná společná možnost.

Odpověď Kerberos AS-REP, kde klient dostane TGT i Session Key s AES, ale odpověď je šifrovaná pomocí RC4.

Volba typu šifrování pro Service Ticket

Pro získání Service Ticket klient posílá žádost TGS-REQ, kam dává také TGT (obsahuje TGT Session Key) a Authenticator (šifrovaný pomocí TGT Session Key).

Když DC sestavuje odpověď TGS-REP, tak pro šifrování Session Key vychází z

• povolené typy šifrování na doménovém řadiči
• účet služby, jaké má povolené typy šifrování v atributu msDS-SupportedEncryptionTypes
• typy šifrování uvedené v požadavku (podporované klientem)

Pro zašifrování části odpovědi (se Session Key) se použije typ šifrování použitý v TGT Session Key (tedy také jak byl šifrován Authenticator).

Pro volbu typu šifrování Service Ticket se uplatňuje

• povolené typy šifrování na doménovém řadiči
• účet služby, jaké má povolené typy šifrování v atributu msDS-SupportedEncryptionTypes a jaké reálně u účtu existují klíče (pomocí nich se šifruje)

V praxi se mohou použít různé typy šifrování, děje se to nyní při uplatnění AES256-CTS-HMAC-SHA1-96-SK. Pak je Session Key s AES a Service Ticket může být a RC4.

V dokumentu Encryption Type Selection in Kerberos Exchanges se nachází další důležitá informace v části Encryption type of the service ticket. Když se volí typ šifrování pro Service Ticket, tak se bere atribut msDS-SupportedEncryptionTypes plus RC4 (a DES). To by znamenalo, že je možno vystavit Service Ticket s RC4, i když na účtu tuto šifru nepovolíme. Což se mi v jednom případě v praxi stávalo (zmíněno v druhé části v Zvláštní chování - vystavení RC4 Service Ticket).

Pozn.: Ale již vůbec nevím, jak si vyložit poznámku ve FAQ u update 11/2022, že po updatu se změnilo automatické přidávání RC4 nebo AES.

Níže je ukázka Kerberos TGS-REP paketu s popsanými částmi. Je vystaven Service Ticket pro službu HTTP/www.firma.local. Service Ticket i Session Key využívá AES.

Informace o získaných Kerberos Service Ticket na klientovi

Ve Windows můžeme použít řádkový příkaz klist, který vypíše všechny kešované Kerberos tickety (TGT a Service Ticket), které klient získal. Je vidět pro jakou identitu (Client) a službu (Server) byl ticket vystaven, který DC jej vystavil (Kdc Called). A také jaká šifra (KerbTicket Encryption Type) byla použita pro šifrování ticketu a pro Session Key (Session Key Type).

Pozn.: Důležité, pokud používáme User Account Control (UAC). Pak záleží, jestli je příkazový řádek spuštěn standardně nebo jako administrátor (elevation prompt). Každá situace zobrazí jiné tickety, protože v systému jde o dvě různé session (používá se jiný user access token).

Základní použití příkazu klist

Příklad časti výstupu příkazu klist, který ukazuje Service Ticket pro webovou službu (využívající Keytab soubor a servisní uživatelský účet). Takto vypadal před řadou let (než přišla aktualizace 11/2022).

C:\>klist
Current LogonId is 0:0x4c2b5
Cached Tickets: (10)

#2>  Client: bouska @ FIRMA.LOCAL
     Server: HTTP/www.firma.local @ FIRMA.LOCAL
     KrbTicket Encryption Type: RSADSI RC4-HMAC(NT)
     Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
     Start Time: 4/25/2014 12:53:44 (local)
     End Time:   4/25/2014 22:18:52 (local)
     Renew Time: 5/2/2014 12:18:52 (local)
     Session Key Type: RSADSI RC4-HMAC(NT)
     Cache Flags: 0
     Kdc Called: dc.firma.local

Aktuální (po aktualizaci 11/2022) výstup stejného Service Ticket.

#1>     Client: bouska @ FIRMA.LOCAL
        Server: HTTP/www.firma.local @ FIRMA.LOCAL
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40810000 -> forwardable renewable name_canonicalize
        Start Time: 1/8/2024 13:09:53 (local)
        End Time:   1/8/2024 23:09:53 (local)
        Renew Time: 1/15/2024 13:09:53 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: dc.firma.local

Stejný Service Ticket po nastavení atributu msDS-SupportedEncryptionTypes na servisním účtu, aby používal pouze AES.

#1>     Client: bouska @ FIRMA.LOCAL
        Server: HTTP/www.firma.local @ FIRMA.LOCAL
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40810000 -> forwardable renewable name_canonicalize
        Start Time: 1/24/2024 10:54:21 (local)
        End Time:   1/24/2024 17:13:37 (local)
        Renew Time: 1/31/2024 7:13:37 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: dc.firma.local

Další možnosti příkazu klist

Výpis ticketů vystavených pro systém.

klist -li 0x3e7

Můžeme také provést získání ticketu pro určitou službu (SPN).

klist get HTTP/www.firma.local

Pro testy se hodí vymazání všech kešovaných ticketů (takže je můžeme získat znovu).

klist purge

Hledání Service Principal Name

Může se hodit vyhledání, jaký doménový účet má přiřazeno určité SPN.

C:\>setspn -Q HTTP/server.firma.local
Checking domain DC=firma,DC=local
CN=Server SSO,OU=Objekty,DC=firma,DC=local
   HTTP/server.firma.local

Existing SPN found!

Důležité je, jak sestavíme SPN, na které se ptáme. Často používáme servisní třídu HTTP (pro webové služby). Pokud je SPN přiřazeno k účtu uživatele, tak použijeme HTTP. Ale pokud služba využívá účet počítače (třeba IIS), tak se identifikuje pomocí HOST SPN (a HTTP Service Class funguje jako alias na HOST SPN). Tedy pokud je adresa služby stejná jako adresa počítače, tak musíme hledat HOST/server.firma.local.

Atribut msDS-SupportedEncryptionTypes účtů v AD

Několikrát jsme zmínili atribut msDS-SupportedEncryptionTypes, podle kterého se rozhoduje o typu šifrování. Obsahuje seznam šifrovacích algoritmů podporovaných daným účtem uživatele, počítače, GMSA nebo účtem důvěry.

Uživatelské účty mají ve výchozím stavu hodnotu atributu msDS-SupportedEncryptionTypes prázdnou. Počítačové účty mají většinou nastavenu hodnotu 0x1C (28), můžeme ji změnit centrálně pomocí Group Policy. Počítač s podporovaným Windows OS si hodnotu sám nastaví u svého účtu v AD.

Pokud atribut nemá vyplněnu hodnotu (nebo je 0x0), tak se standardně používal typ šifrování RC4-HMAC-MD5 kvůli zpětné kompatibilitě. Po updatu 11/2022 je výchozí AES256-HMAC-SHA1-SK. A je možno změnit klíčem DefaultDomainSupportedEncTypes v registrech na DC. Více probereme v další kapitole.

Hodnoty atributu msDS-SupportedEncryptionTypes

Některé z možných hodnot atributu msDS-SupportedEncryptionTypes:

• 0x4 (4) - RC4-HMAC
• 0x10 (16) - AES256-HMAC-SHA1
• 0x18 (24) - AES128-HMAC-SHA1, AES256-HMAC-SHA1
• 0x1C (28) - RC4-HMAC, AES128-HMAC-SHA1, AES256-HMAC-SHA1
• 0x1F (31) - DES-CBC-CRC, DES-CBC-MD5, RC4-HMAC, AES128-HMAC-SHA1, AES256-HMAC-SHA1

Po updatu 11/2022 máme další varianty:

• 0x27 (39) - DES-CBC-CRC, DES-CBC-MD5, RC4-HMAC, AES256-HMAC-SHA1-SK
• 0x38 (56) - AES128-HMAC-SHA1, AES256-HMAC-SHA1, AES256-HMAC-SHA1-SK
• 0x3C (60) - RC4-HMAC, AES128-HMAC-SHA1, AES256-HMAC-SHA1, AES256-HMAC-SHA1-SK

Jak se hodnota sestavuje, pomocí flagů s typy šifrování, je popsáno v Supported Encryption Types Bit Flags.

Ruční nastavení msDS-SupportedEncryptionTypes

Atribut msDS-SupportedEncryptionTypes můžeme ručně nastavit na účtu uživatele nebo počítače. Přímo do atributu zadáme číselnou hodnotu.

Na uživatelských účtech můžeme využít i nastavení na záložce Account (v Active Directory Users and Computers).

Group Policy - Configure encryption types allowed for Kerberos

Pro počítačové účty můžeme určit, které typy šifrování může Kerberos protokol na daném zařízení používat. Využijeme Group Policy a nastavíme politiku Network security: Configure encryption types allowed for Kerberos v cestě Computer/Policies/Windows Settings/Security Settings/Local Policies/Security Options. Network security: Configure encryption types allowed for Kerberos

Po aplikaci politiky si počítač nastaví atribut msDS-SupportedEncryptionTypes svého účtu v AD. V praxi to vypadá, že politika se na počítač bez přihlášeného uživatele standardně uplatní (nastaví používané typy šifrování), ale ke změně atributu dojde až ve chvíli, kdy se přihlásí uživatel.

Pozn.: Nastavení této politiky na doménový řadič ovlivní celou doménu.

Windows Update Listopad 2022 (11/2022)

Microsoft vydal 8. 11. 2022 aktualizace, které mění chování DC. Jako defaultní se volí AES Session Keys jako obrana proti zranitelnosti CVE-2022-37966. Aktualizace obsahuje opravu i dalších zranitelností týkajících se Kerberos (CVE-2022-37967) a Netlogon (CVE-2022-38023) protokolu (a ovlivňuje jejich chování).

Windows Update November 8, 2022

• Windows Server 2016 - KB5019964
• Windows Server 2019 - KB5019966
• Windows Server 2022 - KB5019081

Hned poté se objevily zprávy, že některým uživatelům, kteří instalovali tento update na doménový řadič (a měli blokované RC4), přestala fungovat řada Kerberos autentizací. Microsoft oznámil, že nejde o očekávané chování po zpřísnění zabezpečení a pracuje na opravě. 17. 11. 2022 byla vydána speciální (Out-of-band) aktualizace pro DC (jinde nebylo třeba instalovat). Není součástí Windows Update, musíme ručně stáhnout samostatný balíček nebo kumulativní aktualizaci.

Windows Update November 17, 2022 Out-of-band

• Windows Server 2016 - KB5021654
• Windows Server 2019 - KB5021655
• Windows Server 2022 - KB5021656

V seznamu oprav aktualizace z 10. 1. 2023, třeba pro Windows Server 2022 - KB5022291, je také uvedena oprava problému souvisejícího s RC4. Podle některých zpráv je to zapracování OOB patche (třeba 11B checker). Každopádně dnes (s instalovanými současnými aktualizacemi) jsem na žádný problém nenarazil (ani při zablokování RC4).

Změny chování v Kerberos protokolu

S listopadovým updatem MS zveřejnil článek KB5021131: How to manage the Kerberos protocol changes related to CVE-2022-37966, který obsahuje určité informace o změnách týkajících se RC4 (řada informací je v části FAQ).

Po instalaci této aktualizace na doménový řadič se mění chování při volbě Session Key. Nijak neovlivňuje šifrování Service Ticket (tam může být stále RC4). Navíc se mění pouze defaultní hodnota, tedy pokud účet nemá nastaven atribut msDS-SupportedEncryptionTypes nebo je 0. Místo původního RC4-HMAC se nyní použije AES256-CTS-HMAC-SHA1-96-SK (to podle What happened to Kerberos Authentication after installing the November 2022/OOB updates? znamená RC4_HMAC_MD5 Encrypted Ticket s AES256_CTS_HMAC_SHA1_96 Session Keys).

Default Domain Supported Encryption Types

Je to ještě o něco komplikovanější. Vznikl nový klíč v registrech DefaultDomainSupportedEncTypes typu REG_DWORD v cestě HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC. Ten umožňuje na doménovém řadiči nastavit defaultní typ šifrování pro účty, které jej nemají určený (atribut msDS-SupportedEncryptionTypes prázdný nebo 0). Ve výchozím stavu není klíč v registrech vytvořen a jeho defaultní hodnota je 0x27 (39), což znamená DES, RC4, AES Session Keys.

Tato volba Microsoftu je trochu zvláštní, protože DES je již dlouho nepodporovaný a chybí zde AES. Ale prý je to z důvodu kompatibility. V praxi by to mělo způsobit, že se většinou použije AES256-CTS-HMAC-SHA1-96-SK, ale pokud chybí podpora AES, tak se použije RC4.

Testy DefaultDomainSupportedEncTypes a msDS-SupportedEncryptionTypes

Prováděl jsem testy některých variant. Pokud má servisní účet nastaven atribut msDS-SupportedEncryptionTypes na 0, tak standardně uživatel dostane Service Ticket s RC4 a Session Key s AES256. Pokud se atribut msDS-SupportedEncryptionTypes nastaví na 4 (pouze RC4), tak dostane Service Ticket s RC4 a Session Key s RC4.

Pokud je atribut msDS-SupportedEncryptionTypes 0 a na DC se povolí pouze AES (pomocí Group Policy), tak dostane Service Ticket s AES256 a Session Key s AES256. Pokud se na DC se povolí pouze RC4, tak dostane Service Ticket s RC4 a Session Key s RC4.

Zkoušel jsem ještě nastavit klíč DefaultDomainSupportedEncTypes na hodnotu 28 (RC4, AES128, AES256), když je msDS-SupportedEncryptionTypes 0. Pak uživatel dostane Service Ticket s AES256 a Session Key s AES256. Když jsem nastavil hodnotu 4 (RC4), tak dostane Service Ticket s RC4 a Session Key s RC4.

Pozn.: Změny klíče v registrech se projeví téměř okamžitě. Změny atributu účtu za pár desítek vteřin.

Další dopady aktualizace

Uvádí se také (třeba ve FAQ sekci KB5021131 nebo What happened to Kerberos Authentication after installing the November 2022/OOB updates?), že pokud byl dříve účet nastaven pouze s podporou AES, tak se stejně vytvořil RC4 klíč, a pokud bylo pouze nastaveno RC4, tak se vytvořily AES klíče. Po instalaci aktualizace se striktně používá nastavení v registrech, msDS-SupportedEncryptionTypes a DefaultDomainSupportedEncTypes. Může nastat situace, kdy klient nemá nastavenu podporu šifrovacích typů, které jsou nastaveny na účtu služby (msDS-SupportedEncryptionTypes) a DC mu nevystaví ticket, takže se uživatel nepřihlásí (i když před aplikací aktualizace přihlášení fungovalo). Již jsem uváděl, že tato informace mi není moc jasná.

V diskusích se uvádí, že aktualizace 11/2022 způsobí, že přestanou fungovat operační systémy, které nepodporují AES. Řešení by mělo být nastavit klíč DefaultDomainSupportedEncTypes na hodnotu například 0x1C (RC4, AES128, AES256). Ale již současná hodnota 0x27 obsahuje RC4 a moje testy ukazují, že se použije. Možná šlo o původní chybu v aktualizaci, která byla opravena.

Problémy s updatem z 8. 11. 2022

Nepovedlo se mi nalézt přesný popis proč nastával problém po aktualizaci 11/2022, ani jaké změny/opravy provádí OOB update.

V popisech, třeba u OOB aktualizace, se uvádí, že problém nastává, pokud je v doméně nastavena Group Policy Network security: Configure encryption types allowed for Kerberos a vyřazena šifra RC4. Projevuje se tak, že se do systémového logu DC loguje událost ID 14 ze zdroje Microsoft-Windows-Kerberos-Key-Distribution-Center a obsahuje text the missing key has an ID of 1. ID na tomto místě neidentifikuje klíč, ale operaci s klíčem (key operation).

Příklady události z internetu:

While processing an AS request for target service <service>, the account <account name> did not have a suitable key for
 generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes : 18 3. The accounts available
 etypes : 23 18 17. Changing or resetting the password of <account name> will generate a proper key.

While processing an AS request for target service krbtgt, the account squid did not have a suitable key for generating 
a Kerberos ticket (the missing key has an ID of 1). The requested etypes : 18 17 20 19 16 23 25 26. The accounts available
 etypes : 23 18 17. Changing or resetting the password ofsquid will generate a proper key.

While procesing an AS request for target service krbtg, the account did not have a suitable key for generating a Kerberos
 ticket (the missing key has an id of 1). The requested etypes 18 17 23 24 -135 3. The accounts available etypes: 23 18 17.
 Changing the password will generate a proper key. 

Některé tyto informace, a radu použít OOB update, uvádí MS v sekci Known issues in this update KB5019081.

Na internetu je mnoho diskusí, kde se uvádí, že problém po updatu se objevil u účtů, které mají nastaven atribut msDS-SupportedEncryptionTypes a je zde pouze AES (blokováno RC4). I když je AES podporován u klienta, služby i DC. Dá se nalézt zmínka, že jde o chybu, protože se RC4 bit používal jako signál k výběru šifer - the RC4 bit being used as a signal of whether it should use a preferred cipher list or a legacy interoperability list in a specific section of code.

Některé články, kde se řeší daná situace Microsoft patches from November 2022 cause problems, Kerberos Issues November 2022, Updates for Windows (Nov. 2022): Changes in Netlogon and Kerberos protocol - causing issues, KnowledgeBase: You experience errors with Event ID 14 and source Kerberos-Key-Distribution-Center on Domain Controllers.

Java a podpora RC4

V praxi nejde jen o podporu/blokování RC4 v Kerberosu ze strany Microsoftu. Již delší dobu můžeme narazit na problém, že nám přestane fungovat přihlášení do aplikace, která využívá Javu. Často po aktualizaci verze Javy. Praktický příklad je aplikace na Apache Tomcat, která využívá Keytab soubor. Řešení je nastavit servisní účet, aby využíval AES a případně nově vystavit Keytab.

Java přestala podporovat RC4 šifry v Kerberosu (JDK-8139348).

• JDK 17 - Released September 14, 2021
• JDK 11.0.17 - Released October 18, 2022
• JDK 8u351 - Released October 18, 2022