Ad Gruppenmitgliedschaft wird beim vpn login nicht aktualisiert

[phatair 39]

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

[daabm 1.348]

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

[phatair 39]

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?

[NilsK 2.930]

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

[phatair 39]

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

[daabm 1.348]

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

[testperson 1.674]

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

[phatair 39]

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.

 

[daabm 1.348]

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.

[NilsK 2.930]

Moin, 

 

whoami liest doch auch das Access Token aus, arbeitet also rein lokal, oder? Wo sollte dabei eine Verzögerung herkommen? 

 

Gruß, Nils

[phatair 39]

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.

 

[daabm 1.348]

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.

[phatair 39]

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.

[cj_berlin 1.306]

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

[phatair 39]

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