15
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:
Fehler: "Get-ADUser : A call to SSPI failed, see inner exception."
In der Inner Exception steht leider nichts anderes drin.
Ich kenne nur diesen einen Account, der betroffen ist. Was ich bereits herausgefunden habe:
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
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.
- 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.
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1476579339
Url: https://administrator.de/contentid/1476579339
Ausgedruckt am: 21.11.2024 um 23:11 Uhr
15 Kommentare
Neuester Kommentar
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
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
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. 🙂
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. 🙂
Moin,
Ich gehe davon aus, dass du die Basics eines ADDS bereits geprüft hast:
Gruß,
Dani
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.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
Hi @Dani,
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.
Klar, sonst wär's ja witzlos.
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.
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
Get-ADUser -Identity "Username" -Server "DC.Domain.tld" Ahh, mir fehlte das Format-Table am Ende. Hider die InnerException:
System.ServiceModel.Security.SecurityNegotiationException: A call to SSPI failed, see inner
exception. ---> System.Security.Authentication.AuthenticationException: A call to SSPI failed, see
inner exception. ---> System.ComponentModel.Win32Exception: The system cannot contact a domain
controller to service the authentication request. Please try again later
--- End of inner exception stack trace ---
at System.Net.Security.NegoState.StartSendAuthResetSignal(LazyAsyncResult lazyResult, Byte
message, Exception exception)
at System.Net.Security.NegoState.StartSendBlob(Byte message, LazyAsyncResult lazyResult)
at System.Net.Security.NegoState.ProcessAuthentication(LazyAsyncResult lazyResult)
at System.Net.Security.NegotiateStream.AuthenticateAsClient(NetworkCredential credential, String
targetName, ProtectionLevel requiredProtectionLevel, TokenImpersonationLevel
allowedImpersonationLevel)
at System.ServiceModel.Channels.WindowsStreamSecurityUpgradeProvider.WindowsStreamSecurityUpgradeIn
itiator.OnInitiateUpgrade(Stream stream, SecurityMessageProperty& remoteSecurity)
--- End of inner exception stack trace ---
Server stack trace:
at System.ServiceModel.Channels.WindowsStreamSecurityUpgradeProvider.WindowsStreamSecurityUpgradeIn
itiator.OnInitiateUpgrade(Stream stream, SecurityMessageProperty& remoteSecurity)
at System.ServiceModel.Channels.StreamSecurityUpgradeInitiatorBase.InitiateUpgrade(Stream stream)
at System.ServiceModel.Channels.ConnectionUpgradeHelper.InitiateUpgrade(StreamUpgradeInitiator
upgradeInitiator, IConnection& connection, ClientFramingDecoder decoder,
IDefaultCommunicationTimeouts defaultTimeouts, TimeoutHelper& timeoutHelper)
at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.SendPreamble(IConnection
connection, ArraySegment`1 preamble, TimeoutHelper& timeoutHelper)
at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.DuplexConnectionPoolHelper.Accept
PooledConnection(IConnection connection, TimeoutHelper& timeoutHelper)
at System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection(TimeSpan timeout)
at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.CallOpenOnce.System.ServiceModel.Channels.ServiceCha
nnel.ICallOnce.Call(ServiceChannel channel, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce(TimeSpan timeout,
CallOnceManager cascade)
at System.ServiceModel.Channels.ServiceChannel.EnsureOpened(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway,
ProxyOperationRuntime operation, Object ins, Object outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall,
ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at :
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Microsoft.ActiveDirectory.WebServices.Proxy.Resource.Get(Message request)
at Microsoft.ActiveDirectory.Management.AdwsConnection.SearchAnObject(ADSearchRequest request)Sieht mir nach derselben Meldung aus, die ich auch beim Zugriffsversuch auf das SYSVOL Share bekomme (Zeilen drei bis vier). Immerhin einheitlich.
Klar, sonst wär's ja witzlos.
Zitat von @Dani:
Ich gehe davon aus, dass du die Basics eines ADDS bereits geprüft hast:
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.
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
Moin,
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.
Gruß,
Dani
Klar, sonst wär's ja witzlos. 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)? face-winkSystem.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
Die gute Nachricht ist, dass ich die Fehlermeldung in unserer KB gefunden habe. Die schlechte ist, dass die Fehlermeldung verschiedene Ursache haben kann. face-smileFall 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
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.
Viele Grüße
Festus94
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.
Viele Grüße
Festus94
Moin,
Ansonsten deaktivere für das System einmal die Proxykonfiguration bzw. vergleiche dies, mit dem Benutzerkonto wo der Zugriff nach wie vor funktioniert.
In wie weit bist du in klist (z.B. klist get host/%computername%) eingetaucht?
Gruß,
Dani
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. 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
Hi @Dani.
Ja, der Benutzer ist Mitglied der Gruppe Domain Users.
Die Proxykonfiguration ist identisch zu anderen Benutzern, das habe ich gerade noch mal verglichen.
Ich werde später mal den Cache auf den DNS-Servern leeren und es noch mal testen. Tut ja nicht weh.
Das ist ja ein Traum. Davon sind wir noch ein ganzes Stück entfernt.
Da wird es immer Unterschiede geben. Od hast du etwas Spezifisches im Sinn?
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
Ja, der Benutzer ist Mitglied der Gruppe Domain Users.
Zitat von @Dani:
Puh, gute Frage. Ich bin schon länger nicht operativ unterwegs. Ansonsten deaktivere für das System einmal die Proxykonfiguration bzw. vergleiche dies, mit dem Benutzerkonto wo der Zugriff nach wie vor funktioniert.
Puh, gute Frage. Ich bin schon länger nicht operativ unterwegs.
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.
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...
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.
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?
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?
Nur sehr oberflächlich. Wenn ich explizit Server (zum Beispiel die DCs) angebe, bekomme ich Tickets zurück, darunter ein Ticket zum angegebenen Server.
#3> Client: User @ DOMAIN.TLD
Server: host/DC @ DOMAIN.TLD
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
Start Time: 11/8/2021 11:21:25 (local)
End Time: 11/8/2021 21:21:25 (local)
Renew Time: 11/15/2021 11:06:12 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: DC.DOMAIN.TLDWenn 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.
Current LogonId is 0:0x8a72f947
Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x6fb
klist failed with 0xc000018b/-1073741429Der SPN auf dem Computerkonto ist aber gesetzt.
Viele Grüße
Festus94
Moin,
Unabhängig davon bitte mal folgenden Befehl ausführen:
Gruß,
Dani
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 KerberosUnabhängig davon bitte mal folgenden Befehl ausführen:
Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))} Gruß,
Dani
Moin @Dani,
stimmt, aber das Ganze ist so seltsam...
Den Link werde ich mir später mal ansehen.
Das Kommando wirkt sich nur auf meinen User aus, richtig?
Danke dir.
stimmt, aber das Ganze ist so seltsam...
Den Link werde ich mir später mal ansehen.
Das Kommando wirkt sich nur auf meinen User aus, richtig?
Danke dir.
Moin,
Gruß,
Dani
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
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.
Ich melde mich. Danke dir.
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.
Ich melde mich. Danke dir.
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
nach dem Löschen der Kerberos-Tickets bleibt der Fehler bestehen. Es wird aber sauber ein neues Service Ticket für LDAP bezogen:
#2> Client: User @ DOMAIN.TLD
Server: ldap/Server @ DOMAIN.TLD
KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96
Ticketkennzeichen 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
Startzeit: 11/9/2021 18:48:52 (lokal)
Endzeit: 11/10/2021 4:48:39 (lokal)
Erneuerungszeit: 11/16/2021 18:48:39 (lokal)
Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96
Cachekennzeichen: 0
KDC aufgerufen: DC.DOMAIN.TLDIch 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
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.
Viele Grüße
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.
Viele Grüße
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
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
