Ressource Forest

Achtung
Für den Einsatz als Ressourcen Forest mit Trennnug der Sichtbarkeit sind in Exchange 2007 und Exchange 2010 vorarbeiten erforderlich. Der Ressourcenforest ist aber kein "Hosting" im klassischen Sinne. Siehe dazu auch Segregation 2007 und Segregation 2010

Exchange und OCS funktionieren perfekt innerhalb einer Organisation bei der die Grenze des Active Directory auch der Active Directory Forest ist. Solange sich alles innerhalb eines Forests in einer oder mehreren Domänen abspielt, habe wir eine relativ problemlose Betriebsumgebung. Alle Exchange Server und OCS Server können einen beliebigen globalen Katalogserver (GC) fragen, und erhalten immer die gleiche Antwort. Dies gibt ihnen als Administrator als auch als Firma einen hohen Freiheitsgrad in der Positionierung von Servern und Diensten.

Dummerweise ist die Realität oft so, dass Firmen nicht nur einen Forest betreiben. Das kann aufgrund der Größe, betrieblicher Separierungsvorschriften (z.B. Entwicklung etc.) oder durch Zukäufe entstanden sein. Als Betreiber haben Sie dann zwei Optionen:

Bei Zukäufen ist eine Migration meist nicht schnell möglich, so dass eine Koexistenz für eine Übergangszeit angesagt ist. Es kann aber auch darauf hinauslaufen, dass nur bestimmte Dienste konsolidiert werden, aber z.B. Clients, Anmeldedienste wieder dezentral bleiben. Und damit sind wir beim Ansatz einer Ressourcen-Konfiguration.

Was ist ein Ressourcen Forest ?

Mal abgesehen von dem "Hosting", welches einen speziellen Schalter beim Setup und anderen Einschränkungen unterworfen ist, können die anderen Modelle, die auf Exchange Hosting beschrieben sind, auch als Ressourcen Forest genutzt werden. Das Prinzip eines Ressourcen Forest ist, dass die Anmeldekonten nicht im gleichen Forest liegen, wie der Service Exchange, Lync o.ä. und entsprechend die Benutzer sich an ihrer Anmeldedomäne authentifizieren und über einen Trust den Zugriff auf die Dienste erhalten.

Ob dann z.B. in Exchange die Organisation eine "Single-Org" ist, oder in sich per Segregation die Sichtbarkeit eingeschränkt ist oder es sogar mehrere Ressoucenforests gibt, ist hiervon unabhängig. Allerdings muss natürlich die Applikation mit dieser Betriebsart zurecht kommen.

Einsatzszenarien

Zuerst könnten Sie sich natürlich fragen, warum jemand zusätzliche DNS-Server, Domain Controller, Trusts etc. einrichten will, um z.B. Exchange oder Lync in einem Ressourcen Forest zu betreiben. Schließlich kostet das alles zusätzliche Hardware, Ressourcen, Lizenzen und auch der Betrieb ist aufwändiger und damit teurer. Auf der anderen Seite stehen aber auch Vorteile, dass Sie die Systeme ein Stück weit getrennt und unabhängig betreiben können.

Es gibt also schon einige Argumente für den Betrieb eines Ressourcenforest. Dies wird interessanter, je mehr eigenständige Firmenteile oder Töchter es gibt, die zwar ihre eigenständige Domäne mit Clients und Diensten brauchen, aber dennoch eine gemeinsame Kommunikationsplattform für Exchange, Lync, Sharepoint etc. suchen.

Ich kenne einige Firmen, die aus genau diesem Grund eine Ressourcenumgebung betreiben, in der Exchange und wenige andere konzernweite Dienste platziert sind und dennoch jede Konzerntochter die Freiheit hat, eigene Anmeldedienste mit ihren eigenen Servern zu betreiben.

Exchange

Fangen wir mit Exchange an. Normalerweise würde Exchange erwarten, das der Active Directory Account, an dem Exchange seine Postfachinformationen (HomeMTA, HomeMDB, ProxyAddresses etc.) hinterlegt, auch das aktive und nutzbare Anmeldekonto ist. Das ist aber beim Ressourcenforest erst mal nicht der Fall. Sicher könnte der Administrator nun den Postfachbenutzer aktiv lassen und über weitere Berechtigungen das Anmeldekonto der anderen Domäne mit "Vollzugriff" berechtigen. Aber das würde dann nur für dieses Postfach gelten aber z.B. nicht für öffentliche Ordnerzugriffe oder zum Download des Offline Adressbuchs. Eine einfache Erweiterung der Berechtigungen ist also nicht ausreichend.

Aber die Microsoft Entwickler haben schon von Anfang an an einen Betrieb als Ressourcen Forest gedacht und je nach Exchange Version einen Weg implementiert, um Konten aus einem vertrauten Forrest einen Zugriff auf die Inhalte so zu gewähren, als wäre es das aktive Postfachkonto. Dieser Weg war zu Zeiten der Migration von Exchange 5.x auf Exchange 2000 sogar die einzige Möglichkeit, wie Benutzer einer NT4-Domäne dennoch ein Exchange 2000-Postfach verwenden konnten.

