festus94
Goto Top

Authentifizierung funktioniert nicht mehr

Hallo zusammen,

ich habe ein seltsames Problem, bei dem ich Unterstützung gebrauchen könnte. Ich habe einen Account im Active Directory, der seit ein paar Wochen plötzlich Probleme hat, sich gegen Remote-Systeme zu authentifizieren. Ich versuche mal, das Ganze halbwegs verständlich zu erklären.

Hier ein paar Beispiele, was nicht mehr funktioniert:
  • Wenn ich Active Directory Users and Computers öffne, dann kann ich mich nicht gegen andere Domänen im Forest verbinden. Auch die Verbindung zu anderen Domänen-Controllern in der eigenen Domäne funktioniert nicht.

access denied
access denied_2

  • Wenn ich in der PowerShell versuche, zum Beispiel mit Get-ADUser das Active Directory anzufragen, bekommt ich einen nicht näher spezifizierten SSPI-Fehler.

Fehler: "Get-ADUser : A call to SSPI failed, see inner exception."
In der Inner Exception steht leider nichts anderes drin.

  • Ich kann nicht mal mehr das SYSVOL Share im Explorer öffnen. Ich werde immer nach meinen Credentials gefragt. Auffällig ist die Fehlermeldung.

error2

Ich kenne nur diesen einen Account, der betroffen ist. Was ich bereits herausgefunden habe:
  • Es ist kein Berechtigungsproblem.
  • Eine Kopie dieses Accounts funktioniert einwandfrei.
  • Das Problem ist nicht bezogen auf einen konkreten Client oder Server.
  • Wenn ich in der PowerShell statt eines Servernamens eine IP-Adresse angebe, funktioniert die Abfrage. Wenn ich mich korrekt erinnere, wird in diesem Fall NTLM verwendet.
  • Wenn ich in der PowerShell einen Servernamen angebe und zusätzlich den Paramter Credential mitgebe, funktioniert die Abfrage. Wenn ich mich nicht irre, wird bei dieser Methode der Authentifizierungsprozess von vorne begonnen, indem wieder ein neues TGT angefordert wird.
  • Wenn ich beim Aufruf des SYSVOL Shares meine Credentials angebe, funktioniert der Aufruf.
  • Wenn ich beim Aufruf des SYSVOL Shares die IP-Adresse des Servers verwende, funktioniert der Aufruf.
  • Wenn ich den Traffic mitschneide, während ich das SYSVOL Share aufrufen, sehe ich im Capture erst dann Kerberos Traffic, nachdem ich die Credentials eingebe.
  • Nehme ich diesen Account melde mich damit an einem Domänen-Controller an und öffne die DSA, dann funktioniert die Konsole wunderbar, da sie dann den lokalen Server verwendet. Sobald ich hier versuche, einen anderen DC oder eine andere Domäne anzugeben, kommen die Fehlermeldungen von oben. Das Ganze betrifft natürlich auch andere Konsolen.

Für mich riecht das irgendwie nach einem Kerberos-Problem. Mir sind keine Änderungen bekannt, als deren Folge dieses Problem entstanden sein könnte. Ich wüsste jetzt ehrlich gesagt auch nicht, wie ich diesen Zustand nur bei einem Account herbeiführen könnte.

Habt ihr eine Idee, wo ich ansetzen könnte? Klar, ich könnte den Account einfach löschen, neu anlegen und gut. Aber ich finden das Problem spannend und würde es gerne verstehen.

Vielen Dank vorab und viele Grüße

Festus94

Content-Key: 1476579339

Url: https://administrator.de/contentid/1476579339

Ausgedruckt am: 03.10.2022 um 20:10 Uhr

Mitglied: sabines
sabines 06.11.2021 um 15:26:17 Uhr
Goto Top
Moin,

so wie du es beschreibst liegt es tatsächlich am benutzten Account.
Vielleicht irgendwo cached credentials oder ein zwischengespeicherter Eintrag in der reg.
Was passiert, wenn du das Passwort des Accounts mal änderst.

