none
Passwortänderung funktioniert an einem Client nicht. Arbeitsstationsvertrauensstellung RRS feed

  • Allgemeine Diskussion

  • Hallo,

    ich habe ein Phänomen das ich nicht wirklich verstehe. Ich habe einen Windows 8 Client in einer 2008R2 Domain. Wenn ein User (egal welcher) versucht an diesem Client sein Passwort zu ändern, erscheint folgender Fehler

    "die Sicherheitsdatenbank auf dem Server enthält kein Computerkonto für diese Arbeitsstationsvertrauensstellung"

    Der Client existiert aber im AD (Replikation läuft fehlerfrei) Anmeldung am Client funktioniert auch. nltest und Test-Computersecurechannel gibt keine Fehler zurück. Ich habe den Client auch schon komplett neu aufgesetzt... Fehler bleibt bestehend. Auf einem Windows7 Client im selben Subnetz funktioniert der Passwortwechsel einwandfrei.

    Im Eventlog des Clients ist nichts zu finden...

    Im Eventlog des DC' taucht folgende Meldung auf, wenn versucht wird das PW zu ändern

    Ein Kerberos-Authentifizierungsticket (TGT) wurde angefordert.

    Kontoinformationen:
        Kontoname:                Username
        Angegebener Bereichsname:        Domain

        Benutzer-ID:                Domain\Username

    Dienstinformationen:
        Dienstname:                krbtgt
        Dienst-ID:                Domain\krbtgt

    Netzwerkinformationen:
        Clientadresse:                ::ffff:172.21.101.113
        Clientport:                56019

    Weitere Informationen:
        Ticketoptionen:            0x40810010
        Ergebniscode:                0x0
        Ticketverschlüsselungstyp:        0x12
        Typ vor der Authentifizierung:    2

    Zertifikatsinformationen:
        Zertifikatausstellername:        
        Seriennummer des Zertifikats:    
        Zertifikatfingerabdruck:   

    Ich bin langsam mit meinem Latein an Ende...

    Vorschläge?

    Grüße


    Best regards
    Andreas Ernst
    MCITP:EA, MCP, MCTS

    Mittwoch, 23. Oktober 2013 09:02

