13
AD GPO: Lokale Adminrechte definieren pro Benutzer und Gerät
Hallo zusammen
Wir haben in unserem Geschäft eine Domäne mit Active Directory im Einsatz wie auch die GPMC.
Nun wurde ich nicht richtig fündig im Internet, darum melde ich mich hier.
Bei uns dürfen bzw müssen die User lokale Adminrechte besitzen, nun stellt sich bei mir die Frage wie ich das am einfachsten löse, am liebsten per GPO's.
Weil die Ausgangslage ist zum Beispiel so:
Notebook A ist im Besitz von User A und nur User A darf auf Gerät A lokale Adminrechte besitzen
Notebook B ist im Besitz von User B und nur User B darf auf Gerät B lokale Adminrechte besitzen
Wenn sich User B an Notebook A einloggt, soll er sich zwar einloggen können/dürfen, aber keine Adminrechte bekommen
Wieso gibt es für sowas keine pragmatische Lösung? Ausser ich hätte Sie übersehen...
Es handelt sich um ca. 150 Benutzer, darum ist für jeden einzelnen einen AD-Gruppe zu erstellen auch keine Lösung.
Wir haben in unserem Geschäft eine Domäne mit Active Directory im Einsatz wie auch die GPMC.
Nun wurde ich nicht richtig fündig im Internet, darum melde ich mich hier.
Bei uns dürfen bzw müssen die User lokale Adminrechte besitzen, nun stellt sich bei mir die Frage wie ich das am einfachsten löse, am liebsten per GPO's.
Weil die Ausgangslage ist zum Beispiel so:
Notebook A ist im Besitz von User A und nur User A darf auf Gerät A lokale Adminrechte besitzen
Notebook B ist im Besitz von User B und nur User B darf auf Gerät B lokale Adminrechte besitzen
Wenn sich User B an Notebook A einloggt, soll er sich zwar einloggen können/dürfen, aber keine Adminrechte bekommen
Wieso gibt es für sowas keine pragmatische Lösung? Ausser ich hätte Sie übersehen...
Es handelt sich um ca. 150 Benutzer, darum ist für jeden einzelnen einen AD-Gruppe zu erstellen auch keine Lösung.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 670016
Url: https://administrator.de/forum/ad-gpo-lokale-adminrechte-definieren-pro-benutzer-und-geraet-670016.html
Ausgedruckt am: 06.01.2025 um 22:01 Uhr
13 Kommentare
Neuester Kommentar
Moin,
Mein gut und ernst gemeinter Vorschlag: Konzept überdenken, Nutzer bekommen keine (dauerhaften) Adminrechte auf ihren Rechnern.
Gruß
Mein gut und ernst gemeinter Vorschlag: Konzept überdenken, Nutzer bekommen keine (dauerhaften) Adminrechte auf ihren Rechnern.
Gruß
3
Grundsätzlich deiner Meinung, aber hier nicht hilfreich.
In der Forschung und mit Roboterarbeit sieht das anders aus. Es geht nicht nur um Software-Installationen, sondern auch um im Gerätemanager bei den Ethernet-Anschlüssen feste IP-Adressen zu setzen und auch im Labor zum Teil die Firewall temporär deaktivieren zu müssen.
In der Forschung und mit Roboterarbeit sieht das anders aus. Es geht nicht nur um Software-Installationen, sondern auch um im Gerätemanager bei den Ethernet-Anschlüssen feste IP-Adressen zu setzen und auch im Labor zum Teil die Firewall temporär deaktivieren zu müssen.
Ich bleibe dabei und antworte hilfreich weiter: Alternativlösungen suchen.
oder zum Beispiel Admin by request.
Alles kein Grund, den 150 Benutzern dauerhaft Adminrechte auf den Rechnern zu geben. Das ist meines Erachtens eine unverantwortbare Sicherheitslücke, ja, auch im Labor.
auch um im Gerätemanager bei den Ethernet-Anschlüssen feste IP-Adressen
oder zum Beispiel Admin by request.
Alles kein Grund, den 150 Benutzern dauerhaft Adminrechte auf den Rechnern zu geben. Das ist meines Erachtens eine unverantwortbare Sicherheitslücke, ja, auch im Labor.
Ich sehe das grundsätzlich auch so aber nicht ganz so strickt. Das ist eben Windows by Design,
Ich kenne aber auch keine Uni und kein Labor, die Windows einsetzen und das sollten sie auch nicht. Daher würde ich sagen: Linux.
Für das Berechtigungsprinzip würde ich wirklich eine Gruppe pro Gerät anlegen, die Gruppe lokal in die Admin-Gruppe, den Benutzer in der AD in die Gerätegruppe - fertig. Störst du dich an der Anzahl der Gruppenobjekte?
Ich kenne aber auch keine Uni und kein Labor, die Windows einsetzen und das sollten sie auch nicht. Daher würde ich sagen: Linux.
Für das Berechtigungsprinzip würde ich wirklich eine Gruppe pro Gerät anlegen, die Gruppe lokal in die Admin-Gruppe, den Benutzer in der AD in die Gerätegruppe - fertig. Störst du dich an der Anzahl der Gruppenobjekte?
Zitat von @ukulele-7:
Ich sehe das grundsätzlich auch so aber nicht ganz so strickt. Das ist eben Windows by Design,
Ich kenne aber auch keine Uni und kein Labor, die Windows einsetzen und das sollten sie auch nicht. Daher würde ich sagen: Linux.
Für das Berechtigungsprinzip würde ich wirklich eine Gruppe pro Gerät anlegen, die Gruppe lokal in die Admin-Gruppe, den Benutzer in der AD in die Gerätegruppe - fertig. Störst du dich an der Anzahl der Gruppenobjekte?
Ich sehe das grundsätzlich auch so aber nicht ganz so strickt. Das ist eben Windows by Design,
Ich kenne aber auch keine Uni und kein Labor, die Windows einsetzen und das sollten sie auch nicht. Daher würde ich sagen: Linux.
Für das Berechtigungsprinzip würde ich wirklich eine Gruppe pro Gerät anlegen, die Gruppe lokal in die Admin-Gruppe, den Benutzer in der AD in die Gerätegruppe - fertig. Störst du dich an der Anzahl der Gruppenobjekte?
Ja ich störe mich an der Anzahl Gruppenobjekte, da wir dies bei uns über eine Webseite machen müssen wegen IAM (Identity Access Management) und seit längerer Zeit nicht mehr direkt im AD Gruppen erstellen können. Ich benötige pro Gruppenerstellung irgendwie 20x oder mehr Zeit.
Zitat von @CamelCase:
Ich bleibe dabei und antworte hilfreich weiter: Alternativlösungen suchen.
oder zum Beispiel Admin by request.
Alles kein Grund, den 150 Benutzern dauerhaft Adminrechte auf den Rechnern zu geben. Das ist meines Erachtens eine unverantwortbare Sicherheitslücke, ja, auch im Labor.
Ich bleibe dabei und antworte hilfreich weiter: Alternativlösungen suchen.
auch um im Gerätemanager bei den Ethernet-Anschlüssen feste IP-Adressen
oder zum Beispiel Admin by request.
Alles kein Grund, den 150 Benutzern dauerhaft Adminrechte auf den Rechnern zu geben. Das ist meines Erachtens eine unverantwortbare Sicherheitslücke, ja, auch im Labor.
Das ist mal ein Anfang, danke, jetzt fehlt noch das diese die Firewall deaktivieren können. Es werden eigene Apps entwickelt/programmiert welche zum Teil mit unbekannten Socket-Ports arbeiten, zum testen hat sich dann jeweils herausgestellt das es am einfachsten ist kurz die FW abzuschalten um sicher zu sein das es "nur" an dem liegt. Sobald die App fertig programmiert ist mit einem festen Port, sieht es wieder anders aus, aber nicht in der Entwicklung.
Auch reicht es nicht Programme mit einem anderen User zu installieren, gewisse Programme benötigen Adminrechte damit diese funktionieren. (Treiber Zugriffe, Log-Files in gewisse Bereiche schreiben/lesen und weitere diverse Sachen welche ich auch nicht ganz verstehe, aber das Problem ganz klar an den Rechten lag)
Du kannst da auch mit Variablen wie %%USERNAME%%
jetzt fehlt noch das diese die Firewall deaktivieren können.
Ist schnell gebaut. Lass das Systemkonto per geplantem Task x-minütlich nach einer Datei suchen, die nur benannte Nutzer erstellen können (über NTFS-Rechte gesichert). Ist die Datei vorhanden, erstellt der Task eine Regel per netsh.exe, die alles zulässt und löscht danach die Datei. Ist die datei nicht da, löscht selbiger Task die Regel wieder.Zur eigentlichen Frage: diese Zuordnung per Kommando zu erreichen ist doch ein Kinderspiel.
Erstell eine Textdatei (\\server\share\adm.txt), die du am Server für Nicht-Dom-Admins read-only (!) ablegst, mit folgender Form:
pcname1 NameAdminpc1
pcname2 NameAdminpc2
...
Nun erstelle per GPO einen geplanten immediate Task, er wieder als Systemkonto handelt und folgende Aktion ausführt:
for /f "tokens=2 delims= " %%a in ('findstr /i %computername% \\server\share\adm.txt') do net localgroup administratoren /add %%a for /f "tokens=1,2 delims= " %%a in ('findstr /i "\<%computername%\>" \\server\share\adm.txt') do if /i %%a==%computername% net localgroup administratoren /add %%b Edit: Code korrigiert.
Hi,
wir haben solche Anforderungen bei uns auch. Allerdings haben die Anwender dann 2 Benutzerkonten. Eins, mit welchem sie "normal" arbeiten und welche ein Postfach und Zugriff auf die diversen Ressourcen im Netz haben. Das Zweite bekommt die Adminrechte am PC, aber keine Rechte für irgendwelche Ressourcen, außer z.B. für Freigaben mit Installationsdateien der diversen Softwares.
Man kann dann auch über "Ausführen als" Programme mit diesem Admin-Konto ausführen, während man am Desktop mit seinem "normalen" Konto angemeldet ist. Wenn es denn tatsächlich notwendig ist. Also bei ungefähr 1% aller Fälle, von denen es behauptet wird. Bei den anderen 99% kann man es entweder über den Kompatibilitätsmodus oder der granularen Vergabe der notwendigen Rechte an das "normale" Konto lösen. Falls die 1% doch Rechte auf Ressourcen im Netz benötigen, dann erhalten die Admin-Konten eben diese, aber eben nur genau diese.
Für das selektive Erteilen der Adminrechte für nur genau die Computer, für welche sie gedacht sind, bieten sich per GPO verschiedene Möglichkeiten an.
E.
wir haben solche Anforderungen bei uns auch. Allerdings haben die Anwender dann 2 Benutzerkonten. Eins, mit welchem sie "normal" arbeiten und welche ein Postfach und Zugriff auf die diversen Ressourcen im Netz haben. Das Zweite bekommt die Adminrechte am PC, aber keine Rechte für irgendwelche Ressourcen, außer z.B. für Freigaben mit Installationsdateien der diversen Softwares.
Man kann dann auch über "Ausführen als" Programme mit diesem Admin-Konto ausführen, während man am Desktop mit seinem "normalen" Konto angemeldet ist. Wenn es denn tatsächlich notwendig ist. Also bei ungefähr 1% aller Fälle, von denen es behauptet wird. Bei den anderen 99% kann man es entweder über den Kompatibilitätsmodus oder der granularen Vergabe der notwendigen Rechte an das "normale" Konto lösen. Falls die 1% doch Rechte auf Ressourcen im Netz benötigen, dann erhalten die Admin-Konten eben diese, aber eben nur genau diese.
Für das selektive Erteilen der Adminrechte für nur genau die Computer, für welche sie gedacht sind, bieten sich per GPO verschiedene Möglichkeiten an.
- Ein Startup Script, welches anhand einer zentralen Datenbasis die Mitglieder der lokale Administratoren-Gruppe einträgt. Hier reicht 1 GPO, 1 Script und 1 Datenbasis für alle Computer. In der Datenbasis stehen Paare aus Computernamen (oder besser SID) und Benutzerkonto (besser SID).
- Die Richtlinie "Eingeschränkte Gruppen". Hier benötigt man für jeden Computer genau eine GPO, welche nur für diesen einen Computer gilt und welche die Mitglieder der lokalen Administratorengruppe diese Computers so festlegt, dass neben den "normalen" Mitgliedern nur der für diesen Clomputer angedachte "Besitzer" dort Mitglied ist.
- Die Einstellung "lokale Benutzer und Gruppen". Hier braucht man 1 GPO und je Computer eine Gruppe, in welcher jeweils nur der betreffende Computer Mitglied ist. Das Erstellen der Gruppen pro Computer inkl. Mitglied ist unter Powershell mit ein paar Klicks erledigt. Dann erstellt man in dieser GPO je Computer ein Einstellungselement mit Zielgruppenadressierung auf "Computer ist Mitglied in Gruppe" und Einstellung für BuiltIn-Administratoren:
- alle Mitglieder entfernen
- "normale" Mitglieder der lokalen Administratoren hinzufügen
- den "Besitzer" hinzufügen
E.
Moin.
Vielleicht hilft dir das hier ja weiter?
https://www.12beadmin.com/
Geht zumindest in dies Richtung. Und das es zu 100% PowerShell ist, kann man es auch leicht anpassen.
Cheers,
jsysde
Vielleicht hilft dir das hier ja weiter?
https://www.12beadmin.com/
Geht zumindest in dies Richtung. Und das es zu 100% PowerShell ist, kann man es auch leicht anpassen.
Cheers,
jsysde
Hi,
haben die Problematik bei uns auch. haben wir über das Feld managedBy gelöst. Anleitungen finden sich dazu einige. Zum Beispiel: https://miriamxyra.com/2015/03/05/lokale-administratorenrechte-per-grupp ...
Das Feld wird bei uns automatisch über eine Schnittstelle zu unserer Verwaltungssoftware gepflegt. Dazu sind dann auch keine extra Gruppen oder ähnliches nötig.
Grüße,
Mad-Eye
haben die Problematik bei uns auch. haben wir über das Feld managedBy gelöst. Anleitungen finden sich dazu einige. Zum Beispiel: https://miriamxyra.com/2015/03/05/lokale-administratorenrechte-per-grupp ...
Das Feld wird bei uns automatisch über eine Schnittstelle zu unserer Verwaltungssoftware gepflegt. Dazu sind dann auch keine extra Gruppen oder ähnliches nötig.
Grüße,
Mad-Eye
1
Ist bei uns auch so.
Jetzer "username", der lokale Admin Rechte benötigt (ist eigentlich nur in der USB Hardwareentwicklung nötig), bekommt noch ein zusätzliches Konto "username-admin" und wird im ManagedBy Feld eingetragen. "username-admin" hat keine Rechte auf die Netzwerklaufwerke zuzugreifen.
Zusätzlich, für diejenigen, die Admin Rechte nur selten benötigen, wurde LAPS eingeführt. Somit erhalten sie das lokale Admin Kennwort nur auf Nachfrage, welches sich automatisch nach angegebener Zeit ändert - also für den Benutzer unbrauchbar wird, aber für die Admins in der LAPS Datenbank immer aktuell hinterlegt ist.
Jetzer "username", der lokale Admin Rechte benötigt (ist eigentlich nur in der USB Hardwareentwicklung nötig), bekommt noch ein zusätzliches Konto "username-admin" und wird im ManagedBy Feld eingetragen. "username-admin" hat keine Rechte auf die Netzwerklaufwerke zuzugreifen.
Zusätzlich, für diejenigen, die Admin Rechte nur selten benötigen, wurde LAPS eingeführt. Somit erhalten sie das lokale Admin Kennwort nur auf Nachfrage, welches sich automatisch nach angegebener Zeit ändert - also für den Benutzer unbrauchbar wird, aber für die Admins in der LAPS Datenbank immer aktuell hinterlegt ist.
Zitat von @DerWoWusste:
Zur eigentlichen Frage: diese Zuordnung per Kommando zu erreichen ist doch ein Kinderspiel.
Erstell eine Textdatei (\\server\share\adm.txt), die du am Server für Nicht-Dom-Admins read-only (!) ablegst, mit folgender Form:
pcname1 NameAdminpc1
pcname2 NameAdminpc2
...
Nun erstelle per GPO einen geplanten immediate Task, er wieder als Systemkonto handelt und folgende Aktion ausführt:
Das wäre schon alles, wenn, ja wenn da nicht das Problem wäre, das manche PC-Namen evtl. den Namen anderer PC-Namen enthalten (also ein PC heißt Hanswurst, ein anderer Wurst). Ebenso darf der PC-Name nicht einem Nutzernamen gleichen. Somit muss es besser heißen:
Edit: Code korrigiert.
jetzt fehlt noch das diese die Firewall deaktivieren können.
Ist schnell gebaut. Lass das Systemkonto per geplantem Task x-minütlich nach einer Datei suchen, die nur benannte Nutzer erstellen können (über NTFS-Rechte gesichert). Ist die Datei vorhanden, erstellt der Task eine Regel per netsh.exe, die alles zulässt und löscht danach die Datei. Ist die datei nicht da, löscht selbiger Task die Regel wieder.Zur eigentlichen Frage: diese Zuordnung per Kommando zu erreichen ist doch ein Kinderspiel.
Erstell eine Textdatei (\\server\share\adm.txt), die du am Server für Nicht-Dom-Admins read-only (!) ablegst, mit folgender Form:
pcname1 NameAdminpc1
pcname2 NameAdminpc2
...
Nun erstelle per GPO einen geplanten immediate Task, er wieder als Systemkonto handelt und folgende Aktion ausführt:
for /f "tokens=2 delims= " %%a in ('findstr /i %computername% \\server\share\adm.txt') do net localgroup administratoren /add %%a for /f "tokens=1,2 delims= " %%a in ('findstr /i "\<%computername%\>" \\server\share\adm.txt') do if /i %%a==%computername% net localgroup administratoren /add %%b Edit: Code korrigiert.
Das hört sich bisher am praktischen an, habe auch bereits getestet manuell, mit deiner zweiten Code-Zeile, da bei uns definitiv viele Rechner fast identisch heissen, nur die Nummerierung hinten ist fortlaufend.
Allerdings klappt es via GPO noch nicht ganz richtig.
"immediate Task" bei der Computer oder User-Configuration einrichten? Es will beides nicht klappen
Code als (z.b) adm.bat abspeichern auf \\server\share
GPO anwenden auf eine OU, in der Computerkonten liegen
Die Einstellung natürlich auch im Computerteil vornehmen
GPO anwenden auf eine OU, in der Computerkonten liegen
Die Einstellung natürlich auch im Computerteil vornehmen
