phatair 38 Geschrieben 26. Juni Melden Teilen Geschrieben 26. Juni Hallo zusammen, Wir haben ein kleines Problem bei unserem vpn login. Wir nutzen forticlient für den ssl vpn. Die Verbindung wird mit bzw vor der Windows Anmeldung ausgeführt. Soweit funktioniert das auch gut. Nur ist uns jetzt aufgefallen, dass neue Gruppenmitgliedschaften nicht übernommen werden. Dies passiert nur, wenn der Client direkt im LAN ist. Sieht also wie folgt aus. User ist im vpn oder offline. Wir fügen den User in eine neue ad Gruppe hinzu. User baut neue vpn Verbindung auf bzw meldet sich bei bestehender Verbindung ab und meldet sich neu an Windows an und baut dabei auch die vpn Verbindung neu auf. Whomai /groups zeigt weiterhin die Gruppe nicht an. Meldet sich der User an einem Client im LAN neu an, wird die Gruppe gleich übernommen. Ich vermute, dass irgendwie zwischengespeicherte Infos verwendet werden. Wenn der User im vpn dann den Bildschirm sperrt, entsperrt und dann neu anmeldet, wird die Gruppe auch übernommen ( wird von ms im unten genannten link als workaround genannt). Bin mit dem Fortinet Support noch drüber das zu analysieren. Aber aktuell sagen die, es liegt an unseren clients. Kann man beim login irgendwie forcieren, dass die Gruppen neu ausgelesen werden und nicht zwischengespeicherte Infos verwendet werden? Ich hatte folgenden ms Artikel gefunden https://learn.microsoft.com/en-us/troubleshoot/windows-client/group-policy/group-membership-changes-not-updating-over-some-vpn-connections Dieser beschreibt genau unsere Problem, aber wir bauen schon die von connection mit der Windows Anmeldung auf. Würde es vielleicht schon ausreichen ein klist purge beim vpn login mitzugeben, damit die Gruppen neu eingelesen werden? Für Ideen wäre ich sehr dankbar. Liebe Grüße Zitieren Link zu diesem Kommentar
daabm 1.292 Geschrieben 26. Juni Melden Teilen Geschrieben 26. Juni "mit der Windows-Anmeldung" ist zweideutig... "VORHER" wäre wichtig. Also bevor die Logon-Session aufgebaut wird. klist dürfte da nicht helfen, da cached Creds (noch) kein Kerberos machen. Zitieren Link zu diesem Kommentar
phatair 38 Geschrieben 26. Juni Autor Melden Teilen Geschrieben 26. Juni Hi Martin, da war ich dann etwas ungenau - stimmt. Die Anmeldung am SSL VPN findet vor der Windows Anmeldung statt. Wir wählen im Login Screen die "Anmeldeoptionen" aus und dort gibt es den FortiClient zur Auswahl. Die User melden sich mit ihren AD Login, es wird die SSL VPN Verbindung aufgebaut und es erfolgt die Abfrage vom 2Faktor. Erst danach wird die Windows Anmeldung durchgeführt. Mir ist daher schleierhaft warum die Gruppenmitgliedschaft nicht aktualisiert wird. Auch verwenden wir bei den VPN Sessions keine anderen GPOs. Alles identisch zum LAN. Einzig beim VPN Login wird als Post Action ein "gpupdate" durchgeführt. Aber das dürfte ja kein Problem darstellen, oder doch? Wenn ich dann eben den Bildschirm mit STRG+L sperre, wieder entsperre, danach mich von Windows abmelde und neu inkl. VPN anmelde, ist die Gruppe auch aktualisiert. Bin etwas ratlos an was das liegen könnte. Gibt es irgendwelche Einstellungen in Windows die so ein Verhalten erklären könnten? Zitieren Link zu diesem Kommentar
NilsK 2.884 Geschrieben 26. Juni Melden Teilen Geschrieben 26. Juni Moin, Für mich klingt das aber, als fände in dem Fall eben keine neue Anmeldung statt, denn dann müsste man ja auch kein gpupdate ausdrücklich ausführen. Anscheinend findet doch nur eine Anmeldung mit Cached Credentials statt. Gruß, Nils Zitieren Link zu diesem Kommentar
phatair 38 Geschrieben 26. Juni Autor Melden Teilen Geschrieben 26. Juni (bearbeitet) Hi Nils das ist bzw. war auch meine Vermutung und das versuche ich gerade mit dem Support rauszufinden. Allerdings bin ich jetzt doch noch mehr verwirrt. Bei den letzten 2 Tests hat es jetzt plötzlich funktioniert. Neue AD Gruppe erstellt. Meinen User hinzugefügt Von Windows abgemeldet und Anmeldung inkl SSL VPN whoami /groups hat jetzt dann die neue Gruppe angezeigt puh....gibt es irgendeine Einstellung mit der definiert wird, wie lange die Verbindung zum DC dauern darf bis eine zwischengespeicherte Anmeldung verwendet wird? Meine Vermutung ist, dass vielleicht manchmal die Connection einfach etwas zu langsam ist und der Client (trotz bestehender DC Verbindung) meint er ist offline. Gruß, Steffen Edit: Ein kurzer Nachtrag. bei dem command whoami /groups werden Gruppen unterschiedlich dargestellt einige Gruppen sind als "Typ" Gruppe angegeben und einige als "Alias" und werden bei den Gruppen als "Lokale Gruppe" angezeigt. So z.B. auch meine Test Gruppe die dem User schon längst entzogen wurde. Aber auch andere Domänen Gruppen werden als "Alias" und "Lokale Gruppe" angezeigt. Andere Domain Gruppen werden eben als "Gruppe" und ohne "Lokale Gruppe" angezeigt. Ist das normal bzw. was ist hier der Unterschied? Heißt das Attribut "Lokale Gruppe" wirklich, dass der Client diese Gruppen als lokale Gruppe ansieht und nicht als AD Gruppe? Zitat Gruppenname Typ SID Attribute ======================================================== =============== Domain\xal Gruppe S-1-5-21-602162358-..... Verbindliche Gruppe, Standardmäßig aktiviert, Aktivierte Gruppe Domain\test5 Alias S-1-5-21-602162358-..... Verbindliche Gruppe, Standardmäßig aktiviert, Aktivierte Gruppe, Lokale Gruppe bearbeitet 26. Juni von phatair Zitieren Link zu diesem Kommentar
daabm 1.292 Geschrieben 26. Juni Melden Teilen Geschrieben 26. Juni Das mit den Gruppen bei whoami ist blödsinnig umgesetzt Es gibt in der Tat eine Zeit die man nach dem Herstellen der VPN-Verbindung warten muß, bis der Rechner die RootDSE-Verbindung gefunden hat. Ohne die ist es ein Cached Logon, der User merkt davon nichts. Sind so roundabout 10 bis 30 Sekunden. In Skripts kann man das abfangen durch ne Schleife, beim interaktiven Logon fällt mir dazu leider auch nichts ein - wir haben das gleiche Problem. Und wir schieben deshalb auch nen gpupdate hinterher... 😂 1 Zitieren Link zu diesem Kommentar
testperson 1.618 Geschrieben 27. Juni Melden Teilen Geschrieben 27. Juni Hi, kannst du evtl. auf "Always VPN" (About Always On VPN for Windows Server Remote Access | Microsoft Learn) wechseln und vor der Anmeldung automatisch einen Device Tunnel aufbauen? Gruß Jan Zitieren Link zu diesem Kommentar
phatair 38 Geschrieben 28. Juni Autor Melden Teilen Geschrieben 28. Juni Danke für den Tipps und Hilfestellungen. Wir beobachten das Verhalten jetzt erstmal weiter. Möglicherweise ist es wirklich nur das Verhalten bzw. die Trägheit von whoami /groups. Zitieren Link zu diesem Kommentar
daabm 1.292 Geschrieben 28. Juni Melden Teilen Geschrieben 28. Juni Ich kann bestätigen, daß es das nicht ist. Wenn Du eine VPN-Verbindung herstellst und Dich dann sofort anmeldest, ist die RootDSE noch nicht da und Du machst eine Offline-Anmeldung mit allen bekannten Nebenwirkungen. Zitieren Link zu diesem Kommentar
NilsK 2.884 Geschrieben 28. Juni Melden Teilen Geschrieben 28. Juni Moin, whoami liest doch auch das Access Token aus, arbeitet also rein lokal, oder? Wo sollte dabei eine Verzögerung herkommen? Gruß, Nils Zitieren Link zu diesem Kommentar
phatair 38 Geschrieben 1. Juli Autor Melden Teilen Geschrieben 1. Juli Am 28.6.2024 um 18:05 schrieb daabm: Ich kann bestätigen, daß es das nicht ist. Wenn Du eine VPN-Verbindung herstellst und Dich dann sofort anmeldest, ist die RootDSE noch nicht da und Du machst eine Offline-Anmeldung mit allen bekannten Nebenwirkungen. Uff...jetzt stehe ich irgendwie auf dem Schlauch. Aber MS sagt ja extra, wenn Gruppenmitgliedschaften bei einer VPN Verbindung nicht aktualisiert werden, soll man die VPN Verbindung vor dem Login aufbauen. Das wäre, nach meinen Verständnis, ja bei uns gegeben, da der FortiClient erst die VPN Verbindung aufbaut und dann die Windows Anmeldung durchführt. Wenn ich dich jetzt aber richtig verstehe, ist aber auch in dieser Konstellation (da die Anmeldung zu schnell nach der VPN Verbindung hergestellt wird) der Fehler nicht wirklich gelöst. Man müsste somit erst eine VPN Verbindung aufbauen, kurz warten und dann die Windows Anmeldung durchführen, richtig? Wenn ich dich also richtig verstehe, gibt es keine wirklich Lösung für das Problem? Außer man sperrt den Bildschirm nach der Anmeldung, entsperrt den Bildschirm und meldet sich ab und wieder an. Das hatte bei uns zumindest geholfen. Zitieren Link zu diesem Kommentar
Beste Lösung daabm 1.292 Geschrieben 1. Juli Beste Lösung Melden Teilen Geschrieben 1. Juli Genau. Du darfst Dich erst anmelden, wenn Windows kapiert hat, daß eine Domäne verfügbar ist Und je nach Qualität und Art der Verbindung kann das auch mal ein paar Sekunden länger dauern. 1 Zitieren Link zu diesem Kommentar
phatair 38 Geschrieben 2. Juli Autor Melden Teilen Geschrieben 2. Juli Alles klar. Das heißt ein Großteil der VPN Lösungen ist davon betroffen, wenn die nicht bei der Anmeldung warten bis wirklich die VPN Verbindung steht und die DCs befragt werden können. Gut zu wissen. Ich werde beim Support mal nachfragen ob man hier irgendwie eine Verzögerung definieren kann. Danke für die Hilfe. Zitieren Link zu diesem Kommentar
cj_berlin 1.281 Geschrieben 2. Juli Melden Teilen Geschrieben 2. Juli (bearbeitet) Naja, es gibt ja die Policy "wait for network", nur traut man sich in VPN-Szenarien meistens nicht, sie zu aktivieren... Beste Lösung bisher: Clients raus aus dem AD, cloud-joined und Kerberos für den Zugriff auf on-prem Ressourcen einrichten... bearbeitet 2. Juli von cj_berlin 1 Zitieren Link zu diesem Kommentar
phatair 38 Geschrieben 2. Juli Autor Melden Teilen Geschrieben 2. Juli Die "Wait for network" GPO haben wir eigentlich auf allen Clients aktiviert und diese greift auch für VPN Clients https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.WindowsLogon::SyncForegroundPolicy Wir sprechen ja von dieser GPO, richtig? Cloud joined ist bei uns nicht möglich, wir sind nicht in der Azure/EntraID Welt und werden das auch zeitnah nicht sein. Ob das jetzt gut oder schlecht ist würde ich hier gerne nicht diskutieren 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.