Ressource Forest

Achtung
Für den Einsatz als Ressourcen Forest mit Trennung 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 bzw. Adress Book Polices.

Beachten Sie dazu auch die Seiten LinkedMailbox und Disabled Account, Ressourceforest und Gruppenrechte und Ressource Forest Konsolidierung

Nicht erst seit Office365 sind Umgebungen mit mehr als einem Forest auch bei den kleinen und mittelständischen Firmen angekommen. Oft ist es auch einfach eine Migration von Benutzern in einen anderen Forest im Rahmen eines Zukaufs oder Verkaufs von Firmenteilen, der einen zeitweiligen parallelen Betrieb erfordern. Dies könnte gerade für Migrationen von Exchange 2003 nach Exchange 2013 erforderlich sein, da es hier keinen direkten Migrationsweg mehr gibt.

Exchange und Lync 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 Lync 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:

  • Migration und Konsolidierung
    Wer lieber einen Forest, eine Exchange Organisation und eine OCS Umgebung betreibt, wird möglichst schell eine Migration herbei führen und vielleicht nur temporär eine Koexistenz implementieren.
  • Koexistenz mit Trust, DirSync ,Federation und Replikation
    Wer mit mehreren Exchange Organisationen leben muss, wird sich über die immer verbesserten Möglichkeiten freuen., um Exchange Organisationen zu verbinden (z. B. Kalender Federation) oder mit Drittprodukten wie Quest Migration Manager o.ä.

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.

  • Schema
    So sind Schemaerweiterungen für Produkte nicht mehr in den Anmeldedomänen erforderlich, was in großen Firmen weit weniger Abstimmungsbedarf bedeutet.
  • Admin-Trennung
    Zudem sind die Ressourcen-Forests deutlich besser geschützt, da sie eine eigene Administration haben. Vorbei die Zeiten, dass ein Admin unwissentlich an der "Default Domain Policy" eine Änderung vornimmt, die alle Exchange Server betrifft.
  • Sicherheit
    Da es in den Ressourcendomains bis auf wenige Admin-konten nur deaktivierte Platzhalter gibt, ist deren Sicherheit deutlich höher. Zudem müssen bei geeigneter Planung die Domaincontroller z. B. nicht per LDAP für Clients erreichbar sein, so dass Sie einen "Bulk Export" über LDIFDE/CSVDE nicht befürchten müssen.
    Ein Massenexport per MAPI ist im Rahmen der sichtbaren GAL denkbar (Segregation 2007 und Adress book Polices)
  • Beste Zusammenarbeit trotz unterschiedlicher Domains und Forests
    Wir wissen, dass eine Exchange Organisation innerhalb eine Forests lebt und eine Zusammenarbeit über Forest-Grenzen hinweg nur per Federation geht. Durch die Konsolidierung von zentralen Diensten in einem Forest vereinfacht sich deutlich die Zusammenarbeit.
  • Migration
    Auch beim Zukauf oder Verkauf von Firmenteilen kann ein Ressourcenforest von Vorteil sein. So kann eine Teilfirma ihre Anmeldedomäne mitnehmen oder behalten und muss nur die Exchange Postfachdaten übertragen. Das ist deutlich einfacher als ein kompletter "Neuaufbau" einer eigenen Umgebung. Auch beim Zukauf können die Neumitglieder sehr schnell in die allgemeine Kommunikation eingebunden werden, ohne dass gleich eine aufwändige Migration von Anmeldekonten mit Clients, Profilen, SID-History etc. erfolgen muss

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.

Matrix der Optionen

Jeder Benutzer muss sich natürlich an einer Domäne, die Teil eines Forest ist, authentifizieren. Dies ist im folgenden dann die Anmeldedomäne bzw. der Anmeldeforest. Ale Resourceforest werden Strukturen bezeichnet, in denen Dienste bereit gestellt werden, aber in der Regel eben keine aktiven Konten zur Authentifizierung vorgehalten werden .Damit also Dienste in einem Ressourcenforest die Anmeldedaten prüfen können, ist eine Verbindung, d.h. DNS-Namensauflösung, IP-Leitwege und Trusts einzurichten.

