Kerberos Fehler wenn Client im VPN

[Reingucker 3]

 

@ Reingucker

 

Der RADIUS VPN-AD-USER wurde für die Anmeldung an der Domäne verwendet, auch wenn sich bereits ein AD Benutzer authentifiziert hat.

Ich habe dann mit KLIST nachgeschaut und habe auch Tickets beider User (VPN-AD-USER + AD-USER) gesehen.

 

Wenn ich auf die Domäne zugreife (GPO's / Netlogon) wird dieser VPN-AD-USER verwendet, da sehe ich TGT's für KRB und einige der DC's für den CIFS Dienst.

Wenn ich nun auf Fileserver oder andere Dienste (Printserver, Freigaben vom DC usw.) zugreife wird ein TGT für den Angemeldeten AD-USER verwendet bzw. angefordert.

 

Wa?

 

Ich habe exakt das gleiche Experiment durchgeführt. Ein AD-User meldet sich auf dem Client am AD an und stellt dann unter einem anderen AD-User eine VPN-Verbindung mit authentifizierung an der Dom her. Und ich bekam bei klist eben NICHT die Tickets des VPN-AD-Users sondern nur die Tickets des welcher sich an dem Client angemeldet hat. Mein VPN-User habe ich auf Freigaben in der Dom zugreifen lassen (mal Vollzugriff/mal ändern/mal lesen/mal kein Zugriff). Und selbst wenn sich der VPN-AD-User auf die Freigabe drauf kam oder auch nicht, so sah ich im log immer welcher User es war. Und trotzdem bekam er kein Ticket. Konnte aber auf die Freigabe zugreifen wenn zugriff erlaubt.

 

Mach doch mal die Überwachung rein und schau welcher User da auf die Freigabe zugreift. Es ist nicht der am Client angemeldete User. Es ist der VPN-User. Sollte eigentlich durch setzen der Zugriffsberechtigungen klar werden aber im log hast du es dann nochmal schriftlich. Und dafür bekommt der VPN-User kein Ticket.

 

Mit dem NETLOGON scheint es nochmal etwas anderes zu sein, wie du auch in deinem ersten Post festgestellt hast. Das habe ich nicht probiert.

[Beetlejuice 11]

Sehr kurios ...

 

Ich habe zuerst in die Security Logs geschaut und nach einem zugriff auf den Fileserver, wurde mit der AD-USER angezeigt. Vom VPN-AD-USER fehlt da jede spur.

 

Als 2. habe ich dann die Freigabe beschränkt dass einmal der AD-USER und einmal der VPN-AD-USER keine Berechtigung haben hier zuzugreifen.

Auch wenn der VPN-AD-USER keine Berechtigung hatte konnte ich drauf zugreifen. Aber als der AD-USER keine Berechtigung mehr hatte, konnte ich auch nicht auf die Freigabe zugreifen.

[Reingucker 3]

Hm. Ich hatte auf der Freigabe/ntfs den am Client angemeldeten AD-User als Vollzugriff und den VPN-AD-User als variablen Zugriff (von alles bis garnix). Und der Zugriff auf die Freigabe war dann immer von den Berechtigungen des VPN-AD-Users abhängig. Und der stand auch immer im log. Und wenn der am Client angemeldete AD-User überhaupt nicht in der Freigabe/ntfs eingetragen war, dann ging der VPN-AD-User trotzdem mit seinen entsprechenden Berechtigungen. Also ziemlich konträr zu deinen Erfahrungen.

 

Ok, heute komme ich nicht mehr dazu, aber ich werde morgen Abend das nochmal alles durchspielen und Video davon machen. Kann ja auch sein dass ich irgendwas falsch eingestellt habe. Wüsste aber nicht was, zumal ja auch das VPN ect. gar nicht gehen würde wenn ich da etwas falsch gemacht hätte.

[Beetlejuice 11]

Hast du das VPN mit NAP oder ohne gemacht?

[Reingucker 3]

Ohne NAP. Also einfach nur RAS-Radius-SSTP-VPN-NPS.

[Reingucker 3]

So, ich hab das jetzt doch schon gestern Abend nochmal durchgespielt.Hab mir von der Heise Seite einen Bildschirmaufzeichner geholt und hab das Video aufgenommen. Alles schick. Dann hab ich es auf  Youtube hochgeladen (70 minuten), dann wurde es bearbeitet (10 min), und dann kam die Meldung dass das Format nicht unterstützt wird. Tja, es wurde im avi+ Format aufgezeichnet. Ok. Hab ich es in wmv convertiert (35 min) und dann dieses hochgeladen (70 min) und dann wurde es bearbeitet und es plöpte die Meldung "Film zu lang, veröffentlichung abgelehnt" auf. Hä? 23 Minuten Film zu lang? Tja, und da hab ich jetzt keinen Bock mehr auf youtube. Ich habe es auf eine Webseite von mir gestellt und wer es sich anschauen möchte kann es ja runter laden. Und wer nicht, der nicht. Ist mir schnurz jetzt.

 

www.linuzdreck.de/0002.wmv

[Beetlejuice 11]

Moin,

 

vielen dank für Deine Bemühungen. Es ist schade, dass es mit youtube nicht so funktioniert hat, aber ich habe mir das Video auch so angeschaut ;).

 

