Kerberos Fehler wenn Client im VPN

[Beetlejuice 11]

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

 

[daabm 1.366]

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.

[Beetlejuice 11]

Hi das habe ich gestern auch gelesen.

Wir verwenden aber schon TCP, auf der tmg sowie im Netzwerktrace vom DC sehe ich nur TCP Verbindungen.

[daabm 1.366]

Mach's trotzdem :)

[Beetlejuice 11]

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

[daabm 1.366]

"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?

[Beetlejuice 11]

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

[Reingucker 3]

Vielleicht off-topic; rein informativ für mich

 

Funktioniert der TMG hier als Kerberos-proxy und kann dann in die tickets reinschreiben was der client darf? Also der client wird durch den TMG authentifiziert und authorisiert und die authorisierung entspricht den Zugriffseinstellungen auf dem TMG?

[Beetlejuice 11]

Nein, die TMG ist ein "Standalone" Server ohne AD Anbindung. Dieser macht auch kein Kerberos-Proxy.

 

Einzig allein ein Web-Proxy für VPN über HTTPS ist eingerichtet (VPN SSTP.)

[Reingucker 3]

Das heißt der user auf dem remote client authentifiziert sich nur an der TMG und dümpelt dann im bereitgestellten VPN-Subnetz? Müsste sich dann der User nicht nochmal an der Domäne anmelden um auf überhaupt irgendwas im AD zugreifen zu können?

[Beetlejuice 11]

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.

[Reingucker 3]

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 3. Februar 2015 von Reingucker

[Beetlejuice 11]

Also, ich bin mir nicht ganz 100% sicher, aber die Anmeldung mit VPN, die ist doch unabhängig von der Windows Anmeldung oder?

 

Hintergrund, wir verwenden für die VPN  Verbindung lokale Benutzer (welche auf der TMG gepflegt werden). Diese haben aber den gleichen Namen wie die Domain Accounts.

[Reingucker 3]

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 3. Februar 2015 von Reingucker

[Beetlejuice 11]

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???