Jump to content

Laufwerkszuordnung in verschachtelten Gruppen


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Geschrieben (bearbeitet)

Hallo,

 

Gibt es eine Möglichkeit während des Logons die Verschachtelung von Gruppen auszuwerten?

Hintergrund:

Bei uns werden diverse Laufwerke beim Logon des Benutzers gemappt.

 

Dies erfolgt mit einem VB Script
 

If MemberOf(ObjGroupDict, "Laufwerk-Allgemein") Then
    wshNetwork.MapNetworkDrive "g:", "\\Server01\Allgemein"
End If

 

Das funktioniert auch sehr gut, solange der Benutzer wirklich direkt Mitglied der Gruppe "Laufwerk-Allgemein" ist.
Ist er jedoch nur Mitglied der Gruppe sec-all-QMH die Mitglied der "Laufwerk-Allgemein" Gruppe ist, wird der Code oben nicht ausgeführt.

 

Danke

Thomas

bearbeitet von Alith Anar
einen von vielen Typos korrigiert
Geschrieben
vor 6 Stunden schrieb Alith Anar:
 

Gibt es eine Möglichkeit während des Logons die Verschachtelung von Gruppen auszuwerten?

Ja. Nicht die memberOF-Funktion in VBS benutzen ;-)

GPP, oder halt die Funktion erweitern, so dass sie Rekursion benutzt. Oder, wie @NilsK angedeutet hat, whoami und dann die Ausgabe nach der gewünschten Gruppe durchflöhen.

Geschrieben

Moin,.

 

Aber warum das AD fragen, wenn die Information schon vollständig lokal vorliegt? TokenGroups ist interessant, wenn man die Daten für ein anderes bzw. beliebiges Konto abfragen will. Hier geht es aber um das eigene. 

 

Gruß, Nils

Geschrieben
vor 2 Stunden schrieb NilsK:

Aber warum das AD fragen, wenn die Information schon vollständig lokal vorliegt

Um nicht DOS-Befehle in Skripten aus anderen Sprachen verwenden und deren Ausgabe parsen zu müssen. Aber performance-technisch hast Du absolut recht.

Eigentlich müsste man mal schauen, welche API whoami aufruft, und einen Wrapper in PowerShell bzw. VBS basteln.

Geschrieben

Moin,

 

Naja, "DOS-Befehle" trifft ja nun nicht zu. whoami.exe ist ein Dienstprogramm wie viele andere auch. Solange es keinen Grund gibt, etwas in Powershell neu zu implementieren, was es bereits gibt, bin ich immer sehr dafür, das Vorhandene zu verwenden.

 

Gruß, Nils

Geschrieben

Moin,

etwas, was unformatierten Text, der auch noch Locale-spezifisch ist, auf den stdout ausspuckt, ist für mich ein DOS-Befehl. Es steht nirgends geschrieben, dass "Befehle" ausschließlich als Teil der cmd.exe implementiert sein müssen, es geht also eher um die Art der Eingabe und Ausgabe - UND darum, ob ein neuer Prozess gestartet werden muss, um das gewünschte Ergebnis zu erreichen. Für einen gelegentlichen beaufsichtigten Aufruf durch den Operator mag das Prinzip "lieber sich ums Bewährte verrenken als das Neue debuggen zu müssen" durchaus ökonomisch sinnvoll sein. Wenn man aber Tools baut, die jahrelang unbeaufsichtigt, zum Teil in vorher unbekannten Umgebungen, laufen sollen, sieht die Ökonomie bisweilen anders aus.

Geschrieben

Mein Problem ist doch nicht, *wie* man genügend PowerShell oder VBS um einen DOS-Befehl strickt, damit es tut, sondern *dass* man es machen muss, um etwas zu erreichen, das evtl. mit einem API-Aufruf bessere (z.B. von der Systemsprache unabhängige) Ergebnisse liefert.

 

Und in dieser unseren Zeit ist das Ereignis "powershell.exe spawned a child process" etwas, was regelmäßig für Gesprächsbedarf sorgt.

Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...