Office 365 Sonderfall
Office 365 stellt für die meisten Anwender auch einen Ressource Forest Model bereit, aber einen Verzeichnisabgleich und ADFS zum Betrieb. Dieses Thema ist auf Office 365 und Folgeseiten beschrieben.

Für den Betrieb in einer Firma sind folgende vier Konstellationen interessant, wenn es um den betrieb von Exchange und Lync in einer MultiForest Umgebung geht

Modell Postfach Lync Resforest Bewertung

Alles On-Prem

Account

Account

Entfällt

Dieser Fall wird nicht weiter betrachtet, da er die normale Installation aller drei oder mehr Dienste in einem Forest beschreibt. Es gibt keinen Ressourcenforest.

HostedExchange

Ressource

Account

disabled Account

Diese Variante gibt es schon viele Jahre und ist gut dokumentiert. Exchange war schon deutlich früher auf dem Markt als Lync und Firmen, die damals von verteilten Exchange 5.x Installationen mit vielen NT4-Domänen nach Exchange 200x migriert haben, konnten nicht darauf warten, bis alle NT4-Domänen endlich in einem zentralen Forest konsolidiert wurden.

Aber auch heute ist es noch eine oft genutzte Lösung für große Firmen, die aus administrativer Sicht z.B. den Betrieb des "Messaging" von den anderen Diensten abtrennen wollen. Das erleichtert. z.B. Updates, da die Abhängigkeiten von Exchange zu Windows Versionen und Forest/Domain-Level entfällt und die Exchange DCs/GCs von den AnmeldeDCs für PCs etc. getrennt sind

HostedLync

Account

Ressource

disabled Account

Diesen Einsatzfall nutze ich selbst z.B.: für die testweise Bereitstellung von Lync in einem separaten Forest. In dem Anmeldeforest muss kein Schema o.ä. erweitert werden. Es sind nur ein OneWay-Trust und DNS-Einträge erforderlich. So kann Lync natürlich auch Produktiv als komplett getrennte "Telefonanlage" genutzt werden.

Die Kombination von Lync auf Office 365 und lokalem Exchange ist hingegen noch nicht sinnvoll da Exchange UM und ein paar andere Dinge nicht möglich sind. Microsoft geht bei Office 365 davon aus, dass zuerst das Postfach in die Cloud geht.

HostedAll

Ressource

Ressource

disabled Account

Ein kompletter Betrieb aller "Kommunikationsdienste" in einem Ressource Forest hat den großen Vorteil, dass auch die Interaktion von Lync und Exchange einfacher ist als bei einer getrennten Umgebung.

Office 365 wäre ein Beispiel wobei hier ohne Trust natürlich keine "Disabled Accounts" zum Einsatz kommen.

Jedes der Modelle hat individuelle Vorteile und Einschränkungen. Aber schauen wir uns zunächst einmal die Konfiguration der Produkte beim Betrieb in einem Ressource Forest an.

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.

Was passiert, wenn man z.B.: bei einer Migration zwei aktive Konten hat ? Die Ergebnisse sind dann nicht unbedingt vorhersehbar, denn dann greift die Logik von Exchange ins Leere, um das Postfach zu einer übermittelten SID zu finden.

(EnabledUser AND AccountSID=UserSID) OR (DisabledAccount AND MSexchMasterAccountSID = UserSID)

Ich kenne Berichte von Clients, die das Offline Adressbuch nicht mehr herunterladen konnten, Zugriffe auf Stellvertreter nicht funktionieren, SendAs nicht mehr geht. Letztlich sollten Sie aber als Grundprinzip immer einhalten, dass ein Benutzer immer nur genau ein aktives Konto hat und alle anderen Konten schon aus Sicherheitsüberlegungen deaktiviert sein sollten.

