Kerberos Encryption Types unter Windows 7 und Windows Server 2008 R2

Kerberos Encryption Types unter Windows 7 und Windows Server 2008 R2

  • Comments 8
  • Likes

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 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 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
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 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.

EType_Policy

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.

EType_Attribute

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 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
  • Hey Fabian!

    Danke für den Artikel - das sollte die "Awareness" von AES in KRB für Win7 und Server2008R2 deutlich steigern. :-)

    Du erwähnst die Änderung des Computerkonto-Attributes ms-DS-Supported-Encryption-Types durch den NETLOGON-Dienst, was bei einem Neustart und _zyklisch_ im Laufbetrieb geschehen kann. Wie "zyklisch" geschieht die Änderung denn, wenn die Systeme nicht so rasch neu gestartet werden?

    Cheerio!

    Florian

  • Hi Florian,

    im Normalfall sollte die Änderung im Zuge der Gruppenrichtlinienaktualisierung vom NETLOGON Dienst initiiert werden. Das setzt dann natürlich voraus, daß die GPO-Einstellung am Client angekommen ist und auch ein DC erreichbar ist, wenn die Hintergrundaktualisierung läuft.

    Insgesamt sollte man also die Zeit einrechnen, die der Client benötigt, um die Richtilinie zu bekommen (also standardmäßig in etwa 90 Minuten + offset) plus die zweite GPO-Hintergrundaktualisierung, bei der der NETLOGON Dienst dann die Attributänderung anfordert.

    Je nach Umgebung kann sich dieser (standardmäßige) Zeitraum von in etwa 180 Minuten also unterscheiden, wenn diese Eckdaten unterschiedlich sind.

    Viele Grüße und ein angenehmes Wochenende,
    Fabian

  • Hey Fabian!

    Danke - dann ist die "Wartezeit" nur auf das Abarbeiten der Gruppenrichtlinien beschränkt. Im Artikel las es sich so, als wäre das wohle ein Offset, der vom NETLOGON-Dienst selbst bestimmt würde.

    Vielen Dank nochmals und auch dir ein schönes Wochenende!

    Florian

  • Moin Florian,

    genau, der NETLOGON-Dienst hängt sich sozusagen in diesem konkreten Fall im Laufbetrieb an die Gruppenrichtlinienverarbeitung. Macht ja auch Sinn, schließlich kommt die Einstellung per Policy. :-)

    Übrigens läßt sich der Vorgang mittels NETLOGON-Logging sehr schön nachvollziehen. Wenn man also einmal ein Problem in diese Richtung hat, ist das Logging ein guter Ansatzpunkt neben den Netzwerktraces und Eventlogs.

    Viele Grüße
    Fabian

  • 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ürgen

  • Hallo Jürgen,

    vielleicht mag Florian ja auch etwas schreiben, aber ich kann es ebenfalls versuchen.

    Grundsätzlich können wir hier in diesem Blog keinen Support im klassischen Sinne leisten, daher nur eine kurze Antwort meinerseits: Ich würde in Richtung SMB Signing oder NTLM SSP schauen - vermutlich wird in dieser Richtung das Problem liegen. Aber mit den vorhandenen Angaben kann man natürlich nur Mutmaßungen treffen.

    Ich würde vorschlagen, je nach Dringlichkeit eine Anfrage bei uns zu öffnen - wenn es "nicht eilt", können alternativ auch die Microsoft Communities weiterhelfen, so etwa unsere Technet Foren: http://www.technet-foren.de .

    Viele Grüße

    Fabian

  • 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.

  • 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

    Fabian

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment