none
Kerberos Problem auf einem Windows 2008 DC - kann keine Authentifizierungen mehr machen RRS feed

  • Frage

  • Hallo alle.

    Wir haben jetzt zum zweiten Mal ein kritisches Problem bei einem Domain Controller. Das Problem tritt auf einem Windows 2008 System. Fängt damit an, dass Benutzer nicht mehr auf DFS Freigaben zugreifen können. Auf die File Server schon aber nicht über DFS. Die Fehlermeldung heißt "Sie haben keine Berechtigungen".

    Auf dem betroffenen DC laut Logs ist alles Perfekt. Nur niemand sonst kann diesen DC benutzen. Sobald man den herunterfährt und bei Authentifizierung anderen DC verwendet wird - funktioniert alles. Wenn man ihn wieder startet - können Benutzer auf nichts mehr zugreifen.

    Man kommt über UNC nicht auf den Server und auch keiner DC mehr kann mit dem betroffenen kommunizieren.Im Beispiel betroffene DC SITEDC02, funktionierende SITEDC01.

    Im Log auf dem betroffenen habe ich jetzt nur folgendes gefunden:

    - DCOM 10006 "DCOM got error "2147943850" from the computer SITEFS02 when attempting to activate the server:
    {03837521-098B-11D8-9414-505054503030}"

    - KDC 13 "The account for SITECLIENT2011-01$ has corrupt keys stored in the DS. Changing or setting the password should restore correct keys."

    Dazu im Security Log gibt es Haufen folgenden Meldungen:

    4625 Sec Auditing "An account failed to log on.

    Subject:
        Security ID:        NULL SID
        Account Name:        -
        Account Domain:        -
        Logon ID:        0x0

    Logon Type:            3

    Account For Which Logon Failed:
        Security ID:        NULL SID
        Account Name:       
        Account Domain:       

    Failure Information:
        Failure Reason:        An Error occured during Logon.
        Status:            0xc000006d
        Sub Status:        0x8009030e

    Process Information:
        Caller Process ID:    0x0
        Caller Process Name:    -

    Network Information:
        Workstation Name:    -
        Source Network Address:    172.22.48.157
        Source Port:        59915

    Detailed Authentication Information:
        Logon Process:        Kerberos
        Authentication Package:    Kerberos
        Transited Services:    -
        Package Name (NTLM only):    -
        Key Length:        0

    This event is generated when a logon request fails. It is generated on the computer where access was attempted.

    The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

    The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

    The Process Information fields indicate which account and process on the system requested the logon.

    The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

    The authentication information fields provide detailed information about this specific logon request.
        - Transited services indicate which intermediate services have participated in this logon request.
        - Package name indicates which sub-protocol was used among the NTLM protocols.
        - Key length indicates the length of the generated session key. This will be 0 if no session key was requested."

    DCDIAG liefert keine Fehlermeldung.

     

    Auf den funktionierenden DC gibt es folgende Fehlermeldungen:

    - GroupPolicy 1058 "The processing of Group Policy failed. Windows attempted to read the file \\domain.local\sysvol\domain.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:
    a) Name Resolution/Network Connectivity to the current domain controller.
    b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).
    c) The Distributed File System (DFS) client has been disabled."

    - Security-Kerberos 4 "The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server sitedc02$. The target name used was cifs/sitedc02.domain.local. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (domain.local) is different from the client domain (domain.local), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server."

    Dabei werden ganz unterschiedliche SPN erwähnt "CIFS, DNS, ..."

    Dazu noch kommt bei dem DCDIAG folgende Fehler:

    - "[SITEDC02] LDAP bind failed with error 8341,

       A directory service error has occurred..
       Got error while checking if the DC is using FRS or DFSR. Error:

       A directory service error has occurred.The VerifyReferences, FrsEvent and

       DfsrEvent tests might fail because of this error."

    - "Replications Check,SITEDC01] A recent replication attempt failed:

                From SITEDC02 to SITEDC01

                Naming Context: DC=DomainDnsZones,DC=domain,DC=local

                The replication generated an error (1256):

                The remote system is not available. For information about network troubleshooting, see Windows Help.

               

                The failure occurred at 2011-12-27 11:53:52.

                The last success occurred at 2011-12-26 18:53:52.

                17 failures have occurred since the last success.

             [SITEDC02] DsBindWithSpnEx() failed with error -2146893022,

             The target principal name is incorrect.."

    Der Fehler kommt zu allen Zonen.

     

    Letztes mal haben wir den DC versucht zu reparieren. SPN Einträge überprüft, sogar Computer Konto Passwort zurückgesetzt. Hat nichts gebracht. Am Ende haben wir den DC aus der Domäne entfernt. Jetzt möchten wird das Problem finden, denn morgen sind eventuell mehr DCs betroffen.

    Würde für alle Hinweise dankbar.

    PS. TechNet für ähnliche Probleme haben wir bereits letztes mal durchgecheckt und alle Vorschläge ausprobiert.

    Dienstag, 27. Dezember 2011 11:32

