20
Domänen-Benutzer Admin Rechte delegieren
Morgen Zusammen,
ich wollte heute einem `Domänen-Benutzer Adminrechte zuweisen, das heißt er soll auf Clients Programme installieren und entfernen können.
Über die AD habe ich eine neue OU erstellt und mit diesen Aufgaben versehen:
"Computer" -Objekte"
"Benutzer" -Objekte"
und im letzten Fenster Vollzugriff erteilt.
Wenn ich mich aber mit dem Benutzer anmelde hat er nur Benutzerrechte, habe auch mal gpupdate /force ausgeführt und PC neugestartet, immer noch das gleiche.
Was habe ich übersehen?
ich wollte heute einem `Domänen-Benutzer Adminrechte zuweisen, das heißt er soll auf Clients Programme installieren und entfernen können.
Über die AD habe ich eine neue OU erstellt und mit diesen Aufgaben versehen:
"Computer" -Objekte"
"Benutzer" -Objekte"
und im letzten Fenster Vollzugriff erteilt.
Wenn ich mich aber mit dem Benutzer anmelde hat er nur Benutzerrechte, habe auch mal gpupdate /force ausgeführt und PC neugestartet, immer noch das gleiche.
Was habe ich übersehen?
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: 4969519422
Url: https://administrator.de/contentid/4969519422
Ausgedruckt am: 23.11.2024 um 12:11 Uhr
20 Kommentare
Neuester Kommentar
Moin.
Bevor du Weiteres probierst, zwei Fragen:
-weißt Du 100%ig, was Du tust?
-weißt Du, welche Konsequenzen es haben kann, wenn Du das nicht 100%ig weiß?
Sei bitte vorsichtig.
Für einen Supportbenutzer sollte man keine Adminrechte auf mehr als einem Rechner vergeben. Mein Vorschlag zum Vorgehen:
Sicherer Umgang mit Supportkonten
Bevor du Weiteres probierst, zwei Fragen:
-weißt Du 100%ig, was Du tust?
-weißt Du, welche Konsequenzen es haben kann, wenn Du das nicht 100%ig weiß?
Sei bitte vorsichtig.
Für einen Supportbenutzer sollte man keine Adminrechte auf mehr als einem Rechner vergeben. Mein Vorschlag zum Vorgehen:
Sicherer Umgang mit Supportkonten
1
Falsche Stelle
Lokale Admin-Rechte erteilt du über die eingeschränkte Gruppen GPO
https://www.windowspro.de/wolfgang-sommergut/lokale-gruppen-benutzer-ueb ...
Nur ein gut gemeinter Tipp erstelle separate Support-Konten für die Administration auf den WS die man nur aktiviert wenn man sie braucht, normale Userkonten sollten keine lokalen Admins sein!
Lokale Admin-Rechte erteilt du über die eingeschränkte Gruppen GPO
https://www.windowspro.de/wolfgang-sommergut/lokale-gruppen-benutzer-ueb ...
Nur ein gut gemeinter Tipp erstelle separate Support-Konten für die Administration auf den WS die man nur aktiviert wenn man sie braucht, normale Userkonten sollten keine lokalen Admins sein!
1
Was hast du genau gemacht?
Zitat von @2423392070:
Was hast du genau gemacht?
Was hast du genau gemacht?
Ich habe eine neue unter "Organizational Unit" erstellt und die "Objektverwaltung zuweisung" durchgeführt.
Bin davon ausgegagen das ich hierüber auch Rechte delegieren kann, aber wie es aussieht war er der Falsche weg.
Ich habe diese OU und den Benutzer gelöscht und werde es jetzt über die Lösung die der Kollege hier gespostet hat mal anschauen.
https://www.windowspro.de/wolfgang-sommergut/lokale-gruppen-benutzer-ueb ...
Ach ja und nein ich teste es nicht an einem produktiven DC, sondern auf einem Hyper-V wo ich eine Kopie vom DC habe.
Hallo,
Grüße
lcer
Zitat von @watIsLos:
Ich habe eine neue unter "Organizational Unit" erstellt und die "Objektverwaltung zuweisung" durchgeführt.
Bin davon ausgegagen das ich hierüber auch Rechte delegieren kann, aber wie es aussieht war er der Falsche weg.
Und was war in dieser OU drinnen?Zitat von @2423392070:
Was hast du genau gemacht?
Was hast du genau gemacht?
Ich habe eine neue unter "Organizational Unit" erstellt und die "Objektverwaltung zuweisung" durchgeführt.
Bin davon ausgegagen das ich hierüber auch Rechte delegieren kann, aber wie es aussieht war er der Falsche weg.
Grüße
lcer
Im "OU" war selber noch gar nichts drin, dieses habe ich zum Testen angelegt. Danach habe ich die delegierung vorgenommen mit einem Domänen-User.
Da es aber nicht geklappt hat, habe ich sowohl die OU als auch den User wieder gelöscht.
Da es aber nicht geklappt hat, habe ich sowohl die OU als auch den User wieder gelöscht.
Hallo,
Ich glaube da solltest Du nochmal irgendwo systematisch nachlesen, wie man das macht:
Grüße
lcer
Zitat von @watIsLos:
Im "OU" war selber noch gar nichts drin, dieses habe ich zum Testen angelegt. Danach habe ich die delegierung vorgenommen mit einem Domänen-User.
Da es aber nicht geklappt hat, habe ich sowohl die OU als auch den User wieder gelöscht.
Im "OU" war selber noch gar nichts drin, dieses habe ich zum Testen angelegt. Danach habe ich die delegierung vorgenommen mit einem Domänen-User.
Da es aber nicht geklappt hat, habe ich sowohl die OU als auch den User wieder gelöscht.
Ich glaube da solltest Du nochmal irgendwo systematisch nachlesen, wie man das macht:
- Die delegierten Rechte wirken auf den Inhalt der OU.
- Rechte werden gestattet. In dem Fall muss der PC wissen, wem er was gestatten soll.
Grüße
lcer
1
Ja, ich habe das mit dem delegieren der Rechte Missverstanden, war der Falsche Ansatz.
Ich denke den Ansatz mit einem PAW Rechner der nur auf die Clients per RDP per /restrictedAdmin zugreift wäre für mich hier der beste Ansatz.
Alle Clients haben einen Lokalen-Admin mit einem 14 Stelligen PW: z.B. "UDGhjbsd#3Da34"
Ja, LAPS gibt es auch aber ich habe das so gelöst.
Alle Clients sind in verschiedne Subnetze unterteilt, segmentiert. Es gibt strikte Firewallregel nur welche Ports die benötigt werden sind auch offen. Dazu kommt noch Application Whitelisting und paar GPO Security Regeln.
Der PAW User selbst läuft auf einem physischen PC, er selber ist auch in einem seperaten VLAN und darf nur auf diese Clients zugreifen, auf keine Server, oder Workstation!
So sollte es sicher sein.
Alle Clients haben einen Lokalen-Admin mit einem 14 Stelligen PW: z.B. "UDGhjbsd#3Da34"
Ja, LAPS gibt es auch aber ich habe das so gelöst.
Alle Clients sind in verschiedne Subnetze unterteilt, segmentiert. Es gibt strikte Firewallregel nur welche Ports die benötigt werden sind auch offen. Dazu kommt noch Application Whitelisting und paar GPO Security Regeln.
Der PAW User selbst läuft auf einem physischen PC, er selber ist auch in einem seperaten VLAN und darf nur auf diese Clients zugreifen, auf keine Server, oder Workstation!
So sollte es sicher sein.
Zitat von @DerWoWusste:
Moin.
Bevor du Weiteres probierst, zwei Fragen:
-weißt Du 100%ig, was Du tust?
-weißt Du, welche Konsequenzen es haben kann, wenn Du das nicht 100%ig weißt?
Sei bitte vorsichtig.
Für einen Supportbenutzer sollte man keine Adminrechte auf meehr als einem Rechner vergeben. Mein Vorschlag zum Vorgehen:
Sicherer Umgang mit Supportkonten
Moin.
Bevor du Weiteres probierst, zwei Fragen:
-weißt Du 100%ig, was Du tust?
-weißt Du, welche Konsequenzen es haben kann, wenn Du das nicht 100%ig weißt?
Sei bitte vorsichtig.
Für einen Supportbenutzer sollte man keine Adminrechte auf meehr als einem Rechner vergeben. Mein Vorschlag zum Vorgehen:
Sicherer Umgang mit Supportkonten
Hallo,
LAPS gehört als allererstes auf die Clients!
Grüße
lcer
Zitat von @watIsLos:
Alle Clients haben einen Lokalen-Admin mit einem 14 Stelligen PW: z.B. "UDGhjbsd#3Da34"
Ja, LAPS gibt es auch aber ich habe das so gelöst.
Na ja. Das Problem bei den aktuellen Angriffsmustern ist es ja, dass der Bösewicht die Schadsoftware vom normalen Benutzer per Mausklick installieren läßt. Die Schadsoftware erlangt dann Lokale Adminrechte auf dem Client. Anschließend versucht er sich im Netzwerk auszubreiten ("Lateral Movement") um auf irgendeinem Rechner dann höherwertige Adminrechte zu erlangen. Dieses "Lateral Movement" unterbindet LAPS, da jeder Rechner ein eigenes Password hat. Du lieferst ihm die gesamte Client-Herde auf dem Silbertablett....Alle Clients haben einen Lokalen-Admin mit einem 14 Stelligen PW: z.B. "UDGhjbsd#3Da34"
Ja, LAPS gibt es auch aber ich habe das so gelöst.
LAPS gehört als allererstes auf die Clients!
Grüße
lcer
nicht vergessen, dass LAPS auch wieder nicht zu Ende gedacht ist, da es mit lokalen Konten arbeitet, die nicht an Domänenressourcen kommen und somit wieder die Unterstützung eines Domänenkontos brauchen. Mein Ansatz nicht.
@lcer00
Wie soll das gehen das ein Benutzer der keine Rechte hat Schadsoftware installieren kann?
Meinst Du per Exploit eine Schwachstelle im Browser ausnutzt, oder per Zero-Day-Lücke?
Klar das ist Möglich, gut sagen wir mal das passiert dann hat er immer noch keine Domän-Admin Rechte sondern nur die für den Lokalen Client. Er kann sich damit nur in einem kleinen Segmentierten Netz bewegen. Durch "Lateral Movement" könnte er sich hocharbeiten, aber nur wenn der Admin kein remoteGuard, oder restrictedAdmin verwendet.
Wie soll das gehen das ein Benutzer der keine Rechte hat Schadsoftware installieren kann?
Meinst Du per Exploit eine Schwachstelle im Browser ausnutzt, oder per Zero-Day-Lücke?
Klar das ist Möglich, gut sagen wir mal das passiert dann hat er immer noch keine Domän-Admin Rechte sondern nur die für den Lokalen Client. Er kann sich damit nur in einem kleinen Segmentierten Netz bewegen. Durch "Lateral Movement" könnte er sich hocharbeiten, aber nur wenn der Admin kein remoteGuard, oder restrictedAdmin verwendet.
Ich verstehe den LAPS Ansatz und finde diesen nicht schlecht, anderseits Frage ich mich ob das wirklich die Lösung sein kann, will man die AD noch wichtiger machen als es eh schon ist?!
Per Zero-Day-Lücke lässt sich das genauso aushebeln und dann spielt der Lokale-Admin wie auch das LAPS keine Große Rolle mehr.
die Idee vom @DerWoWusste finde ich Interessant, werde ich mir heute Abend mal genauer anschauen.
Per Zero-Day-Lücke lässt sich das genauso aushebeln und dann spielt der Lokale-Admin wie auch das LAPS keine Große Rolle mehr.
die Idee vom @DerWoWusste finde ich Interessant, werde ich mir heute Abend mal genauer anschauen.
Hallo,
Du kannst nicht ausschließen, dass irgend ein User auf einen präparierten Link klickt. Du kannst aber dafür sorgen, dass der Bösewicht nicht so einfach von dem Client-PC wegkommt. Das geht super mit LAPS.
Die Lösung von @DerWoWusste ist super, aber nur, wenn man weiß, was man tut. Die LAPS-Lösung ist supereinfach zu implementieren. Bei Deinem Kenntnisstand solltest Du erst mal die einfache Lösung (LAPS) umsetzten und Dich dann später um die Kür kümmern.
Grüße
lcer
Zitat von @watIsLos:
Ich verstehe den LAPS Ansatz und finde diesen nicht schlecht, anderseits Frage ich mich ob das wirklich die Lösung sein kann, will man die AD noch wichtiger machen als es eh schon ist?!
Das AD ist das wichtigste. Wichtiger geht nicht.Ich verstehe den LAPS Ansatz und finde diesen nicht schlecht, anderseits Frage ich mich ob das wirklich die Lösung sein kann, will man die AD noch wichtiger machen als es eh schon ist?!
Per Zero-Day-Lücke lässt sich das genauso aushebeln und dann spielt der Lokale-Admin wie auch das LAPS keine Große Rolle mehr.
Die Aussage ist Quatsch. Ich glaube Du solltest Dich nochmal die Grundlagen von Active Directory befassen. Und damit, wie man das Active Directory gegen welche Angriffe absichert. Fang mal an mit https://learn.microsoft.com/de-de/security/compass/privileged-access-acc ...Du kannst nicht ausschließen, dass irgend ein User auf einen präparierten Link klickt. Du kannst aber dafür sorgen, dass der Bösewicht nicht so einfach von dem Client-PC wegkommt. Das geht super mit LAPS.
Die Lösung von @DerWoWusste ist super, aber nur, wenn man weiß, was man tut. Die LAPS-Lösung ist supereinfach zu implementieren. Bei Deinem Kenntnisstand solltest Du erst mal die einfache Lösung (LAPS) umsetzten und Dich dann später um die Kür kümmern.
Grüße
lcer
Du kannst nicht ausschließen, dass irgend ein User auf einen präparierten Link klickt. Du kannst aber dafür sorgen, dass der Bösewicht nicht so einfach von dem Client-PC wegkommt. Das geht super mit LAPS.
Wie sicher ist denn LAPS?
Hallo,
Grüße
lcer
Zitat von @watIsLos:
Wie sicher ist denn LAPS?
Es ist die von Microsoft empfohlene Lösung. Du fragst also - wie sicher Windows ist!Du kannst nicht ausschließen, dass irgend ein User auf einen präparierten Link klickt. Du kannst aber dafür sorgen, dass der Bösewicht nicht so einfach von dem Client-PC wegkommt. Das geht super mit LAPS.
Wie sicher ist denn LAPS?
Grüße
lcer
1
Okay, also relativ sicher 
Gut ich schaue es mir mal an.
Gut ich schaue es mir mal an.
Es ist die von Microsoft empfohlene Lösung. Du fragst also - wie sicher Windows ist!
Die Schlussfolgerung finde ich unzulässig. Microsoft hat viel zu oft bewiesen, dass sie sicherheitstechnisch ungenau arbeiten und haarsträubende Fehler einbauen. Vor Jahren hatten Sie einen Weg aufgezeigt, domänenweit das lokale Adminkennwort per GPO zu setzen. Sie mussten zurückrudern und den Weg für unsicher erklären. Mittlerweile gilt das von Ihnen Vorgeschlagene als eine der größten Sicherheitslücken aller Zeiten (die zudem auch noch fortbesteht, da nicht automatisch patchbar, wenn einmal eingesetzt). Daraufhin kamen Sie mit LAPS - auf jeden Fall schon besser.Schaut man auf die Details, frage ich mich: warum sollte ich Kennwörter in die Zwischenablage kopieren müssen? Das allein ist doch ganz schlechte Praxis. Natürlich kann man auch auf andere Weise rangehen um das Kennwort zu erlangen - aber wie setze ich das dann ein? Die Tücke liegt im Detail. Mit meiner Lösung kennst Du das Kennwort nicht, gibst es nicht ein, es wird nirgendwo zwischengespeichert (cmdkey kann dieses sofort wieder löschen) und es ist nur für die Dauer der Supporttätigkeit gültig. Zudem ist es ein Domänenkonto und nicht die holzk. Idee, da ein lokales Konto zu nutzen.
Das ist wirklich Interessant und ein schönes Beispiel dafür, aber im Grunde arbeitet sich hier Microsoft auch nur von einem Schritt zum nächsten obwohl wir als Enduser ja die Leidtragenden sind...
Wenn ich mir überlege was mich heute MS-Updates an Zeit kosten und wie viele Schwierigkeiten diese bereiten oh je... will nicht Wissen wie das in Zukunft besser werden soll.
Vor Jahren hatten Sie einen Weg aufgezeigt, domänenweit das lokale Adminkennwort per GPO zu setzen. Sie mussten zurückrudern und den Weg für unsicher erklären. Mittlerweile gilt das von Ihnen Vorgeschlagene als eine der größten Sicherheitslücken aller Zeiten (die zudem auch noch fortbesteht, da nicht automatisch patchbar, wenn einmal eingesetzt).
Wenn ich mir überlege was mich heute MS-Updates an Zeit kosten und wie viele Schwierigkeiten diese bereiten oh je... will nicht Wissen wie das in Zukunft besser werden soll.
Vor Jahren hatten Sie einen Weg aufgezeigt, domänenweit das lokale Adminkennwort per GPO zu setzen. Sie mussten zurückrudern und den Weg für unsicher erklären. Mittlerweile gilt das von Ihnen Vorgeschlagene als eine der größten Sicherheitslücken aller Zeiten (die zudem auch noch fortbesteht, da nicht automatisch patchbar, wenn einmal eingesetzt).
