Beetlejuice 11 Geschrieben 30. Januar 2015 Melden Teilen Geschrieben 30. Januar 2015 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 Zitieren Link zu diesem Kommentar
daabm 1.334 Geschrieben 31. Januar 2015 Melden Teilen Geschrieben 31. Januar 2015 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. Zitieren Link zu diesem Kommentar
Beetlejuice 11 Geschrieben 31. Januar 2015 Autor Melden Teilen Geschrieben 31. Januar 2015 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. Zitieren Link zu diesem Kommentar
daabm 1.334 Geschrieben 31. Januar 2015 Melden Teilen Geschrieben 31. Januar 2015 Mach's trotzdem :) Zitieren Link zu diesem Kommentar
Beetlejuice 11 Geschrieben 2. Februar 2015 Autor Melden Teilen Geschrieben 2. Februar 2015 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 Zitieren Link zu diesem Kommentar
daabm 1.334 Geschrieben 2. Februar 2015 Melden Teilen Geschrieben 2. Februar 2015 "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? Zitieren Link zu diesem Kommentar
Beetlejuice 11 Geschrieben 3. Februar 2015 Autor Melden Teilen Geschrieben 3. Februar 2015 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 Zitieren Link zu diesem Kommentar
Reingucker 3 Geschrieben 3. Februar 2015 Melden Teilen Geschrieben 3. Februar 2015 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? Zitieren Link zu diesem Kommentar
Beetlejuice 11 Geschrieben 3. Februar 2015 Autor Melden Teilen Geschrieben 3. Februar 2015 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.) Zitieren Link zu diesem Kommentar
Reingucker 3 Geschrieben 3. Februar 2015 Melden Teilen Geschrieben 3. Februar 2015 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? Zitieren Link zu diesem Kommentar
Beetlejuice 11 Geschrieben 3. Februar 2015 Autor Melden Teilen Geschrieben 3. Februar 2015 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. Zitieren Link zu diesem Kommentar
Reingucker 3 Geschrieben 3. Februar 2015 Melden Teilen Geschrieben 3. Februar 2015 (bearbeitet) 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 Zitieren Link zu diesem Kommentar
Beetlejuice 11 Geschrieben 3. Februar 2015 Autor Melden Teilen Geschrieben 3. Februar 2015 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. Zitieren Link zu diesem Kommentar
Reingucker 3 Geschrieben 3. Februar 2015 Melden Teilen Geschrieben 3. Februar 2015 (bearbeitet) 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 Zitieren Link zu diesem Kommentar
Beetlejuice 11 Geschrieben 3. Februar 2015 Autor Melden Teilen Geschrieben 3. Februar 2015 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??? Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.