Abgelegt unter: Tipps & Tricks | Tags: ActiveDirectory, AD, MMC, Organisationseinheit, OU
Heute meldete sich ein Administrator-Kollege bei mir mit dem Problem, dass er eine OU verschieben möchte, dabei aber immer folgende Fehlermeldung erhalte:
Active Directory-Domänendienste:
Das Objekt <Name der OU> konnte aufgrund folgenden Problems nicht verschoben werden:
Zugriff verweigert
„Ich habe wohl nicht alle benötigten Rechte dazu“, meinte er lakonisch. Doch auch als ich als Domänen- (bzw. sogar Enterprise-)Administrator die OU verschieben wollte, durfte ich dieselbe Fehlermeldung auf meinem Bildschirm bewundern…
Dabei ist des Rätsels Lösung ganz einfach: Zum Verschieben einer OU benötigt man das Löschrecht am Ausgangsort und das Schreibrecht am Zielort.
Seit dem Windows Server 2008 existiert die Option „Objekt vor zufälligem Löschen schützen“ (engl: „Protect object from accidental deletion“), die in der Management-Konsole „Active Directory Benutzer und -Computer“ erst dann sichtbar wird, wenn die Option „Erweiterte Features“ (zu finden im Menü „Ansicht“) aktiviert wurde. Diese Option wird standardmässig auf Organisationseinheiten gesetzt und bewirkt nichts anderes, als dass in den Sicherheitseinstellungen das Recht „Löschen“ der Gruppe „Jeder“ verweigert wird. Da eine explizite „Verweigerung“ eines Rechtes alle erteilten Zugriffsrechte wirkungslos macht, kann auch ein Domänen-Administrator eine so geschützte OU nicht löschen, bis er das entsprechende Häckchen entfernt.
Und nun müsste auch klar sein, weshalb sich eine OU nicht einfach so verschieben lässt: Das benötigte Löschrecht am Ausgangsort fehlt, da dieses von der Option „Objekt vor zufälligem Löschen schützen“ verweigert wird.
Und so muss das Häckchen bei „Objekt vor zufälligem Löschen schützen“ auch dann entfernt werden, wenn die OU verschoben werden soll.
Mit Vorteil setzt man das besagte Häckchen nach erfolgter Verschiebung am Zielort wieder neu, damit der Schutz vor versehentlichem Löschen wieder gegeben ist.
Abgelegt unter: Anleitungen | Tags: AD, Connector, Konfiguration, SCSM
Heute will ich den System Center Service Manager ans Active Directory anbinden. Die Konsole ist geladen und zeigt mir an, was ich für das „Getting started“ noch alles tun sollte. Im Kasten „Import User Accounts“ sehe ich den Link „Import user accounts with the Active Directory Connector“, den ich nun mal anklicke. Der sog. „Active Directory Connector Wizard“ startet und zeigt mir seine Begrüssungsseite, die ich sogleich mit einem Klick auf „Next“ wieder verlasse.
Als erstes muss ich nun einen Namen und eine Beschreibung für den einzurichtenden Connektor eingeben; da das Häckchen bei „Enable this connector“ schon gesetzt ist, klicke ich anschliessend auf „Next“.
Auf der nächsten Seite „Select a domain or organizational unit“ schlägt mir der Wizard automatisch vor, die ganze Domäne, welcher der Service Manager Server angehört, anzubinden; ich hätte jedoch auch die Möglichkeit, eine andere Domäne oder auch nur eine einzelne Organisationseinheit zu wählen. Ebenso muss ich hier das Konto angeben, welches für den Zugriff auf das Active Directory verwendet werden soll. Die entsprechende Auswahl enthält bereits das „Operational System Account“ und das „Workflow Account“, der Knopf daneben bietet mir an, ein weiteres Konto für den Service Manager zu definieren. Ich wähle allerdings der Einfachheit halber das vorgeschlagene „Operational System Account“, über den Knopf „Test Connection“ kann ich sogleich überprüfen, ob der Zugriff ins Active Directory klappt: „The connection to the server was successful“, darf ich lesen; klappt perfekt!
Auf der nächsten Seite „Select Objects“ muss ich nun auswählen, ob ich alle Computer, Drucker, Benutzer und Benutzergruppen übernehmen will, oder ob ich gezielter auswählen möchte. Ich bin mit dem vorgeschlagenen „All…“ einverstanden und klicke wiederum auf „Next“.
Schon erhalte ich die Summary-Seite, die mir nochmals meine getätigten Angaben präsentiert. Sieht alles gut aus, also klicke ich auf „Create“. Wenige Sekunden später erhalte ich die Meldung, dass der Active Directory Connector erfolgreich erstellt worden sei und schliesse den Wizard mit „Close“.
Nun wechsle ich wieder zurück in die Service Manager Console in den Abschnitt „Administration“ und navigiere zu „Connectors“. Siehe da, einen Moment später kann ich bereits lesen, dass der Status „Finished Success“ sei.
Ich wechsle deshalb in den Abschnitt „Configuration Items“ und stöbere dort etwas herum. Tatsächlich: alle Userobjekte, alle Printqueues und alle Computerobjekte sind im Service Manager angekommen.
Nun habe ich mich noch gefragt, ob ich noch einen Zeitplan definieren muss, wie häufig dieser AD-Connector synchronisieren soll. Doch in einem Blog-Post des Service Manager Teams finde ich rasch die Information, dass ein aktivierter AD-Connector automatisch jede Stunde gestartet wird, um allfällige Änderungen an Objekten im AD zu übernehmen. Wird mal schneller eine Synchronisation benötigt, kann die jederzeit über „Synchronize now“ gestartet werden.
Das lief ja mal wieder wie am Schnürchen, also schaue ich mal noch gleich, was mir angeboten wird, wenn ich im Kasten „Import User Accounts“ auf der Administration-Seite auf den Link „Create and assign user roles“ klicke. Wie ich feststelle, navigiere ich damit zu „Administration“ -> „Security“ -> „User Roles“. Hier finde ich standardmässig angebotene Rollen wie „Authors“, „End Users“, „Problem Analysts“, „Incident Resolvers“ usw.
Also schaue ich mir diese Rollen mal kurz durch und finde bei den folgenden drei Rollen bereits Mitgliedschaften (alle übrigen Rollen enthalten noch keine Mitglieder):
- Mitglieder der Rolle „Administrators“ haben volle Zugriffsrechte auf alle Operationen und auf alle Objekte im System; als standardmässige Mitglieder finde ich hier mein Account, unter welchem ich den Service Manager installiert habe, das „Operational System Account“ sowie diejenige AD-Gruppe, die ich bei der Installation angegeben habe, als ich nach einer Gruppe gefragt wurde, welche Administrative Rechte für diese Management Gruppe erhalten soll. Passt!
- Mitglieder der Rolle „End Users“ dürfen laut Beschreibung auf das Self-Service-Portal zugreifen, Incidents anlegen, die Installation von Software verlangen, Announcements lesen und in der Knowledge Base suchen; standardmässig ist hier „Authenticated Users“ eingetragen, was meiner Meinung nach ebenfalls Sinn macht.
- In der Rolle „Workflow“ finde ich das „Workflow Account“ wieder. Workflows werden laut Beschreibung automatisch durch den Service Manager gestartet und können beliebige Configuration und/oder Work Items erstellen. Auch das macht Sinn.
Somit denke ich, dass die Aktivität „Import User Accounts“ für den Moment abgeschlossen ist und mache somit Schluss für heute.