If knowledge matters EXCHANGE FEDERATION

Transkript

1 If knowledge matters EXCHANGE FEDERATION In diesem Artikel lesen sie, wie sich zwei Organisationen eine gegenseitige Kalendereinsicht ermöglichen können. Wir beschreiben dies am Beispiel von Microsoft Exchange 2010 SP1. Mit der Exchange 2010 RTM Version wurden noch öffentliche Zertifikate für die "Federation" benötigt und es gab weitere Unterschiede. Viele im Internet verfügbare Beschreibungen zu einer Exchange 2010 Federation beruhen auf der Exchange 2010 RTM Version, auch die beiden derzeit (Stand ) von Microsoft verfügbaren Exchange 2010 Federation Webcasts. Wenn sie eine Federation mit Exchange 2010 SP1 planen sollten sie nur die zu dieser Version passenden Dokumentationen verwenden um Missverständnisse zu vermeiden.

2 EXCHANGE FEDERATION & ORGANISATIONSÜBERGREIFENDE KALENDEREINSICHT In diesem Artikel lesen sie, wie sich zwei Organisationen eine gegenseitige Kalendereinsicht ermöglichen können. Wir beschreiben dies am Beispiel von Microsoft Exchange 2010 SP1. Mit der Exchange 2010 RTM Version wurden noch öffentliche Zertifikate für die "Federation" benötigt und es gab weitere Unterschiede. Viele im Internet verfügbare Beschreibungen zu einer Exchange 2010 Federation beruhen auf der Exchange 2010 RTM Version, auch die beiden derzeit (Stand ) von Microsoft verfügbaren Exchange 2010 Federation Webcasts. Wenn sie eine Federation mit Exchange 2010 SP1 planen sollten sie nur die zu dieser Version passenden Dokumentationen verwenden um Missverständnisse zu vermeiden. Kalendereinsicht: Was bedeutet überhaupt "gegenseitige Kalendereinsicht"? Zumindest die Möglichkeit, die Free/Busy-Zeiten eines anderen Kalenders abfragen zu können. Herr Anton von der Firma ADAM möchte beispielsweise prüfen, ob Herr Berthold von der Firma BERTA am nächsten Mittwochnachmittag Zeit für eine Besprechung hat. Dazu erstellt Herr Anton mit seinem Outlook-Client eine Besprechungsanfrage und gibt als Termin den avisierten Zeitpunkt an, danach trägt er im Besprechungsassistenten die ihm bekannte adresse von Herrn Berthold ein und sobald er diese Eingabe abgeschlossen hat, versucht der Exchange-Server der Firma ADAM die Free/Busy-Zeiten von Herrn Berthold beim Exchange-Server der Firma BERTA zu erfragen. Damit die Exchange-Server der Firmen ADAM und BERTA sich unterhalten können, ist natürlich eine netzwerktechnische Verbindung notwendig. Diese Verbindung wird i.d.r. über das Internet vorgenommen, was voraussetzt, dass die beteiligten Exchange- Server über das Internet erreichbar sind. Sehr hilfreich ist in diesem Zusammenhang, wenn jede beteiligte Firma die Exchange Autodiscover-Funktionalität im Internet bereitstellt. Die gegenseitige Kalendereinsicht kann über die genannten Free/Busy-Abfragen hinausgehen, beispielsweise können - sofern dies konfiguriert wurde- auch Kalender der anderen Organisation als shared Kalender in Outlook eingebunden werden. Damit können diese Kalender -wie unternehmensinterne freigegebene Kalender- sehr einfach eingesehen werden. Früher und Jetzt: Gegenseitige Kalendereinsichten bzw. Free/Busy Zeitabfragen waren mit älteren Exchange-Versionen noch sehr aufwendig (Active Directory Trusts, VPN-Tunnel, Replikation der Free/Busy Systemordner etc.). Dies warf zum einen Sicherheitsfragen auf, denn jede Organisation musste der anderen Organisation Zugang zum eigenen Netzwerk und zum eigenen Active Directory gewähren, auch der Implementationsaufwand war hoch. Mit Exchange 2010 SP1 ist weder ein AD-Trust noch ein VPN notwendig, auch müssen keine Free/Busy-Systemordner repliziert werden und der Aufwand zum Erstellen der Lösung ist eher gering. MFG: Einen wichtigen Baustein habe ich noch nicht erwähnt: das Microsoft Federation Gateway (MFG). Beim MFG handelt es sich um einen kostenlosen Dienst von Microsoft, der für die "Federation" notwendig ist. Sobald eine Kalenderabfrage an eine andere Organisation erfolgt, kontaktiert der abfragende Exchange- Server zuerst das MFG und erhält darüber eine Art Zugangstoken, mit dem er bei der anderen Exchange- Organisation einen dortigen Kalender abfragen kann (vorausgesetzt der Anfragende hat die entsprechenden Rechte um den betreffenden fremden Kalender einzusehen). Damit das MFG diesen Authentifizierungstoken herausrückt, müssen einige Vorbedingungen erfüllt sein. Beispielsweise muss die CAIRO AG - 2 -