Alle Antworten

  • Client aus der Domain nehmen, Konto im AD löschen, Client wieder ins AD aufnehmen, immer fleißig neu starten zwischendurch.


    Servus
    Winfried

    GPOs: http://www.gruppenrichtlinien.de/
    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/

    Donnerstag, 24. Oktober 2013 17:30
  • Die Anmeldung geht gegen einen beliebigen DC, die Kennwortänderung gegen den PDC. Check das Computerkonto mal auf allen DCs, die Du so hast...

    Martin

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))

    Restore the forum design - my user defined Cascading Style Sheet!

    Freitag, 25. Oktober 2013 07:07
  • Hallo,

    bei einer Neuinstallation wird das AD Konto ohnehin gelöscht.

    Ich habe dies aber nun nochmals gemacht.

    PC aus der Domain. Client restart. Replikaiton abgewartet. Konto gelöscht, Replikaiton abgewartet, auf allen DCs gescheckt. Rechner in die Domain -> restart, Replikation abgewartet auf allen DCs verfügbar.

    PW Änderung schlägt immernoch mit der gleichen Meldung fehl :-(


    Best regards
    Andreas Ernst
    MCITP:EA, MCP, MCTS


    Freitag, 25. Oktober 2013 08:28
  • hallo Martin,

    "die Kennwortänderung gegen den PDC"

    Das hatte ich auch als erstes im Verdacht. Leider hapert es wohl wo anderst. Der Client ist an allen DCs verfügbar.

    Grüße


    Best regards
    Andreas Ernst
    MCITP:EA, MCP, MCTS

    Freitag, 25. Oktober 2013 08:30

  • bei einer Neuinstallation wird das AD Konto ohnehin gelöscht.

    Ich habe dies aber nun nochmals gemacht.

    Wenn Du damit das Computerobjekt meinst, dann habe ich das noch nie gesehen dass ein rausnehmen aus einer Domain das Computerobjekt im AD gelöscht hat.

    PC aus der Domain. Client restart. Replikaiton abgewartet. Konto gelöscht, Replikaiton abgewartet, auf allen DCs gescheckt. Rechner in die Domain -> restart, Replikation abgewartet auf allen DCs verfügbar.

    PW Änderung schlägt immernoch mit der gleichen Meldung fehl :-(


    Führe einen sauberen Neustart aus, möglicherweise ist ein 3rd Party Dienst oder eine 3rd Party Anwendung dafür verantwortlich. http://support.microsoft.com/kb/929135/de

    Servus
    Winfried

    GPOs: http://www.gruppenrichtlinien.de/
    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/

    Samstag, 26. Oktober 2013 22:14
  • Hallo,

    > Wenn Du damit das Computerobjekt meinst, dann habe ich das noch nie gesehen dass ein rausnehmen aus einer Domain das Computerobjekt im AD gelöscht hat.

    unsere Softwareverteilung löscht das AD Konto wenn ich dem Client eine Betriebssysteminstallation zuweise.

    Den CleanNeustart werde ich testen.

    Grüße


    Best regards
    Andreas Ernst
    MCITP:EA, MCP, MCTS

    Montag, 28. Oktober 2013 08:25
  • > Wenn Du damit das Computerobjekt meinst, dann habe ich das noch nie gesehen dass ein rausnehmen aus einer Domain das Computerobjekt im AD gelöscht hat.

    unsere Softwareverteilung löscht das AD Konto wenn ich dem Client eine Betriebssysteminstallation zuweise.

    Ah ok.

    Den CleanNeustart werde ich testen.


    Konntest Du schon testen?

    Servus
    Winfried

    GPOs: http://www.gruppenrichtlinien.de/
    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/

    Montag, 28. Oktober 2013 19:17
  • Hallo Winfried,

    eben habe ich es ausprobiert. Leider wieder keine Besserung :(


    Best regards
    Andreas Ernst
    MCITP:EA, MCP, MCTS

    Dienstag, 29. Oktober 2013 12:42
  • Hallo Andreas,

    stimmt Deine Zeitreplikation (DCs, Clients) in der Domäne?

    LG,

    Thomas

    Dienstag, 29. Oktober 2013 12:48
  • Hallo Thomas,

    Zeit stimmt. Auch NLTest meldet mir einen sicheren Kanal.

    Grüße


    Best regards
    Andreas Ernst
    MCITP:EA, MCP, MCTS

    Dienstag, 29. Oktober 2013 13:53
  • Erstelle bitte auf dem betroffenen Client ein Network Trace und analysiere das exakte Fehlerverhalten inkl. ggf. Kerberos-Errors im Network Trace.

    Als Basiswissen für eine Network Trace-Analyse kannst Du folgende Artikel nehmen:

    Kerberos for the Busy Admin
    http://blogs.technet.com/b/askds/archive/2008/03/06/kerberos-for-the-busy-admin.aspx

    Kerberos errors in network captures
    http://blogs.technet.com/b/askds/archive/2012/07/27/kerberos-errors-in-network-captures.aspx

    --

    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Dienstag, 29. Oktober 2013 16:04
  • Hallo,

    Rechner ist momentan nicht verfügbar... Werde sobald wie möglich Tracen um dem Problem auf die Schliche zu kommen. Werde mich wieder melden.

    Grüße


    Best regards
    Andreas Ernst
    MCITP:EA, MCP, MCTS

    Donnerstag, 31. Oktober 2013 14:42
  • Hallo,

    bin gerade dazu gekommen.

    am fehlerhaften Client bekomme ich einen Kerberos Req auf den ein ERROR KDC_ERP_PREAUTH_Required bekommt (meines erachtens normal) worauf der Client wieder einen Request schickt und der Server mit einem Response Ticket antwortet.

    Aber nun hört es auf... Nichts mehr.

    Auf einem Client wo es funktioniert sehe ich später ein TGS Request und ein Respond des DC's dieses fehlt aber auf dem Win8 Client.

    Bei einer normalen Anmeldung am Client wird eine TGS Req generiert... Nur eben bei der Passwortänderung nicht.

    PS: Mittlerweile kann ich den Fehler auf allesn Windows 8 Clients reproduzieren...


    Best regards
    Andreas Ernst
    MCITP:EA, MCP, MCTS


    • Bearbeitet Andreas Ernst Montag, 4. November 2013 08:37 edit...
    Montag, 4. November 2013 08:28
  • Das Verhalten müsste genauer untersucht werden, da die geschilderten Informationen so nicht weiterhelfen das Problem einzugrenzen.

    --

    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Montag, 4. November 2013 15:06
  • Am 04.11.2013 schrieb Andreas Ernst:

    PS: Mittlerweile kann ich den Fehler auf allesn Windows 8 Clients reproduzieren...

    Welche Softwareverteilung habt ihr im Einsatz? Kannst Du einen Client
    blank mit einer Windows DVD manuell installieren und testen? Wir
    hatten hier im Forum kürzlich etwas ähnliches, nach einer
    vollständigen Installation über eine Softwareverteilung und diversen
    Anpassungen später noch, war anschließend das hinzufügen von Windows
    Features nicht mehr möglich.


    Servus
    Winfried

    Gruppenrichtlinien
    WSUS Package Publisher
    HowTos zum WSUS Package Publisher

    Montag, 4. November 2013 17:45
  • Hallo,

    werde ich,gleich morgen

    prüfen und gebe Bescheid.


    Best regards
    Andreas Ernst
    MCITP:EA, MCP, MCTS

    Montag, 4. November 2013 19:03
  • Hallo Winfried,

    habe gerade einen Client gefunden den ich schon vor längerem von Hand installiert habe. Auf diesem Tritt das Problem auch auf. Ich werde mich mal an unseren Extermen Support wenden.

    Grüße


    Best regards
    Andreas Ernst
    MCITP:EA, MCP, MCTS

    Dienstag, 5. November 2013 08:38
  • habe gerade einen Client gefunden den ich schon vor längerem von Hand installiert habe. Auf diesem Tritt das Problem auch auf. Ich werde mich mal an unseren Extermen Support wenden.

    Bei diesem Client kann natürlich eine bereits installierte SW dieses Problem ebenfalls verursachen. Deshalb mein Hinweis auf eine blanke Neuinstallation ohne zusätzliche SW. Testen, SW installieren, testen.


    Servus
    Winfried

    Gruppenrichtlinien
    WSUS Package Publisher
    HowTos zum WSUS Package Publisher

    Dienstag, 5. November 2013 12:25
  • Hallo,

    Lösung besser spät als nie.

    http://social.technet.microsoft.com/Forums/de-DE/7a4e1da7-3a5a-4a33-b51e-6c49961676cf/windows-8-81-domain-kennwort-ndern-the-security-database-on-the-server-does-not-have-a?forum=active_directoryde

    Grüße


    Best regards
    Andreas Ernst
    MCITP:EA, MCP, MCTS

    Dienstag, 10. Dezember 2013 10:41