Zum Inhalt wechseln


Foto

Kerberos Fehler wenn Client im VPN

Active Directory ISA / TMG / UAG Windows 7

  • Bitte melde dich an um zu Antworten
69 Antworten in diesem Thema

#1 Beetlejuice

Beetlejuice

    Member

  • 194 Beiträge

 

Geschrieben 30. Januar 2015 - 16:34

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

 


-----------------------------
Bunt ist das Leben und
Granatenstark !!! :cool:
-----------------------------

#2 daabm

daabm

    Expert Member

  • 2.111 Beiträge

 

Geschrieben 31. Januar 2015 - 08:49

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.

Greetings/Grüße, Martin

Mal ein gutes Buch über GPOs lesen? Oder ein kleines, aber feines Blog darüber?

Und wenn mir die IT mal auf die Nerven geht - coke bottle design refreshment (-:


#3 Beetlejuice

Beetlejuice

    Member

  • 194 Beiträge

 

Geschrieben 31. Januar 2015 - 11:35

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.
-----------------------------
Bunt ist das Leben und
Granatenstark !!! :cool:
-----------------------------

#4 daabm

daabm

    Expert Member

  • 2.111 Beiträge

 

Geschrieben 31. Januar 2015 - 15:25

Mach's trotzdem :)


Greetings/Grüße, Martin

Mal ein gutes Buch über GPOs lesen? Oder ein kleines, aber feines Blog darüber?

Und wenn mir die IT mal auf die Nerven geht - coke bottle design refreshment (-:


#5 Beetlejuice

Beetlejuice

    Member

  • 194 Beiträge

 

Geschrieben 02. Februar 2015 - 12:38

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


-----------------------------
Bunt ist das Leben und
Granatenstark !!! :cool:
-----------------------------

#6 daabm

daabm

    Expert Member

  • 2.111 Beiträge

 

Geschrieben 02. Februar 2015 - 19:04

"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.micr...y/cc772815.aspx

Oder sollte ganz trivial die Uhrzeit nicht mehr stimmen?

Greetings/Grüße, Martin

Mal ein gutes Buch über GPOs lesen? Oder ein kleines, aber feines Blog darüber?

Und wenn mir die IT mal auf die Nerven geht - coke bottle design refreshment (-:


#7 Beetlejuice

Beetlejuice

    Member

  • 194 Beiträge

 

Geschrieben 03. Februar 2015 - 08:19

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


-----------------------------
Bunt ist das Leben und
Granatenstark !!! :cool:
-----------------------------

#8 Reingucker

Reingucker

    Senior Member

  • 397 Beiträge

 

Geschrieben 03. Februar 2015 - 11:05

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?



#9 Beetlejuice

Beetlejuice

    Member

  • 194 Beiträge

 

Geschrieben 03. Februar 2015 - 11:14

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.)


-----------------------------
Bunt ist das Leben und
Granatenstark !!! :cool:
-----------------------------

#10 Reingucker

Reingucker

    Senior Member

  • 397 Beiträge

 

Geschrieben 03. Februar 2015 - 11:37

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?



#11 Beetlejuice

Beetlejuice

    Member

  • 194 Beiträge

 

Geschrieben 03. Februar 2015 - 11:49

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.


-----------------------------
Bunt ist das Leben und
Granatenstark !!! :cool:
-----------------------------

#12 Reingucker

Reingucker

    Senior Member

  • 397 Beiträge

 

Geschrieben 03. Februar 2015 - 11:57

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, 03. Februar 2015 - 12:33.


#13 Beetlejuice

Beetlejuice

    Member

  • 194 Beiträge

 

Geschrieben 03. Februar 2015 - 13:23

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.


-----------------------------
Bunt ist das Leben und
Granatenstark !!! :cool:
-----------------------------

#14 Reingucker

Reingucker

    Senior Member

  • 397 Beiträge

 

Geschrieben 03. Februar 2015 - 13:49

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, 03. Februar 2015 - 14:02.


#15 Beetlejuice

Beetlejuice

    Member

  • 194 Beiträge

 

Geschrieben 03. Februar 2015 - 14:29

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


-----------------------------
Bunt ist das Leben und
Granatenstark !!! :cool:
-----------------------------