DNS ist ok und sysvol repliziert sauber, keine anderen Probleme im AD?

Grüße
Mitglied: Festus94
Festus94 06.11.2021 aktualisiert um 15:45:04 Uhr
Goto Top
Hi @sabines,

ansonsten keine Probleme. Sonst müsste es ja auch mindestens mal mehrere Konten betreffen. Und auch bei Replikationsfehlern vom SYSVOL Share würde der Zugriff funktionieren. DNS passt auch, sonst käme ich gar nicht so weit. Da gab es auch keine Änderung, die zeitlich im Zusammenhang stehen würde.

Eine Kennwortänderung kann ich mal ausprobieren, allerdings passt das irgendwie nicht zum Problem, denn dann dürfte es bei expliziter Angabe von Credentials ja auch nicht klappen.

Danke dir. 🙂
Mitglied: Dani
Dani 07.11.2021 um 15:09:16 Uhr
Goto Top
Moin,
Wenn ich in der PowerShell versuche, zum Beispiel mit Get-ADUser das Active Directory anzufragen,
Wie lautet die komplette Abfrage?

In der Inner Exception steht leider nichts anderes drin.
auch nicht mit $error[0].Exception | fl * -Force?

>Wenn ich beim Aufruf des SYSVOL Shares meine Credentials angebe, funktioniert der Aufruf.
Ist das der selbe Account mit dem du Probleme hast oder ist es ein anderer Account?

Ich gehe davon aus, dass du die Basics eines ADDS bereits geprüft hast:
  • Zeitzone, Datum und Uhrzeit?
  • DCDIAG, REPADMIN
  • Ereignisprotokolle auf den jeweiligen DC (Stichwort NTDS General, NTDS KCC)
  • Funktioniert der Zugriff via AD Explorer


Gruß,
Dani
Mitglied: Festus94
Festus94 07.11.2021 um 19:32:13 Uhr
Goto Top
Hi @Dani,

Zitat von @Dani:

Wie lautet die komplette Abfrage?


Zitat von @Dani:

auch nicht mit $error[0].Exception | fl * -Force?

Ahh, mir fehlte das Format-Table am Ende. Hider die InnerException:


Sieht mir nach derselben Meldung aus, die ich auch beim Zugriffsversuch auf das SYSVOL Share bekomme (Zeilen drei bis vier). Immerhin einheitlich. face-smile

Zitat von @Dani:

Ist das der selbe Account mit dem du Probleme hast oder ist es ein anderer Account?

Klar, sonst wär's ja witzlos. face-wink

Zitat von @Dani:

Ich gehe davon aus, dass du die Basics eines ADDS bereits geprüft hast:
  • Zeitzone, Datum und Uhrzeit?
  • DCDIAG, REPADMIN
  • Ereignisprotokolle auf den jeweiligen DC (Stichwort NTDS General, NTDS KCC)

Ich kann in den Logs nichts Ungewöhnliches sehen. Eine Suche in den Administrative Events nach dem betroffenen Account (der mit den Problemen, nicht der via PowerShell Gesuchte) bringt kein passendes Event zum Vorschein. DIe Logs sind allerdings riesig.

Da die Fehlermeldung auf Client-Seite ja aber sagt, dass kein passender DC kontaktiert werden kann, bekommt der Ziel-DCs von der Anfrage vermutlich gar nichts mit? Ansonsten funktioniert das AD sauber. Sonst wären ja auch mehr Benutzer betroffen. Es tritt mit verschiedenen DCs auf, also ist es auch nicht serverspezifisch.

Zitat von @Dani:


Ja, das funktioniert. Das wird aber einfach daran liegen, dass auch hier explizit Credentials angegeben werden. Für mich ist das immer noch Kerberos-bezogen.

Viele Grüße