3 Domain-Eigentümerschaft der eigenen domain dem MFG bestätigt worden sein. Die gesamte Kommunikation mit dem MFG verläuft übrigens SSL verschlüsselt, also sehr sicher. Einrichten der gegenseitigen Kalendereinsicht: Der Prozess mit dem eine gegenseitige Kalendereinsicht per Federation eingerichtet wird unterteilt sich in zwei Abschnitte. In Abschnitt eins baut jede teilnehmende Organisation eine Federation mit dem MFG auf. In Abschnitt zwei konfiguriert jede Organisation welche Kalenderdetails an wen freigegeben werden. Federated Delegation Subdomain: Als Vorbereitung für Schritt 1 ist eine sogenannte Federated Delegation Subdomain zu erstellen. Sie wird bei den Exchange Accepted Domains eingetragen. Angenommen ihre domain lautet auf den Namen abc.de, dann sollte der Name der Federated Delegation Subdomain exchangedelegation.abc.de lauten (die Subdomain können sie auch anders nennen, allerdings empfehle ich als Bezeichnung exchangedelegation zu verwenden). Verwenden sie diese neue Subdomain nicht für zwecke. Diese Subdomain wird als Account Namespace für den sogenannten Organization Identifier verwendet, der Account Namespace sollte unterschiedlich zur primary domain sein. Anlegen der Federated Delegation Subdomain -> New Accepted Domain Wizard: Schritt 1 - Federation mit dem Microsoft Federation Gateway einrichten: Die MFG-Federation beginnt mit dem Erstellen des erforderlichen Zertifikates per New Federation Trust Wizard. Danach können sie per PowerShell die sogenannten Proof-Werte ihrer -Domains ermitteln (Get-FederatedDomainProof DomainName abc.de) - diese Proof-Werte benötigen sie, denn sie müssen sie im public DNS ihrer domain (bzw. der neuen Subdomain) als Texteintrag veröffentlichen. Diese Einträge weisen sie gegenüber dem MFG als berechtigter Inhaber der domain aus. Nun sollten sie einige Stunden abwarten, damit über die DNS-Replikation der neuen Texteinträge das MFG diese Einträge finden und auslesen kann. Anschließend starten sie den Manage Federation Wizard, er wird die Federation mit dem MFG einrichten. In dem Wizard können mehrere domains eingetragen werden, wichtig ist, dass sie als erste domain die neue exchangedelegation-subdomain eintragen (diese Domain wird dann in CAIRO AG - 3 -

4 Fettschrift angezeigt). Der Manage Federation Wizard wird versuchen die Federation zu aktivieren, diese Aktivierung kann nur dann erfolgreich sein, wenn das MFG die neuen DNS-Texteinträge auslesen kann. Wenn alles klappt, haben sie den ersten Schritt geschafft. Die gleiche Prozedur muss auch jede Organisation durchlaufen, mit der sie eine Kalendereinsicht vereinbaren möchten. Mit dem Cmdlet Get- FederatedOrganizationIdentifier können sie prüfen, ob die exchangedelegation-subdomain (also die neuangelegte Subdomain) der Account Namespace des Organization Identifiers ist. Per Set- FederatedOrganizationIdentifier Enabled $false können sie die Federation mit dem MFG jederzeit deaktivieren (ein Enabled $true aktiviert sie wieder). Federation vorbereiten (Zertifikatserstellung) -> New Federation Trust Wizard: Federation mit dem MFG vereinbaren -> Manage Federation Wizard: CAIRO AG - 4 -