Exchange selbst "sucht" nicht in mehreren Forests, selbst wenn diese durch Trusts verbunden sind, nach relevanten Objekten, sondern immer nur im eigenen Forest.

Das Verhalten hat Auswirkungen auf Mitgliedschaften in Gruppen und die Anwendung von Berechtigungen

Exchange, Verteiler und LinkedMailbox

Sie haben nun gelesen, dass Sie als Benutzer auf ein Postfach zugreifen können, wenn Sie mit der richtigen SID ankommen. Beim Ressourceforest mit deaktivieren Benutzern wertet Exchange das Feld "msexchMasterAccountSID" anstatt der "objectSID" aus. Aber Berechtigungen können ja auch über Gruppen vergeben werden und hier haben wir nun folgende Situation, dass wir zwei Benutzerkonten und zwei Forests mit Gruppen haben.

  • Anmeldekonto im Accountforest
    Mit dem Konto meldet sich der Anwender an. Es hat aber keine Exchange Properties
  • Disabled Account im Ressource Forest
    Dieses deaktivierte Konto trägt alle Exchange Properties
  • Security Group im Account Forest
    Das Anmeldekonto ist natürlich in Gruppen des Anmeldeforst, um z.B. Berechtigungen auf Server und Dienste zu erhalten. Diese Gruppe ist aber nicht für Exchange relevant.
  • Verteilergruppe im RessourceForest
    Hier ist dann die Linked-Mailbox, d.h. das deaktivierte Konto im Ressourceforest Mitglied, um Mails zu erhalten. Diese Gruppe erscheint auch in der Exchange GAL. Exchange versucht diese Gruppen immer zu einer Universal Security Group zu machen. Damit kann sie aber keine Konten aus einem anderen Forest enthalten. Für Exchange würde das auch keinen Sinn machen, da die Konten des Anmeldeforest für Exchange nicht sichtbar sind.

Die Frage ist nun, welche der Gruppen für Berechtigungen auf z.B. öffentliche Ordner oder andere Postfächer verwendet werden kann. Ich hatte auch die Hoffnung, dass ich die Exchange Verteiler einfach berechtigen kann. Zumindest können die Anwender in Outlook z.B. einfach die Verteiler als Stellvertreter eintragen. Aber wirken die Berechtigungen auch?

Spiler: Verteilergruppen aus dem Resource Forest sind keine gültigen Berechtigungsgruppen. Zumindest konnte ich es nicht anders nachstellen.

Natürlich habe ich mir überlegt, wie das sein kann. Und letztlich ist der der Anmeldebenutzer, der bei der Anmeldung an Windows seine eigene SID und die seiner "Gruppenmitgliedschaften" in seinem Kerberos bzw. NTLM-Token zusammensammelt und Outlook auf den Weg zum Exchange Server schickt. Der Exchange Server bekommt also die ObjectSID des Users und die SIDs der Gruppen. Wie weiter oben schon beschrieben, schaut Exchange nun nicht nur nach der ObjectSID sondern auch der msexchMasterAccountSID, um die passende MAilbox zu finden. Wenn der Anwender aber nun auf einen öffentlichen Ordner oder ein anderes Postfach zugreifen will, dann wäre es aufwändig, erst anhand der ObjectSID des angemeldeten Benutzers nach einer Mailbox zu suchen und dann für diese die Mitgliedschaften in Gruppen zu ermitteln und dann zu prüfen, ob die Berechtigungen für einen Zugriff vorhanden sind. Da ist es für Exchange einfacher direkt die SID-Liste auf dem Authentication-Protokoll zu verwenden.

