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 (TGT als auch Session Key).
Siehe dazu auch:
Changes in Kerberos Authentication https://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 https://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 Session Key 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.
Beim EInsatz von Windows Server 2003 DCs gibt es ebenso einiges zu beachten, 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
https://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 im Session Key von einem System angefordert werden, kann man entweder die Dokumentation bemühen, das Kerberos Logging hochdrehen oder aber einen Netzwerktrace ziehen. Hier ist auf dem Client in 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 Session Key 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. Dies gilt für die TGT als auch die TGS.
Hierzu existiert seit Windows 7 RSAT bzw. Windows Server 2008 R2 GPMC / GPEDIT eine neue Einstellung, die den Session Key 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 https://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 https://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 für den Session Key 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.
Zusätzlich existieren die ETypes auch für KDCs, die damit das TGT und das TGS verschlüsseln. Da das TGT nur von den KDCs ausgewertet werden muß, stellt die Nutzung von AES in den allermeisten Umgebungen ab 2008 eher kein Problem dar. Beeinflussen kann man das Verhalten der KDCs in Bezug auf die angefragt Verschlüsselungsstufe mit dem im KB961302 genannten Schlüssel "KdcUseRequestedEtypesForTickets", um etwa RC4 für die Pre-Authentication o.ä. zu erreichen, was jedoch aus Sicherheitsgründen nicht die erste Wahl sein sollte.
Viele Grüße
Fabian
Comments
Anonymous
January 01, 2003
Hallo Manuel, ich gehe davon aus, daß die von Dir eingesetzten Samba Bibliotheken Probleme haben? Falls ja, macht vielleicht ein upgrade der Samba Version Sinn - vielleicht sind die Probleme in einer aktuelleren Version behoben. DES einzusetzen ist wie angesprochen nur "der letzte Weg". Die Gruppenrichtlinie "Network security: Configure encryption types allowed for Kerberos" ist nur auf Windows 7 bzw. Windows Server 2008 R2 RSAT verfügbar, von dort mußt Du die Einstellung also bei Bedarf vornehmen. Ansonsten stehen wie immer auch viele Communities bei Fragen zur Verfügung, so etwa unsere Technet Foren: http://www.technet-foren.de . Viele Grüße FabianAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
November 24, 2009
Hallo Florian, vielleicht kannst du weiterhelfen, da ich glaube Kerberos ist an meine Dilemma schuld. Eine Windows 2003 Domain wird umgebaut beide DCs des Zentrale werden durch Windows 2008 R2 ersetz. Jetzt dauern aber alle Zugriffe auf einen Windows 2003 Printserver (kein DC) elend lange, somit auch das öfnen von Office Dokumenten. Auch andere Sachen dauern nun länger. Es gibt keine Fehler in den Logs. Ich suche nun schon seit 5 Tagen Hiiiilfe JürgenAnonymous
February 26, 2010
Hmmm. Also ich versuche bereits seit Tagen vergebens Samba einem Active Directory zu joinen. Da es offenbar in den Kerberos Bibliotheken dort gewisse Bugs gibt, bin ich auf die DES Verschlüsselung angewiesen, aber ich finde den angesprochenen Menüpunkt überhaupt nicht in den Gruppenrichtlinien.