Festus94
Mitglied: Dani
Dani 07.11.2021 aktualisiert um 20:40:48 Uhr
Goto Top
Moin,
Klar, sonst wär's ja witzlos. face-wink face-wink
Ich hab dir nicht über die Schulter gesehen. Daher frage ich sicherheitshalber nochmals nach. Damit verbunden auch die Frage, ob du den Zugriff auch schon von einem anderen Rechner ausprobiert hast? Sind Rechner, DC(s) und betroffenens Benutzerkonto in der selben Windows Domäne? Ist der betroffener Benutzer Mitglieder der AD-Gruppe Domain Users (Domänen-Benutzer)?

System.ServiceModel.Channels.ServiceChannelProxy.InvokeService
Ein Proxy Server ist in den Einstellungen des Benutzer (nicht) hinterlegt?

Sieht mir nach derselben Meldung aus, die ich auch beim Zugriffsversuch auf das SYSVOL Share bekomme (Zeilen drei bis vier). Immerhin einheitlich. face-smile face-smile
Die gute Nachricht ist, dass ich die Fehlermeldung in unserer KB gefunden habe. Die schlechte ist, dass die Fehlermeldung verschiedene Ursache haben kann. face-sad

Fall 1)
Bei uns in einem Subnetzwerk ist der Fehler aufgetreten, weil ein Business Router einen IPv6 Bereich ins LAN gepusht hat. Somit waren die Domain bzw. Hostnames in dem Bereich teilweise durch IPv6 Adressen ungültig.

Fall 2)
Remove Bogus IP Addresses. Sprich ein Cleanup der DNS-Caches auf DCs im dem Netzbereich war notwendig (Dnscmd /ClearCache).

Fall 3)
Berechtigungen der Domäne (dc=test,dc=local) in ADSedit waren für eine Gruppe falsch gesetzt.

Für mich ist das immer noch Kerberos-bezogen.
Wurden Änderungen für/an CredSSP durchgeführt?


Gruß,
Dani
Mitglied: Festus94
Festus94 08.11.2021 um 08:23:30 Uhr
Goto Top
Hi @Dani,

ja, es ist unabhängig vom Clientsystem. Selbst, wenn ich das Ganze von einem DC aus mache, erhalte ich den Fehler. An die Gruppe Domain Users dachte ich auch schon, allerdings ist diese vorhanden. Der Account ist auch nicht in der Gruppe Protected Users. Das Problem tritt sowohl bei Abfragen/DCs in der eigenen als auch in anderen Domänen innerhalb des Forests auf.

Ein Proxy ist als Systemproxy definiert. Das gilt dann aber bei allen Benutzern. Wenn ich die Abfrage nach dem Proxy mit einem anderen Account mache, kommt dasselbe Ergebnis zurück. In den Einstellungen für Webproxys ist die automatische Erkennung aktiv. Wenn ich mich nicht irre, müsste auch hier ein Proxy gesetzt werden, das weiß ich aber nicht sicher. Wo konnte man noch mal sehen, ob de automatische Erkennung etwas gefunden hat?

Deine drei Fälle sehen interessant aus, vielen Dank dafür.

Zu Fall 1: Das müsste doch dann den Client betreffen, wenn er die Domäne auflöst, richtig? Dann sollte es an diesem Client aber alle User betreffen. Ich kann den Domänennamen problemlos auflösen und bekomme nur IPv4-Adressen zurück.

Zu Fall 2: Nur , um sicher zu gehen: Das betrifft den DC, der als DNS-Server vom Client angefragt wird, um die Domäne aufzulösen? Das könnte ich natürlich dann einfach mal testen.

Zu Fall 3: Kannst du "falsch" genauer definieren? War es eine systembezogene Gruppe wie Domain Users? Oder eine Gruppe des Nutzers mit Deny? Wobei es dann ja mit einer Kopie des Accounts nicht klappen dürfte. Aber da kann ich auch mal auf die Suche gehen.

