watislos
Goto Top

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?

Content-Key: 4969519422

Url: https://administrator.de/contentid/4969519422

Printed on: July 25, 2024 at 18:07 o'clock

Member: DerWoWusste
Solution DerWoWusste Dec 15, 2022 at 10:30:24 (UTC)
Goto Top
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ß?
face-smile

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
Mitglied: 4863114660
4863114660 Dec 15, 2022 updated at 10:32:45 (UTC)
Goto Top
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!
Mitglied: 2423392070
2423392070 Dec 15, 2022 at 10:32:11 (UTC)
Goto Top
Was hast du genau gemacht?
Member: watIsLos
watIsLos Dec 15, 2022 at 10:41:18 (UTC)
Goto Top
Zitat von @2423392070:

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 ...
Member: watIsLos
watIsLos Dec 15, 2022 at 10:44:42 (UTC)
Goto Top
Ach ja und nein ich teste es nicht an einem produktiven DC, sondern auf einem Hyper-V wo ich eine Kopie vom DC habe.
Member: lcer00
lcer00 Dec 15, 2022 at 10:59:34 (UTC)
Goto Top
Hallo,
Zitat von @watIsLos:

Zitat von @2423392070:

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.
Und was war in dieser OU drinnen?

Grüße

lcer
Member: watIsLos
watIsLos Dec 15, 2022 updated at 11:04:24 (UTC)
Goto Top
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.
Member: lcer00
lcer00 Dec 15, 2022 at 11:10:59 (UTC)
Goto Top
Hallo,
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.

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
Member: watIsLos
watIsLos Dec 15, 2022 at 11:16:03 (UTC)
Goto Top
Ja, ich habe das mit dem delegieren der Rechte Missverstanden, war der Falsche Ansatz.
Member: watIsLos
watIsLos Dec 15, 2022 updated at 11:46:18 (UTC)
Goto Top
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.


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?
face-smile

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
Member: lcer00
lcer00 Dec 15, 2022 at 12:27:50 (UTC)
Goto Top
Hallo,
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....

LAPS gehört als allererstes auf die Clients!

Grüße

lcer
Member: DerWoWusste
DerWoWusste Dec 15, 2022 at 12:39:48 (UTC)
Goto Top
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.
Member: watIsLos
watIsLos Dec 15, 2022 updated at 13:40:44 (UTC)
Goto Top
@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.
Member: watIsLos
watIsLos Dec 15, 2022 updated at 13:21:02 (UTC)
Goto Top
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.
Member: lcer00
lcer00 Dec 15, 2022 at 13:47:58 (UTC)
Goto Top
Hallo,
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.

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
Member: watIsLos
watIsLos Dec 15, 2022 updated at 14:08:28 (UTC)
Goto Top
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?
Member: lcer00
lcer00 Dec 15, 2022 at 14:13:33 (UTC)
Goto Top
Hallo,
Zitat von @watIsLos:

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?
Es ist die von Microsoft empfohlene Lösung. Du fragst also - wie sicher Windows ist!

Grüße

lcer
Member: watIsLos
watIsLos Dec 15, 2022 at 14:14:52 (UTC)
Goto Top
Okay, also relativ sicher face-wink
Gut ich schaue es mir mal an.
Member: DerWoWusste
DerWoWusste Dec 15, 2022 updated at 14:47:54 (UTC)
Goto Top
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.
Member: watIsLos
watIsLos Dec 15, 2022 at 15:08:20 (UTC)
Goto Top
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.


Zitat von @DerWoWusste:

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).