Exchange Adminkonzept

Diese Beschreibung ist für Exchange 2000/2003. Exchange 2007 nutzt ein anderes Berechtigungsmodell.

Auf der Seite Adminkonzept habe ich einige Informationen zu Prinzipien einer administrativen Delegierung von Berechtigungen beschrieben. Diese Seite beschäftigt sich mehr mit den Exchange Berechtigungen, d.h. wie Sie vielleicht in ihrer Umgebung die Berechtigungen etwas weiter vergeben können, so dass nicht alle IT-Mitarbeiter auch "Exchange Fulladmin" sind, wenn es nicht notwendig ist: Denn der größte Feind einer stabilen Umgebung ist der Administrator, der mit zu vielen Berechtigungen sorglos hantiert. Dazu gehört, dass man eben nicht als Administrator auch seine Mails liest oder im Internet surfte. Und dass man als Administrator auch nur die Rechte des täglichen Bedarf ausüben kann und besonders kritischen Berechtigungen (z.B. Schema Admin, Exchange Organisationsadministrator, Mailbox Full Admin) gesonderten Konten vorbehalten bleiben.

Unterstützung durch Net at Work:
Diese Seite kann nur eine Einführung sein. Kleine Firmen werden vermutlich nur eine Teilmenge davon umsetzen, während größere Firmen sehr viel mehr als diese paar Abschnitte definieren sollten. Wir können Sie hier natürlich unterstützen.

Grundprinzipien

Die Verwaltung von Exchange Einstellungen, Exchange Servern und Exchange Empfängern wird über Berechtigungen im Active Directory und auf den Servern gesteuert. Daher sollten Sie einige Grundregeln beachten:

  • Keine Berechtigungen an Benutzer
    Es werden keine Benutzer für die Vergabe von Berechtigungen verwendet. Einzig die durch das Exchange Setup eingetragenen Computerkonten (Exchange Server) sind erlaubte Einzelberechtigungen
  • Berechtigungen nur über dazu bestimmte universelle Sicherheitsgruppen
    Für die Vergabe von Berechtigungen werden entsprechende Sicherheitsgruppen angelegt und verwendet.
  • Keine Deaktivierung von Vererbung auf Objektebene.
    Die Vererbung von Berechtigungen auf Objekt bzw. Containerebene wird nicht deaktiviert. Eine Vergabe von Rechten "nur auf dieses Objekt" sind aber möglich.
  • DENY nur in Ausnahmefällen
    Um Berechtigungen zu entfernen kann mit DENY gearbeitet werden. Dies sollte aber nur in Ausnahmefällen und mit einem sehr engen Fokus erfolgen.
  • Keine Änderung der "Default Berechtigungen" von Exchange
    Die Berechtigungen, welche von Exchange bei der Installation oder über Assistenten gesetzt werden, werden nicht verändert. Es werden nur zusätzliche Rechte vergeben.
  • Beschränkung auf die Rechte des Exchange Assistenten
    An Stellen ohne Assistent werden nur einfache Rechte verwendet. (nicht erweitert)
  • Admin-Account
    Die Berechtigungen zur Verwaltung werden nur an spezielle Admin-Accounts vergeben. „Normale“ Benutzer erhalten keine administrative Berechtigungen.
  • ChangeLog
    Alle Änderungen der Berechtigungen werden protokolliert (Sharepoint-Liste oder gesondertes Changelog)

Tätigkeiten und ihre Berechtigungen

Um die benötigten Berechtigungen und Gruppen entwerfen zu können, sind die gewünschten Aufteilungen der Zuständigkeiten zu definieren. Hier eine kleine Auswahl von möglichen Rollen, die mit entsprechenden Berechtigungen versehen werden können.

Tätigkeiten Berechtigungen

Benutzer verwalten
Anlegen, ändern, Löschen, Mailadresse zuweisen, Quota

Rechte in der OU und Exchange Read

Sonderfall Mail versucht SA zu erreichen

