Laufwerkszuordnung in verschachtelten Gruppen

[cj_berlin 1.401]

Moin,

 

eine Lösung, die zumindest eine einheitliche Plattform (Batch) einsetzt, wäre

whoami /groups /fo csv | findstr <Gruppenname> > nul
if ERRORLEVEL 0 net use Z: \\server\SHARE

 

Eine Lösung, die gar keine Skriptsprache nutzt, habe ich bereits vorgeschlagen.

 

Ob es sich lohnt, sich mit dem API-Wrapper für PowerShell (und somit ja auch für VBS, ist ja alles P/Invoke) zu beschäftigen, muss ich noch bewerten.

bearbeitet 30. Oktober 2021 von cj_berlin

[testperson 1.758]

Hi,

 

in PowerShell sollte man hiermit

([System.Security.Principal.WindowsIdentity]::GetCurrent()).Groups

starten können.

 

Gruß

Jan

[daabm 1.386]

Kann man leider nicht...

1. Liefert nur SIDs zurück

2. Funktioniert nicht, wenn AppLocker läuft und es nicht als Admin läuft (Constrained Language Mode - danke MS...)

[cj_berlin 1.401]

vor 48 Minuten schrieb daabm:

Kann man leider nicht...

1. Liefert nur SIDs zurück

2. Funktioniert nicht, wenn AppLocker läuft und es nicht als Admin läuft (Constrained Language Mode - danke MS...)

1. wäre ja kein Hindernis, denn man kann im Skript auch gegen die SID der gewünschten Gruppe filtern, die ist ja schnell nachgeschaut. Und ohne Verbindung zur Domäne liefert whoami ja auch nur SIDs.

2. wenn das Skript signiert ist, würde es ja im Full Language Mode laufen - oder?

[daabm 1.386]

Zu 1: Ohne Domäne keine SID-Auflösung - und wenn ich eh die Domäne fragen muß wegen der SIDs, dann kann ich auch gleich TokenGroups nehmen

Zu 2: AFAIK nein - Constrained schnippelt fast alle Methoden und alles aus .NET weg. Das ist IMHO nur halb fertig gedacht.

[cj_berlin 1.401]

Zu 2. Also *gedacht* ist es wohl schon richtig - Laut Doku (also: gedacht  ) sollen signierte Skripte, deren Signierer in AppLocker per Rule berechtigt ist, im Full Mode laufen. Ob das Gedachte tatsächlich so umgesetzt wurde, muss man testen... Finde das Dokument leider gerade nicht :-( 

[cj_berlin 1.401]

Ich korrigiere: Jedes Skript, was in eine Allow-Rule fällt, läuft im Full Language Mode. Hier sind nur Default Rules (C:\Windows, C:\Program Files und BUILTIN\Administrators) aktiv PLUS eine Publisher-Rule:

 

@daabm Oder hast Du ein anderes Verhalten gemeint oder beobachtet?

[Alith Anar 40]

Also AppLocker läuft nicht.

 

Wenn ich das ganze auf Powershell umstelle, dann muss ich das Script aber signieren, oder?

[cj_berlin 1.401]

Gerade eben schrieb Alith Anar:

Wenn ich das ganze auf Powershell umstelle, dann muss ich das Script aber signieren, oder?

Wenn weder AppLocker noch Execution Policy das erzwingen, dann musst Du es auch nicht signieren.

[Alith Anar 40]

Die ExecutionPolicy ist auf dem Standard, also remotesigned. Also müsste ich es signieren.

[NilsK 2.978]

Moin,

 

Oder du schaltest die Policy um ...

 

Deinen Nachfragen entnehme ich, dass du in der Powershell nicht zuhause bist. Dann solltest du dir überlegen, ob es Sinn ergibt, die Login-Logik auf Powershell umzustellen. 

 

Gruß, Nils

[Alith Anar 40]

Ich weiss wie ich an die Befehle , Parameter etc. herankomme und kann mir dann kleinere Scripte zusammenstellen und bauen, aber ja 100%ig angekommen bin ich nicht.
Der Scriptumbau wäre sowieso eher ein "Privatprojekt" für das Selbststudium und wird somit eh ein bisschen dauern. Und ich werde vermutlich auch länger daran sitzen, als jemand der jeden Tag intensiv mit der Shell arbeitet, aber das Wissen ist es mir wert am Ende.
 
Die Policy umstellen will ich eigentlich nicht, um nicht, damit die User nicht jeden Kram ausführen können, der Ihnen über den Weg läuft. Da kenn ich leider meine Pappenheimer, die erst alles anklicken und dann fragen was Sie da gemacht haben.

[cj_berlin 1.401]

vor 8 Stunden schrieb Alith Anar:

Die ExecutionPolicy ist auf dem Standard, also remotesigned. Also müsste ich es signieren.

Nein, wenn es nicht "remote" ist. Remote = von einem Server kommend, der in den Internet Explorer Security Zones nicht "Intranet" ist. Da ein Logon-Skript in der Regel aus SYSVOL kommt, wäre es im Zweifel nicht "remote".

Außerdem, wenn Du das Skript im GPO-Zweig "Scripts" ausführst, wird die Execution Policy für diese Ausführung aus "Bypass" gestellt.

[Weingeist 165]

So richtig Straight ist das das nicht, hat auch ein paar Stolpersteine. Meines Wissens gibts keine Api die das direkt kann. Wenn doch, ich wäre empfänglich. =)

Hatte ich mir mal vor ~15 Jahren mit VB die Zähne dran ausgebissen bis ich nen Code gefunden habe. Die Anwendung sollte AD-Gruppenzugehörigkeit nutzen für allerelei Bereichtigungen. Der Code war dann vereinfach gesagt eine Abfrage von AD mittels ADO über ein Service-Konto. Das Service-Konto war nötig weil ein normaler User nicht alle gewünschten Parameter auslesen durfte. Details weiss ich nicht mehr zu 100%, meine es war nötig für das auflösen der SID.

-> Mitunter problematisch in einem Script wenn das PW im Klartext vorliegt. Eventuell wäre es denkbar eine Mini-Mini Anwendung zu schreiben wo dann der Krempel verschlüsselt ist und dann direkt per Kommandozeile geprüft wird. Habe ich mal mit VB6 gemacht, kann ich aber nicht auffinden.

 

 

Habe den Code noch kurz überflogen, die Basis war von Joe Kaplan. Basiert auf den bereits genannten "TokenGroups". So richtig straight-forward ist es nicht, braucht schon ein paar Apis und ein paar Eigenheiten gibt es auch. Abfrage eines verfügbaren DC's, SID (Octet) in String umwandeln, einzelne Mitgliedschaften sind als String, mehrere als Array hinterlegt usw. Könnte das Modul zu Verfügung stellen fals gewünscht, dann kannst die notwendigen Befehle extrahieren. Dürfte vermutlich in VBS zu grossen Teilen auch zu verwenden sein. ;)

[MurdocX 965]

Mein Vorschlag: Konsolidieren zu einem Laufwerk und dort die Berechtigung mit NTFS und ABE regeln. Viele sind sogar offen, wenn man ihnen den Vorschlag unterbreitet. Mut zur Veränderung