Details des Zugriffssteuerungsprozesses in Exchange

Letztes Änderungsdatum des Themas: 2006-12-04

Wie bereits unter Zugreifen auf Exchange-Objekte erläutert, verwendet Microsoft® Exchange einen zweistufigen Vorgang zur Steuerung des Zugriffs auf Elemente im Exchange-Informationsspeicher:

• Einleitende Prüfungen   Durch diese Prüfungen wird der Zugriffssteuerungsprozess optimiert und beschleunigt. Bestimmte Typen von Benutzern verfügen immer über Vollzugriff auf Elemente im Exchange-Informationsspeicher (mit Ausnahme der administrativen Aufgaben in Öffentlichen Ordnern), weshalb weitere Überprüfungen unnötig sind und der Benutzer sofort Zugriff auf das angeforderte Element erhält. Zusätzlich wird bei der Notwendigkeit von anschließenden Zugriffsüberprüfungen (z. B. bei einem qualifizierten Benutzer, der administrativen Zugriff auf einen Öffentlichen Ordner anfordert) durch die einleitenden Prüfungen ermittelt, welcher Berechtigungssatz für die Folgeüberprüfungen des Zugriffs zu verwenden ist.
• Zugriffssteuerung auf Objektebene   Jedes Objekt im Exchange-Informationsspeicher (Postfach, Ordner oder Nachricht) verfügt über einen Satz von Sicherheitsbeschreibungen. Jede Sicherheitsbeschreibung ist ein Attribut, das Informationen darüber enthält, welche Benutzer Zugriff auf das Objekt haben und welcher Art der Zugriff pro Benutzer sein darf. Zur Steuerung des Zugriffs auf spezielle Objekte wie Öffentliche Ordner-Strukturen (im Gegensatz zu einzelnen Öffentlichen Ordnern) sowie zur Steuerung der erweiterten Eigenschaften von E-Mail-aktivierten Öffentlichen Ordnern werden zusätzliche Steuerelemente verwendet.

Ausführen von einleitenden Prüfungen

Exchange verwendet eine Reihe einleitender Prüfungen, um zu ermitteln, welche Art von Überprüfung (falls überhaupt) bei der Prüfung der Zugriffssteuerung auf Objektebene anzuwenden ist.

Anmerkung:

In diesem Abschnitt werden zwei einleitende Prüfungen beschrieben. Exchange führt eine weitere einleitende Prüfung aus, um zu bestimmen, ob der Benutzer Zugriff auf ein Attribut eines Ordners oder einer Nachricht anfordert. Eine vollständige Behandlung des von Exchange zur Implementierung der Zugriffssteuerung für einzelne Attribute verwendeten Mechanismus geht jedoch über den Rahmen dieses Handbuchs hinaus.

Ermitteln des Benutzertyps

Wenn ein Benutzer versucht, auf ein Objekt im Exchange-Informationsspeicher zuzugreifen, prüft Exchange vor der Überprüfung der Zugriffssteuerungseinstellungen auf Ordner- oder Nachrichtenbene zuerst, ob der Benutzer einer der folgenden Benutzertypen ist:

• Postfachbesitzer (nur bei Postfächern)   Der Postfachbesitzer verfügt über Vollzugriff auf das Postfach mit allen darin enthaltenen Nachrichten. Es werden keine weiteren Prüfungen vorgenommen.
• Exchange-Administrator - Vollständig   Bei Verwendung einer administrativen Anwendung verfügt ein vollständiger Administrator über Vollzugriff auf alle Objekte im Exchange-Informationsspeicher. Es werden daher keine weiteren Prüfungen mehr vorgenommen (mit Ausnahme von Anforderungen zur Ausführung administrativer Aufgaben an Öffentlichen Ordnern; siehe weiter unten in diesem Thema unter "Ermitteln des Typs der Clientanwendung").
• Exchange-Administrator mit Leserechten   Bei Verwendung einer administrativen Anwendung verfügt ein Administrator mit Leserechten über Lesezugriff auf alle Objekte im Exchange-Informationsspeicher. Es werden daher keine weiteren Prüfungen mehr vorgenommen, bevor dem Benutzer Zugriff auf dieser Ebene gewährt wird. Weitere Informationen zu administrativen Anwendungen finden Sie unter "Ermitteln des Typs der Clientanwendung".

Ermitteln des Typs der Clientanwendung

