Segregation Addresslist - Exchange 2007 für mehrere Firmen

Diese Anleitung funktioniert NICHT mit Exchange 2010. hier gibt es zwei andere Modelle:
Adress book Polices und MultiTenant /Hosting

Migrate to Exchange 2010 Address Book Policies from Exchange 2007 Address List Segregation
http://technet.microsoft.com/en-us/library/hh529930.aspx

Hosting Days: Unified Communications in a Software + Services World http://www.msdev.com/Directory/Description.aspx?eventId=1720
Hosting Days: Microsoft Exchange 2010 Hosting Roadmap
http://www.msdev.com/Directory/Description.aspx?eventId=1711

Microsoft unterscheidet drei Betriebsarten für Exchange:

  • Normaler Exchange Betrieb
    Dies entspricht dem wohl ab häufigsten eingesetzten Konfigurationsmodell, bei der es meist nur einen Forest gibt, welcher sowohl Exchange als auch die Anmeldekonten enthält. Die "Globale Adressliste" enthält alle Empfänger (außer verborgene Empfänger).
    Fast alle Artikel der MSXFAQ sind für diese Betriebsart abgestimmt.
  • Exchange Hosted (HMC)
    Verschiedene Firmen wie 1und1 und andere betreiben "Hosted Postfächer", d.h. dies auch als HMC benannte Modell nutzt Exchange als Backend zur Bereitstellung von Outlook und OWA aber ist weit von dem entfernt, was die normalen Administratoren können. Hier wird sehr restriktiv mit Berechtigungen umgegangen, Vererbungen deaktiviert und es findet keine manuelle Konfiguration von Benutzern mehr statt. Die komplette Verwaltung erfolgt über ein Provisioning, d.h. mit Datenbanken, Webseiten, Skripte etc. Dieser Betrieb erfordert einige zusätzliche Server und die Lizenzvereinbarungen verhindern den Einsatz einer solchen Lösung innerhalb einer Firma oder Firmengruppe.
    Dieses Modell ist auf der MSXFAQ nicht beschrieben !
  • Exchange Segregated
    Dies ist eine Sonderform des ersten normalen Modells, bei dem verschiedene Empfängergruppen das gleiche Active Directory und die gleiche Exchange Organisation nutzen aber komplett voneinander separiert sind. Jede "Gruppe" hat also ihre eigene Adressliste, GAL und OAB. Bei dem Konzept kann es aber keinerlei Überlappung geben, d.h. es ist nicht vorgesehen, dass bestimmte Personen oder Gruppen auch Personen anderer Gruppen sehen. Dies sollten sie vorab wissen. Damit diese Funktion auch für andere Clients gewahrt bleibt, die z.B. per SMTP, POP3 und IMAP4 arbeiten und per LDAP direkt das Active Directory anzapfen, werden Berechtigungen auf Organisationseinheiten derart geändert, dass "authentifizierte Benutzer" per Default die Benutzer nicht mehr sehen. Das müssen Sie bei der Umsetzung vorab wissen
    Diese Seite beschreibt die Konfiguration "Exchange Segregated Addresslist".

Änderungen an ACLs im Active Directory sind Aktionen, die sehr leicht ins Auge gehen können. Wenn Sie wenige Erfahrung mit ADSIEDIT haben, dann üben Sie vorher in einem Testfeld oder holen Sie Hilfe hinzu. Zumal Sie hier mit Rechte vergeben, Rechte Verweigern und Vererbung abschalten.
ACHTUNG: Alle bisherigen Beschreibungen zum Einrichten von Hosting mit Deaktivieren der Vererbung etc. sind veraltet und nicht mehr unterstützt.
Basierend auf diesem Whitepaper werden ich diese Seite in Kürze noch einmal überarbeiten müssen. Meine Vorarbeiten und Arbeit zu dieser Seite hat sich mit der Veröffentlichung überschnitten. Maßgeblich ist das Whitepaper.

Im Internet kursieren unterschiedliche Anleitungen zur Einrichtung von Adresslisten und Berechtigungen, damit mehrere Firmen voneinander abgeschirmt auf dem gleichen Exchange Server bzw. in der gleichen Exchange Organisation nebeneinander betrieben werden können. Einige Beschreibungen arbeiten mit "DENY-Einstellungen" während andere Konzepte die Vererbung abschalten, um weiter oben gegebene Rechte zu entfernen. Beide Varianten haben ihre Vor und Nachteile. Das Problem ist, dass Beschreibungen für Exchange 2003 und Exchange 2007 vermischt werden, obwohl sie komplett unterschiedlich funktionieren.

White Paper: Configuring Virtual Organizations and Address List Segregation in Exchange 2007
http://technet.microsoft.com/en-us/exchange/bb936719.aspx
http://technet.microsoft.com/en-us/exchange/bb936719(EXCHG.80).aspx
Seit Feb2008 beschreibt diese Whitepaper eine Exchange 2007 Umgebung. Sie werden sicher Übereinstimmungen wiederfinden. Die Anleitung wiederspricht "817218 How to restrict OWA address searches to multiple organizational units".
http://blogs.msdn.com/dgoldman/archive/2008/02/17/exchange-2007-address-list-segregation-document-Updates.aspx
http://blogs.msdn.com/dgoldman/archive/2008/02/19/exchange-2003-address-list-segregation-document.aspx
ACHTUNG. Auch die in dem White Paper aufgeführten Skripte sind aufgrund verschiedener Fehler anzupassen !!

Missing permissions on the Address Lists Container breaks the OAB Generation process
http://blogs.msdn.com/dgoldman/archive/2007/05/16/missing-permissions-on-the-address-lists-container-breaks-the-oab-generation-process.aspx
Beschreibt auch, wie man die Rechte wieder auf "Default" setzen kann

Exchange 2003 / 2007 Address List Segregation Document - Updates!
http://blogs.msdn.com/dgoldman/archive/2008/02/17/exchange-2007-address-list-segregation-document-Updates.aspx

Exchange 2007 Address List Segregation Tool
http://www.telnetport25.com/category/address-list-segregation/
Andy Grogan (MVP) hat sogar ein Programm entwickelt., um alle Einstellungen vorzunehmen. Sie sollten aber dennoch "verstehen", warum welche Einstellungen vorgenommen wurden.

Diese Seite beschreibt in Kürze, wie die mehrere Firmen auf einem Exchange Server betreiben können und jede Firma möglichst wenig von der anderen Firma "sieht". Denn technisch ist es eine Exchange Organisation und ohne weitere Anpassungen würden die Benutzer alle eine große gemeinsame GAL verwenden. Das kann natürlich nicht gewünscht sein. Im wesentlichen dreht es sich dabei um folgende Themen.

  • Benutzer und Gruppen
  • Empfängerrichtlinien
  • Adressliste/GAL
  • OAB
  • öffentliche Ordner
  • OWA, ActiveSync und Autodiscover
  • Sonstiges

Die Kurzanleitung kann nicht alle Punkte komplett abdecken, sondern soll eine Einführung in die Thematik mit weiterführenden Links bieten. Themen wir Datensicherung, Archivierung, verschiedene Postfachgrenzwerte, Datenbankdesign etc. werden nicht behandelt.

Für die Umsetzung habe ich eine Segregation 2007 Checklist erstellt.

Vorarbeiten

Da eine Exchange Organisation immer ein einem Forest lebt und Postfächer immer ein Windows Anmeldekonto benötigen, sollten sie sich Gedanken über die Platzierung der Benutzer machen. Sie können alles in einer Domäne abwickeln und die Firmen in OUs eingruppieren. Denkbar wäre auch eine (Unter-)Domäne pro Firma, wenn individuelle Kennwortrichtlinien oder administrative Belange dies erfordern. Bei Konzernen mit eng angebundenen Töchtern könnte auch ein Exchange Ressourcen Forest ein gangbarer Weg sein, bei dem im Exchange Forest nur deaktivierte Konten vorhanden sind, die über einen Trust die Authentifizierung von anderen Anmeldedomänen außerhalb des Forests nutzten. Wenn dies klar ist, dann sollten beim Benutzer aber noch einige Felder zusätzlich gepflegt werden:

  • UPN
    Vermutlich macht es keinen guten Eindruck, wenn die Anwender sich als "HOSTINGDOMAIN\Username" anmelden. Das kann sich kein Benutzer merken. Zum Glück erlaubt das Active Directory zusätzliche "Anmeldenamen". Bei geeigneter Konfiguration kann sich ein Anwender einfach mit seiner E-Mail-Adresse anmelden. Dazu ist nur der UPN entsprechend zu setzen.
  • MemberOf
    Für die spätere Verwaltung der Sichtbarkeit bestimmter Daten sollten alle Benutzer einer Firma in einer Sicherheitsgruppe aufgenommen werden. Diese wird später zur Steuerung der Berechtigungen auf Ordner und Adressen genutzt.
  • Eindeutiges Feld zur "Erkennung" des Kunden
    Sicher werden Sie bei den Benutzern auch die Felder Vorname, Nachname etc. pflegen. Sie sollten aber mindestens ein Feld vorgeben, welches später für die Adresslisten genutzt wird. Hier darf man sich auch nicht vertippen. Man kann dazu eines der "Benutzerdefinierten Felder" nehmen. Weniger geeignet ist z.B. das Feld "Firma" (company), da es nicht bei Verteilern existiert. Auch eine Abfrage auf Gruppenmitgliedschaften über das Feld "memberOf" ist für eine LDAP-Abfrage nicht geeignet, da es sich dabei um ein Array handelt.
  • Feld: msExchQueryBaseDN
    Wenn die Benutzer per "OutlookWeb Access" ihre Postfächer lesen, dann steuert diese Feld das Adressbuch bzw. die Basis der Adressbücher , welche der Benutzer sehen und verwenden kann. Hier muss der "distinguishedName" der Adressliste bzw. des Adresslistcontainers eingetragen werden. Dieses Feld steuert allerdings nur OWA! Die Adresslisten für Outlook werden über Rechte gesteuert.

Exchange 2007 - How to Specify Address Lists in Outlook Web Access
http://technet.microsoft.com/en-us/library/bb430794.aspx
If the querybaseDN parameter is set to a specific OU and the displayAddressLists parameter is set to $false, the user will not have access to any address lists. If the querybaseDN parameter is set to a specific OU and the displayAddressLists parameter is set to $true, the user will have access only to users in the OU that is specified by the querybaseDN parameter.

  • Feld: msExchUseOAB
    Gerate mit dem Outlook 2003 Cached Mode wird auch das Offline Adressbuch wichtig. Auch hier kann Exchange problemlos mehrere OABs verwalten. Sie müssen nur in diesem Feld dann pro Benutzer hinterlegen, welches OAB für ihn gilt. Wenn Sie pro Firma eine Datenbank verwenden, dann können Sie auch dort die Default OAB vorgeben.
  • Feld: addressBookRoots (ADSIEDIT -Configuration/Services/Microsoft Exchange)
    Dieses Feld verweist auf die Basis der Adressbücher. Warten Sie daher damit, bis sie die Adressbücher auch angelegt haben, damit Sie sich nicht vertippen.

