Jump to content

OU / Standort Admin


Direkt zur Lösung Gelöst von daabm,
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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 

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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 von paramode
Link zu diesem Kommentar

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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?

Link zu diesem Kommentar

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.

 

Link zu diesem Kommentar
  • Beste Lösung

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.

Link zu diesem Kommentar

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

Link zu diesem Kommentar
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.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...