5 Schritt 2 Kalenderfreigabe: Sobald die Federation mit dem MFG aufgebaut ist, sind sie in der Lage mit jeder anderen Organisation die ebenfalls eine Federation mit dem MFG betreibt, Kalendereinsicht zu gewähren bzw. Kalenderabfragen durchzuführen. Wer welche Kalender bis zu welchem Detailgrad einsehen kann lässt sich auf zweierlei Arten konfigurieren: Individuell: d.h. jeder Anwender gibt selbst seinen Kalender für bestimmte Menschen einer anderen Organisation frei und informiert die Berechtigten darüber Allgemein: die Administratoren definieren für alle Anwender die Kalenderfreigaben über eine sogenannte Organisationsbeziehung Individuelle Kalenderfreigabe: Dies erfordert Outlook 2010 als Client (bzw. OWA 2010). Mit diesem Client kann ein Anwender seinen Kalender an externe adressen (= Mitarbeiter einer anderen Organisation die auch eine Federation mit dem MFG erstellt hat) freigeben und bei der Freigabe den Berechtigten gleich per informieren (in der Freigab können sie anfordern, dass der Empfänger seinen Kalender für sie freigibt): CAIRO AG - 5 -

6 Allgemeine Kalenderfreigabe: hier gibt die Administration alle Kalender ihrer Organisation frei, der Detailgrad der Freigabe kann im New Organization Relationship Wizard definiert werden: Nach dem Klicken auf Next werden die Verbindungsinformationen abgefragt: CAIRO AG - 6 -

