Jump to content

Kerberos Fehler wenn Client im VPN


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hi,

 

ich habe Probleme mit der Kerberos Authentifizierung sobald ein Client im VPN ist.

Fehler aus dem network Trace: KerberosV5:KRB_ERROR  - KDC_ERR_PREAUTH_FAILED (24)

 

Wir haben mehrere DCs, eine TMG die das Routing/Firewalling und VPN Gateway stellt und Clients die im internen Netz und im externen arbeiten.

Das interne Servernetz ist Subnetz 1 und die internen Clients liegen im Subnet 2.

Externe Clients wählen sich via VPN auf die TMG ein und sind im Subnet 3.

 

Bei den Internen Clients kann ich keine Fehler im Trace oder Log feststellen.

Sobald sich aber ein Client ins VPN einwählt, sehe ich om Trace immer wieder die beiden Fehlermeldungen:

 

KerberosV5:KRB_ERROR  - KDC_ERR_PREAUTH_REQUIRED (25)

KerberosV5:KRB_ERROR  - KDC_ERR_PREAUTH_FAILED (24)

 

Letztendlich bedeutet das, dass sich der Client nicht korrekt authentifiziert (PREAUTH_FAILED) und das daher immer wieder ein (PREAUTH_REQUIRED) vom DC an den Client gesendet wird.

In der Firewall bzw. in der TMG kann ich keine Fehler oder Denied Connections festellen.

 

Nun stehe ich was auf dem Schlauch woran das liegen könnte.

habt ihr da Ideen...?

 

cu

Beetlejuice

 

Link zu diesem Kommentar

Das passiert sehr häufig, wenn die Kerberos-Pakete größer als 1506 Byte und kleiner als 2048 Byte sind. Kerberos verwendet bis 2048 Byte UDP, und ab 1507 Byte werden daraus zwei Pakete. Die kommen über VPN gerne "out of order" am DC an, der dann nix damit anfangen kann. Zwinge Kerberos, immer TCP zu verwenden, und Du solltest Ruhe haben.

Link zu diesem Kommentar

Moin,
 
ich habe das mal umgestellt, was aber leider nicht zum Erfolg führte.
 
Ich habe das ganze auch nochmal versucht genauer zu verstehen und mir dazu den Networktrace angeschaut.

742	11:32:59 02.02.2015	8.6452551		192.168.248.55	WIN10002.dev.domain.de	KerberosV5	KerberosV5:AS Request Cname: hans.wurst Realm: dev.domain.de Sname: krbtgt/dev.domain.de 	{TCP:166, IPv4:816}
743	11:32:59 02.02.2015	8.6459572		WIN10002.dev.domain.de	192.168.248.55	KerberosV5	KerberosV5:KRB_ERROR  - KDC_ERR_PREAUTH_REQUIRED (25)	{TCP:166, IPv4:816}
787	11:33:00 02.02.2015	9.0950799		192.168.248.55	WIN10002.dev.domain.de	KerberosV5	KerberosV5:AS Request Cname: hans.wurst Realm: dev.domain.de Sname: krbtgt/dev.domain.de 	{TCP:172, IPv4:816}
788	11:33:00 02.02.2015	9.0970095		WIN10002.dev.domain.de	192.168.248.55	KerberosV5	KerberosV5:KRB_ERROR  - KDC_ERR_PREAUTH_FAILED (24)	{TCP:172, IPv4:816}

Hier können wir erkennen, dass der Benutzer Hans.Wurst aus dem VPN (192.168.248.x/24) versucht ein Ticket für die Domain "dev.domain.de" beim Primary KDC "krbtgt/dev.domain.de" anzufragen.
Dieses gelingt nicht und beim 2. mal gibt es einen Fehler mit "KDC_ERR_PREAUTH_FAILED".
 
 
Wenn nun der Benutzer Hans Wurst versucht, im selben VPN, eine Verbindung zum Fileserver, Druckserver aufzubauen, erhält er ein gültiges Ticket. Das gilt auch, wenn der Benutzer sich direkt alle Freigaben von einem DC z.b. WIn10002 anzeigen und zugreifen möchte. (\\win10002.dev.domain.de\netlogon).

