OU / Standort Admin

[paramode 0]

Guten Tag,

 

wir haben an einem Standort einen OU Admin dem ich gerne die Verwaltung der Benutzer und Computer ermöglichen möchte. Das klappt mit "Objektverwaltung zuweisen..." auch ganz gut, nur wenn es dann um Sicherheitsgruppen geht, kann der OU-Admin auch Computerkonten außerhalb seiner OU hinzufügen. Hat jemand einen Tipp wie man diese Berechtigungen anpasst, bzw. kennt jemand eine gute Anleitung für das Thema OU Admin? Ich habe im Netz bisher dazu wenig gefunden.

 

Gruß, Andreas 

[testperson 1.785]

Hi,

 

mir würde spontan ein alternatives, angepasstes "Frontend" einfallen, das dem User nur das zeigt bzw. anbietet, was er sehen / nutzen darf. Ggfs. halt auch eine 3rd Party ala Manage Engine AD Manager plus, Quest Active Roles oder eine "User-On-Boarding-Lösung".

 

Ansonsten den User in eine Gruppe packen und der Gruppe das Recht "Lesen" bzw. "Inhalt auflisten" auf den OUs zu nehmen / verweigern, wo er nichts sehen / nutzen soll. An dieser Stelle wäre allerdings Dokumentation, nur Gruppen berechtigen und Dokumentation das wichtigste, was auch für die Delegation gilt.

 

Gruß

Jan

[Dukel 465]

Ich glaube das hat nichts mit den Berechtigungen zu tun sondern damit, dass jeder User bis zu 10 Computer ins AD (jede OU) aufnehmen darf.

[testperson 1.785]

Ich lese daraus, dass der Admin in seiner OU Gruppen erstellen und in diese Gruppen Userkonten / Computerkonten aus dem gesamten AD hinzufügen kann, aber nicht soll.

Aber warten wir mal ab. :)

[paramode 0]

Hallo Jan, vielen Dank für deine Antwort. Eine Frontend wäre als Lösung für diesen einen, und kleinen Einzelfall zu "groß". Das muss ich irgendwie anders hinbekommen. Mit dem "Lesen" wäre ein Ansatz.

 

An Dukel, es geht nicht darum neue Konten hinzuzufügen, denn dass kann/darf er jetzt schon nicht. Es geht nur um die vorhandenen Computerkonten aus anderen OUs.

 

Neue Gruppen kann er auch nicht erstellen. Nur vorhandene bearbeiten.

bearbeitet 24. Mai 2019 von paramode

[Dukel 465]

Was _genau_ (!) kann der User und soll er nicht?

[Sunny61 820]

Es gibt beim Nils einen Artikel zu dem Thema und auch ein Frontend, evtl. hilft es oder Du kannst es anpassen. https://www.faq-o-matic.net/2008/06/23/ad-adressen-im-sekretariat-bearbeiten-lassen/

 

[NilsK 3.000]

Moin,

 

das AD sieht es nicht vor, per Berechtigung nur selektiv Mitglieder zu einer Gruppe hinzuzufügen. Wenn das wirklich erforderlich ist, müsste man also mit einem Workaround arbeiten. Aus Erfahrung stelle ich aber in Frage, ob das Erfordernis wirklich so wichtig ist.

 

Zwei mögliche Ansätze sind schon genannt worden: 

1. ein Frontend bzw. ein anderes Tool, das nur die erlaubten Objekte auswählbar macht. Das allein reicht aber nicht - das Tool müsste, wenn es Sinn haben soll, über einen separaten (Service-) Account auf das AD zugreifen und der User dürfte gar keine Schreibrechte auf die Zielgruppen haben. Effektiv würde man also ein separates Berechtigungssystem bauen.
2. Die auswähbaren Objekte selbst per AD-Berechtigungen einschränken. Das ist denkbar - wäre aber zum einen ein erheblicher Eingriff in die AD-Berechtigungen (und könnte dazu führen, dass Microsoft es nicht mehr supportet) und würde zum anderen bedeuten. dass der betreffenden User die versteckten Objekte überhaupt nicht mehr sehen und benutzen kann.

Da das AD für so ein Szenario nicht gebaut wurde, würde ich, wie gesagt, genau prüfen, ob das wirklich erforderlich ist.

 