Aufgefallen ist mir, dass Du eine Verbindung zur Freigabe explizit mit einem anderem User aufbaust.

 

Ich habe die Freigabe immer direkt im Explorer eingegeben, somit wird die Sitzung des angemeldeten AD-USERs verwendet.

 

 

 

Deine Vorgehensweise werden ich ebenfalls nochmal nachstellen.

 

Danke und cu

[Reingucker 3]

Moin,

 

ich habe sowohl ohne Userangabe auf die Freigabe zugegriffen als auch mit Userangabe. Ohne Userangabe wird ja der am Rechner angemeldete User, in diesem Fall User1, dazu benutzt die Verbindung herzustellen. Das sieht man dann ja in den Logs wo überall User1 drin steht.

 

Ich stelle es auch gleich nochmal so nach wie du beschrieben hast. Wird ein kleinerer Video und dürfte damit auf youtube rauf kommen. Btw, es sind 20 min Maxgröße für Film bei youtube. War früher nicht. Daher sind auch die neusten Kinofilme dort in viele 20 min Teile zerlegt.

[Beetlejuice 11]

Hi, dann passt das ja zu unseren beiden Beobachtungen.

 

es ist aber irgendwie nicht schön 2 verschieden AD Benutzer zu haben.

 

Für die Freigaben wird dann primär der AD-USER verwendet, es sei denn du gibst explizit einen anderen User an. Dies muss ja nicht der VPN-USER sein, sondern kann jeder x-beliebige AD USER sein.

 

Der Zugriff auf den Domain-Stamm (dev.domain.de), um sich am Anmeldeserver zu registrieren oder GPOs zu beziehen, dafür wird dann ausschließlich der VPN-AD-USER verwendet.

Das ist natürlich doof, da die GPO's und auch an dem VPN-AD-USER hängen müssen und das ist finde ich eine weitere Schwachstelle, die bei weiteren Konfiguration vom Admin übersehen werden könnte.

 

cu

[Reingucker 3]

Der AD-User wird zwar primär für die Freigabe verwendet - er kommt aber nicht über das VPN. Das sieht man im vid wenn ich auch den AD-User User1 explizit als Anmeldung für den Zugriff auf die Freigabe angebe: Obwohl er Zugriffsrechte hat kommt er nicht drauf! 

 

Also ist der lokale AD-User für Zugriffe über die VPN-Verbindung keine Gefahr.

 

Einzige Ausnahme sind das NETLOGON wie ich in meinem Film gezeigt habe. Da kommt der AD-User mit Hilfe des Computerkontos, dem VPN-Client an dem er angemeldet ist, drauf. Ist schön zu sehen finde ich. 

 

 

Der Zugriff auf den Domain-Stamm (dev.domain.de), um sich am Anmeldeserver zu registrieren oder GPOs zu beziehen, dafür wird dann ausschließlich der VPN-AD-USER verwendet.

Das ist natürlich doof, da die GPO's und auch an dem VPN-AD-USER hängen müssen und das ist finde ich eine weitere Schwachstelle, die bei weiteren Konfiguration vom Admin übersehen werden könnte.

 

cu

 

Ja, das sollte man wissen. Ich teste das gleiche Szenario in den nächsten Tagen auch mit DirectAccess. Da dürfte das Problem dann nicht mehr auftauchen.