Legen Sie aber noch keine Benutzer an !!

Empfängerrichtlinien und akzeptierte Domains

Wenn die Benutzer gemäß ihrem Standard eingerichtet werden, dann ist es an der Zeit auch eine entsprechende Empfängerrichtlinie anzulegen.

Alle Empfänger die im Feld "company" den entsprechende Inhalt haben, sollten natürlich auch über eine Empfängerrichtlinie die passende Adresse erhalten. Bei Exchange 2000/2003 ist dieser Eintrag auch zugleich dafür maßgeblich, dass sich Exchange für diese Domain zuständig fühlt und die Mals auch annimmt. Bei Exchange 2007 müssen Sie zusätzlich noch die "Akzeptierten Domains" pflegen. Wenn Sie zwischen Internet und Exchange noch ein Relay, Virenscanner o.ä. stehen haben, dann müssen Sie dort zumindest die Domain ebenfalls konfigurieren.

Adressbücher, GAL, OAB und die Berechtigungen

Die Einrichtung von Adresslisten und GAL sind etwas kniffliger, da man hier sehr wohl zwischen einem "echten" Hosting unterscheiden muss, bei dem niemand auch nur eine Spur sehen darf, welche anderen Firmen noch in der gleichen Organisation betrieben werden und einem Hosting eines Firmenverbunds, bei dem zwar jeder Teilfirma nur ihre primären Empfänger in der GAL und dem Offline Adressbuch sehen sollen, aber ein Zugriff auf die anderen Adressen doch über Adressbücher möglich sein soll. Dabei gilt:

  • Es kann mehrere GAL's in einer Exchange Organisation geben
  • Ein user nutzt aber immer genau eine GAL und sollte auch immer genau eine GAL sehen
  • Es kann mehrere Offline Adressbücher geben
    Bei Exchange 2000/2003 basierten diese auf GALs, während Exchange 2007 dazu Adressbücher nutzt.
  • Ein Benutzer verwendet nur ein OAB
    Sie können ein OAB pro Benutzer oder pro Datenbank oder das globale Default OAB nutzen.
  • Es kann mehrere Adressbücher geben, die auch in einer Hierarchie angeordnet werden.
  • Inhalte der Adressbücher und GAL's können per LDAP-Abfragen bestimmt werden
  • Die Sichtbarkeit bzw. Erreichbarkeit wird über AD-Berechtigungen gesteuert.

Die Steuerung der Sichtbarkeit sollte unbedingt über Windows Sicherheitsgruppen gesteuert werden. Diese Gruppe sollte auch nicht in der OU des Kunden liegen, so dass er sie nicht selbst verändern kann, sondern muss besonders geschützt werden.

Bei einem kooperativen Hosting, bei dem mehrere Firmenteile in der gleichen Organisation nebeneinander existieren und auch Zugriff auf andere Adresslisten benötigen, ist es natürlich tödlich, eine Gruppe der "Firmenmitgliedschaft" für die Adresslistensteuerung zu nutzen. Wenn die Führungsebene von Firma1 auch die Personen der Tochterfirma 2 sehen soll, dann kann man sie ja nicht gleich zu "Mitarbeitern" der Tochterfirma machen. An deren gruppen hängen ja auch noch anderen Berechtigungen. Hier bietet es sich an, eigene Gruppen für die Adresslistensteuerung zu verwenden.

Handelt es sich aber um ein echtes Hosting, dann kann ein Mitarbeiter auch nur in genau einer Firmengruppe sein und auch nur die Adressbücher der Firma nutzten. Hier kann man dann die Firmengruppe nutzen.

Adresslisten

Adressenlisten sind der schwierige Teil beim Einrichten eines Hostings. Unter dem Container "Alle Adresslisten", welcher per ADSIEDIT aber als "All Address Lists" erscheint, kann man als Administrator mehrere Adresslisten anlegen.

ESm Adresslisten ADSI Adresslisten

Das ganz ähnelt einer Verzeichnisstruktur auf einem Dateiserver. für jede Firma könnte man hier eine Adressliste anlegen und sogar darunter weitere Adresslisten nach Strukturen definieren. Hierbei gib es zwei Dinge zu beachten:

  • LDAP Filter
  • Berechtigungen

Auf beide Dinge gehe ich getrennt ein.

LDAP-Filter

Für jede Adressliste ist ein LDAP-Filter zu definieren. Leider kann man hier nicht auf die Mitgliedschaften von Gruppen aufbauen, sondern muss AD-Felder verwenden. Der Assistent ist aber auch hier nicht intuitiv. Wenn Sie z.B. "Alle Exchange Empfänger" auswählen und dann z.B. die Bedingungen  Benutzer - Feld "Company=Firma1" addieren, dann gilt dies nicht für alle Empfänger, sondern nur für Benutzer. Man sieht das nur im LDAP-Filter


Der erste Teil schließt alle Empfänger ein und wird dann mit "(objectCategory=contact)(company=HostingF1*)" und verknüpft. Als Ergebnis sieht man NUR die Kontakte. Hier muss man den LDAP-Filter besser manuell eingeben. Auch ist das Feld "Company" nicht gerade geeignet, da es bei Gruppen nicht vorhanden ist.