Postfach Aktionen
Exmerge, Postfach Moven

  • Rechte in der OU
  • Rechte auf Mailbox (SendAs/RcvAs/ oder auf Quell/Zielstore

Verteiler
Anlegen, ändern, Löschen, Mailadresse zuweisen, Quota

  • Rechte in der OU und Exchange Read
  • Sonderfall Mail versucht SA zu erreichen

Kontakt
Anlegen, ändern, Löschen, Mailadresse zuweisen, Quota

  • Rechte in der OU und Exchange Read
  • Sonderfall Mail versucht SA zu erreichen

PF-Folder

  • Anlegen durch den User mit Outlook unter "seinen Ordner". Optional Berechtigungen wenn erlaubt
  • Anlegen der BasisOrdner und Berechtigung, Replikation, Mailenabled etc. durch PF Admin 

AG Administration
Einrichten neuer AGs, Berechtigungen anpassen

  • Exchange Administrator über die Organisation

Server Backup/restore/Desaster Recovery

  • Exchange Admin über die administrative Gruppe

Queue Management

  • Lokaler Admin (Perfmon)
  • Exchange View bis zum Server
  • remove Message erfordert LokalAdmin

MessageTracking

  • Exchange Org – VIEW
  • Read auf "Tracking Share" + WMI-Berechtigungen
    Alternative: eigene DB/MessageStats (?)

How to Grant WMI Permissions für Message Tracking
http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3ADPerm/29fa71f4-60bc-4fea-98eb-86528a9106d9.mspx?mfr=true

Besondere Tätigkeiten für Organisationsadministratoren

Seltene Aufgaben die vom Exchange Org Admin durchgeführt werden und daher nicht delegiert werden. Hinzu kommt, dass diese Tätigkeiten nur sehr selten durchgeführt werden müssen und entsprechende Kenntnisse daher nicht jeder Administrator haben muss.

  • Verwaltung der administrativen Gruppen
    Das Anlegen, Delegieren und Löschen von administrativen Gruppen sind eher seltene und gravierende Änderungen . Es ist sinnvoll diese äderungen bei der Standardgruppe des Exchange OrganisationsAdministratoren zu belassen.
  • Verwaltung der Routinggruppen und Connectoren
    Auch die Verbindungen zwischen den verschiedenen Routinggruppen werden durch den Exchange Organisation Admin verwaltet und nicht gesondert delegiert. Sie sind theoretisch aber auch durch den Admin der administrativen Gruppe verändert werden.
  • RUS und Empfängerrichtlinien
    Der Empfängeraktualisierungsdienst ist eine wichtige Infrastruktureinrichtung, die ebenfalls nur durch entsprechend geschulte Mitarbeiter verändert werden sollten
  • Adressbuchansichten und Offline Adressbücher
    Diese Einstellungen sollten ebenfalls zentral koordiniert werden und müssen daher nicht delegiert werden
  • öffentliche Ordner (Standard)
    Die öffentlichen Ordner sollten in der Regel „flach“ und einfach gehalten sein. Wenn lokale Benutzer oder Administratoren mit Outlook Ordner in ihrem „Teilzweig“ anlegen dürfen, dann erben diese Ordner die Replikationseinstellungen des darüberliegenden Ordners. Dies ist in den meisten Fällen ausreichend. Daher ist zu prüfen, ob es überhaupt erforderlich ist, die Administration von Teilbereichen an andere Administratoren zu delegieren. Gerade Fehler bei der Konfiguration hinsichtlich der Replikation können sehr schnell zu hohen Datenvolumen führen und sollten daher vermieden werden. Ideal ist ein Ordnerkonzept, welches die Ordner weitgehend festlegt und daher nach der Ersteinrichtung kaum Änderungen mehr erforderlich sind.
  • öffentliche Ordner (System)
    Einstellungen der Systemordner (Offline Adressbuch, Free/Busy-Zeiten, Formulare) bleiben den Organisationsadministratoren vorbehalten. Eine Delegierung ist hier nicht erforderlich, da Änderungen nur sehr selten durchgeführt werden und eine zentrale Kontrolle erhalten bleiben soll.
  • Site Recovery (Free/Busy etc.)
    Die Wiederherstellung kompletter Standorte und speziell der „Sitefolder“ wird sicher nicht der Administrator einer administrativen Gruppe durchführen, sondern bleibt auch den Organisationsadministratoren vorbehalten.

3. Übersicht der Objekte und Rechte

Folgende Objekte und Ort können mit Rechten versehen werden:

  • Exchange Organisation
    Auf dieser Ebene benötigen alle Gruppen, die mit etwas mit der Exchange Konfiguration zu tun haben, zumindest das Recht zu „Lesen“. Das Schreibrecht erlaubt zudem die Änderung von Empfängerrichtlinien, RUS, Adressbüchern, OAB etc. Und sollte sehr wenigen Personen eingeräumt werden. Im Idealfall genau einer administrativen Gruppe.
  • Exchange Admininistrative Gruppe
    Pro administrativer Gruppe sind können die darin enthaltenen Server, Datenbanken Connectoren und anderen Einstellungen delegiert werden. Über die aktive Vererbung hat hier jede Gruppe mit Lesenrecht auf der Exchange Organisation ebenfalls READ.
    Sofern erforderlich können über eigene administrative Gruppen hier Lesen und Schreiben delegiert werden.
    Hinweis: Ab Exchange 12 wird diese Zwischenstufe vermutlich entfallen.
  • EX- Server
    Die nächste Stufe ist der jeweilige Server selbst, auf den Berechtigungen vergeben werden. Dies sind aber Rechte auf das Exchange Objekt und sind nicht mit den Berechtigungen auf den Server als Hardware und Betriebssystem zu verwechseln. Diese Rechte erlauben dem Administrator z.B. die Datenbanken auf dem Server zu stoppen und zu starten und Servereinstellungen vorzunehmen, sofern diese nicht durch Richtlinien vorgegeben werden.
    Normal werden hier keine weiterer Delegierung vorgenommen. Erst mit E12 wird dies interessant.
  • Exchange Mailbox Store
    Unter dem Server gibt es die Speichergruppen mit den Datenbanken, die ebenfalls separat berechtigt werden können. Dies wird z.B.: genutzt, um das „SendAs“-Recht für Migrationen, Move-Mailbox oder den Einsatz von ExMerge zu setzen.
  • Exchange öffentliche Ordner
    Administrative Berechtigungen auf öffentliche Ordner dienen dazu, z.B. die Konfiguration von Einstellungen der Replikation, Grenzwerte, Mailadresse etc. zu delegieren. Diese Rechte sind nicht mit den Inhalten (Editor, Autor etc.) zu verwechseln. Und sind nicht erforderlich, um Ordner anzulegen oder die Rechte auf die Inhalte zu pflegen.
    Hier ist zu prüfen, ob eine Delegierung überhaupt erforderlich ist und die Verwaltung von Mailadresse und Replikaten nicht zentralisiert erfolgen soll, zumal der Public Folder Tree eine administrativen Gruppe zugeordnet ist.
  • Active Directory Benutzer/Kontakte/Verteiler in OUs
    Die eigentlichen Empfänger von Nachrichten sind nicht in der Exchange Konfiguration zu finden, sondern normale Objekte in der jeweiligen Domänenpartition und werden dort in OUs abgelegt. Wenn Sie Benutzeradministratoren zugleich auch die Exchange Eigenschaften verwalten sollen, ist das OU-Berechtigungskonzept maßgeblich. Die Administratoren benötigen allerdings noch selektiv Leserechte auf die Exchange Konfiguration um z.B. Postfächer anzulegen. (Anzeige der verfügbaren Datenbanken).
    Jeder Standort hat seine eigene OU mit weiteren unterOU’s für die verschiedenen Objekte. Über Berechtigungen wird sichergestellt, dass
  • SRV Exchange lokal Server
    Zuletzt sind für bestimmte Aktivitäten auch entsprechende Berechtigungen auf dem Server und Betriebssystem erforderlich, z.B. zum Stoppen und Starten von Diensten, Installationen von Update und Patches oder die Verbindung zu WMI, Freigaben (trackinglog) und Registrierung (Diagnoseprotokoll)

Für die verschiedenen Tätigkeiten müssen entsprechende Rechte über Gruppen und Gruppenmitgliedschaften vergeben werden.

Konzeptvorschlag

Basierend auf den Annahmen zur Delegierung von Berechtigungen könnte folgendes vereinfachtes Berechtigungsmodell angesetzt werden.

  • Kooperation statt Konfrontation
    Das System erlaubt eine sehr feine und restriktive Konfiguration von Berechtigungen auf einzelne Objekte und sogar einzelne Eigenschaften. Allerdings wird dies immer schwerer zu verwalten und zu überschauen. Über „Tätigkeitsbeschreibungen“ wird festgelegt, welcher Personenkreis für welche Tätigkeiten zuständig ist, auch wenn die Berechtigungen mehr Änderungen zulassen würden. Der Aufwand dies alles 100% dicht zu machen ist nicht zu rechtfertigen. (Siehe auch 313807 XADM: Enhancing the Security of Exchange 2000 für the Exchange Domain Servers Group)
  • Jeder Exchange Admin kann „sehen“
    Es wird darauf verzichtet, die Inhalte von Administrativen Gruppen über „DENY“ oder andere Wege vor Benutzern zu verbergen. Dies macht die Vergabe einfacher, da damit ein READ auf der Organisation für alle Exchange Administratoren für viele Aufgaben ausreichend ist und keine Vererbung deaktiviert werden muss
  • Wenige ORG-Administratoren
    Aufgrund der globalen Wirkung von Empfängerrichtlinien, RUS und Adressbüchern ist die Anzahl der Administratoren mit ORG-Rechten beschränkt.
  • Effektive und zugleich unterste Berechtigungsstufe ist die Admingroup
    Es wird darauf verzichtet, einzelne Berechtigungen auf einzelne Server, Speichergruppen oder Datenbanken zu vergeben oder zu verbieten.
    Meist ist ein Admin der AdminGroup auch Admin über die Server und kann auch so über Umwege (Backup, PowerControls o.ä.) auf alle Mailboxen zugreifen, d.h. ein Verbot in Exchange ist nur vordergründig wirksam.
  • MailboxAdmin
    Eine besondere Rolle kommt den Personen zu, die auch in die Mailboxinhalte Einblick nehmen können oder müssen (z.B. ExMerge, Migration, Archiv, Auswertungen, Virenscan). Dieses Recht ist an der Regel an „SendAs/ReceiveAs“ des Users oder der Datenbank gebunden und für Administratoren mit einem DENY versehen. Ein explizites Recht auf den User oder die Datenbank gewinnt aber und ist daher der geeignete Weg diese Funktion zu erlauben. (MSXFAQ.DE - Mailboxrechte)
  • Rechte per Assistent
    Für die Vergabe der Berechtigungen wird der Berechtigungsassistent des Exchange System Managers genutzt. Die Rechte beschränken sich auf „NONE, READ, ADMIN, FULLADMIN.
    Benefiting from Exchange Administration Delegation Wizard
    http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3AdminGuide/b9ba8186-737d-4e86-99bb-6374e25082f7.mspx
    Natürlich wird es Ausnahmen geben, die durch den Wizard nicht eingestellt werden können.
  • FullAdmin limitert
    Die Berechtigung „Full Admin“ ist auf die OrganisationsAdministratoren beschränkt. Damit ist sichergestellt, dass Berechtigungen selbst nicht durch lokale Administratoren weiter delegiert werden können.

Umsetzung

Nachdem Sie nun gelesen haben, welche Berechtigungen vergeben werden können, nachdem Sie die entsprechenden Rollen und die ausübenden Personen definiert haben, geht es zuletzt natürlich an die Umsetzung dieser Berechtigungsstruktur. Dazu sind im wesentlichen folgende Schritte erforderlich:

  • Namenskonzept für Gruppen
    Für die Vergabe von Berechtigungen sind Sicherheitsgruppen erforderlich. Ein Namenskonzept hilft bei der unterscheidung von Gruppen für Datenzugriffen (Freigaben und NTFS) und Verteilergruppen.
  • Anlegen der Sicherheitsgruppen
    Weiterhin sind die Gruppen selbst in einer geeigneten OU anzulegen, so dass unerlaubte Änderungen ausgeschlossen sind. Hierzu bieten sich universelle Sicherheitsgruppen an. Die SID ist für die Berechtigung erforderlich und wenn Sie mehrere Domänen in einem Forest betreiben, dann sind universelle Gruppen aufgrund ihrer Auflösung über den GC besser geeignet.
  • Berechtigungen delegieren
    Diese neu geschaffenen Gruppen werden nun verwendet, um an den verschiedenen Stellen die erforderlichen Berechtigungen einzutragen.
  • Pflegen der Mitgliedschaften
    In diese neu geschaffenen Gruppen sind die entsprechenden administrativen Benutzerkonten aufzunehmen. Allerdings sollten Sie hier noch keine "Fakten" schaffen, sondern erst mal nur einen "Testadmin" einfügen und damit prüfen, ob die vergebenen Berechtigungen auch der zugeteilten Rolle entsprechen. Erst dann sollten Sie die gewünschten administrative Konten in die Gruppe aufnehmen.

Natürlich sind die Möglichkeiten der MSXFAQ begrenzt hier ein vollständiges Konzept für alle Anwendungsfälle und Umgebungen zu erstellen. Das kann ich nicht im Rahmen der Webseite leisten.

Unterstützung durch Net at Work:
Wenn Sie Unterstützung bei einer individuellen Ausarbeitung benötigen, dann sprechen Sie uns doch einfach an.

Weitere Links