Änderungen an CredSSP sind mir nicht bekannt. Mein Kollege sagt auch, dass es keine Änderung gegeben hat. Ich wollte gerade generell noch mal die GPOs prüfen, die au den User wirken, aber beim Aufruf von rsop.msc bekomme ich auch die Meldung "Error - The system cannot contact a domain controller to service the authentication request.". Immerhin ist es überall kaputt...

Danke dir. face-smile

Viele Grüße

Festus94
Mitglied: Dani
Dani 08.11.2021 um 11:07:21 Uhr
Goto Top
Moin,
An die Gruppe Domain Users dachte ich auch schon, allerdings ist diese vorhanden
Ist der betroffene Nutzer auch in der Gruppe drin?

Wenn ich mich nicht irre, müsste auch hier ein Proxy gesetzt werden, das weiß ich aber nicht sicher. Wo konnte man noch mal sehen, ob de automatische Erkennung etwas gefunden hat?
Puh, gute Frage. Ich bin schon länger nicht operativ unterwegs. face-smile Ansonsten deaktivere für das System einmal die Proxykonfiguration bzw. vergleiche dies, mit dem Benutzerkonto wo der Zugriff nach wie vor funktioniert.

Nur , um sicher zu gehen: Das betrifft den DC, der als DNS-Server vom Client angefragt wird, um die Domäne aufzulösen?
Die Kollegen haben das in der KB nicht genauer beschrieben. Sowie ich das verstehe, wurde dies auf allen DCs durchgeführt.

Zu Fall 3: Kannst du "falsch" genauer definieren? War es eine systembezogene Gruppe wie Domain Users? Oder eine Gruppe des Nutzers mit Deny?
In unseren Fall war es eine von uns angelegte Gruppe, in der der Nutzer Mitglied war. Aber es kann natürlich auch direkt das Benutzerkonto sein. Man muss dazu sagen, dass wir unsere Active Directory gehärtet haben. Es wird nahe zu auf keine Standardgruppe zurückgegriffen. Fluch und Segen zu gleich...

Ich wollte gerade generell noch mal die GPOs prüfen
Hast du einmal die Gruppenmitgliedschaften (gpesult /r) von dem defekten und einem funktionierenden Benutzerkonto verglichen?

In wie weit bist du in klist (z.B. klist get host/%computername%) eingetaucht?


Gruß,
Dani
Mitglied: Festus94
Festus94 08.11.2021 um 11:27:07 Uhr
Goto Top
Hi @Dani.

Zitat von @Dani:

Ist der betroffene Nutzer auch in der Gruppe drin?

Ja, der Benutzer ist Mitglied der Gruppe Domain Users.

Zitat von @Dani:

Puh, gute Frage. Ich bin schon länger nicht operativ unterwegs. face-smile Ansonsten deaktivere für das System einmal die Proxykonfiguration bzw. vergleiche dies, mit dem Benutzerkonto wo der Zugriff nach wie vor funktioniert.

Die Proxykonfiguration ist identisch zu anderen Benutzern, das habe ich gerade noch mal verglichen.

Zitat von @Dani:

Die Kollegen haben das in der KB nicht genauer beschrieben. Sowie ich das verstehe, wurde dies auf allen DCs durchgeführt.

Ich werde später mal den Cache auf den DNS-Servern leeren und es noch mal testen. Tut ja nicht weh.

Zitat von @Dani:

In unseren Fall war es eine von uns angelegte Gruppe, in der der Nutzer Mitglied war. Aber es kann natürlich auch direkt das Benutzerkonto sein. Man muss dazu sagen, dass wir unsere Active Directory gehärtet haben. Es wird nahe zu auf keine Standardgruppe zurückgegriffen. Fluch und Segen zu gleich...

Das ist ja ein Traum. face-smile Davon sind wir noch ein ganzes Stück entfernt.

Zitat von @Dani:

Hast du einmal die Gruppenmitgliedschaften (gpesult /r) von dem defekten und einem funktionierenden Benutzerkonto verglichen?