Antworten

  • Danke alle für eure Antworten. Das Problem ist behoben.

    Große Hilfe hat den Artikel gebracht.

    http://blogs.technet.com/b/deds/archive/2009/04/09/fehlerbehebung-zu-the-target-principal-name-is-incorrect-unter-windows-server-2008.aspx

    Die im Artikel beschrieben Schritte haben das Problem behoben.

    Unklar ist nur wie es dazu gekommen ist dass die Passwörter unterschiedliche Versionen hatten und wie kann man solche Situationen in Zukunft vermeiden.

    @Martin. So viele DCs, weil wir ca. 10 Standorten haben. Pro Standort ist 1 DC (wenn Standort mehr als 100 User hat, dann zwei für Ausfallsicherheit).

    • Als Antwort markiert Kas Tigar Mittwoch, 28. Dezember 2011 09:35
    Mittwoch, 28. Dezember 2011 09:35

Alle Antworten

  • Hallo,

    kling so als gäbe es Probleme mit dem Computerobjekt des DCs ... Meine erste Idee war die Uhrzeit. Wenn die Uhrzeit zwischen den DCs auseinander geht, schlägt kerberos fehl. Wenn es sich um einen virtuellen DC handelt, kann der virtuallisierungs Host schon mal die lokale Zeit ändern.

    Ist dieser DC in letzter Zeit mal über ein Backup wiederhergestellt worden ?

    Als Lösung würde ich den DC herunterstufen, aus der Domäne entfernen, Konto löschen und wieder hochstufen. Danach wird er wieder sauber funktionieren. Aber die Ursache bleibt natürlich unklar....

     


    Viele Grüße Carsten
    Dienstag, 27. Dezember 2011 14:37
  • Hallo und danke für die Antwort.

    Zeit stimmt natürlich (hat man als erstes überprüft).

    Der DC wurde letzte Zeit nicht angefasst und auch nicht zurück gesichert.

    Die Möglichkeit kennen wir, wollen aber es nicht angehen denn es an der Stelle gar nicht bringt. Wir möchten nicht jeder Woche DCs neu aufsetzen sondern das Problem finden und lösen.

    Letztes mal haben wir übrigens das probiert, nach der Promotion war aber der somit neugeborene DC nicht mehr funktionsfähig. Wenn man sich versucht hat anzumelden, kam immer "User name or password wrong". Dann hat man den gelöscht und neues erstellt.

    Jetzt suchen wir nach dem Problem und einer Lösung!

    Dienstag, 27. Dezember 2011 15:10
  • Also nach dem ihr den DC komplett entfernt und neu gemacht habt, ist der Fehler wieder aufgetreten ?

    Wie werden bei euch neue DCs installiert ? Gibt es ein Template oder änliches ?

    Habt ihr nur 2008er DCs ?

    Ist die Kommunikation zwischen den DCs frei oder gibt es eine Firewall dazwischen ?


    Viele Grüße Carsten
    Dienstag, 27. Dezember 2011 15:34
  • Nur der Vollständigkeit halber: Läuft auf dem DC nur die AD, oder auch andere Dienste? Wie schauts mit Software von Drittanbietern aus?

    LG Ronald Kaufmann

     

    Dienstag, 27. Dezember 2011 15:42
  • Nach dem wir damals den DC entfernt und einen neuen erstellt haben, gibt es das Problem nicht. Das war übrigens ein anderes Standort.

    DCs werden fast immer aus einem Template genommen. Und wir haben ca. 10 DCs die ohne Problem funktionieren.

    Und wenn letztes mal hatten wir ein Problem mit einem 2008 R2 Server erstellt aus dem Template, diesmal ist ein 2008 SP2 x32 betroffen welches ohne Template gemacht wurde.

    Es gibt in der Domäne ein 2003 R2 Server. Alle andere sind 2008.

    Zwischen den zwei DCs aus dem ersten Eintrag gibt es kein Firewall. Zwischen Standorten gibt es schon aber an dem Standort haben wir zwei DCs und der ersten hat kein Problem.

     

    Zusätzliche Info.

    Wenn man "repladmin /syncall" auf dem betroffenen DC ausführt, kommt - keine Fehler.

    Wenn auf dem funktionierendem kommt:

    C:\Windows\system32>repadmin /syncall
    "CALLBACK MESSAGE: Error contacting server c3b0733d-5ad6-476a-83a9-99ab73b802af._msdcs.domain.local (network error): -2146893022 (0x80090322):
        The target principal name is incorrect."

    Dienstag, 27. Dezember 2011 15:48
  • > DCs werden fast immer aus einem Template genommen. Und wir haben ca. 10
    > DCs die ohne Problem funktionieren.
     
    Warum eigentlich immer so viele DCs? Wollt Ihr Euch dauernd um die
    Replikation kümmern? (:
     
    Einer (na gut, ausfallsicher, also zwei) reicht für deutlich
    fünfstellige Benutzerzahlen...
     
    mfg Martin
     

    A bissle "Experience", a bissle GMV... Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Dienstag, 27. Dezember 2011 20:27
  • hmmm, das klingt nach einer genaueren Analyse aller Komponenten.

    - Netzwerkeinstellungen der DCs

    - DNS-Zonen auf falsche Einträge untersuchen

    - dcdiag muss auf jedem DC sauber durch laufen

    - Eventlogs

    - bei den R2 Servern kannst du den BPA verwenden (Rolle überprüfen)

    Nehmt ihr die Server schon vor dem dcpromo in die Domäne auf ? Seid wann tritt diese Problem auf wurde was geändert ? Habt ihr Änderungen an den DCs vorgenommen (z.B. RPC Ports per Registry festgelegt) ?

    Als Empfehlung solltet ihr alle DCs auf den gleichen Stand bringen.

     


    Viele Grüße Carsten
    Mittwoch, 28. Dezember 2011 06:46
  • Danke alle für eure Antworten. Das Problem ist behoben.

    Große Hilfe hat den Artikel gebracht.

    http://blogs.technet.com/b/deds/archive/2009/04/09/fehlerbehebung-zu-the-target-principal-name-is-incorrect-unter-windows-server-2008.aspx

    Die im Artikel beschrieben Schritte haben das Problem behoben.

    Unklar ist nur wie es dazu gekommen ist dass die Passwörter unterschiedliche Versionen hatten und wie kann man solche Situationen in Zukunft vermeiden.

    @Martin. So viele DCs, weil wir ca. 10 Standorten haben. Pro Standort ist 1 DC (wenn Standort mehr als 100 User hat, dann zwei für Ausfallsicherheit).

    • Als Antwort markiert Kas Tigar Mittwoch, 28. Dezember 2011 09:35
    Mittwoch, 28. Dezember 2011 09:35