Active Directory Aufgaben Delegation
Verfasser: Norbert Fehlauer
Mark hat in seinem HowTo „Objektverwaltung zuweisen - Delegation von Aufgaben“
ja schon die generelle Möglichkeit der Aufgabendelegation im Active Directory dargestellt.
Da es sich jedoch, wie dort angemerkt, nur um eine sehr allgemeine Aufgabe (Vollzugriff auf Benutzerobjekte) handelt, habe ich das zum Anlass genommen eine etwas spezifischere Aufgabe mit Lösung aufzuzeigen. Möglicherweise ergeben sich ja so für einige von euch „ungeahnte Administrationsmöglichkeiten“ ;)
Folgende Aufgabe, vor die man eventuell gestellt wird, sei gegeben:
In einer Firma existiert eine Personalabteilung, welche zukünftig Benutzerdaten im Active Directory unterhalb einer Organizational Unit OU pflegen soll.
Zu diesen Daten gehören Felder wie Telefonnummern, Faxnummern, Adressen aber auch der Vorname und Nachname eines Mitarbeiters.
Welche Felder genau, das wird im Abschnitt „Noch einige ergänzende Informationen“ aufgelistet.
Hierzu wird als erstes eine Sicherheitsgruppe „Personalabteilung“ im Active Directory angelegt, damit man dieser die Aufgabe delegieren kann.
Man könnte die Aufgabe zwar auch einem Nutzer direkt delegieren, allerdings hat das dann zwei nicht zu unterschätzende Nachteile:
- Sollte
dieser Mitarbeiter, dem man die Aufgabe delegiert hat, irgendwann
kündigen, dann muss man als Administrator dafür sorgen, dass die
Berechtigungen die mit dem Assistenten vergeben wurden, entfernt werden
und zusätzlich muss man diese Aufgabe, an einen neuen Nutzer, erneut
delegieren. Dieses ganze Hin- und Herdelegieren erspart man sich, indem
man mit Gruppen arbeitet, da dann nur der eine Nutzer aus der Gruppe herausgenommen
wird, und der andere hinein.
Die Idee, Berechtigungen besser auf Gruppenebene zu setzen als für einzelne Benutzer sollte an jeder Stelle überlegt werden an der mit Berechtigungen gearbeitet wird. Also auch und gerade auf Dateisystem/NTFS Ebene und auf Freigaben. Das erleichtert die Arbeit ungemein, denn auch das Gegenteil vom obigen Beispiel kann passieren. Nicht der Mitarbeiter scheidet aus dem Unternehmen aus, sondern es kommt ein weiterer hinzu …
- Jede Vergabe von Rechten im AD hat natürlich auch einen Perfomance-Faktor auf das gesamte Active Directory. Das heißt drastisch formuliert: Je mehr Berechtigungen ich vergebe, desto langsamer wird mein System. Lesenwerter KB-Artikel hierzu ist: http://support.microsoft.com/?kbid=271876
Delegationsassistent
Man beginnt mit dem Delegationsassistenten auf der OU ab der man die Rechte vergeben will.
In diesem Beispiel wird das auf der OU "Test" der Fall sein.
Über das Kontextmenü auf dieser OU wird der Delegationsassistent gestartet. Dieser führt den Administrator dann durch die folgenden Schritte.
Abbildung 1:
Delegationsassistenten starten
Abbildung 2 Hinzufügen der zu berechtigenden Gruppe
Abbildung 3 Auswahl der
zu delegierenden Aufgaben
Abbildung 4 Die Berechtigungen sollen nur auf Benutzerobjekte wirken
Abbildung 5 Welche Berechtigung soll erteilt werden?
Abbildung 6
Zusammenfassung
In dem Fenster der Zusammenfassung steht folgender Text:
Sie haben gewählt, dass im folgenden
Active Directory-Ordner die Objektverwaltung
zugewiesen werden soll:
domain.de/Test
Folgenden Gruppen, Benutzern oder Computern haben
Sie die Objektverwaltung zugewiesen:
Personalabteilung (DOMAIN\Personalabteilung)
Sie haben folgende Berechtigungen:
Lesen und Schreiben Persönliche Informationen
Lesen und Schreiben Öffentliche Informationen
Für folgende Objekttypen:
Benutzer
Damit hat man jetzt schon mal die Delegation als solches hinter sich gebracht. Wenn man sich nun als Mitglied der Gruppe Personalabteilung anmeldet und eine geeignete MMC startet, dann sieht man Folgendes, beim Bearbeiten eines Nutzerobjektes, vor sich:
Abbildung 7 Allgemeine Eigenschaften eines Nutzerobjektes
Abbildung 8 Konteneigenschaften eines Nutzerobjektes
Es werden hier nur die einige Eigenschaftsseiten gezeigt, in denen man jetzt auch Änderungen vornehmen kann. Auf allen anderen kann man zwar etwas eintragen, beim Übernehmen der Änderungen wird man dann aber auf die fehlenden Zugriffsrechte hingewiesen.
Wie man sieht, bewirken die beiden Haken „Lesen und Schreiben von Öffentlichen und Persönlichen Informationen“ schon mal die grundsätzlichen Felder zu bearbeiten.
Zwischenergebnis
Für den Arbeitsablauf innerhalb der Beispielfirma bedeutet dies schon mal, dass die Personalabteilung ab sofort die benötigten Felder selbst eintragen und aktualisieren kann ohne dem Administrator diese erst per Mail mitzuteilen. Man hat also gleich zwei Fliegen mit einer Klappe geschlagen. Als Administrator wird man nicht mehr mit solchen Aufgaben beschäftigt und die Personalabteilung muss nicht auf den Administrator warten, bis dieser die Aktualisierung vornimmt.
Zusatzaufgabe
Oftmals kommt dann aber noch hinzu, dass man gleich noch zusätzliche Aufgaben wie das Entsperren eines Kontos delegieren möchte. (wer schon mal Kontensperrrichtlinien definiert hat weiß was ich meine.J)
Deshalb möchte ich hier auch gleich noch diese Möglichkeit im Anschluss aufzeigen.
Man beginnt wieder mit dem Delegationsassistenten und geht die oben gezeigten Schritte bis zu diesem Fenster:
Abbildung 9 Berechtigungen um ein Nutzerkonto zu entsperren
Dort werden dann die beiden Attribute lockout Time lesen und lockout Time schreiben angehakt und der Assistent danach beendet.
Wer das auch noch mal für Windows 2000 nachlesen möchte findet in der MSKB wie immer den passenden Artikel.
http://support.microsoft.com/?kbid=294952
Wenn man nun das Nutzerobjekt öffnet, kann man dessen Konto entsperren.
Abbildung 10 Nutzerkonto entsperren
Endergebnis
Damit hätte man jetzt eigentlich schon die obige Aufgabe mit Zusatz bestanden.
Dies bedeutet jetzt also, dass man sich als Administrator auf die wichtigeren Aufgaben konzentrieren kann, als Konten zu aktualisieren oder freizuschalten. Zum Beispiel müssen die vorgenommenen Delegationen ja noch sinnvoll dokumentiert werden. Denn zum derzeitigen Stand hat man jetzt das Problem, dass man erst nachschauen muss auf welche OU man welche Rechte delegiert hat. Dies kann natürlich gerade bei vielen Delegationen und einer großen AD-Umgebung recht unübersichtlich werden.
Dokumentation
Um das ganze etwa einfacher zu dokumentieren gibt es in den Supporttools von Windows 2000 und Windows Server 2003 das Tool dsacls.exe
Mit diesem Kommandozeilentool kann man sich unter anderem Berechtigungen im AD anzeigen lassen. (man kann sie auch darüber setzen und ändern)
Wenn man nun an der Kommandozeile folgendes eintippt,
C:\>dsacls OU=Test,DC=domain,DC=de > c:\permission.txt
erhält man im angegebenen Pfad eine .txt Datei, die die gesetzten Rechte auflistet.
Das sieht dann folgendermaßen aus.
Allow DOMAIN\Personalabteilung SPECIAL ACCESS for Personal Information
WRITE PROPERTY
READ PROPERTY
Allow DOMAIN\Personalabteilung SPECIAL ACCESS for Public Information
WRITE PROPERTY
READ PROPERTY
Allow DOMAIN\Personalabteilung SPECIAL ACCESS for lockoutTime
WRITE PROPERTY
READ PROPERTY
Aus Gründen der Übersichtlichkeit habe ich nur den hier interessanten Teil dokumentiert, denn es werden auch alle standardmäßig gesetzten Rechte aufgelistet.
Tipp 1: Der DN (Distinguished Name) der OU oder auch jedes anderen AD Objektes lässt sich am einfachsten mit dem Tool ldp.exe, ebenfalls in den Supporttools enthalten, finden. (Zumindest für diejenigen die nicht fließend ldap sprechen können.)
Tipp 2: Wenn man sich mal in den Rechten verstrickt hat, kann man mittels dsacls.exe die per Standard definierten Rechte zurückbekommen indem man folgendes eintippt: dsacls OU=Test,DC=domain,DC=de /S
Zusatzaufgabe 2
Nachdem jetzt einige Wochen alles super gelaufen ist, stellt man anhand steigender Fragen der Personalabteilung fest, dass es ganz praktisch wäre, wenn diese auch gleich die Postfächer für bestimmte User auf dem Exchange 2003 Server anlegen könnten. Dies würde bedeuten, dass man nur noch die eigentlichen User selbst anlegen müsste und die Personalabteilung kann dann entscheiden ob diese Nutzer E-Mail-berechtigt sein sollen.
Nachfolgend werden die dazu notwendigen Schritte erklärt. Diese wurden zum Teil aus dem MSKB Artikel http://support.microsoft.com/?scid=kb;en-us;316792 übernommen.
Als erstes muss der Gruppe Personalabteilung im Exchange System Manager (ESM) auf die entsprechende „Administrative Gruppe“ die Funktion „Exchange-Administrator – Nur Ansicht“ vergeben werden. Dies geschieht analog zur Delegation im Active Directory nur dass man dazu den ESM benötigt und dort dann den Delegationsassistenten aufruft. Man kann diese Delegation auch auf der Ebene der Exchange Organisiation vergeben, nur ist das in diesem Fall unnötig und birgt nur die Gefahr zu viele Rechte zu vergeben. Sollten mehrere „Administrative Gruppen“ vorhanden sein, muss die Delegation für alle durchgeführt werden in denen die Personalabteilung Postfächer erstellen können soll.
Abbildung 11: Berechtigungsvergabe im Exchange System Manager (ESM)
Um jetzt auch Postfächer erstellen zu können muss die Gruppe Personalabteilung noch einige zusätzliche Active Directory Attribute beschreiben dürfen.
autoReplyMessage
adminDisplayName
displayName
dLMemDefault
homeMDB (Exchange Mailbox Store)
homeMTA
legacyExchangeDN
mailNickname
mAPIRecipient
mDBUseDefaults
msExchADCGlobalNames
msExchControllingZone
msExchFBURL
msExchHideFromAddressLists
msExchHomeServerName (Exchange Home Server)
msExchMailboxGuid
msExchMailboxSecurityDescriptor
msExchPoliciesExcluded
msExchPoliciesIncluded
msExchResourceGUID
msExchUserAccountControl
proxyAddresses
quotaNotificationStyle
quotaNotificationSchedule
showInAddressBook
targetAddress
textEncodedORAddress
Die Berechtigungen auf diese Active Directory Attribute können danach dann wieder mittels „Active Directory Benutzer und Computer“-MMC vergeben werden. Der Einfachheit halber wird hier mal die Kommandozeilenvariante gezeigt. Die nachfolgende Befehlszeile bitte einfach an der Kommandozeile eingeben. Es handelt sich um eine lange Zeile also bitte keine zusätzlichen Enter oder Freizeichen einfügen.
C:\ dsacls "OU=test,DC=domain,DC=de" /I:S /G "\personalabteilung:WP;autoReplyMessage;user" "\personalabteilung:WP;adminDisplayName;user" "\personalabteilung:WP;dLMemDefault;user" "\personalabteilung:WP;homeMDB;user" "\personalabteilung:WP;homeMTA;user" "\personalabteilung:WP;legacyExchangeDN;user" "\personalabteilung:WP;mail;user" "\personalabteilung:WP;mailNickname;user" "\personalabteilung:WP;mAPIRecipient;user" "\personalabteilung:WP;mDBUseDefaults;user" "\personalabteilung:WP;msExchADCGlobalNames;user" "\personalabteilung:WP;msExchControllingZone;user" "\personalabteilung:WP;msExchFBURL;user" "\personalabteilung:WP;msExchHideFromAddressLists;user" "\personalabteilung:WP;msExchHomeServerName;user" "\personalabteilung:WP;msExchMailboxGuid;user" "\personalabteilung:WP;msExchMailboxSecurityDescriptor;user" "\personalabteilung:WP;msExchPoliciesExcluded;user" "\personalabteilung:WP;msExchPoliciesIncluded;user" "\personalabteilung:WP;msExchRecipLimit;user" "\personalabteilung:WP;msExchResourceGUID;user" "\personalabteilung:WP;msExchUserAccountControl;user" "\personalabteilung:WP;proxyAddresses;user" "\personalabteilung:WP;quotaNotificationStyle;user" "\personalabteilung:WP;quotaNotificationSchedule;user" "\personalabteilung:WP;showInAddressBook;user" "\personalabteilung:WP;targetAddress;user" "\personalabteilung:WP;textEncodedORAddress;user" "\personalabteilung:WP;displayName;user"
Wie bereits erwähnt findet sich dieser Befehl auch in einem MSKB Artikel, nur leider ist in diesem ein kleiner Fehler und deswegen wird man bei Ausführung dieses Befehls dann eine Fehlermeldung beim Postfacherstellen erhalten.
Für jedes Attribut erhält man dabei eine Bestätigung über die korrekte Berechtigungsvergabe nach folgendem Muster:
Allow DOMAIN\Personalabteilung SPECIAL ACCESS for msExchFBURL
WRITE PROPERTY
Nun noch an die fällige Dokumentation der vorgenommenen Änderungen denken und alles läuft zur Zufriedenheit. Auf den Computern der Personalabteilung muss jetzt noch der Exchange Systemmanager (inklusive eventueller Exchange Service Packs) installiert werden, damit die entsprechenden „Exchange Aufgaben“ in der MMC zur Verfügung stehen.
Zusammenfassung
Anhand der obigen Anleitung kann man erkennen, welch mächtiges Werkzeug Microsoft dem Administrator mit der Aufgabendelegation an die Hand gegeben hat. Man kann die Rechtevergabe sozusagen auf jedes einzelne, im Active Directory vorhanden, Attribut anwenden. Und dadurch sehr differenziert Berechtigungen an Nutzergruppen verteilen. Man muss darauf achten, die Dokumentation immer im gleichen Zuge wie die Delegation zu erstellen, damit man im Falle eines Falles nicht erst lange suchen muss. Ich hoffe die Anleitung hat geholfen einige Fragen zu klären. Für Feedback bin ich natürlich immer offen.
Noch einige ergänzende Informationen
Vielleicht haben sich ja einige gefragt, welche Attribute werden eigentlich von den beiden gesetzten Haken „persönliche und öffentliche Informationen“ beeinflusst. Hier dann die Antwort:
Personal Information
The following table describes the Personal Information property sets.
Personal Information Property Sets
|
Term |
Description |
|
Description |
Property set containing user attributes that describe personal user information. |
|
CN |
Personal-Information |
|
Display-Name |
Personal Information |
|
Rights-GUID |
77B5B886-944A-11d1-AEBD-0000F80367C1 |
|
Applies-To |
Computer (Schema ID GUID: bf967a86-0de6-11d0-a285-00aa003049e2) |
|
Property Set Members |
Address Address-Home Assistant Comment Country-Name Facsimile-Telephone-Number International-ISDN-Number Locality-Name MSMQ-Digests MSMQ-Sign-Certificates Personal-Title Phone-Fax-Other Phone-Home-Other Phone-Home-Primary Phone-Ip-Other Phone-Ip-Primary Phone-ISDN-Primary Phone-Mobile-Other Phone-Mobile-Primary Phone-Office-Other Phone-Pager-Other Phone-Pager-Primary Physical-Delivery-Office-Name Picture Post-Office-Box Postal-Address Postal-Code Preferred-Delivery-Method Registered-Address State-Or-Province-Name Street-Address Telephone-Number Teletex-Terminal-Identifier Telex-Number Telex-Primary User-Cert User-Shared-Folder User-Shared-Folder-Other User-SMIME-Certificate X121-Address X509-Cert |
Public-Information
The following table describes the Personal Information property sets.
Public Information Property Sets
|
Term |
Description |
|
Description |
Property set containing user attributes that describe user public information |
|
CN |
Public-Information |
|
Display-Name |
Public Information |
|
Rights-GUID |
e48d0154-bcf8-11d1-8702-00c04fb96050 |
|
Applies-To |
Computer (Schema ID GUID: bf967a86-0de6-11d0-a285-00aa003049e2)
inetOrgPerson (Schema ID GUID: 4828CC14-1437-45bc-9B07-AD6F015E5F28) |
|
Property Set Members |
Additional-Information Allowed-Attributes Allowed-Attributes-Effective Allowed-Child-Classes Allowed-Child-Classes-Effective Alt-Security-Identities Common-Name Company Department Description Display-Name-Printable Division E-mail-Addresses Given-Name Initials Legacy-Exchange-DN Manager ms-DS-Allowed-To-Delegate-To ms-DS-Approx-Immed-Subordinates ms-DS-Auxiliary-Classes Obj-Dist-Name Object-Category Object-Class Object-Guid Organization-Name Organizational-Unit-Name Other-Mailbox Proxy-Addresses RDN Reports Service-Principal-Name Show-In-Address-Book Surname System-Flags Text-Country Title User-Principal-Name |
Die Daten wurden aus
Microsofts Whitepaper zum Thema Active Directory Delegation entnommen. Zu finden
sind diese beiden Dokumente unter folgenden Links:
http://www.microsoft.com/downloads/details.aspx?FamilyID=631747a3-79e1-48fa-9730-dae7c0a1d6d3&DisplayLang=en
http://www.microsoft.com/downloads/details.aspx?FamilyID=29dbae88-a216-45f9-9739-cb1fb22a0642&DisplayLang=en
Weiterführende Links:
http://support.microsoft.com/?kbid=308404
http://support.microsoft.com/?kbid=296490
http://support.microsoft.com/?kbid=294952
http://support.microsoft.com/?kbid=279723
http://support.microsoft.com/?kbid=271876
http://support.microsoft.com/?kbid=316792