Gruß, Nils

[testperson 1.785]

Hi,

 

mir kommt grade noch Just Enough Administration in den Sinn. Damit sollte das ggfs. auch realisierbar sein: https://docs.microsoft.com/de-de/powershell/jea/role-capabilities#create-a-role-capability-file

Zitat

VisibleCmdlets = @{ Name = 'Restart-Service'; Parameters = @{ Name = 'Name'; ValidateSet = 'Dns', 'Spooler' }},
                 @{ Name = 'Start-Website'; Parameters = @{ Name = 'Name'; ValidatePattern = 'HR_*' }}

 

Wäre dann wohl der Ansatz.

 

Gruß

Jan

[NilsK 3.000]

Moin,

 

das entspricht vom Prinzip her dem Ansatz 1. Ist auch ungefähr so aufwändig. 

 

Gruß, Nils

 

[daabm 1.395]

JEA taugt dafür nicht - da kannst die Sichtbarkeit der AD-Objekte nicht einschränken. Wenn das mit Bordmitteln gelöst werden MUSS, braucht es LOM (List Object Mode), und da fängt dann der ganz große Spaß an...

 

Ich frage mal ganz anders: Was ist denn die Auswirkung, wenn der delegierte Admin da Computer und User aufnehmen kann? Was geht dann kaputt oder funktioniert nicht mehr oder hat zu viele Rechte?

[paramode 0]

Vielen Dank für die Antworten und Beteiligung. Hätte nicht gedacht dass MS so etwas nicht ausreichend vorsieht.

 

Bei dieser Sicherheitsgruppe (Ordnerumleitung) würde aufgrund der weiter unten verlinkten GPO nichts bei anderen Konten passieren. Bei einer anderen GPO, die deutlich weiter oben angesetzt ist, könnten Computer z. B. ein Wartungskonzept zugeteilt bekommen, oder bei einem anderen Beispiel Benutzer zum lokalen Netzwerkoperatoren hinzugefügt werden. Ich möchte (muss leider) die AD Struktur für „andere“ flach und nicht zu sehr verschachtelt halten.

 

Ich werde mal den Vorschlag von daabm weiter nachgehen, oder hast du da ein konkretes Beispiel? Weil ich nicht das ganze AD in diesen Mode versetzen möchte.

 

[daabm 1.395]

Nein, Du willst meinem "Vorschlag" nicht nachgehen. LOM ist nichts für KMU-Umgebungen, sorry. Und LOM ist eine globale Einstellung, da geht nix "selektiv".

 

Da wäre es einfacher, die Gruppenstruktur so umzubauen, daß die delegierten Gruppen eben KEINE Auswirkungen weiter oben haben. Für Gruppen gilt prinzipiell das gleiche wie für GPOs: Was sich in unteren OUs befindet, darf weiter oben nicht verwendet werden. Sonst kann man nicht sinnvoll delegieren.

[NilsK 3.000]

Moin,

 

JEA wäre durchaus geeignet, denn man könnte, wie in dem Beispiel zutreffend angegeben, passende Filter definieren und so einschränken, welche Mitglieder in die Gruppe dürfen. Aber: das hat einen Preis, nämlich erheblichen Aufwand für Entwicklung und Test.

 

Da die Diskussion allerdings in eine seltsame Richtung geht, mache ich hier Schluss.

 

Gruß, Nils

[testperson 1.785]

Am 24.5.2019 um 21:19 schrieb daabm:

JEA taugt dafür nicht - da kannst die Sichtbarkeit der AD-Objekte nicht einschränken.

Unterm Strich tut das keine "Alternative-Frontend-Lösung". ;)

Nach den letzten Infos des TO wäre aber wohl

Am 24.5.2019 um 23:07 schrieb daabm:

Da wäre es einfacher, die Gruppenstruktur so umzubauen, daß die delegierten Gruppen eben KEINE Auswirkungen weiter oben haben. Für Gruppen gilt prinzipiell das gleiche wie für GPOs: Was sich in unteren OUs befindet, darf weiter oben nicht verwendet werden. Sonst kann man nicht sinnvoll delegieren.

der derzeit beste Ansatz.