Berechtigungen

Das zweite Problem stellt sich bei den Berechtigungen. Die Hierarchie sieht nicht nur einem Dateiserver sehr ähnlich, sondern die Berechtigungen sind auch ähnlich. Wie beim Dateisystem kann ich eine Adressliste "sehen", wenn ich auf dem übergeordneten Ordner "lesen" habe, auch wenn ich sonst keine Berechtigungen auf der Adressliste selbst habe. Einen Teil der Adresslisten kann ich beseitigen, indem ich Sie einfach Lösche (z.B. "Alle Benutzer", "Alle Gruppen" etc.)

Greife ich im Beispiel nun auf die Adressliste "AL Firma2", auf die ich keine Berechtigungen habe,  mit Outlook zu, dann bekomme ich zuerst den den nichtssagenden Fehler und dann die leere Adressliste angezeigt. Die Berechtigungen sind aber alles andere als "trivial" und ich möchte hier nur einen Auszug wiedergeben, soweit er für das weitere Verständnis erforderlich ist. Exchange vergibt hier sehr diversifiziert Rechte, auf welche Objekte die Rechte gegeben werden, ob diese vererbbar sind oder selbst vererbt werden. Auf den ersten Blick könnte man vermuten, dass JEDER und ANONYM Berechtigt wären. Auf untergeordneten Containern tauchen dann weitere Rechte auf, die explizit durch den System Manager vergeben worden sind und nicht auf einer Vererbung beruhen.

Daher hier mal eine vereinfachte Darstellung:

Container User Rechte Fokus von oben vererbt

All Address Lists
(Vererbung aktiv)

AuthenticatedUser
AuthenticatedUser
AuthenticatedUser

Read
Open Address List
Lists content

Nur dieses Objekt
Nur dieses Objekt
Objekt und Unterobjekte

nein
nein
Ja

HostingF1
(Vererbung aktiv)

AuthenticatedUser
AuthenticatedUser
AuthenticatedUser

Read
Open Address List
Lists content

Nur dieses Objekt
Nur dieses Objekt
Objekt und Unterobjekte

nein
nein
Ja

Man sieht also, dass auf einer untergeordneten Adressliste "Authentifizierte Benutzer" auch noch mal explizit ein "READ" und "Open Address List" und nicht von oben vererbt bekommen. für die Vergabe von Berechtigungen bedeutet dies, dass man dieses Recht dann auch einfach "löschen" kann. Es bleibt dann aber das vererbte "List Content" übrig.

Um die Erreichbarkeit von Adresslisten zu steuern, kann man daher drei Verfahren "kombinieren":

  • Explizite Rechte entfernen
    Wenn es ausreichend ist, kann man einfach die "Authentifizierte Benutzer" von den Adresslisten entfernen und über Gruppen dem gewünschten Personenkreis die Berechtigungen erteilen. Da die Rechte aber vom ESM auf jeder Adressliste explizit gegeben werden, muss man diese auch wieder entfernen. Selbst wenn man darunter danach eine neue Adressliste anlegt, ist "Authentifizierte Benutzer" immer wieder explizit mit einem "Open Address List" dabei.

Achtung beim Entfernen der expliziten Berechtigungen
Wenn Sie eine neue Adressliste unter solch einer Adressliste anlegen, dann müssen Sie auch wieder AuthenticatedUser entfernen. Der Exchange System Manager trägt dieses Recht ein.

  • Rechte verweigern
    Reicht die Wegnahme der vom ESM vergebenen expliziten Berechtigungen nicht aus, dann könnte man bestimmten Personen oder Gruppen die Rechte verweigern. Hier muss man bedenken, dass ein vererbtes DENY durch ein explizites ALLOW überstimmt wird aber eine Ebene darunter nicht mehr gewinnt, was die Vergabe nicht einfacher macht. Das macht es beim Shared Hosting schwer, wenn später ausgewählte Personen einer Firma doch in besondere Adressbücher einer anderen Firma schauen sollen. Dann muss man explizite Gruppen für die Steuerung von Adressbüchern nutzen und sollte nicht die generischen "Mitarbeiter von Firma x"-Gruppe verwenden. Legt man eine neue Adressliste an, dann ist aber zumindest das DENY auch auf diese unteradresslisten aktiv.

Achtung beim Einsatz von DENY
Ein DENY auf "authentifizierte Benutzer" sperrt auch die Exchange Dienstkonten und andere Prozesse aus. Im schlimmsten Fall auch den Administrator, der sich aber als Notnagel immer noch zum "Owner" machen und dann die Rechte wieder anpassen kann.

Sicherheitslücke beim DENY
Wenn man über eine Gruppe ein Recht entzieht, dann müssen die Personen natürlich auch Mitglied dieser Gruppe sein. Ansonsten sehen sie zu viel. Eigentlich ein schlechtes Design, wenn Sie nicht sicherstellen, dass die Gruppe korrekt gepflegt ist.

  • Vererbung deaktivieren und neu berechtigen
    In der TechNet und anderen Artikeln wird beim Hosting oft geraden die Vererbung zu unterbrechen, die Rechte zu kopieren und dann getrennt weiter zu berechtigen. Auch dies ist ein denkbarer weg, wenn man ansonsten vererbte Berechtigungen nicht durch ein DENY ausschalten kann. Heikel ist, wenn das nächste Exchange Update weitere Gruppen in die Berechtigungen einfügt. Durch der Installation von Exchange 2007 bekommt die Gruppe "Exchange Recipient Administratoren" z.B. vererbte Berechtigungen auf den Container "All Address Lists" und ich bin nicht sicher, dass dies bei deaktivierter Vererbung sauber abgebildet wird.

    Daher bin ich immer sehr vorsichtig mit der Deaktivierung der Vererbung. Es gibt aber Situationen, in denen es nicht anders geht. Dann ist es die Pflicht des Betreibers eben diese abweichende Konfiguration bei allen zukünftigen Änderungen zu berücksichtigen.

