none
Ein Problem bei Kerberos Authentifizierung bei einem Windows 2008 R2 SP1 DC für ein 3t Anbieter Software RRS feed

  • Frage

  • Hallo alle. Wir benutzen eine Software welche für Kerberos Authentifizierung konfiguriert ist. Bis heute hat sich die Software erfolgreich bei einem Windows 2003 R2 DC authentifiziert. Wir haben letzte Woche das letzte Windows 2003 DC am Standort mit einem Windows 2008 R2 SP1 DC ersetzt. Soweit funktioniert die 3t Anbieter Software, aber ein Benutzer kann sich nicht mehr anmelden. Wenn er versucht sich anzumelden, kommt die Meldung von unten:

    Evnt ID 14, Source: Kerberos-Key-Distribution-Center:

    While processing an AS request for target service krbtgt/KOCHGROUP.ORG, the account "usrename" did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 3). The requested etypes : 17. The accounts available etypes : 23  -133  -128  3  -140. Changing or resetting the password of krbtgt will generate a proper key.

    Ich habe diesen Artikel bereits gefunden und das Passwort von krbtgt geändert. Das hat nichts gebracht, außerdem läuft KDC Service unter Local System Konto.

    http://technet.microsoft.com/en-us/library/dd348670(WS.10).aspx

    I habe zum Testzwecken einen Windows 2003 R2 DC aus einem anderen Standort für die Authentifizierung konfiguriert und der Benutzer kann sich ohne Problem anmelden, sobald ich das wieder zurück ändere,  funktioniert wieder nicht. Aber alle andere Benutzer können sich ohne Problem auch bei einem Windows 2008 R2 SP1 DC anmelden.

    Ich habe auch einen Hotfix in KB gefunden, bei welchem diese Fehlermeldung mit dem Einsatz von DES Verschlüsselung in Verbindung gebracht wird. Allerdings benutzt das problematische Konto keine DES Verschlüsselung und das Hotfix ist eigentlich in dem SP1 schon mit dabei.

    Bitte um Hinweis. Was ist an dem Benutzerkonto so besonderes und wie man das Problem beheben kann?

    Danke!

    Montag, 14. November 2011 08:43

Antworten

  • Ich habe das Problem folgendes behoben.

    Bei der krb5.ini Datei, die bei BO für AD Integration verwendet wird habe ich die drei folgende Zeile hinzugefügt:

        default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac
        default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac
        permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac

    Somit habe ich den Einsatz von AES und RC4 erzwungen.  Der Fehler ist weg und die Benutzer können sich anmelden.

    Im Network Monitor kommt eine Anfrage von eType 23 und eine Antwort darauf.

    Danke an alle Beteiligte.
    • Als Antwort markiert Kas Tigar Dienstag, 15. November 2011 16:29
    Dienstag, 15. November 2011 16:28

Alle Antworten

  • Hallo,

    schau Dir mal bitte folgenden Artikel an:

    http://technet.microsoft.com/en-us/library/dd560670(WS.10).aspx

     


    Martin Forch
    Montag, 14. November 2011 08:55
  • Hallo Martin,

    danke für Deine Antwort.

    Ich habe den Artikel durchgelsen allerdings handelt es sich dabei um Einsatz von DES Verschlüsselung. Wie ich aber schon geschrieben habe, es wird kein DES beim Konto verwendet.

    Gruß,

    Montag, 14. November 2011 13:56
  • > Kerberos ticket (the missing key has an ID of 3). The requested etypes :
    > 17. The accounts available etypes : 23 -133 -128 3 -140. Changing or
    > resetting the password of krbtgt will generate a proper key.
     
    Schau Dir mal diesen Artikel an:
     
    Dein Account hat laut Fehlermeludng die ETypes 3 und 23. Und 3 ist DES.
     
    mfg Martin
     

    A bissle "Experience", a bissle GMV...
    Montag, 14. November 2011 16:53
  • Vielen Dank Martin, das war sehr hilfreich.

    Jetzt komme ich zu mindestens voran. So wie ich die Meldung verstehe (mit Hilfe des Artikels) Benutzer fordert ein Kerberos Ticket mit etype 17 (aes128-cts-hmac-sha1-96). Aber zur Verfügung steht nur etype 23 (rc4-hmac) und 3 (des-cbc-md5). Die Frage ist nur, wenn unter "account available" das Benutzer Konto gemeint ist, mit welcher sich der Benutzer anzumelden versucht, warum ist dann nur etype 23 und 3 möglich? Laut dem Artikel ist bei Windows 7 / 2008 default etype AES und RC4.

    Zweite Frage. Ich habe jetzt die GPO für DC so angepasst, dass alle eTypen erlaubt sind. Dennoch kommt zum Problem. Eigentlich ändert das nichts. Ich habe sogar bei Client alle eTypen aktiviert und probiert - das gleiche Ergebnis.

    Dann habe ich Network Monitor eingeschaltet und Trafik aufgenommen und zu verstehen was überhaupt passiert.

    Laut dem Request Packet, fordert der Client eType 17 an. Zurück kommt Fehler KDC_ERR_ETYPE_NOSUPP. Der Fehler bedeutet:

    KDC has no support for encryption type

    Aber das stimmt nicht, denn 2008 DC unterstützt eType 17 und 23 by default. Außerdem habe explizit alles erlaubt.

    Was mir auch nicht klar ist. Wie unterscheiden sich die Pakete KerbersoV5 AS Request Cname und TGS Request Realm.

    Denn ich sehe ab und zu beim Logon Versuch das erste öfter aber auch das zweite.

     

    Dienstag, 15. November 2011 14:58
  • Ich habe das Problem folgendes behoben.

    Bei der krb5.ini Datei, die bei BO für AD Integration verwendet wird habe ich die drei folgende Zeile hinzugefügt:

        default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac
        default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac
        permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac

    Somit habe ich den Einsatz von AES und RC4 erzwungen.  Der Fehler ist weg und die Benutzer können sich anmelden.

    Im Network Monitor kommt eine Anfrage von eType 23 und eine Antwort darauf.

    Danke an alle Beteiligte.
    • Als Antwort markiert Kas Tigar Dienstag, 15. November 2011 16:29
    Dienstag, 15. November 2011 16:28
  • > Benutzer anzumelden versucht, warum ist dann nur etype 23 und 3 möglich?
     
    Dafür dürfte - wenn ich Deinen nächsten Post richtig verstehe - eure 3rd
    party Anwendung verantwortlich sein.
     
    > Was mir auch nicht klar ist. Wie unterscheiden sich die Pakete
    > KerbersoV5 AS Request Cname und TGS Request Realm.
     
    AS: Authentication - erstmalige Anmeldung mit Ergebnis "ich habe ein TGT".
     
    TGS: Zugriff auf Ressource - ich brauche ein Service-Ticket, aber ein
    TGT habe ich schon (bin also bereits authentifiziert, nur noch nicht
    authorisiert).
     
    mfg Martin
     

    A bissle "Experience", a bissle GMV...
    Dienstag, 15. November 2011 16:55
  • Vielen Dank für die Aufklärung.
    Donnerstag, 17. November 2011 08:49