7 An dieser Stelle kann zwischen einer automatischen Konfiguration per Autodiscover bzw. der manuellen Eingabe der Werte gewählt werden. Die automatische Konfiguration ist vorzuziehen, da die bei der manuellen Konfiguration benötigten Eingaben nicht gerade trivial sind. Die automatische Konfiguration setzt ein funktionierendes Autodiscover per Internet voraus, d.h. die andere Organisation muss ein öffentliches Zertifikat für die gesicherte Autodiscover-Abfrage bereitstellen. Natürlich müssen auch die Web-Services URL s der anderen Organisation (im obigen Beispiel die Firma abc.de) korrekt gesetzt sein (die sog. External URL s). Wollen zwei Firmen ihre Kalender gegenseitig einsehen, muss jede Firma eine Organisationsbeziehung zur jeweils anderen Firma erstellen. Ein Fallstrick wartet auf die Organisationen, die ihre Exchange Web-Services über Microsoft ISA oder einen Microsoft TMG Server veröffentlichen (beides sind Advanced Firewall Server) aber mehr dazu später. Sollte das Autodiscover der anderen Organisation nicht korrekt funktionieren und sie versuchen die Organisationsbeziehung per automatischer Konfiguration zu erstellen wird der Wizard eine Fehlermeldung ausgeben. Fehlermeldungen erhalten sie auch, wenn die Werte bei der manuellen Konfiguration nicht stimmen. Wenn sie per Get- FederationInformation DomainName abc.de den Status der anderen Organisation abfragen wollen, dann sollte ihr Exchange 2010 SP1 Server zumindest über das Update Rollup 3 verfügen (siehe Sharing Policies: Anwender-Kalenderfreigaben haben eine höhere Priorität als die generellen Freigaben per Organisationsbeziehung. Wenn Anwender bzgl. der möglichen Freigabedetails reglementiert werden sollen erfolgt dies über die sog. Sharing Policies. Es können mehrere unterschiedlich konfigurierte Sharing Policies angelegt werden, jedem Anwender kann nur eine Sharing Policy zugewiesen werden. Sharing Policies wirken übrigens nur auf Exchange 2010 basierte Mailboxen. CAIRO AG - 7 -

8 Default Kalenderfreigaben: Persönliche Kalenderberechtigungen bzw. Freigaben haben eine höhere Priorität als generelle Kalenderfreigaben per Organisationsbeziehung. Achten sie bei den Kalenderberechtigungen auf die Default Rechte. Ist der Berechtigungsstand von Default beispielsweise auf None eingestellt, ist dieser Kalender per Federation nicht einsehbar. Dies kann auch genutzt werden, um die Kalender von bestimmten Personen vor Fremd-Einsicht zu schützen. Exchange 2007 Mailboxen vorhanden?: Sind in einer der Organisationen neben dem unverzichtbaren Exchange 2010 SP1 Server auch Mailboxen auf Exchange 2007 Server vorhanden, können auch diese Anwender ihre Kalender freigeben bzw. auf Kalenderfreigaben zugreifen. Eine Voraussetzung ist, dass der Exchange 2007 Server mindestens über das Service Pack 2 verfügt. Weiterhin muss auf dem Exchange 2007 Server ein zusätzlicher Adressraum angelegt werden (Add-AvailabilityAddressSpace -AccessMethod InternalProxy -ProxyUrl CAS server name>/ews/exchange.asmx -ForestName <SMTP domain of the remote Exchange organization> -UseServiceAccount $True) und für jeden abzufragenden Kalender der anderen Organisation ist ein aktivierter Kontakt anzulegen. Da es Aufwendig ist diese Kontakte zu pflegen, empfiehlt sich eine baldige Migration der Mailboxen nach Exchange Und noch etwas gilt es zu beachten: Exchange 2007 lässt Kalenderverfügbarkeitsabfragen für maximal 42 Tage zu, bei Exchange 2010 wurde dieser Wert auf 62 Tage erhöht. Wenn nun eine Exchange 2010 basierte Mailboxen eine Anfrage an eine Exchange 2007 basierte Mailbox stellt kann die Anfrage eventuell zu einem Fehler (Microsoft.Exchange.InfoWorker.Common.Availability.TimeIntervalTooBigException: The requested time duration specified for FreeBusyViewOptions.TimeWindow is too long. The allowed limit = 42 days; the actual limit = 62 days. ---> The requested time duration specified for FreeBusyViewOptions.TimeWindow is too long. The allowed limit = 42 days; the actual limit = 62 days.) führen, da Exchange Tage anfordert aber dieser Wert das 42 Tage Limit des Exchange 2007 Servers überschreitet. Deshalb sollte der maximumqueryintervaldays Wert beim Exchange 2007 Server angepasst werden (Lösungsdetails siehe: d4cc0e) Microsoft ISA (Internet Security & Acceleration) bzw. TMG (Forefront Threat Management Gateway) Server: Werden Exchange Web-Services per ISA oder TMG Server im Internet veröffentlicht, gibt es Besonderheiten. Es ist riskant, Exchange-Server direkt mit dem Internet zu verbinden, beispielsweise über Portweiterleitungen der Unternehmensfirewall an Exchange-Ports. Denn hierbei wäre ein direkter und unauthentifizierter Zugriff aus dem Internet auf interne Ressourcen (Exchange-Services) möglich. Der CAIRO AG - 8 -

9 Exchange-Server wird solche Anfragen zwar mangels Authentifizierung abweisen, dennoch können Unbekannte versuchen eventuelle Schwachstellen des Servers zu identifizieren und auszunutzen. Besser und üblich ist, die Exchange-Services über einen Publisher im Web zu veröffentlichen. Als Publisher dienen oft Microsoft ISA bzw. TMG Server; diese Produkte führen eine Pre-Authentifizierung des Anfragers durch und reichen nur autorisierte Anfragen an interne Ressourcen (Exchange-Services) durch. Und genau hier gibt es ein Problem mit der Federation. Die Exchange 2010 Federation verwendet sogenannte SAML Tokens (und keine vorhandenen Useraccounts) zur Authentifizierung gegenüber dem Exchange-Server der abzufragenden Organisation. Diese SAML Tokens holt sich der abfragende Exchange-Server vom MFG. Setzt die abzufragende Organisation einen ISA bzw. TMG Servers ein, müssen diese Anfragen die Pre-Authentifizierung dieser Firewallserver passieren, was aber nicht gelingt, da weder der ISA noch der TMG Server diese SAML Token verstehen und überprüfen können. Somit werden diese Anfragen geblockt und nicht an den Exchange-Server weitergereicht. Aber nicht nur Kalenderanfragen sind das Problem, auch Autodiscover-Anfragen werden nur nach Pre- Authentifizierung an die Exchange-Services weitergeleitet und beantwortet. D.h. beim Einsatz eines ISA oder TMG Servers werden beim Versuch eine Organisationsbeziehung zu erstellen Probleme auftreten, bereits die im New Organizational Relationship Wizard vorgesehene Autodiscover-Möglichkeit wird nicht funktionieren. Uns selbst wenn sie die benötigten Werte in den Organizational Relationship Wizard manuell eingeben, wird die Organisationsbeziehung nicht herzustellen sein. Ändern sie die ISA bzw. TMG Firewallregeln dahingehend (= Web-Listener ohne Authentifizierung), dass die entsprechenden Anfragen ohne Pre-Authentifizierung an den Exchange-Server weitergereicht werden, können sie die Organisationsbeziehung erstellen und Kalendereinsichten sind möglich. Allerdings ist diese Vorgehensweise riskant, denn damit verzichten sie auf die empfohlene Pre-Authentifizierung und binden diverse Exchange Web-Services unmittelbar an das Internet an. Schön wäre, wenn Microsoft sich dieses Problems annehmen würde. Gibt es aus anderen Gründen ohnehin eine VPN-Verbindung zwischen den beiden beteiligten Organisationen, dann könnte ein Ansatz sein, die Exchange-CAS zu Exchange-CAS Kommunikation über diese VPN-Verbindung laufen zu lassen (beispielsweise mittels lokaler Host-Einträge bei den Exchange- Servern) um die Pre-Authentifizierungsproblematik bei den ISA bzw. TMG Servern zu umgehen. Dann kann die ISA bzw. TMG Pre-Authentifizierung gegenüber Internet-Anfragen weiterhin aktiv bleiben. Resümee: Die mit Exchange 2010SP1 mögliche Federation erleichtert organisationsübergreifende Kalendereinsichten deutlich; bei funktionierendem Autodiscover und ohne die Beteiligung von ISA bzw. TMG Servern stellen sie mit geringem Aufwand einen effizienten Service bereit, den sie bald nicht mehr missen möchten. Die Microsoft Online-Dokumentation (TechNet) zur Federation finden sie hier: Grundlegendes zum Verbund (Exchange 2010 SP2): DE/library/dd aspx CAIRO AG - 9 -

10 SERVICE Sie finde diesen Beitrag auch in dem Blog unseres Infrastructure Teams REAKTIONEN AUF DIESES DOKUMENT Wenn Sie weitere Fragen oder Anregungen zu Inhalt und Form dieses Dokuments haben stehen wir Ihnen gerne zur Verfügung. CAIRO AG Phone +49 (621) Voltastr. 21 Mail teamcairo@cairo.ag Mannheim Internet CAIRO AG