Achtung beim Abschalten der Vererbung
Sie wissen nie, ob nachfolgende Produktinstallation die Berechtigungen auf höherer Ebene ändern und darauf vertrauen, dass diese auch in die Struktur vererbt wird.

Bezogen auf die Sichtbarkeit der Adresslisten haben wir nur vier verschiedene Optionen, Adresslisten vor neugierigen Blicken anderer Firmen zu schützen, die alle für dich individuelle Vorteile und Einschränkungen haben: 

  • Adresslisten gar nicht anzeigen
    Vielleicht brauchen Sie die Adresslisten gar nicht und die Mitarbeiter arbeiten sowieso immer nur mit der GAL, von der es eine pro Firma gibt. Dann können Sie die Adresslisten komplett durch ein DENY für die Mitarbeitergruppe auf "All AdressLists" blockieren. Man muss nichts an der Vererbung unterbrechen und keine weiteren Besonderheiten betrachten.
    Das bedeutet aber auch, dass es eben auch keine Adresslisten für Führungskräfte beim Shared Hosting gibt und auch keine Adresslistenstruktur für Besprechungsräume, Orte etc.
  • Adresslisten sichtbar aber nicht erreichbar
    Man kann eine komplexe Struktur aufbauen, aber solange die Personen kein "Open Address List"-Rechte haben, können Sie die Liste nicht nutzen. Sie sehen Sie aber, was beim echten Hosting natürlich nicht tolerierbar ist. Beim Shared Hosting kann es aber sehr effektiv sein, z.B.: ein "Open Address list" per DENY oben zu stoppen und dann auf die einzelnen Adressbücher über ein explizites ALLOW wieder zu vergeben. Alternativ könnte man auf dem Adresslistenbaum einer Firma die anderen Firmengruppen mit einem DENY aussperren
  • Nur erreichbare Adresslisten sichtbar
    Die "Lesbarkeit" des Inhalts einer Adressliste kann man mit Bordmitteln konfigurieren aber das verhindert immer noch nicht, dass man alle Adresslisten sieht. Beim Windows Server Dienst wurde dazu ABEUI (Access Based Enumeration) eingeführt. Bei Exchange muss man dem Active Directory über eine Änderung der "dsHeuristics" beibringen, dass er die Berechtigungen anders ermittelt. Dann kann man eine Adressliste über ein vergebenes Recht "List Object" sehen, obwohl man im übergeordneten Container kein "List Content" hat

So schön es also ist, dass ein Anwender nur die Adresslisten sieht, die er auch sehen darf, so schwerwiegend kann die Änderung der "dsHeuristics" sein. Wer auf Adresslisten komplett verzichten kann, ist daher fein raus. Wird aber echtes Hosting mit Adresslisten gewünscht, dann muss man die "dsHeuristics" und Berechtigungen anpassen.

Bei der Verwendung von Adresslisten sollten Sie die Funktion des RUS nicht unterschätzen. Der ist nämlich dafür zuständig, das Feld "showInAddressBook" bei allen Benutzern entsprechend zu aktualisieren. Wenn Sie im Exchange System Manager eine Adressliste anlegen, dann sehen Sie bei der Vorschau erst alle Einträge und wenn Sie die Vorschau nach dem Speichern öffnen, vielleicht nur eine partielle Liste. Dies ist besonders bei mehreren Domains und WAN-Verbindungen der Fall. Prüfen Sie in diesem Fall den Fortschritt des RUS.

  • MSDN - Controlling Object Visibility
    http://msdn2.microsoft.com/en-us/library/ms675746.aspx
    Konfiguration von "dSHeuristics"
    • List Content ADS_RIGHT_ACTRL_DS_LIST
      Grant: erlaubt auch die Anzeige von Unterobjekte n
      Deny: versteckt Unterobjekte komplett
    • List Objekt (ADS_RIGHT_DS_LIST_OBJECT) und "dSHeuristics:bit3 = 1"
      dann kann man trotzdem Unterobjekte sehen. Achtung: höhere Last
  • 319213 How To use Address Lists to Organize Recipients in Exchange 2003
    Beschreibt die Steuerung über eine Abschalten der Vererbung
  • 253828 How the Recipient Update Service Populates Address Lists
  • Address List Access Control
    http://www.microsoft.com/technet/prodtechnol/exchange/2000/maintain/exrecip.mspx

"You may need to create multiple address lists if your organization has numerous locations, departments, product teams, and so forth. Exchange 2000 allows you to control which users can access these lists by exposing the access control editor on each address list object. On the Security tab of the address list, you can explicitly deny the Open Address List right to anyone who should not be able to access this particular address list"

GAL

Anders verhält es sich mit der GAL. Man kann hier problemlos mehrere GALs anlegen. Der Outlook Client nutzt immer nur eine GAL aus der Menge der GALs und nutzt dabei folgende Logik:

However, the user only sees one GAL. The GAL that the client sees is determined by ordered evaluation:
• user has rights to open the GAL.
• user is a member of the GAL.
• Largest GAL out of those that remain.

Address List Access Control
http://www.microsoft.com/technet/prodtechnol/exchange/2000/maintain/exrecip.mspx
312287 How to make sure that Outlook clients access the correct global address list if there is more than one global address list

Oder auf Deutsch:

  • Hole die GALs, die der Benutzer mit seinen Rechten "sehen" kann
  • Bevorzuge die GAL, in der das Post selbst aufgelistet wird
  • Nimm die GAL mit den meisten Objekten

D.h. selbst wenn ein Benutzer mehrere GALs sehen kann, so wird in Outlook immer nur eine GAL angezeigt. Wichtig ist aber das Kriterium "Berechtigungen". welches als einziges Kriterium sicher funktioniert.

Berechtigungen
Allerdings sieht das Exchange Addresslist Segregation Dokument keine weitere Filterung durch Berechtigungen vor, sondern beschreibt, dass ein Postfach immer nur ein "GENAU EINER" GAL enthalten sein darf. Das Problem wird sichtbar, wenn Sie dann eine GAL anlegen, in der mehrere Postfächer unterschiedlicher GALs oder gar alle Postfächer enthalten sind (z.B. für Drittprogramme wie Faxserver, UM-Server, Blackberry o.ä.). Wird solch eine Adressliste addiert, dann sehen plötzlich alle Benutzer alle anderen Empfänger, da die Anwender auch die anderen GALs sehen und nun in zwei (ihrer eigenen und der neuen) enthalten sind und die neue Adressliste "größer" ist.
Das Setzen von Rechten (Bitte kein DENY sondern durch Entfernen der Allows) löst das Problem, aber ist nicht "Supported", d.h. es kann später bei Updates etc. zu Problemen führen. Dokumentation der Änderungen ist also Plicht.

GAL und Blackberry
Gibt es also Dienste, die alle user sehen müssen (z.B. Blackberry, Faxserver etc.) so ist sicher zustellen, dass die GAL mit allen Benutzern nie von anderen Anwendern gesehen werden kann, da sie sonst bevorzugt genutzt werden würde (der user ist enthalten und sie ist die größte GAL)

Sie könnten natürlich sagen, dass Sie die "Default GAL" einfach löschen und für jede Firme eine GAL anlegen, in der dann die jeweiligen Mitarbeiter genau einmal auftauchen. Das Löschen der Default GAL ist aber nicht ratsam, da es auch andere Dienste und Nutzer (z.B.: Virenscanner, Archivprodukte, Blackberry Server, user Helpdesk) gibt, die die komplette Liste haben müssen. Einige Installationsroutinen können fehlschlagen, wenn Sie fest codiert die GAL befragen. Also bleibt nur eine korrekte Berechtigung, die wie uns auszugsweise anschauen.

GAl Permissions 

Auch hier ist gut zu erkennen, dass es zwar sehr viele vererbte Rechte gibt, aber auch hier wurden folgende Rechte explizit undn icht vererbt gegeben und können demnach auch entfernt werden.

Container User Rechte Fokus von oben vererbt

GAL HostingF1
(Vererbung aktiv)

AuthenticatedUser
AuthenticatedUser
AuthenticatedUser

Read
Open Address List
Lists content

Nur dieses Objekt
Nur dieses Objekt
Objekt und Unterobjekte

nein
nein
Ja

Auch bei der Berechtigung der GAL können Sie nun zwei Ansätze fahren, die beide kein "Plug and Play" sind, sondern Hilfe benötigen.

  • Anderen Firmen den Zugriff aktiv verweigern
    Sie können für jede Firma eine GAL anlegen und darauf den anderen Firmen den Zugriff per DENY verweigern. Das bedeutet aber, dass Sie beim Anlegen einer neuen Firme auch auf allen bestehenden GALs die Rechte anpassen und Personen, die in zwei Firmengruppen sind, eventuell gar keine GAL haben.
  • Default Rechte entfernen und der Firmengruppe den Zugriff gewähren.
    Sie legen eine neue GAL für die Firma an, entfernen die Berechtigungen für authentifizierte Benutzer und geben der Firmengruppe die Berechtigungen diese GAL zu lesen und zu öffnen.

Denken Sie aber auch daran, dass das Entfernen der Default Rechte die "Default GAL"  für alle Dienste auch erst mal versteckt. Daher bin ich hier eher dafür, auf die Default GAL den "Hosting usern" den Zugriff zu verbieten und über ein Provisioning eben sicherzustellen, dass die "normalen Anwender" die komplette GAL nicht erhalten. Auch wenn dies natürlich eine saubere Pflege der Menschen in Gruppen bedeutet.

Die Berechtigungen der Default GAL könnten dann wie folgt aussehen

Rechte der Default GAL

Entsprechend wäre eine GAL für die Firma ohne "authentifizierte Benutzer" und mit der Sicherheitsgruppe versehen::

GAL für Firma 11

Sie sehen schon, dass Sie bei der Anlage einer neuen Firma schon sehr gewissenhaft die Sicherheitsgruppe dieser Firma auf allen anderen Adresslisten "aussperren" müssen. Ein Berechtigen auf die Benutzerobjekte selbst sollten sie aber nicht durchführen. Auch wenn das erst einmal erfolg verspricht, macht es das System sehr schwer zu warten und sichert den Zugriff nicht gegen die OAB-Generierung ab.