Mit dem Wissen können wir uns nun aber alternativen überlegen, z.B.

  • Anmeldebenutzer in Verteilergruppen
    Sie können ja das Benutzerkonto aus dem Anmeldeforest einfach in die Security Group des Ressource Forest aufnehmen. Allerdings funktioniert dies nur, wenn es eine "Domain lokale" Gruppen ist Exchange stellt allerdings jede Grupp auf "Universal Security" um, damit Sie im gesamten Forest vorhanden ist. Wenn ihr Ressourceforest aus nur genau einer Domain besteht, dann können Sie den Gruppentyp umstellen.
    Übere ein Provisioning könne man z.B. in solchen Gruppen alle LinkedMailbox-User suchen und dann die dazu passenden Anmeldekonten addieren.
  • SID der Gruppe kopieren
    Ein zweiter Ansatz könnte es sein, die SID der Verteilergruppen aus dem Resource Forest an eine Gruppe im Anmeldeforest mit ADMT anzufügen und die Anwender im Anmeldeforest in die Gruppe aufzunehmen. Bei der nächsten Anmeldung bekommt der Anwender auch die SIDHistory seiner Gruppen und damit die Rechte im Ressource Forest.

So richtig zufrieden bin ich mit diesen Optionen aber beide Male nicht. Vielleicht ändert Microsoft hier irgendwann doch noch etwas, um Berechtigungen anhand der Verteilergruppen im Ressourceforest mit LinkedMailboxesn als Mitglied auszuwerten. Denn es bietet sich für Anwender geradezu an, die Verteiler in Outlook zur Rechtevergabe zu nutzen.

Diese Aussagen geben einen Versuchsreihe wieder. Es kann durchaus sein, dass das von mir gewünscht Verhalten mittlerweile möglich ist oder aktiviert werden kann.

Daher möchte ich ihnen auch die ein oder andere Quelle aufführen, die so eine Funktion suggeriert.

Assume that you deploy a linked mailbox in a Microsoft Exchange Server 2013 forest, and the linked mailbox is associated with a disabled user account that's in a trusted account forest. When you run the Add-MailboxPermission cmdlet to grant permissions for the linked mailbox, the permissions are granted to the wrong account in the Exchange Server 2013 forest instead of the account in the account forest.
Quelle https://support.microsoft.com/en-us/topic/permissions-for-a-linked-mailbox-are-added-to-an-account-in-the-wrong-forest-in-an-exchange-server-2013-environment-7efff06d-113e-050e-5aea-c53a0e73f31d

Using security groups to set calendar permissions does not work in an Exchange resource forest
https://support.microsoft.com/en-us/topic/using-security-groups-to-set-calendar-permissions-does-not-work-in-an-exchange-resource-forest-86d65464-9f5c-96c4-4afb-8b9af644e31b 

CU12 Exchange 2016 can break additional configurations you have defined in the EWS web.config file. For example we have added the key add key=”UseDisabledAccount” value=”1″ to the OWA and to the EWS web.config. This key helps with the correct handling of low-level calendar permissions as AvailabilityOnly and LimitedDetails on security groups when working with resource forests ( linked mailboxes ). After CU12 has been installed this key was not present in the EWS web.config anymore. It turned out when a customer reported that users who want to access a resource calendar are not able to open it in Outlook and OWA.
https://webbanshee.net/cu12-exchange-2016-net-4-7-2/ 

Resource Forest Folder Permissions in Exchange
https://www.priasoft.com/wp-content/uploads/2015/06/ResourceForestFolderPermissionsinExchange.pdf
Sehr ausführliches aber älteres White Paper, welche die Probleme benennt. Der Anmeldebenutzer ist nicht Mitglied des Verteilers und hat daher nicht die SID. Die LinkedMailbox kommt nicht zum Einsatz. Lösungsansätze: Die SID des Verteilers per ADMT an eine Gruppe im AccountForest hängen, damit der Benutzer die SID hat.

 

 

Lync und OCSa>

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

Lync Outlook Add-on

Mit dem Lync Client wird auch ein Add-on in Outlook installiert. Dieses Add-on ist dazu da, dass die Anwender in Outlook ein "Meeting" planen können. Wenn ein Anwender so ein Meeting einplant, dann muss das Add-on sich von Lync natürlich die Meeting-Daten besorgen, also die Informationen über die SimpleURLs, die Einwahlrufnummern etc. Das erfolgt per "Lync WebServices". Dazu benötigt das Add-on aber die SIP-Adresse.