Da wird es immer Unterschiede geben. Od hast du etwas Spezifisches im Sinn?

Zitat von @Dani:

In wie weit bist du in klist (z.B. klist get host/%computername%) eingetaucht?

Nur sehr oberflächlich. Wenn ich explizit Server (zum Beispiel die DCs) angebe, bekomme ich Tickets zurück, darunter ein Ticket zum angegebenen Server.


Wenn ich nach dem Anfordern des Tickets mit Get-ADUser genau diesen DC anfrage, bekomme ich aber weiterhin den SSPI-Fehler.

Wenn ich den lokalen Server, auf dem ich bin, angebe, kommt ein Fehler.


Der SPN auf dem Computerkonto ist aber gesetzt.

Viele Grüße

Festus94
Mitglied: Dani
Dani 08.11.2021 um 19:09:57 Uhr
Goto Top
Moin,
Der SPN auf dem Computerkonto ist aber gesetzt.
Da du gesagt hast, dass am selben Computer ein anderes Benutzerkonto funktioniert, kann es am SPN nicht liegen.

Nur sehr oberflächlich.
Kleiner Crashkurs: Taming the Three-Headed Beast Kerberos

Unabhängig davon bitte mal folgenden Befehl ausführen:


Gruß,
Dani
Mitglied: Festus94
Festus94 09.11.2021 um 07:45:36 Uhr
Goto Top
Moin @Dani,

stimmt, aber das Ganze ist so seltsam... face-wink

Den Link werde ich mir später mal ansehen.

Das Kommando wirkt sich nur auf meinen User aus, richtig?

Danke dir.
Mitglied: Dani
Dani 09.11.2021 um 11:22:24 Uhr
Goto Top
Moin,
Das Kommando wirkt sich nur auf meinen User aus, richtig?
Nein. Es wirkt sich auf allen angemeldeten Benutzer aus, die am Rechner/Server angemeldet sind, wo der Befehl ausgeführt wird. Machst du das z.B. auf deinem Rechner, bist nur du betroffen. Machst du das auf einem RDS Hosts sind alle zu dem Zeit angemeldeten Benutzer betroffen. Der Befehl führt einen Reset der Kerberkos Tickets durch.


Gruß,
Dani
Mitglied: Festus94
Festus94 09.11.2021 um 11:24:11 Uhr
Goto Top
Hi,

dann ist das schlecht. Es handelt sich um einen administrativen Account, der meinst in einer RDS-Umgebung genutzt wird. Auf meinem Client kann ich das aber mal machen, da tritt das Problem ja auch auf. Aber nicht mitten am Tag. face-wink

Ich melde mich. Danke dir.
Mitglied: Festus94
Festus94 09.11.2021 um 18:51:21 Uhr
Goto Top
Hi @Dani,

nach dem Löschen der Kerberos-Tickets bleibt der Fehler bestehen. Es wird aber sauber ein neues Service Ticket für LDAP bezogen:


Ich hoffe, dass ich morgen dazu komme, den DNS-Cache zu löschen. Da schulde ich dir ja noch eine Rückmeldung.

Viele Grüße

Festus94
Mitglied: Festus94
Festus94 12.11.2021 um 07:43:12 Uhr
Goto Top
Hi @Dani,

ich habe inzwischen auch den DNS-Cache auf den ganzen DNS-Servern gelöscht. Danach habe ich den Client-Cache auf meiner Maschine gelöscht. Der Fehler ist noch immer da. face-sad

Viele Grüße
Mitglied: Festus94
Festus94 21.11.2021 um 18:53:06 Uhr
Goto Top
Hi @Dani,

seit ein paar Tagen funktioniert der betroffene Account wieder. Änderungen sind mir wieder nicht bekannt, und laut Logging auch nicht gemacht worden. Ist sehr seltsam, aber ich werde wohl nicht mehr dahinter kommen.

Danke noch mal für deine Unterstützung.

Viele Grüße

Festus94