Microsoft hat als Lösung den Weg gesehen, dass ein Postfachkonto, welches als Platzhalter dient, zum einen durch den Active Directory Connector als deaktiviertes Konto angelegt werden kann und später bei der Umstellung des Anmeldekontos mit ADMT zusammengeführt werden kann. Damit kamen dann erstmals deaktivierte Benutzerkonten ins Spiel, um Postfächer für andere Anmeldekonten bereit zu stellten. Allerdings musste Microsoft diese Logik in Exchange natürlich implementieren und bei deaktivierten Konten in einem anderen Feld (MSExchMasterAccountSID) nach dem Anmeldekonto suchen. Dass dies nicht immer problemlos war, weil auch andere Prozesse ein Konto vielleicht einmal deaktivierte haben, hatte ich schon früh auf Exchange 200x Disabled Account beschrieben.

Dieses Verhalten wurde mit Exchange 2007 erstmals geändert. Hier wurde erstmals das Postfach noch ausführlicher klassifiziert. Schließlich wurden auch Räume und Ressourcen als Postfächer abgebildet und mussten von normalen Benutzerpostfächern natürlich unterschieden werden. In dem Zuge wurde dann auch die "Linked Mailbox" eingeführt.

Das Postfachkonto ist zwar per Default immer noch ein deaktiviertes Konto. Als Nebeneffekt kann so niemand dieses Konto für andere Zwecke oder den Postfachzugriff missbrauchen. Aber es ist nicht mehr zwingend deaktiviert, was bei einer Migration sehr hilfreich sein kann

Lync und OCS

Was für Exchange gilt, kann OCS/Lync nur billig sein. Auch hier ist es relativ einfach möglich, Lync in einem eigenen Ressource-Forest zu betreiben und die Anmeldung über andere Anmelde-Domains zu betreiben. Diese Konstellation habe ich z.B. auch in OCS-Aktion eingesetzt. Ein "Single Server" hat einen Forest samt OCS bereit gestellt und den konnte ich beim Kunden sehr einfach einfach aufstellen, "einbinden" und nach dem Test wieder entfernen.

Auch hier werden für gewöhnlich deaktivierte Konten in der Ressourcendomäne eingesetzt, damit diese nicht für andere Zwecke missbraucht werden können. Ein OCS oder Lync-Server bedient auch diese Benutzer. Aber diesmal ist das Feld "msRTCSIP-OriginatorSID" für die Zuordnung eines Anmeldekontos aus einem anderen Forest zum OCS/Lync-Benutzer maßgeblich. Diese Feld im Ressourcenforest enthält die ObjectSID des Anmeldekontos

Für die Anzeige solcher "Ressourcenbenutzer" gibt es sogar mit "Get-CsAdContact" ein eigenes Powershell-Commandlet. Get-CsAdContact sucht nach Konten die einen msRTCSIP-OriginatorSID enthalten. Der Begriff "Contact" ist dabei irreführend, da es eigentlich Benutzer sind und eben keine Active Directory Kontakte.

Das AD-Konto in der Ressourcendomäne muss für die Funktion von Lync nicht deaktiviert sein.
Aus Sicherheitsgründen sollten Sie aber schon dafür sorgen, dass ein Anwender sich nicht anmelden kann.

Deploying Lync Server 2010 in a Multiple Forest Environment
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=fc2efa36-d1f3-4392-8b3f-7101349b7ca1&displaylang=en

Windows Trusts und "Selective Authentication"

Dass Windows bei Trusts per Default die SID-Filterung aktiv hat, betrifft primär all jede Administratoren, die mit ADMT Benutzer migrieren. Aber eine andere Einstellung bei Trusts kann die Funktion von Exchange im Ressourcen Forest behindern: War früher ein Trust immer "global" zu sehen, d.h. wenn DomainA der DomainB vertraut, und in DomainA war eine Dateifreigabe für "jeder" freigegeben, dann konnten auch Benutzer aus DomainB darauf zugreifen. Das kan unter Windows 2003 und höher nun auch selektiv geschehen und muss auf dem Trust eingestellt werden.

Wenn Sie hier die "selektive Authentifizierung" aktivieren, dann kann erst mal niemand aus der vertrauten Domäne auf ihre Server zugreifen. Ein Zugriff ist dann nur auf die Server möglich, auf denen die entsprechenden Benutzer oder Gruppen der vertrauten Domäne als "Allowed to Authenticate" addiert wurden.

Dies trifft natürlich auch auf Exchange Server in einer Ressourcen-Forest-Umgebung zu. Die Anwender der Anmeldedomäne müssen natürlich auf den Server zugreifen können, um mit ihrem Postfach zu arbeiten.

Windows 2008 R2 und Trusts

Mit Windows 2008 R2 hat Microsoft die Vertrauensstellung beschränkt, Es ist nicht mehr möglich, einen Trust zu einer NT4 Umgebung aufzubauen. Das war unter Windows 2008 noch möglich.

Important Windows NT 4.0 trusts cannot be created between Windows Server 2008 R2-based domains and Windows NT 4.0-based domains. The workaround steps that are documented later in this article apply to only Windows Server 2008. Security changes that are in Windows Server 2008 R2 prevent a trust between Windows Server 2008 R2-based domains and Windows NT 4.0-based domains. This behavior is by design
Quelle:  http://support.microsoft.com/kb/942564/en-us

Unter Windows 2008 konnte dies noch durch ein Absenken des Sicherheitslevels erreicht werden.

Weitere Links

Keywords:Hosting Trust Ressource Forest