Wenn ein Benutzer Zugriff auf einen Öffentlichen Ordner oder auf eine in einem Öffentlichen Ordner enthaltene Nachricht anfordert, prüft Exchange, ob der Benutzer einem der im vorangehenden Abschnitt beschriebenen Benutzertypen entspricht. Exchange überprüft außerdem, welcher Typ von Anwendung von dem Benutzer ausgeführt wird. Exchange führt diese Überprüfungen aus, um zu ermitteln, ob bei anschließenden Zugriffsüberprüfungen die Sicherheitsinformationen verwendet werden sollen, die den normalen Clientzugriff steuern, oder die, die den administrativen Clientzugriff steuern. Exchange speichert die zwei Typen von Sicherheitsinformationen voneinander getrennt (wie weiter unten in diesem Thema unter "Aufbau der Zugriffssteuerung auf Objektebene" beschrieben).

Anmerkung:

Wenn der Benutzer, der Zugriff auf einen Öffentlichen Ordner oder auf eine in einem Öffentlichen Ordner enthaltene Nachricht anfordert, eine administrative Anwendung ausführt, aber nicht einem der im vorangehenden Abschnitt beschriebenen Benutzertypen entspricht, (z. B. Endbenutzer, der nicht Besitzer des angeforderten Objekts ist), ignoriert Exchange die Anforderung des Benutzers nach administrativem Zugriff und behandelt ihn, als ob er eine normale Clientanwendung verwendete.

Wie bereits unter Zugreifen auf Exchange-Objekte erläutert, behandelt Exchange eine Aktion, die in einer Clientanwendung wie Microsoft Outlook® ausgeführt wird, als Clientaktion (d. h. als eine Aktion, die normalen Clientzugriff benötigt), auch wenn der Benutzer selbst die Aktion als "administrativ" einschätzt. Wenn ein Benutzer beispielsweise die Berechtigungen für einen Öffentlichen Ordner ändert und hierzu Outlook verwendet, behandelt Exchange die Aktion als Clientaktion (d. h. als eine Aktion, die normalen Clientzugriff benötigt). Verwendet der Benutzer jedoch den Exchange-System-Manager (eine administrative Anwendung) zum Ändern der Berechtigungen des Öffentlichen Ordners, behandelt Exchange die Aktion als administrativ (d. h. als eine Aktion, die administrativen Clientzugriff benötigt). Diese Unterscheidung zwischen einer Client- und einer administrativen Aktion bietet Schutz vor eine versehentlichen Sperrung. Kein Benutzer von Outlook (noch nicht einmal der Ordnerbesitzer) kann die Berechtigungen, die den Zugriff steuern, mithilfe des Exchange-System-Managers ändern und so einen Administrator daran hindern, unter Verwendung des Exchange-System-Managers auf den Öffentlichen Ordner zuzugreifen.

• Wenn Sie benutzerdefinierte Anwendungen entwickeln, muss Exchange in der Lage sein, diese entweder als administrative oder als Endbenutzeranwendungen zu erkennen. Weitere Informationen finden Sie im Microsoft Exchange Software Development Kit (SDK) (für Exchange 2000 Server oder Exchange Server 2003) im Thema "Exchange Store URLs" unter "Using the Administrative Virtual Root" sowie in "CDO for Exchange Management" unter "Exchange Management Security". Sie können das Exchange SDK von der Exchange Server MSDN-Website herunterladen oder das SDK online anzeigen.
• Zusätzliche Informationen über das Erlangen des Besitzes eines Objekts finden Sie in den Themen "Access Control" und "Security" im Exchange SDK.

Aufbau der Zugriffssteuerung auf Objektebene

Um die Art zu verstehen, in der die Zugriffssteuerung von Exchange gehandhabt wird, ist es notwendig, die Grundlagen der Zugriffssteuerung zu untersuchen, wie sie im (von Exchange erweiterten und veränderten) Sicherheitsmodell von Microsoft® Windows 2000 implementiert ist.

Wenn Sie benutzerdefinierte Anwendungen entwickeln, muss Exchange in der Lage sein, diese entweder als administrative oder als Endbenutzeranwendungen zu erkennen. Weitere Informationen finden Sie im Thema Eigenschaften nach Namespace im Exchange SDK.

Weitere Informationen zum Arbeiten mit Sicherheitsbeschreibungen von Ordnern und Nachrichten finden Sie im Exchange SDK unter "Reference" unter "Application Security Module Reference".