OAB

Für die Outlook 2003/2007 Anwender im Outlook Cached Mode oder alle Outlook Versionen mit einer OST-Datei (Siehe unterwegs mit Outlook) müssen wir natürlich auch noch ein Offline Adressbuch bereitstellen. Das OAB nutzt nun einfach die im vorherigen Schritt angelegte Adressliste (Exchange 2007) oder globale Adressliste (Exchange 2003) und kompiliert diese für die Clients zum Download in einen öffentlichen Ordner oder stellt diese ab Exchange 2007 als WebService (EWS) bereit.

Auf den OAB-Einträgen gibt es jedoch nicht die knifflige Berechtigungsstruktur. Hier sind alle Einträge vererbt und bislang habe ich auch keine Quellen gefunden, die hier Veränderungen vorgenommen haben. Die Definition der OABs ist aber auch nicht kritisch und erfolgt im Exchange System Manager. 

OAB Einrichtung

Der Exchange Server erstellt dann die entsprechenden öffentlichen Ordner, die Sie wieder im Exchange System Manager sehen müssen.

OAB Ordner 

Streng genommen kann aber nun jeder Exchange Benutzer alle öffentlichen Ordner sehen und sich damit die OAB-Dateien, z.B. per OWA, herunter laden. Wer hier also ganz sicher gehen will, muss die vorher verwendeten "Firmengruppen" nun auch zu einem Exchange Verteiler machen und auf den Ordnern berechtigen.

Wann ist es sicher genug ?
Aber all diese Sicherheit funktioniert natürlich nur, wenn ein möglicher Angreifer nicht einfach an Exchange vorbei per LDAP direkt den Domain Controller befragt. Denn über das Setzen von ACLs auf OUs habe ich noch gar nichts geschrieben.

Welches Offline Adressbuch der einzelne Mitarbeiter nutzt, wird nun über zwei Faktoren bestimmt:

  • Einstellungen am Store
    Am Postfachspeicher von Exchange kann ein "Default Offline Adressbuch" konfiguriert werden. Das reicht aus, wenn Sie für jede Firma eine eigene Postfachdatenbank haben.
    OAB am Postfachspeicher
  • Einstellungen beim Benutzer "msExchUseOAB"
    Ist dies nicht der Fall, d.h. in einem Postfachspeicher sind mehrere Firmen abgelegt, dann müssen Sie über das Feld "msExchUseOAB" den distinguishedName des Offline Adressbuchs hinterlegen.
    OAB per user festlegen mit msExchUseOAB

Sicherer ist aber der Eintrag beim Benutzer, denn Postfächer könnten ja mal verschoben werden oder eine Datenbank kann die Postfächer mehrerer virtueller Firmen enthalten. Diese Werte lassen Sich sehr einfach mit ADMODIFY.NET oder einem Skript setzen. Sie sind leider nicht per DSMOD oder der MMC für Benutzer und Computer zu setzen oder einzusehen.

Im Exchange 2007 Hosting Dokument "White Paper: Configuring Virtual Organizations and Address List Segregation in Exchange 2007 http://technet.microsoft.com/en-us/exchange/bb936719(EXCHG.80).aspx" wird gefordert, dass die Einstellung per Benutzer eingestellt wird. Ein kleines PowerShell Skript hilft dabei

Get-Mailbox -OrganizationalUnit "ou=kunde1mou=hosting,dc=msxfaq,dc=net" | %{
	set-mailbox -identity $_ -offlineaddressbook OAB_Firma1
	[string]$dn = $_.distinguishedname 	write-host $dn
	$user = ([adsi]"LDAP://$dn").psbase
	write-host $user.name
	$user.Properties["msExchQueryBaseDN"].Value = "OU=Externe,OU=SCCTest,DC=kit,DC=local";
	$user.CommitChanges();
}

Adressbücher in OWA

Nun können Sie die eigentlichen Anwender und individuelle Verteiler anlegen. Achten Sie penibel darauf, dass die Felder "company", "msExchQueryBaseDN" und "msExchUseOAB" korrekt gepflegt sind.

  • 817218 How to restrict OWA address searches to multiple organizational units

Zudem können und sollten Sie überlegen, ob die Sie Empfangsbeschränkungen zumindest auf Verteiler einer Firma konfigurieren. Oftmals verhindert ja ein Internet Gateway oder die Standardrechte bei Exchange 2007, dass ein Verteiler aus dem Internet erreichbar sind. Aber die anderen Firmen auf dem gleichen Server sind nun mal nicht mehr das "Internet", sondern intern. Dies kann man ebenfalls steuern.

Leider ist zumindest bei Exchange 2003 die MMC so ungeschickt, bei der Anlage des Benutzers noch nicht die sonstigen Kontaktdaten zu erfragen aber dennoch die Funktion "Exchange" anzubieten. Wird der Benutzer gleich für Exchange aktiviert, dann bekommt er die falsche Empfängerrichtlinie, die falsche Mailadresse und man muss nacharbeiten. Bei Exchange 2007 werden zwar mehr Daten abgefragt, aber die Firma oder Custom Attributes sind auch nicht dabei. Hier wird aber die Richtlinie bei einer späteren Änderung in der Exchange Management Console sofort angewendet, so dass hier der Benutzer gleich mit Mail aktiviert werden kann. Wenn Sie den Benutzer in der MMC für Benutzer und Computer anlegen, dann werden Sie bei Exchange 2007 gar nicht gefragt, ob Sie diesen auch für Exchange aktivieren wollen. Dann können Sie in aller Ruhe die Firma ausfüllen und erst dann dem Benutzer ein Postfach geben.

