Vor kurzem hatte ich mit einem Kunden zu tun, welcher beklagte, dass manchmal (!) der Zugriff auf seine NetApp nicht mehr erfolgreich ist. Das Phänomen trat aber erst auf, nachdem ein defekter Domain Controller entsorgt und durch einen neuen, etwas aktueller gepatchten (!) Domain Controller ersetzt wurde.
Das Phänomen tritt aber nur auf, wenn über den Namen (Hostname / FQDN) auf die NetApp zugegriffen wird und die Authentifizierung über den neuen DC erfolgte. Verwendet man anstelle des Namens die IPv4-Adresse der NetApp, so ist der Zugriff immer möglich.
Kerberos V5 vs. NTLM
Der Umstand, dass ein Zugriff auf die NetApp über den Namen manchmal fehlschlägt, jedoch der Zugriff über die IPv4-Adresse immer erfolgreich ist, kann auf Probleme mit dem Kerberos V5 hindeuten.
Die genaue Mechanik von Kerberos V5 kann beispielsweise hier bei Microsoft nachgelesen werden:
https://learn.microsoft.com/en-us/windows-server/security/kerberos/kerberos-authentication-overview
Nur so viel von mir dazu:
wenn sich ein Domänenmitglied (User / Computer) am On-Premises AD anmeldet wird in der Regel ein Ticket Granting Ticket (TGT) ausgestellt. Hält man ein TGT im LSA-Cache, kann hierüber ein Ticket Granting Service Ticket (TGS) erlangt werden. Das TGS ist ein konkretes Zugriffsticket für eine Ressource, welche über Kerberos V5 authentifiziert. Beim Zugriff auf die Ressource (roter Pfeil ganz unten) wird dem Ressourcenträger (eg ein FileServer mit einem SMB-Share) das TGS präsentiert, welches der Ressourcenträger mit seinem Computerkennwort entschlüsselt.
Bei NTLM läuft der Zugriff anders ab und kann natürlich auch bei Microsoft nachgelesen werden:
https://learn.microsoft.com/en-us/windows-server/security/kerberos/ntlm-overview
Grundsätzlich gilt: wenn der Zugriff über eine IP-Adresse erfolgt, handelt es sich in der Regel um NTLM-Authentifizierung (Kerberos V5 verlangt als Basis für den Zugriff Namen).
Einer der Unterschiede zwischen Kerberos V5 und NTLM ist, dass der Ressourcenträger hier nichts entschlüsseln muss. Das Validieren von Benutzername und Kennwort passiert auf dem Logon-Domain Controller des Ressourcenträgers (pass-through-authentication).
Update: KB5021131
Microsoft hat ein interessantes Update zum Kerberos V5 herausgebracht – hier der kurze Abriss:
KB5021131: DefaultDomainSupportedEncTypes
Möchte ich per Kerberos V5 auf eine Ressource zugreifen, benötige ich ein TGS. Der Domain Controller, welcher mich bedient, muss nun herausfinden, welche Kryptografie mit dem Zielsystem möglich ist.
Hierzu zieht der Domain Controller den Wert des Attributes msDS-SupportedEncryptionTypes des Ressourcenträgers heran.
Der dezimale Wert 28 zeigt an, dass das Zielsystem RC4, AES128 und AES256 spricht. Der Computer SV01 hat diesen Wert (28) bei seinem Computerobjekt im AD selbst eingetragen. Die Übersetzung des dezimalen Wertes in die Kryptografie kann hier vollzogen werden:
Bei diesem little-endian sind die Bits wie folgt zugeordnet:
1) DES-CBC-CRC = 2^0 / 1
2) DES-CBC-MD5 = 2^1 / 2
3) RC4-HMAC = 2^2 / 4
4) AES128-CTS-HMAC-SHA1-96 = 2^3 / 8
5) AES256-CTS-HMAC-SHA1-96 = 2^4 / 16
6) AES256-CTS-HMAC-SHA1-96-SK = 2^5 / 32
Die 28 berechnet sich wie folgt: 2^2 + 2^3 + 2^4 (4 + 8 + 16).
Es kann aber nun sein, dass das Attribut msDS-SupportedEncryptionTypes „<not set>“ ist.
Und nun?
msDS-SupportedEncryptionTypes vs. DefaultDomainSupportedEncTypes
Jetzt kommt KB5021131 auf die Bühne!
Vor KB5021131 entsprach das „<not set>“ RC4 (analog zu 0 und 4 – siehe oben).
Durch KB5021131 ändert sich dieses Verhalten jetzt, aber nur, wenn auf einem DC mit diesem Update in der Registry ein Wert hinterlegt, wird:
Wobei gilt: der „Data value“ orientiert sich hier an dem little-endian von msDS-SupportedEncryptionTypes.
Die neue Regel lautet: wenn msDS-SupportedEncryptionTypes „<not set>“ oder „0“ ist, gilt die Kryptografie, welche beim jeweiligen DC in der Registry steht.
Der von Microsoft vorgeschlagene Wert von 0x27 (hexadezimal) bzw. 39 (dezimal) setzt sich zusammen aus: DES_CBC_CRC, DES_CBC_MD5, RC4_HMAC_MD5 und 0x20
0x20?
Ja, 0x20!
0x20 (hexadezimal) / 32 (dezimal) steht für AES256-CTS-HMAC-SHA1-96-SK und AES256-CTS-HMAC-SHA1-96-SK hat es faustdick hinter den Ohren:
…] Enforce AES session keys when legacy ciphers are in use. When the bit is set, this indicates to the KDC that all cases where RC4 session keys can be used will be superseded with AES keys. […
Klar? Nein?
0x20 sagt dem DC per Registry-Eintrag, dass ab jetzt grundsätzlich alle RC4 TGS eben nicht mehr mit RC4 ausgestellt werden, sondern mit AES-Verschlüsselung. Immer unter der Prämisse, dass das Attribut msDS-SupportedEncryptionTypes „<not set>” oder “0” ist.
Warum jetzt das „DES-Geraffel“ beim empfohlenen Wert noch drinsteht, entzieht sich meiner Kenntnis.
0x20 (32 dezimal) macht eigentlich genau das gleiche wie 0x18 (24 dezimal). 0x18 / 24 entspricht AES128- und AES256-Verschlüsselung, setzt aber eine bisherige Kryptografie voraus. Will sagen: 0x20 allein liefert kein TGS.
Kombiniere ich das aber nun mit 0x4 / 4, das entspricht RC4, in Summe 0x24 / 36, kommt raus: AES256, logisch, oder?
Das kann jetzt eklig werden, wenn das Zielsystem die AES-Verschlüsselung nicht unterstützt, so wie beim Kunden.
Das Ende vom Lied:
KRB_AP_ERR_MODIFIED
Die Fehlermeldung im Kerberos-Protokoll „KRB_AP_ERR_MODIFIED“ wird in der Regel mit fehlenden oder falsch gesetzten SPNs in Verbindung gebracht.
Die Fehlermeldung heißt nur, dass das Zielsystem das TGS nicht entschlüsseln konnte, mehr nicht. Zum Entschlüsseln muss zum einen der richtige Schlüssel (genauer: der MD4-Hash) vorliegen und zum anderen die Kryptografie richtig sein.
Komme ich mit einem AES-verschlüsselten TGS zum Ressourcenträger und dieser kann nur RC4, wird das nichts werden.
Langer Rede, kurzer Sinn
Vertrauensstellungen (Windows trusts), sofern vorhanden, müssen auf AES erweitert werden.
Die Ressourcenträger, welche kein AES beim Kerberos-Protokoll unterstützen müssen, identifiziert werden und, wenn möglich, zeitnah aktualisiert werden, damit AES unterstützt wird.
Ist ein aktualisieren nicht möglich und AES-Unterstützung in weiter ferne sollte im Attribut msDS-SupportedEncryptionTypes vorrübergehend die „4“ eingetragen werden, damit einem „DefaultDomainSupportedEncTypes“ bei den DCs nicht in die Suppe spuckt.
Wie findet man diese Objekte?
Am einfachsten mit der (Windows) PowerShell.
$SPN = ‘servicePrincipalName’
$enc = ‘msDS-SupportedEncryptionTypes’
Get-ADObject -Filter { $SPN -like “*” -and $enc -notlike “*” -or $enc -lt 1 }