Sicherheitsbeschreibungen

Jedes Objekt im Exchange-Informationsspeicher (Postfach, Ordner oder Nachricht) verfügt über zwei Sicherheitsbeschreibungen:

• Windows NT-Sicherheitsbeschreibung   Jedes Objekt in einem Windows 2000-System hat eine Microsoft Windows NT®-Sicherheitsbeschreibung. Diese Sicherheitsbeschreibung, die im Exchange SDK als das Feld ntsecuritydescriptor (bzw. auch als die Eigenschaft ptagNTSD) beschrieben wird, gilt für die meisten Vorgänge, die Benutzer mit dem Objekt ausführen (z. B. Lesen oder Bearbeiten von Nachrichten).
• Admin-Sicherheitsbeschreibung   Jedes Exchange Server 2003-Objekt hat eine Admin-Sicherheitsbeschreibung. Diese Sicherheitsbeschreibung, die im Exchange SDK als das Feld admindescriptor (bzw. auch als die Eigenschaft ptagAdminNTSD) beschrieben wird, gilt für administrative Aktionen (z. B. Erstellen oder Löschen von Öffentlichen Ordnern).

Beide Typen von Sicherheitsbeschreibungen enthalten dieselben Informationen, die für Exchange relevant sind:

• Steuerungsinformationen (Informationen über die Sicherheitsbeschreibung; z. B. ob sie explizit oder mithilfe eines Mechanismus zur Erzeugung von Standardwerten erstellt wurde).
• Den Besitzer des Objekts.
• Die primäre Gruppe, der der Objektbesitzer angehört.
• Die freigegebene Zugriffssteuerungsliste (Discretionary Access Control List, DACL).
• Die System-Zugriffssteuerungsliste (System Access Control List, SACL).

  Anmerkung:
  Sicherheitsbeschreibungen können zusätzliche Informationen enthalten, die aber von Exchange 2003 nicht verwendet werden.

Eine vollständige Beschreibung der Elemente einer Sicherheitsbeschreibung in Windows 2000 finden Sie unter "Access Control" in Kapitel 12 des Bands Verteilte Systeme des Microsoft Windows 2000 Resource Kits.

ACLs und ACEs

Im Exchange-Informationsspeicher bestehen die beiden in Sicherheitsbeschreibungen verwendeten Zugriffssteuerungslisten, freigegebene Zugriffssteuerungslisten (Discretionary Access Control List, DACL) und System-Zugriffssteuerungslisten (System Access Control List, SACL), wie in Windows 2000 primär aus Listen von Zugriffssteuerungseinträgen (Access Control Entry, ACE). In der SACL enthaltene ACEs beziehen sich auf Überwachungs- und Alarmfunktionen, während in der DACL enthaltene ACEs steuern, welche Benutzer Aufgaben mit gesicherten Objekten ausführen dürfen und welche Aufgaben dies sein können. Primär werden in diesem Handbuch die in der DACL enthaltenen ACEs behandelt.

Jeder ACE enthält die folgenden Informationen (diese Liste ist eine vereinfachte Darstellung):

• ACE-Typ (entweder "Zugriff gewähren" oder "Zugriff verweigern")
• Sicherheits-ID (SID) des Benutzers oder der Gruppe, dem/r Zugriff gewährt oder verweigert wird.
• Spezifische Berechtigungen, die gewährt oder verweigert werden sollen (in Form einer hexadezimalen Zugriffsmaske).
• Kennzeichen, die weitere Informationen über die Verarbeitungsweise des ACE angeben. Folgende Kennzeichenwerte sind möglich:
  • OBJECT_INHERIT_ACE Der ACE soll an Objekte innerhalb dieses Containers vererbt werden.
  • CONTAINER_INHERIT_ACE   Der ACE soll an Container vererbt werden, die unterhalb dieses Containers erstellt werden.
  • NO_PROPAGATE_INHERIT_ACE   Der ACE wird nur an die unmittelbar untergeordneten Container dieses Containers weitergegeben, aber nicht an Container, die unterhalb der unmittelbar untergeordneten Container erstellt werden.
  • INHERIT_ONLY_ACE   Der ACE ist nicht für dieses Objekt gültig, sondern wirkt sich nur auf Objekte aus, die unterhalb dieses Objekts erstellt werden.
  • INHERITED_ACE   Der ACE wurde von einem übergeordneten Objekt geerbt.

