GPO: wie entziehe ich einer Gruppe von Anwendern lokale Adminrechts bzw. wie gebe ich einem Dummyuser lokale Adminrechte
Hallo,
im Rahmen der Eindämmung potentieller Einfallschneisen für Ungeziefer möchte ich diesem den Weg zumindest schwieriger machen.
Unsere Entwickler (Elektronik) arbeiten z.B. alle mit lokalen Adminrechten - das gilt als potentiell gefährdent.
Allerdings müssen die oft Programme installieren / ausführen die genau das brauchen
Daher möchte ich
a. allen jetzigen Anwendern die lokalen Adminrechte entziehen
b. einen Dummyuser in der Domäne erstellen der überall lokale Adminrechte hat - damit kann man dann temporär als Admin Dinge ausführen
Gibt es eine Anleitung für mich als GPO-Gelegenheitsuser wie man sowas verteilt?
Basis ist SRV16 & W10.
Danke Euch
im Rahmen der Eindämmung potentieller Einfallschneisen für Ungeziefer möchte ich diesem den Weg zumindest schwieriger machen.
Unsere Entwickler (Elektronik) arbeiten z.B. alle mit lokalen Adminrechten - das gilt als potentiell gefährdent.
Allerdings müssen die oft Programme installieren / ausführen die genau das brauchen
Daher möchte ich
a. allen jetzigen Anwendern die lokalen Adminrechte entziehen
b. einen Dummyuser in der Domäne erstellen der überall lokale Adminrechte hat - damit kann man dann temporär als Admin Dinge ausführen
Gibt es eine Anleitung für mich als GPO-Gelegenheitsuser wie man sowas verteilt?
Basis ist SRV16 & W10.
Danke Euch
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 479703
Url: https://administrator.de/forum/gpo-wie-entziehe-ich-einer-gruppe-von-anwendern-lokale-adminrechts-bzw-wie-gebe-ich-einem-dummyuser-lokale-479703.html
Ausgedruckt am: 22.12.2024 um 21:12 Uhr
13 Kommentare
Neuester Kommentar
Hi
zu a: Entziehen kann man das recht einfach per GPO. Einfach die Lokalen Administratoren festlegen per GPO mit der Option "Delete all member / User"
Damit löscht du alles was da momentan so drin ist und legst fest wen du als Admin haben willst
zu b: Dafür richtet man sich LAPS ein. Damit eben NICHT der EINE Benutzer existiert, der da überall Admin hat. Wenn du das machst, hast du nicht wirklich viel gewonnen, da ein PassTheHash Angriff weiterhin überall Zugriff findet
zu a: Entziehen kann man das recht einfach per GPO. Einfach die Lokalen Administratoren festlegen per GPO mit der Option "Delete all member / User"
Damit löscht du alles was da momentan so drin ist und legst fest wen du als Admin haben willst
zu b: Dafür richtet man sich LAPS ein. Damit eben NICHT der EINE Benutzer existiert, der da überall Admin hat. Wenn du das machst, hast du nicht wirklich viel gewonnen, da ein PassTheHash Angriff weiterhin überall Zugriff findet
Moin.
Du willst einen User erstellen, der überallAdminrechte hat und das Kennwort Leuten geben, denen Du nicht einmal lokale Adminrechte zutraust?
Das ist keine gute Idee.
Schau Dir dazu bitte lieber dieses Konzept an: Tipp zur UAC-Nutzung
Das würde erreichen, was Du willst: jeder arbeitet als Nicht-Admin, kann aber jederzeit (und sogar komfortabel) Software bei sich (und nur bei sich) installieren.
Du willst einen User erstellen, der überallAdminrechte hat und das Kennwort Leuten geben, denen Du nicht einmal lokale Adminrechte zutraust?
Das ist keine gute Idee.
Schau Dir dazu bitte lieber dieses Konzept an: Tipp zur UAC-Nutzung
Das würde erreichen, was Du willst: jeder arbeitet als Nicht-Admin, kann aber jederzeit (und sogar komfortabel) Software bei sich (und nur bei sich) installieren.
Hi.
Ja, ich meine in der Aufgabenplanung.
Du kannst Tasks zwar per GPO deployen; da diese Tasks aber personengebunden sind, ist das nicht ganz so einfach. Das starke Konto soll sich ja eben nicht bei jeder Anmeldung aktivieren, sondern nur, wenn sich Nutzer X anmeldet.
Ich kann mal eine deploybare Variante erstellen.
Zum Trigger: der schwache Nutzer ist der jeweilige Entwickler - fortan sollen die ja als Nichtadmins (schwach) arbeiten.
Ich melde mich wieder.
Ja, ich meine in der Aufgabenplanung.
Du kannst Tasks zwar per GPO deployen; da diese Tasks aber personengebunden sind, ist das nicht ganz so einfach. Das starke Konto soll sich ja eben nicht bei jeder Anmeldung aktivieren, sondern nur, wenn sich Nutzer X anmeldet.
Ich kann mal eine deploybare Variante erstellen.
Zum Trigger: der schwache Nutzer ist der jeweilige Entwickler - fortan sollen die ja als Nichtadmins (schwach) arbeiten.
Ich melde mich wieder.
Moin,
Ansonsten würde mich stören, dass du nicht weißt welche Art von Software auf dem Rechnern installiert wird. Leider werden die Rechte oft missbraucht, um Programme zu installieren welche mit der eigentlichen Arbeit nichts zu tun haben. Oder es werden gerne Gruppenrichtlinien mit einer lokalen Konfiguration ausgehebelt. Zudem ist es problemlos möglich Löcher in die Windows-Firewall zu bohren. An deiner Stelle würde ich den Prozess grundlegend überdenken und eine neue Strategie entwerfen.
Gruß,
Dani
Unsere Entwickler (Elektronik) arbeiten z.B. alle mit lokalen Adminrechten - das gilt als potentiell gefährdent.
Allerdings müssen die oft Programme installieren / ausführen die genau das brauchen
je nachdem wäre evtl. eine VM auf dem Rechner/Notebook eine Alternative, welche keinen direkten Zugriff auf das Netzwerk benötigt.Allerdings müssen die oft Programme installieren / ausführen die genau das brauchen
Ansonsten würde mich stören, dass du nicht weißt welche Art von Software auf dem Rechnern installiert wird. Leider werden die Rechte oft missbraucht, um Programme zu installieren welche mit der eigentlichen Arbeit nichts zu tun haben. Oder es werden gerne Gruppenrichtlinien mit einer lokalen Konfiguration ausgehebelt. Zudem ist es problemlos möglich Löcher in die Windows-Firewall zu bohren. An deiner Stelle würde ich den Prozess grundlegend überdenken und eine neue Strategie entwerfen.
Gruß,
Dani
So.
Ich habe mir folgendes überlegt: Task 2 ist ja deploybar, so wie er ist.
Bei Tasks 1 möchte ich fragen, ob Du auf diesen PCs mehrere User hast und hierbei auch nur einem die Adminrechte geben willst. Wenn Du nur einen User hast, dann kannst Du den Task natürlich auch deployen, denn dann braucht da nicht "deinSchwacherUser" rein, sondern nur "any user", wie bei Task 2!
Hast Du mehrere, wird es etwas anstrengender. Ich würde einen Referenztask exportieren, der auf deinem PC manuell erstellt wurde. Der Export erfolgt als .xml-Datei. Um aus dieser Referenzdatei einen passenden Task für jeden PC zu machen, müsstest Du mittels Powershell Kopien erzeugen, die die korrekten Kontennamen enthalten. Das ginge so:
Diese modifizierten Tasks würde ich dann per Startskript so importieren lassen:
Ich habe mir folgendes überlegt: Task 2 ist ja deploybar, so wie er ist.
Bei Tasks 1 möchte ich fragen, ob Du auf diesen PCs mehrere User hast und hierbei auch nur einem die Adminrechte geben willst. Wenn Du nur einen User hast, dann kannst Du den Task natürlich auch deployen, denn dann braucht da nicht "deinSchwacherUser" rein, sondern nur "any user", wie bei Task 2!
Hast Du mehrere, wird es etwas anstrengender. Ich würde einen Referenztask exportieren, der auf deinem PC manuell erstellt wurde. Der Export erfolgt als .xml-Datei. Um aus dieser Referenzdatei einen passenden Task für jeden PC zu machen, müsstest Du mittels Powershell Kopien erzeugen, die die korrekten Kontennamen enthalten. Das ginge so:
(Get-Content -path "\\server\share\exportierterDummy.xml" -Raw) -replace 'deineDomain\\deinNutzername','deineDomain\EntwicklernamevonPC1' | Set-Content -Path \\server\share\TaskfuerPC1.xml
Diese modifizierten Tasks würde ich dann per Startskript so importieren lassen:
schtasks /create /xml \\server\share\Taskfuer%computername% /f
Die gelistete GPO ist die richtige. Prüf erst einmal nach, ob sie auch am Client angewendet wurde.
auf einem elevated command prompt ausführen:
auf einem elevated command prompt ausführen:
gpresult /h %temp%\result.html & %temp%\result.html
Verwende ich bei meinem Dateimanager den lokalen Admin, habe ich keine Netzwerklaufwerke
Normal, denn Netzlaufwerke werden eben per Benutzer verbunden und nicht pro Computer. Du musst die benötigten Daten vorher als Domänennutzer lokal kopieren, oder mit Freigaben arbeiten, die anonym erreicht werden können.
Moin,
Daher eigentlich immer die notwendigen Dateien mit Hilfe von einem Share auf dem jeweiligen Rechner/Server oder per Fernwartungssoftware auf das Zielsystem kopieren. Somit werden keine zusätzlichen Ziele für Malware bekannt gegeben.
@DerWoWusste
Gruß,
Dani
Es verbleibt (für uns) ein Riesenpferdefuß:
sobald ich im lokalen Adminkontext arbeite, habe ich keine Netzlaufwerke mehr (wie oben erwähnt).
Mappe ich die Laufwerke, kommt natürlich die Frage nach den Anmeldeinfos.
Es ist aus Sicht der Sicherheit eigentlich Quark. Denn hast du einen Verschlüsselungstrojaner auf dem Rechner und dieser wird z.B. durch lokalen Administrator geweckt, sind die Daten auf den Netzlaufwerken (irgendwann) dran bzw. weg.sobald ich im lokalen Adminkontext arbeite, habe ich keine Netzlaufwerke mehr (wie oben erwähnt).
Mappe ich die Laufwerke, kommt natürlich die Frage nach den Anmeldeinfos.
Daher eigentlich immer die notwendigen Dateien mit Hilfe von einem Share auf dem jeweiligen Rechner/Server oder per Fernwartungssoftware auf das Zielsystem kopieren. Somit werden keine zusätzlichen Ziele für Malware bekannt gegeben.
@DerWoWusste
Wenn Du ein Setupshare bereitstellen kannst, das anonym genutzt werden darf, hättest Du noch weniger Probleme.
Allerdings keine Lizenzschlüssel oder Anwendungen mit intergrieter Aktivierung dort ablegen. Sonst besteht die Gefahr, dass n Kollege sowas mit nach Hause nimmt für eine Referenzinstallation. Gruß,
Dani