4337	11:34:21 02.02.2015	90.6191223		192.168.248.55	WIN10002.dev.domain.de	KerberosV5	KerberosV5:TGS Request 	{TCP:1004, IPv4:816}
4340	11:34:21 02.02.2015	90.6208364		WIN10002.dev.domain.de	192.168.248.55	KerberosV5	KerberosV5:TGS Response Cname: hans.wurst 	{TCP:1004, IPv4:816}

In dem Response sieht man, für welchen Service das Ticket ausgestellt wurde.
>> Ticket: Realm: DEV.DOMAIN.DE, Sname: cifs/storage3.dev.domain.de
 
Auch auf dem Client kann ich mir  auch die ausgestellten Tickets anzeigen lassen. Auch nach löschen (klist purge), werden diese erneut ausgestellt.
>> klist

#0>     Client: hans.wurst @ DEV.DOMAIN.DE
        Server: krbtgt/DEV.DOMAIN.DE @ DEV.DOMAIN.DE
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
        Start Time: 2/2/2015 12:06:06 (local)
        End Time:   2/2/2015 22:06:06 (local)
        Renew Time: 2/9/2015 12:06:06 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96


#1>     Client: hans.wurst @ DEV.DOMAIN.DE
        Server: cifs/fileserver.DEV.DOMAIN.DE @ DEV.DOMAIN.DE
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
        Start Time: 2/2/2015 12:55:47 (local)
        End Time:   2/2/2015 22:06:06 (local)
        Renew Time: 2/9/2015 12:06:06 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96


#2>     Client: hans.wurst @ DEV.DOMAIN.DE
        Server: ldap/WIN10002.DEV.DOMAIN.DE/DEV.DOMAIN.DE @ MEMBER.OSTHU
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_del
        Start Time: 2/2/2015 12:22:40 (local)
        End Time:   2/2/2015 22:06:06 (local)
        Renew Time: 2/9/2015 12:06:06 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96


#3>     Client: hans.wurst @ DEV.DOMAIN.DE
        Server: host/0200l.DEV.DOMAIN.DE @ DEV.DOMAIN.DE
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
        Start Time: 2/2/2015 12:06:06 (local)
        End Time:   2/2/2015 22:06:06 (local)
        Renew Time: 2/9/2015 12:06:06 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96

 
Wenn ich aber versuche GPOs upzudaten, oder auf den NETLOGON/SYSVOL Ordner vom Domainstamm gehen möchte (dev.domain.de), erhalte ich eine Fehlermeldung (oder werde zum erneuten Anmelden aufgefordert ;  NTLM) und sehe die oben beschriebenen Kerberos Anmeldeversuche.
 
Ein weiteren Hinweis liefert mir das Tool "nltest".

nltest /sc_verify:dev.doamin.de
Fehler bei I_NetLogonControl: Status = 5 0x5 ERROR_ACCESS_DENIED

Ich hoffe es halbwegs Übersichtlich erklärt zu haben, falls doch fragen sind helfe ich gerne weiter.

 

ich hoffe auch dass Ihr mir bei diesem Problem weiterhelfen könnt.

 

Viele Grüße

Link zu diesem Kommentar

"Dieses gelingt nicht und beim 2. mal gibt es einen Fehler mit "KDC_ERR_PREAUTH_FAILED"."

 

Nein, nicht beim 2. Mal - sondern beim ersten Mal. Sind die KDC-Kennwörter synchron? Typischerweise heißt das nämlich "falsches Kennwort"... Und das kann das Userkennwort sein, aber auch das krbtgt-Kennwort. Wobei es dann auch im LAN passieren müßte - wenn Ihr nicht einen DC habt, der aufgrund der Site-Konfig nur bei VPN-Logons verwendet wird?!? Fragen über Fragen...

 

Zum Lesen, was es mit PREAUTH_REQUIRED und PREAUTH_FAILED auf sich hat:

https://technet.microsoft.com/library/cc772815.aspx

 