Die Kennzeichen OBJECT_INHERIT_ACE, CONTAINER_INHERIT_ACE und INHERIT_ONLY_ACE sind für die Art, in der Sicherheit von Exchange verwaltet wird, besonders wichtig. Exchange markiert mit diesen Kennzeichen auf folgende Weise, ob ein ACE für Ordner oder Nachrichten gilt:

• Ordner-ACEs werden mit dem Kennzeichen CONTAINER_INHERIT_ACE markiert.
• Nachrichten-ACEs werden mit den Kennzeichen OBJECT_INHERIT_ACE und INHERIT_ONLY_ACE markiert.

Reihenfolgen von ACEs in der ACL

Manche der Windows NT-Sicherheitsbeschreibungen, die für Objekte im Exchange-Informationsspeicher verwendet werden, verwenden eine andere Reihenfolge der ACEs in der DACL als die von Windows NT-Standardsicherheitsbeschreibungen verwendete Reihenfolge (Windows NT-"Standard"sicherheitsbeschreibungen werden von Objekten im Active Directory®-Verzeichnisdienst und dem Windows 2000-Dateisystem verwendet).

Für Öffentliche Ordner-Anwendungshierarchien unterstützt Exchange die Windows 2000-Standardregeln für die Reihenfolge von ACEs.

MAPI-Clients wie Outlook verwenden jedoch ein MAPI-basiertes ACL-Format anstelle des Windows 2000-Formats. Zur Unterstützung dieser Clients verwendet Exchange einen speziellen Regelsatz für die Sicherheitsbeschreibungen von Postfächern und für Ordner in der Öffentliche Ordner-Standardhierarchie (auch als MAPI-Hierarchie bekannt). Als Folge des Sonderformats wertet Windows aus, ob ein Benutzer Zugriff in einer Art besitzt, die das Zugriffssteuerungsverhalten von Exchange 5.5 nachahmt (das von MAPI-basierten Berechtigungen abhing). Dieses Format ist als "kanonisches Exchange-ACL-Format" (auch als "kanonisches Exchange-Sicherheitsbeschreibungsformat" bezeichnet) bekannt.

Die folgenden Regeln steuern die Reihenfolge von ACEs in einer kanonischen Exchange-ACL:

• Jede ACL enthält beide ACEs - die, die auf Ordner Anwendung finden, und die, die auf Nachrichten in diesen Ordnern angewendet werden. Ordner- und Nachrichten-ACEs können in der ACL gemischt sein.
• Für jeden Gewähren-ACE muss ein entsprechender Verweigern-ACE für denselben Sicherheitsprinzipal vorhanden sein (es sei denn, es werden weder Rechte gewährt noch verweigert). Der Gewähren-ACE muss dem Verweigern-ACE vorangehen.
• Alle ACEs für Benutzer müssen allen ACEs für Gruppen vorangehen (entsprechend den Exchange 5.5-Verteilerlisten). ACEs für die Gruppen Jeder und Anonym müssen als letzte in der Reihenfolge stehen.
• Alle Gewähren-ACEs für Verteilergruppen müssen den entsprechenden Verweigern-ACEs für diese Gruppen vorangehen.

Die folgende Tabelle zeigt ein Beispiel für die Reihenfolge von ACEs in einer kanonischen Exchange-ACL.

Beispiel für die Reihenfolge der Informationen in einer kanonischen Exchange-ACL

Mit einer ACL in diesem Format kann Exchange die Sicherheitsbeschreibungsinformationen in die MAPI-Berechtigungen übersetzen, die von MAPI-Clients wie Outlook erwartet werden.

Wenn ein Benutzer in Outlook Berechtigungen für ein Postfach festlegt, oder wenn Sie im Exchange-System-Manager Berechtigungen für ein Postfach oder einen Öffentlichen MAPI-Ordner festlegen, listet die Benutzeroberfläche MAPI-Berechtigungen und -Rollen auf, die denen von Exchange 5.5 entsprechen. In der folgenden Abbildung wird das Dialogfeld dargestellt, das im Exchange-System-Manager angezeigt wird. Wenn Sie Outlook verwenden, werden diese Informationen im Dialogfeld Eigenschaften des Ordners auf der Registerkarte Berechtigungen angezeigt.

