Kerberos Encryption Types unter Windows 7 und Windows Server 2008 R2
Hallo zusammen, Fabian hier. Ab Windows 7 bzw. Windows Server 2008 R2 werden Kerberos Anfragen und Antworten standardmäßig nicht mehr mit DES (DES-CBC-MD5 & DES-CBC-CRC) verschlüsselt, da DES nicht mehr den Anforderungen an eine zeitgemäße Verschlüsselungsstufe genügt. Windows 7 bzw. 2008 R2 Systeme erzeugen standardmäßig nur noch AES und RC4 Anfragen bzw. Antworten.
Siehe dazu auch:
Changes in Kerberos Authentication http://technet.microsoft.com/en-us/library/dd560670(WS.10).aspx
und
961302 Vista and Windows Server 2008 clients are unable to access cluster names with AES-encrypted Kerberos tickets http://support.microsoft.com/default.aspx?scid=kb;EN-US;961302
Dies kann zu Problemen führen, wenn eine Applikation bzw. ein Dienst keine AES oder RC4 Verschlüsselung „spricht“, sondern nur Kerberos Pakete mit DES unterstützt. In diesem Fall bleibt in den Standardeinstellungen nur der Fallback auf NTLM oder aber die Authentifizierung scheitert. Grundsätzlich sollte also sichergestellt sein, daß die im Unternehmen eingesetzten Applikationen und Dienste AES-Kerberos-fähig sind, bevor das Deployment von Windows 7 Clients oder Windows Server 2008 R2 Systemen beginnt.
Für Windows Server 2003 DCs kann es ebenfalls sinnvoll sein, auf AES „umzuschalten“, siehe dazu:
Changes in default encryption type for Kerberos pre-authentication on Vista and Windows 7 clients cause security audit events 675 and 680 on Windows Server 2003 DC's
http://blogs.technet.com/instan/archive/2009/10/12/changes-in-default-encryption-type-for-kerberos-pre-authentication-on-vista-and-windows-7-clients-cause-security-audit-events-675-and-680-on-windows-server-2003-dc-s.aspx
Um festzustellen, welche Encryption Types von einem System angefordert werden, kann man entweder die Dokumentation bemühen, das Kerberos Logging hochdrehen oder aber einen Netzwerktrace ziehen. Hier ist ein einem Kerberos Request der „EType“, also der „Encryption Type“ entscheidend. Schlägt die Authentifizierung an einer Applikation / einem Dienst (etwa einem Web-Portal) fehl, äußert sich der fehlschlagende Request beispielsweise in einem Netzwerktrace wie folgt:
Kerberos Request (Ausschnitt):
Frame 1 {TCP:48, IPv4:47} <SRC IP> <DEST IP> KerberosV5 KerberosV5:TGS
Request Realm: CONTOSO.COM Sname: HTTP/<hostname>.<FQDN>
0.000000 {TCP:48, IPv4:47} <source IP> <destination IP> KerberosV5
KerberosV5:TGS Request Realm: <fqdn> Sname: HTTP/<hostname>.<fqdn>
- TgsReq: Kerberos TGS Request
- KdcReq: KRB_TGS_REQ (12)
- ReqBody:
- Etype:
+ EType: aes256-cts-hmac-sha1-96 (18)
+ EType: aes128-cts-hmac-sha1-96 (17)
+ EType: rc4-hmac (23)
+ EType: rc4-hmac-exp (24)
+ EType: rc4 hmac old exp (0xff79)
+ TagA:
+ EncAuthorizationData:
Der Etype zeigt an, daß kein DES vom Client angeboten / angefragt wird, die Konsequenz daraus ist folgerichtig das Ablehnen des Requests durch das Web-Portal:
Frame 2 {TCP:48, IPv4:47} <DEST IP> <SRC IP> KerberosV5 KerberosV5:KRB_ERROR
- Kerberos: KRB_ERROR - KDC_ERR_ETYPE_NOSUPP (14)
- KrbError: KRB_ERROR (30)
+ ErrorCode: KDC_ERR_ETYPE_NOSUPP (14)
Der allererste Schritt bei der Windows 7 und Windows Server 2008 R2 Integration in einer Domänen-Umgebung sollte also sein, die AES Kompatibilität sicherzustellen, um ein entsprechendes Sicherheitsniveau zu erreichen. Ist dies jedoch aus verschiedenen Gründen nicht möglich, läßt sich das Standardverhalten von Windows 7 und Windows Server 2008 R2 Systemen auch verändern, um DES Verschlüsselung zuzulassen.
Hierzu existiert seit Windows 7 RSAT bzw. Windows Server 2008 R2 GPMC / GPEDIT eine neue Einstellung, die den Encryption Type zentral verwalten kann. Unter “Computer Configuration\ Windows Settings\ Security Settings\ Local Policies\ Security Options” wird die Einstellung “Network security: Configure encryption types allowed for Kerberos” zu Verfügung gestellt, in der man dann auch DES wieder aktivieren kann.
Ist diese Policy auf einem Windows 7 / 2008 R2 System aktiv, wird folgender Registry Schlüssel geschrieben:
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters
REG_DWORD: „supportedencryptiontypes“.
Wurden alle derzeit verfügbaren Verschlüsselungstypen in der GPO-Einstellung gesetzt (also alle Encryption Types + zukünftige ETypes aktiviert), ergibt sich daraus der Wert „0x7FFFFFFF“ als “supportedencryptiontypes” DWORD-Wert.
Der NETLOGON Dienst fragt dann bei einem DC (secure channel) die Änderung des folgenden Attributs des Client-Computerkontos im AD an: ms-DS-Supported-Encryption-Types http://msdn.microsoft.com/en-us/library/ms677827(VS.85).aspx . Dies passiert bei einem Neustart des Clients bzw. beim Start des NETLOGON-Dienstes oder zyklisch im Laufbetrieb. Als Attributwert des "msDS-SupportedEncryptionTypes" wird der Wert eingetragen, den der Client von der Policy übernommen hat, also in unserem Beispiel etwa „0x1F“ (hex) bzw. „31“ (dezimal), womit alle verfügbaren Encryption Types ausgewählt sind. Diesen Wert liest ein KDC aus, um die Verschlüsselung bei einer Ticket-Anfrage für das jeweilige Konto zu bestimmen.
Wie der Wert Zustande kommt, kann beispielsweise hier nachgelesen werden:
msDS-SupportedEncryptionTypes – Episode 1 - Computer accounts http://blogs.msdn.com/openspecification/archive/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts.aspx
An diesem Punkt ist es also wichtig, daß der vom NETLOGON Dienst angeforderte Schreibzugriff auf das Attribut „msDS-SupportedEncryptionTypes“ erfolgreich ist und der Wert auch korrekt auf den DCs repliziert wird, denn sonst wird der gewünschte Encryption Type zwar vom Client angefordert, der KDC stellt die Anforderung jedoch nicht aus. Er verwendet in diesem Szenario weiterhin die von ihm standardmäßig supporteten ETypes, so etwa bei Windows 7 / Windows Server 2008 R2 DCs AES. Die Authentifizierung würde nun trotz korrekter Group Policy Einstellung scheitern.
Je nach Szenario muß die Policy also für Windows 7 Clients oder aber auch für Windows Server 2008 R2 Member als auch 2008 R2 Domänencontroller aktiviert werden.
Nachdem die Policy am Client angekommen ist, fordert der Client in unserem Beispiel bei Kerberos Requests nun auch wieder DES Verschlüsselung an (Ausschnitt):
Frame 3 {TCP:48, IPv4:47} <SRC IP> <DEST IP> KerberosV5 KerberosV5:TGS
Request Realm: CONTOSO.COM Sname: HTTP/<hostname>.<FQDN>
0.000000 {TCP:48, IPv4:47} <source IP> <destination IP> KerberosV5
KerberosV5:TGS Request Realm: <fqdn> Sname: HTTP/<hostname>.<fqdn>
- TgsReq: Kerberos TGS Request
- KdcReq: KRB_TGS_REQ (12)
- ReqBody:
- Etype:
+ EType: aes256-cts-hmac-sha1-96 (18)
+ EType: aes128-cts-hmac-sha1-96 (17)
+ EType: des-cbc-md5 (3)
+ EType: des-cbc-crc (1)
+ EType: rc4-hmac (23)
+ EType: rc4-hmac-exp (24)
+ EType: rc4 hmac old exp (0xff79)
+ TagA:
+ EncAuthorizationData:
Wie angesprochen ist die Anpassung der Policy / des Encryption Types eher als „letzte Lösung“ zu betrachten, nicht als „Standardfall“. Es sollte besser geprüft werden, wie die Umgebung fit für AES-Kerberos-Verschlüsselung gemacht werden kann.
Viele Grüße
Fabian