Im Exchange 2007 Hosting Dokument "White Paper: Configuring Virtual Organizations and Address List Segregation in Exchange 2007 http://technet.microsoft.com/en-us/exchange/bb936719(EXCHG.80).aspx" wird gefordert, dass die Einstellung per Benutzer eingestellt wird. Ein kleines PowerShell Skript hilft auch dabei:

Get-Mailbox -OrganizationalUnit "ou=kunde1,ou=hosting,dc=msxfaq,dc=net" | %{
	[string]$dn = $_.distinguishedname 	write-host $dn
	$user = ([adsi]"LDAP://$dn").psbase
	write-host $user.name
	$user.Properties["msExchQueryBaseDN"].Value = "ou=kunde1,ou=hosting,dc=msxfaq,dc=net";
	$user.CommitChanges();
}

öffentliche Ordner

Neben den öffentlichen Ordnern für Offline Adressbücher gibt es natürlich auch noch die normalen öffentlichen Ordner. Hier kann es leider keine eigene Basisstruktur pro Firma geben, so dass Sie hier nur einen Basisordner pro Firma anlegen und die Berechtigungen so steuern können, dass nur die Mitarbeiter der Firma über die vorhandene Gruppe berechtigt sind und alle anderen Personen den Ordner nicht einmal sehen können. Sie werden aber damit leben müssen, dass die Anwender erst eine Ebene tiefer mit ihrer Struktur anfangen können.

Sie können die Berechtigungen einfach in Outlook oder mit dem Exchange 2003 Systemmanager einstellen.

In Exchange 2007 können Sie all die Einstellungen für öffentliche Ordner direkt per PowerShell durchführen.

new-publicfolder -name -"Firma1" -path "\"
Remove-PublicFolderClientPermission -id "\Firma1" -user "anonymous" -accessright createitems
Remove-PublicFolderClientPermission -id "\Firma1" -user "Default" -accessright Author
Add-PublicFolderClientPermission -id "\Firma1" -user "Mitarbeiter Firma1" -AccessRight PublishingAuthor

Seit Exchange 2007 SP1 gibt es auch hierfür eine grafische Managementconsole.

OWA, ActiveSync und Autodiscover

Natürlich werden die Anwender auch auf Outlook Web Access und ActiveSync zugreifen wollen. Wenn Sie keine besonderen Designs für die einzelnen Firmen bereitstellen wollen, dann ist die neutrale Anmeldemaske für die meisten Firmen eine gute Wahl. Wer per NLB mehrere Server bereit stellt, sollte vielleicht überlegen, auf dem Startfenster dem Support einen Hinweis zu geben, auf welchem Server der Benutzer nun gelandet ist.

Aber ohne Verschlüsselung geht natürlich nichts. Erst mit der Verfügbarkeit von SAN-Zertifikate ist es nun auch möglich, auf einem virtuellen Webserver viele Domains zu betreiben. für ein Hosting ist dies zwar möglich aber hat den Nachteil, dass bei der Erweiterung um eine Firma ein komplett neues Zertifikat (mit allen alten und dem einen neuen Namen) zu beantragen ist. Das lassen sich die Zertifizierungsstellen gerne bezahlen. Daher wird es dann doch wieder auf mehrere virtuelle Webserver heraus laufen, so dass jede Firme "ihren" eigenen Webserver für OWA und ActiveSync hat.

Mit Outlook 2007 kommt nun noch die Anforderung hinzu, dass immer mehr Funktionen als Webservice angeboten werden. Und Outlook 2007 nutz dazu (zumindest die RTM-Version) den Namen "autodiscover.maildomäne.tld". Sie müssen also einen entsprechenden Eintrag im DNS vornehmen (lassen) und zudem muss das Zertifikat auch noch diesen Namen enthalten.

Das Problem dabei ist aber, dass SSL nur mit einer eindeutigen IP-Adresse funktioniert und eine Vorauswahl über "Hostheader" nicht möglich ist. Jede virtuelle Firma braucht daher eine eigene IP-Adresse mit einem eigenen Zertifikat. Zumindest wenn jede Firma eine eigene "https://webmail.firma.de"-Adresse haben möchte statt "https://webmail.provider.tld".

Tätigkeit erledigt

Optional: Eigene virtueller Webserver Anlegen
- Eigenes Design
- Eigenes Zertifikat

 

Optional: DNS-Eintrag auf autodiscover.firma.tld (Ab Outloo2007 SP1 reicht auch SRV-Record)

 

Optional: DNS-Eintrag auf webmail.firma.tld

 

TESTEN

Vertrauen ist schnell verspielt, wenn eine Firma "mehr" sieht als erwartet. Besonders wenn Firmenverteiler etc. offensichtlich werden, muss man genau kontrollieren, ob alles wie erwartet funktioniert.

Unterstützung durch Net at Work:
Wir können Sie aktiv unterstützen. Rufen Sie einfach an.

"UNDO" - Rückgängig machen

Wenn Sie die Separierung der Adresslisten wieder rückgängig machen wollen, dann können Sie einfach die oben durchgeführten Schritte wieder ungeschehen machen

Weitere Links