Oder sollte ganz trivial die Uhrzeit nicht mehr stimmen?

Link zu diesem Kommentar

Hi,

 

ob beim 1. oder 2. mal kann ich nicht genau sagen, ich habe nur mehere Versuche gesehen und dann gab es den Kerberos Fehler "KDC_ERR_PREAUTH_FAILED".

 

Im LAN besteht das Problem nicht und wir verwenden 3 DC in einer Site, wo auch das VPN zugehört.

 

- Das Userkennwort ist nicht abgelaufen.

- Die Uhrzeit ist auch korrekt.

 

- Was meinst du mit dem krbtgt Kennwort? Wie kann ich das abfragen/prüfen?

 

Wenn weitere Fragen sind, gerne :).

 

cu

Link zu diesem Kommentar

Soweit richtig, der Benutzer meldet sich auch nicht erneut an der domäne an.

 

Sofern der User kein gültiges Ticket hat, fragt er beim nächsten DC mit seinen Anmeldedaten an (aus der aktuellen Anmeldung).

Da diese Anmeldedaten korrekt sind und auch das PW, etc. gültig ist, sollte das kein Problem darstellen.

 

Wenn ich von subnetz zu Subnetz springe, melde ich mich ja auch nicht erneut an, sondern frage beim KDC nach einem Ticket mit meinen bisherigen Anmeldedaten, sofern mein Ticket noch nicht ausgelaufen oder ungültig ist.

Link zu diesem Kommentar

Er benutzt also die temporären anmeldedaten auf seinem Client dafür? Der PC war ja nicht im AD oder in erreichbarer Nähe eines DC als der User sich auf dem Client angemeldet hat. Also bekam er doch die temporäre Anmeldung mit der letzten abgelegten Domainanmeldung. Und angemeldet hat er sich mit PPP an der TMG nur für die Verbindung. Es müsste also irgendeinen Befehl geben der die temporäre Anmeldung am Dom-Client in eine richtige Anmeldung an der Dom umwandelt. Oder gibt es da einen automatismus?  

 

 

Edit:

 

Hm, ne, stimmt. Sobald auf eine Resource zugegriffen wird wirds abgeglichen.

bearbeitet von Reingucker
Link zu diesem Kommentar

Soweit ich das beim Durchlesen all dieser Seiten verstanden habe ist die Anmeldung am TMG nur für die Verbindung - außer der TMG ist so konfiguriert dass er an die Dom weiter reicht. Aber dann müsste er selbst in der Dom sein.

 

Edit:

 

Als Standalone gibts die Auswahl anscheinend auch gar nicht um die Anmeldung an die Dom weiter zu leiten. Und wenn er selbst in der Dom ist brauchs noch eine Zertifikatsstelle in der Dom weil dann auf dem TMG anscheinend nur noch Zertifikate aus der Dom gehen. Hm, was man halt so liest. Obs stimmt...k.a..

bearbeitet von Reingucker
Link zu diesem Kommentar

Ich habe mal folgendes probiert und bin ein wenig vom Ergebnis überrascht.

 

- Einen neuen User für das VPN auf der TMG angelegt "test"

- Mich als Benutzer hans.wurst angemeldet.

- Die VPN Verbindung mit dem Benutzer "test" eingerichtet und verbunden

 

Im Netzwerktrace kann ich nun sehen, dass ein Ticket mit dem Namen "test" und nicht mit hans.wurst angefordert wird.

7303	15:22:20 03.02.2015	99.9293153		192.168.248.55	WIN10002.dev.domain.de	KerberosV5	KerberosV5:AS Request Cname: test Realm: dev.domain.de Sname: krbtgt/dev.domain.de 	{TCP:1742, IPv4:326}
7304	15:22:20 03.02.2015	99.9296332		WIN10002.dev.domain.de	192.168.248.55	KerberosV5	KerberosV5:KRB_ERROR  - KDC_ERR_C_PRINCIPAL_UNKNOWN (6)	{TCP:1742, IPv4:326}

Warum und was nun???

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...