Da Öffentliche Anwendungsordner für den Zugriff mit HTTP- oder NNTP-Clients (Network News Transfer Protocol; z. B. Outlook Web Access) gedacht sind, wird die Umwandlung in MAPI-Berechtigungen hierbei nicht verwendet. Wie in der folgenden Abbildung dargestellt, handelt es sich bei den aufgeführten Berechtigungen um normale Windows 2000-Berechtigungen. Weitere Informationen zu Öffentlichen Anwendungsordnern (auch als allgemeine Öffentliche Ordner bezeichnet) finden Sie im Exchange Server 2003-Administratorhandbuch.

Anmerkung:

Verwenden Sie zum Ändern von MAPI-Berechtigungen nur das von Outlook bereitgestellte Dialogfeld Berechtigungen sowie das vom Exchange-System-Manager bereitgestellte Dialogfeld Clientberechtigungen. Wenn Sie mithilfe der Outlook- oder Exchange-System-Manager-Benutzeroberfläche MAPI-Berechtigungen bearbeiten, kehrt Exchange die Übersetzung zum Speichern der geänderten Sicherheitsbeschreibung um und behält das kanonische Exchange-ACL-Format bei. Wenn Sie jedoch Berechtigungen mithilfe der Windows-Dateisystem-Benutzeroberfläche bearbeiten (z. B. mithilfe des Laufwerks M:\, das vom installierbaren Dateisystem (Installable File System, IFS) in Exchange 2000 Server bereitgestellt wird), wird die Sicherheitsbeschreibung im normalen Windows-ACL-Format gespeichert. Das heißt, dass die ACEs in einer anderen Reihenfolge stehen und dass Exchange die Sicherheitsbeschreibung nicht mehr in MAPI-Berechtigungen übersetzen kann. Weitere Informationen zu diesem Thema finden Sie im Knowledge Base-Artikel 270905, "Clientberechtigungen für Öffentliche Ordner können nicht über Exchange-System-Manager festgelegt werden".

Standard-ACLs für Nachrichten

Wie bereits festgestellt, enthält jede Ordnersicherheitsbeschreibung ACEs, die nur auf Nachrichten Anwendung finden. Diese ACEs, insgesamt als Standard-Nachrichten-ACL bekannt, bieten den Nachrichten im Ordner Sicherheit, die über keine eigenen Sicherheitsbeschreibungsinformationen verfügen.

Wenn ein Benutzer eine solche Nachricht öffnet, erbt die Nachricht dynamisch Nachrichten-ACEs von der Ordnersicherheitsbeschreibung. Wenn sich die Ordnersicherheitsbeschreibung ändert, erben alle neuen Nachrichten, die in dem Ordner geöffnet werden, sofort auch die Änderung der Sicherheitsbeschreibung. Nachrichten, die bereits geöffnet sind, behalten ihre ursprünglichen Sicherheitsbeschreibungen bei, bis sie gespeichert werden.

Die Sicherheitsbeschreibung einer Anlage (oder einer eingebetteten Nachricht) wird von Exchange in der Datenbank aufgezeichnet, aber nicht verwendet. Stattdessen verwendet der Exchange-Informationsspeicher die Sicherheitsbeschreibung der äußersten Nachricht aller angefügten Nachrichten. Die Sicherheit von Anlagen wird im Informationsspeicher beibehalten, damit ein Client eine Nachricht zum Debuggen an einen anderen Benutzer senden kann. Darüber hinaus wird die Sicherheitsbeschreibung einer angefügten Nachricht sofort wirksam, wenn ein Benutzer sie in einen Ordner der höchsten Ebene kopiert.

Spezielle Aspekte bei koexistierenden Servern mit Exchange 2003 und Exchange 5.5

Wenn Ihre Bereitstellung Server mit Exchange 2003 und Exchange 5.5 enthält, gestaltet sich die Verwaltung von Berechtigungen, insbesondere die von Öffentlichen Ordnern, noch komplexer. Weitere Informationen dazu, wie Zugriffssteuerungsinformationen zwischen Exchange 2003- und Exchange 5.5-Servern übermittelt werden, finden Sie unter Berechtigungen Öffentlicher Ordner in einer Microsoft Exchange-Organisation im gemischten Modus. Die wichtigen Aspekte, die sich auf die Verwaltung von Berechtigungen für Öffentliche Ordner beziehen, sind die folgenden:

• Bevor Daten zwischen Servern mit Exchange 2003 und Exchange 5.5 repliziert werden können, müssen alle Benutzer und Gruppen, die über ein Postfach auf den Servern mit Exchange 5.5 verfügen, ein Konto in Active Directory haben.

  • Wenn der Benutzer oder die Gruppe nur über ein Active Directory-Konto verfügt (kein Windows NT 4.0-Konto), ist das Active Directory-Konto ein "aktiviertes" Konto.

  • Wenn der Benutzer oder die Gruppe ein Windows NT 4.0-Konto hat, ist das Active Directory-Konto ein "deaktiviertes" Konto. Dieses mit dem Active Directory-Migrationstool erstellte Konto ist ein Platzhalter, über den eine Active Directory-SID dem vorhandenen Windows NT 4.0-Konto zugeordnet wird.

    Wichtig

    Wenn Sie planen, Benutzerkonten in Windows NT 4.0 für eine bestimmte Dauer zu erhalten und diese dann vollständig zu Active Directory zu migrieren, müssen Sie deaktivierte Konten mit einem SID-Verlauf erstellen. Mit dem Active Directory-Migrationstool kann die Windows NT 4.0-SID in das Attribut sidHistory des neuen deaktivierten Kontos in Active Directory migriert werden. Wenn Sie die Konten zu einem späteren Zeitpunkt aktivieren, kann Exchange mithilfe der Informationen des SID-Verlaufs feststellen, an welchen Stellen Windows NT 4.0-Konten in ACEs durch neu aktivierte Konten ersetzt wurden. Weitere Informationen zu diesem Vorgang finden Sie im Knowledge Base-Artikel 316047, "XADM: Addressierungsprobleme, die entstehen, wenn Sie ADC-generierte Konten aktivieren".

  Exchange 5.5 verwendet MAPI-basierte Berechtigungen, identifiziert Benutzer und Gruppen anhand ihrer DNs (Distinguished Name) im Exchange-Verzeichnis und speichert Zugriffssteuerungsinformationen in der Eigenschaft ptagACLData. Wenn Exchange 2003 Zugriffssteuerungsinformationen auf einen Server mit Exchange 5.5 repliziert, geschieht Folgendes:

  1. Active Directory-Sicherheits-IDs (SID) von Benutzern und Gruppen werden in Exchange-Verzeichnis-DNs (Distinguished Name) konvertiert.
  2. Windows 2000-Berechtigungen werden in MAPI-Berechtigungen konvertiert.
  3. Die konvertierten Zugriffssteuerungsinformationen werden in ptagACLData gespeichert.
  4. ptagNTSD, ptagAdminNTSD und ptagACLData werden auf den Server mit Exchange 5.5 repliziert.
     Wenn ein Server mit Exchange 2003 replizierte Daten von einem Server mit Exchange 5.5 empfängt, geschieht Folgendes:
  5. Die eingehenden Werte von ptagNTSD und ptagAdminNTSD werden verworfen. Durch diesen Schritt wird ein Schutz gegenüber Änderungen gewährleistet, die möglicherweise an diesen Eigenschaften vorgenommen wurden, während sie von Exchange 5.5 gesteuert wurden.
  6. Die Benutzer- und Gruppen-DNs werden aus ptagACLData extrahiert und in Active Directory-SIDs konvertiert.
  7. Die Berechtigungen werden aus ptagACLData extrahiert und in Windows 2000-Berechtigungen konvertiert.
  8. Die konvertierten Zugriffssteuerungsinformationen werden in ptagNTSD gespeichert. Der ursprüngliche Wert von ptagAdminNTSD bleibt unverändert.
  9. Der Wert von ptagACLData wird normalerweise verworfen. Wenn jedoch bei der Konvertierung in Schritt b oder c ein Problem aufgetreten ist, wird der Wert von ptagACLData in Exchange 2003 beibehalten.

• Exchange 5.5 wendet die Berechtigungen auf Ordner an. Sie können einzelnen Nachrichten Berechtigungen nicht explizit zuweisen (Berechtigungen auf Elementebene), wie dies in Exchange 2003 möglich ist. Versuchen Sie beim Replizieren von Ordnern und deren Inhalten von Exchange 5.5 nach Exchange 2003 nicht, explizite Berechtigungen für Nachrichten festzulegen. In Exchange 2003 werden Berechtigungen so verwaltet, dass die Nachrichten sicher sind. Wenn Sie jedoch in dieser Situation die Nachrichtenberechtigungen ändern, gehen diese Änderungen im nächsten Replikationszyklus verloren.