Interessanterweise scheint das Lync 2010 Add-on aber nicht nur die Provisioning-Informationen des Lync Clients zu verwenden, sondern liest aus der GAL die SIP-Adresse aus dem Feld "ProxyAddresses". Achten Sie daher darauf, dass in der Exchange GAL auch die "richtige" SIP-Adresse hinterlegt ist.

Lync und Exchange UM Cross Forest

Beim Betrieb von Exchange und Lync in unterschiedlichen Forests sind auch Besonderheiten bezüglich Unified Messaging zu beachten. Wenn Exchange z.B. die Lync Server als UM-Gateway nutzen soll, dann müssen diese in der Exchange Konfiguration mittels "exchucutil.ps1" eingetragen werden.

Auf der anderen Seite muss Lync natürlich "wissen", welche Benutzer es in der Umgebung gibt. Hier ist der Lync Server durch die Trusts informiert, dass es noch andere Forests gibt und begibt sich auf die Suche nach Empfängern. Das können Sie auch im Lync Eventlog, wenn Sie das ExUM-Debugging von Lync etwas hochschrauben. Aber einige Einstellungen sind erforderlich

  • Benutzer ist in Exchangeforest
  • Lync ist im LyncForest (Ressource Forest)
  • EXCHUSUTIL.PS1 wurde mit dem "forest: exchangeforest" aufgerufen.
  • FIM oder ein anderes Tool erstellt den "Contact" im LyncForest
    msRTC-OriginatorSID = SID from Exchange Forest
    Addiert ProxyAddresses:  enum:extension;phone-context=dialplan.exchangeforest
    Addiert ProxyAddresses: ENUM:User@domain.tld;phone-context=dialplan.dialplan.exchangeforest
    Addiert ProxyAddresses : sip:User@domain.tld
    msRTC-OptionFlags = 385  (hier bin ich nicht sicher bezüglich relevanz)
  • Lync EXUM durchläuft alle Forests

Sie sehen also dass ein DirSync Prozess einige Felder sinnvoll belegen muss, damit Lync den Call an die VoiceMail weiterleitet.

If Lync server is in resource forest, Exchange server is in account forest, and if we need to enable Exchange Unified Messaging (UM) and other Lync Server to office integration scenarios, the msRTCSIP-PrimaryUserAddress has to be added to list of proxyAddresses in both Microsoft Exchange Server and Lync Server forests, and a two-way trust should be established between both forests. But if UM feature is not required, or Lync and Exchange are both in the resource forest, a one-way trust is good enough.
Quelle: http://social.technet.microsoft.com/Forums/de-DE/ocsplanningdeployment/thread/4cf4428c-9fda-4657-b9ba-10ffb1a84002

Identitäten, Anmeldung und Authentifizierung

Wie sie hier schon sehen, sind im Ressourceforest die Benutzer eigentlich immer "disabled". Das ist insofern richtig, wenn zwischen den beiden Forests ein Trust besteht, über den der Ressourcenforest (er vertraut dem Anmeldeforest) die Anmeldung verifizieren kann. Anders siehst es natürlich bei "locker getrennten" Forests aus, wie dies bei Office 365 der Fall ist. Dann ist das Konto in dem "Ressourcenforest" natürlich auch aktiv. Je nach Konfiguration pflegt der Anwender dort dann seine eigenen Anmeldedaten mit eigenen Kennworten, Richtlinien etc. oder es gibt einen Verzeichnisabgleich, der z.B. Änderungen des Kennworts im Anmeldeforest in den Ressourceforest überträgt oder die Anmeldung erfolgt komplett mit Tokens wie z.B.: bei ADFS.

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.

  • 942564 The Net Logon service on Windows Server 2008 and on Windows Server 2008 R2 domain controllers does not allow the use of older cryptography algorithms that are compatible with Windows NT 4.0 by default

Weitere Links