Kalender Federation mit Exchange 2010/2013

Im Vergleich zur Federation unter Exchange 2007 Kalender Federation ist Microsoft mit Exchange 2010/2013 einen neuen Weg gegangen. Musste man unter Exchange 2007 immer eine 1:1 Partnerschaft zwischen den beiden Organisationen einrichten, kann dies nun eine N:M Verbindung sein, bei der das Microsoft "Federation Gateway" die Zugriffe absichert. Eine Exchange Organisation (z.B. der CAS-Server) identifiziert sich gegenüber dem Gateway um um sich ein Token für den Zugriff auf andere Exchange Organisationen zu beschaffen und dann per Autodiscover und EWS die Daten zu erhalten. Natürlich behält der Administrator als auch der Benutzer die Kontrolle darüber, was die andere Seite sehen kann. Auch ist es nicht mehr erforderlich entsprechende Kontakte vorzuhalten.

Wenn Sie noch Exchange 2007 nutzen, dann können die dennoch diesen neuen Weg wählen, wenn Sie einen Exchange 2010 CAS-Server installieren. (Servicepacks und Lizenzen sind zu beachten).

Funktion

Die Exchange 2010/2013 Kalender Federation unterscheidet sich in Installation und Betrieb. Bei der Installation muss jede Exchange Organisation ein Zertifikat erstellen, welches von allen CAS-Servern der eigenen Umgebung genutzt wird. Dieses Zertifikat wird auf das "Microsoft Federation Gateway" hochgeladen. Das Microsoft Federation Gateway muss natürlich sicherstellen, dass hier niemand sich als autoritativ für eine fremde Domäne ausgibt. Daher muss der Administrator einen DNS-Eintrag im öffentlichen DNS vornehmen, welcher vom Federation Gateway überprüft wird.

Zudem muss der Administrator bei sich bestimmen, mit welchen anderen Firmen er eine Federation eingehen will.

Im Betrieb stellt der Anwender wie gewohnt seine Terminanfrage an den Exchange CAS-Server, welche über den Availability-Service nun dafür zuständig ist, die Liste für den Anwender zusammen zu stellen. Lokale Postfächer werden sofort ausgewertet aber wenn Empfänger in einer anderen Exchange Organisation sind, dann passiert folgendes:

  • CAS prüft "OrganizationRelationship"
    Damit kann der Administrator ausgehend steuern, welche andere Organisationen überhaupt angefragt werden. Zudem kann hier hinterlegt werden, wie der Server die Gegenseite erreichen kann, wenn es eine sekundäre Domäne ist oder Autodiscover gar nicht eingerichtet ist und damit statische URLs verwendet werden müssen.
  • Ticket vom Federation Gateway
    Dann holt sich der Server im Auftrag des Benutzers ein Ticket vom Microsoft Federation Gateway für das Ziel.
  • WebService Anfrage an Ziel-Exchange
    Der eigene CAS-Server startet nun eine EWS-Anfrage an die andere Exchange Organisation. Je nach Konfiguration ist dazu erst eine Autodiscover-Anfrage erforderlich.
  • Ziel-Exchange prüft
    Auch das Ziel der Anfrage prüft natürlich die Zulässigkeit. Die Authentifizierung wird über das mitgelieferte Federation Gateway-Token sichergestellt. Zudem prüft der Server auch seinerseits die OrganizationRelationship, um zu bestimmen welche Daten herausgegeben werden.
  • Quell-CAS bereitet die Daten auf
    Der lokale CAS-Server sammelt die Daten von den anderen Exchange Organisationen und ggfls. lokalen Postfächern ein und liefert diese an den Client aus
  • Der Client zeigt den Terminplan
    Erst jetzt kann Outlook in der Terminplanungsansicht zeigen, welche Bereich frei oder belegt sind

Eigentlich klingt das ganz einfach und es ist auf jeden Fall besser und sicherer als der alte Exchange 2007-Weg. Dort war ein Dienstkonto samt Kennwort pro Organisation erforderlich und immer eine latente Gefahr. Das Microsoft Federation Gateway hingegen sieht nie direkt die Daten der Benutzer sondern stellt nur Schlüssel für verifizierte Exchange Server aus, damit diese bei anderen Exchange Servern sich ausweisen können.

TechED Presentation> Federation in Microsoft Exchange Server 2010
http://www.msteched.com/2009/NorthAmerica/UNC315

https://techcommunity.microsoft.com/legacyfs/online/media/2019/01/FB_Errors.FixesV6.pdf

Voraussetzungen

Ausgehend von der Funktionsweise können Sie nun auch die Liste aufstellen, die für den Betrieb erforderlich ist.

Anforderung Erfüllt

Public Domain

Für die Verbindung von Organisation über das Internet sind offizielle Domänennamen erforderlich.

TXT Records im DNS

Das Microsoft Federation Gateway verifiziert die Exchange Organisation anhand eines TXT-Records im öffentlichen DNS. Stellen Sie sicher, dass Sie in ihrer öffentlichen Zone diesen Eintrag anlegen können.

CAS Server kann per HTTPS das MFG erreichen

Der anfragende CAS-Server muss sich für den Zugriff auf die andere Exchange Organisation ein Token beim Microsoft Federation Gateway besorgen. Der Exchange CAS-Server muss daher diesen Server per HTTPS ohne weitere Authentifizierung oder Proxy-Server erreichen können.

CAS-Server per HTTPS zum anderen Exchange CAS

Um später die Anfrage an die andere Exchange Organisation zu senden, muss der CAS-Server natürlich auch mit den anderen Exchange Server per HTTPS kommunizieren können.

CAS Erreichbarkeit

Damit der Exchange Server von anderen Servern gefragt werden kann, muss dieser unter einem Namen für die anderen Server auflösbar und ohne weitere Anmeldung erreichbar sein. Das kann je nach Firma ein Problem sein, da so z.B. WebServices ohne Preauthentication erreichbar sind. Denkbar ist hier dann eine Beschränkung auf die Source-IP der verbundenen Exchange Organisationen

Zertifikate auf allen CAS-Servern

Die Kommunikation ist per HTTPS abgesichert. Die auf dem CAS-Server verwendeten Zertifikate müssen von den anderen Exchange Organisationen in jeder Hinsicht vertrauenswürdig sein, d.h. SAN-Namen, Gültigkeit, ausstellende CA, CRL etc. sind hier zu beachten.

DNS-Auflösung für Autodiscover oder zumindest die Exchange CAS-Server der Gegenseite

Beim Einrichten des Organisationsvertrauens muss ein Hostname für Autodiscover oder direkt die Exchange Web Services URL hinterlegt werden. Dies müssen DNS-Namen sein, die auch im Zertifikat enthalten sind.

Wenn diese Voraussetzungen erfüllt sind, sollte der Einrichtung nichts mehr im Wege stehen.

Einrichtung "Federation Trust" (Kopplung zum MFG)

Für die Funktion der Federation zwischen Exchange 2010 und höher-Servern mit anderen Organisationen ist die Einrichtung einer Federation mit dem Microsoft Federation Gateway-Service von Microsoft (Kostenfrei für Exchange Kunden) erforderlich.
Dies erfordert parallel aber auch, dass die Exchange Server, genauer Autodiscover und EWS, aus dem Internet auflösbar und erreichbar sind.

Die Einrichtung dieser Partnerschaft ist auf der Seite MFG - Microsoft Federation Gateway beschrieben.

Organization Relationship

Wenn die Authentifizierung per Microsoft Federation Gateway konfiguriert und verifiziert ist und die Exchange Server sich auch ein Ticket besorgen können, dann können Sie eine entsprechende Organisationsbeziehung einrichten. Auch das natürlich per GUI und wenn Sie nur ab und an eine neue Partnerschaft auf Gegenseitigkeit einrichten wollen, ist das auch der präferierte Weg.

Beachten Sie, dass dieser Dialog beide Seiten betrifft:

  • Die anfragende Organisation 
    Hier ist wichtig, dass die erste Checkbox aktiv ist, damit überhaupt diese Funktion aktiv ist
  • Die angefragte Organisation
    Für die ZielUmgebung, von der die Daten abgefragt werden, ist die Einstellung bezüglich der Detailstufe relevant. Der Administrator bestimmt damit, welche Informationen die anderen Seite erlangen darf.

Diese Einrichtung steuert aber nur die Federation als solches zwischen zwei Firmen und welche Adressen per default genutzt werden.

Optional: Sharing Policy

Das "Organization Relationship" sorgt schon dafür, dass ihre Anwender die gewünschte Ziel Domäne abfragen können. Sie steuert aber ebenso, welche Abfragen von dieser Domäne an ihre Umgebung gestellt werden dürften..

Zusätzlich kann ein Administrator über Sharing Policies noch genauer steuern, welche Informationen die Benutzer individuell freigeben und austauschen dürfen. Es kann ja sein, dass Sie keine Federation zu einer anderen Domäne einrichten aber die Abfrage von anderen Domänen durchaus erlauben wollen. Die Default Policy erhalten Sie mit (gekürzt):

[PS] C:\>Get-SharingPolicy | fl

Domains           : {*:CalendarSharingFreeBusySimple}
Enabled           : True
Default           : True
AdminDisplayName  :
ExchangeVersion   : 0.10 (14.0.100.0)
Name              : Default Sharing Policy
DistinguishedName : CN=Default Sharing Policy,CN=Federation,CN=Org,CN=Microsoft Exchange,
                    CN=Services,CN=Configuration,DC=msxfaq,DC=net
Identity          : Default Sharing Policy
ObjectCategory    : msxfaq.net/Configuration/Schema/ms-Exch-Sharing-Policy
ObjectClass       : {top, msExchSharingPolicy}
OrganizationId    :
IsValid           : True

Alle Domains dürfen als "Simple Free Busy" sehen, d.h. Belegt-Zeiten aber keine Details. Sie können mehrere Policies anlegen, von denen dann immer eine an die jeweilige Mailbox zugewiesen werden kann.

Set-Mailbox `
   -Identity frank.carius `
   -SharingPolicy "Franks Sharingpolicy"

Wenn Sie z.B. zulassen wollen, dass "anonyme" externe Anfragen erlaubt sein sollen, dann müssen Sie folgendes einrichten. Das Beispiel gilt für einen Exchange Server mit den Namen "EX2010CAS". Passen Sie es für ihre Umgebung entsprechend an.

# Optional: Konfigurieren Sie einen Internet Proxy für ausgehende Anfragen
Set-ExchangeServer `
   -Identity "EX2010CAS" `
   -InternetWebProxy "<Webproxy URL>"

# Erlauben Sie generell das "CalendarPublishing"
Set-OwaVirtualDirectory `
   -Identity "EX2010CAS" `
   -ExternalURL "<URL für CAS01>" `
   -CalendarPublishingEnabled $true

# Anonyme User zulassen
New-SharingPolicy `
   -Name "Anonymous" `
   -Domains 'Anonymous: CalendarSharingFreeBusySimple' `
   -Enabled $true

Ich denke aber nicht, dass dies speziell in Deutschland allzu oft passiert.

Prüfen

Ob ihr Server die Federation-Informationen von anderen Firmen korrekt ermitteln kann, können Sie natürlich prüfen. Mehrere Schritte sind dabei durchzuführen:

  • DNS-Record
    Prüfen Sie per NSLOOKUP, ob die TXT-Einträge auch vorhanden und sichtbar sind. Wenn Sie die internen DNS-Server fragen und eine "Split-Domain" Konfiguration nutzen, dann erhalten die die Daten der internen Domäne und NICHT die Daten, die z.B. das Microsoft Federation Gateway benötigt.
REM Abfrage der MSXFAQ.DE über den vorgegebenen DNS-Server
nslookup -q=TXT msxfaq.de

REM Abfrage der MSXFAQ.DE über einen DNS-Server von Google
nslookup -q=TXT msxfaq.de 8.8.8.8
  • Kontrolle der Federation Information.
    Über das Commandlet "Get-FederationOrganizationIdentifier" können Sie den Status der Federation prüfen. Kontrollieren Sie hier das "Enabled"-Attribut, welches auf True stehen muss und die Liste der Domänen.
Get-FederatedOrganizationIdentifier | fl
  • Test-Commandlets
    Mit der Kalenderfederation kommen auch zwei Commandlets in Funktion, um die Federation zu testen
# Prüfung der Organization Relationship für einen bestimmten Benutzer
Test-OrganizationRelationship

# Prüft die erfolgreiche Verbindung mit dem Federation Gazteway
Test-FederationTrust
  • Mit "Get-FederationInformation" können Sie von einem Exchange Server die Informationen einer anderen Domäne bezüglich Federation abfragen, z.B.
Get-FederationInformation -Domainname "microsoft.com"

Natürlich können Sie bei Fehlern weitere Details z.B. im Eventlog und IISLog finden.

Debugging auf dem Server

Die Exchange "Availability-Services" sind sowohl auf der Seite der anfragenden Organisation als auch auf der Zielorganisation für die Behandlung der Daten zuständig. Entsprechend kann es im Fehlerfall interessant sein, hier die ein oder andere Option zu aktivieren um dann im Eventlog die Fehler zu finden.

Das geht bei Exchange 2010/2013 natürlich auch per PowerShell

# Debugging hochschrauben
get-EventLogLevel "MSExchange Availability\Availability*" `
   | Set-EventLogLevel -Level expert

Im Application Eventlog des Server könnte man dann z.B. folgendes finden:

Log Name:      Application
Source:        MSExchange Availability
Event ID:      4001
Task Category: Availability Service
Level:         Error
Keywords:      Classic User:          N/A
Computer:      EX13.msxfaq.de
Description:
Process Microsoft.Exchange.InfoWorker.Common.Delayed`1[System.String]: <>SMTP:Frank@msxfaq.net failed in application Free/Busy.
Exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.AutoDiscoverFailedException: 
Autodiscover failed für email address <>SMTP:Frank@msxfaq.net with error Microsoft.Exchange.InfoWorker.Common.
Availability.AutoDiscoverFailedException: The response from the Autodiscover service at
'https://autodiscover.msxfaq.net/autodiscover/autodiscover.svc/WSSecurity' didn't return a valid value für User setting 'ExternalEwsURL'.
. Name of the server where exception originated: EX13. ---> Microsoft.Exchange.InfoWorker.Common.Availability.
AutoDiscoverFailedException: The response from the Autodiscover service at 'https://autodiscover.msxfaq.net/
autodiscover/autodiscover.svc/WSSecurity' didn't return a valid value für User setting 'ExternalEwsURL'.
   --- End of inner exception stack trace ---
. Name of the server where exception originated: EX13. This event may occur when the Free/Busy application 
cannot discover a corresponding application in the remote forest.

Ihre Fehlermeldungen können natürlich abweichen. Vergessen Sie aber nach dem Troubleshooting nicht wieder die Debuglevel zurück zu stellen.

# Zurückstellen geht dann wieder mit 
get-EventLogLevel "MSExchange Availability\Availability*" `
   | Set-EventLogLevel -Level lowest

Wenn man z.B. folgende Meldung bekommt und sucht, dann finden sich sehr schnell entsprechenden BLOG-Einträge

Process Microsoft.Exchange.InfoWorker.Common.Delayed`1[Sy... Process Microsoft.Exchange.InfoWorker.Common.Delayed`1[System.String]: 
<>SMTP:user1@msxfaq.info failed in application Free/Busy. Exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.AutoDiscoverFailedException: 
Autodiscover failed für email address <>SMTP:user1@msxfaq.info with error System.Web.Services.Protocols.SoapHeaderException: 
An error occurred when processing the security tokens in the message. 
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) 
at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult) 
at Microsoft.Exchange.SoapWebClient.AutoDiscover.DefaultBinding_Autodiscover.EndGetUserSettings(IAsyncResult asyncResult) 
at Microsoft.Exchange.InfoWorker.Common.Availability.UserSoapAutoDiscoverRequest.EndGetSettings(IAsyncResult asyncResult) 
at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.<>c__DisplayClass4.<EndInvoke>b__3() 
at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.ExecuteAndHandleException(ExecuteAndHandleExceptionDelegate operation). 
---> System.Web.Services.Protocols.SoapHeaderException: An error occurred when processing the security tokens in the message. 
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) 
at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult) 
at Microsoft.Exchange.SoapWebClient.AutoDiscover.DefaultBinding_Autodiscover.EndGetUserSettings(IAsyncResult asyncResult) 
at Microsoft.Exchange.InfoWorker.Common.Availability.UserSoapAutoDiscoverRequest.EndGetSettings(IAsyncResult asyncResult) 
at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.<>c__DisplayClass4.<EndInvoke>b__3() 
at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.ExecuteAndHandleException(ExecuteAndHandleExceptionDelegate operation)
 --- End of inner exception stack trace --- . Name of the server where exception originated: W2K8R2-EX13. 
This event may occur when the Free/Busy application cannot discover a corresponding application in the remote forest.
Get-Federationtrust `
   | Set-Federationtrust `
         -Refreshmetadata `
         -verbose

Es gibt sicher noch viel mehr Fehlermeldungen und wichtig ist, dass Sie mit dem Eventlog von Exchange erste Hinweise bekommen aber auch auf Proxy-Server, mit Netzwerk Monitoring oder auf dem Zielsystem mit IISDebugging das Problem weiter einkreisen können.

Debugging auf dem Client

Mit Tools wie Fiddler können sie auf dem Outlook Client die WebService-Anfragen nachverfolgen. Ich hatte so z.B. schon mal das Problem analysiert, wenn der Benutzer in sehr vielen Gruppen Mitglied ist und daher das Ticket über 100kByte geworden ist.

  • 2491354 You cannot view the free/busy information of Users in a mixed Exchange Server 2007 and Exchange Server 2010 environment

CalFed und Sicherheit

Die Verbindung von zwei Organisationen über Kalender Federation erlaubt es dem einen Exchange Server mit einem Token einen anderen Exchange Server über Daten der Benutzer zu befragen. Das Ganze erfolgt natürlich nur im Rahmen der Berechtigungen und wir müssen einfach hoffen, dass über die WSSSecurity-Anmeldung auch nur diese Daten erreichbar sind. Kritisch könnte hier also zuerst sein, dass der "Default" etwas zu umfangreich eingerichtet ist und quasi eine "offene Federation" besteht.

Aber auch die Kopplung der Identifizierung an einen TXT-Record im DNS ist natürlich eine mögliche AngriffsMöglichkeit, solange DNS noch auf ungesicherte Verbindungen und unsignierte Daten basiert. Das wird sich mittelfristig hoffentlich durch DNSSEC besser. Bis dahin könnte natürlich jemand versuchen, sich als befreundete Firma auszugeben und bei der Einrichtung der Federation die DNS-Anfragen des Microsoft Federation Gateways torpedieren. Denkbar ist dies aber der Nutzen wäre schon sehr fraglich.-

Die abgerufenen Free/Busy-Daten, die ggfls. noch um Ort und Betreff bereichert sind, werden bei korrekter Konfiguration direkt zwischen den beiden Exchange Servern per HTTPS verschlüsselt übertragen. Sie sind quasi ähnlich gesichert wie jede andere SSL-Verbindung.

Damit ist Microsoft als Betreiber des Federation Gateways ein möglicher Schwachpunkt. Zum einen könnte das Federation Gateway unberechtigt entsprechende Tickets ausstellen. Zum anderen "weiß" natürlich das Gateway, welcher Server für welches Ziel wann ein Ticket anfordert. ähnlich einem Webserver könnte Microsoft über Metadaten ermitteln, welche Anwender wohl mit welchen anderen Personen Termine vereinbaren und welche Organisationen miteinander per Kalenderfederation verbunden sind.

Eine gewisse "Sichtbarkeit" dieser Lösung wird sich also nicht verhindern lassen. Allerdings ist es nur eine kleine Teilmenge der Kommunikation. Wenn eine Institution aber auch noch andere Datenquellen einer Firma abschöpft, könnte man damit das Bild zusätzlich abrunden. Das Risiko schätze ich aber als vernachlässigbar gering ein.

Rückbau

Natürlich können Sie alle Änderungen wieder rückgängig machen. Es wurde kein Schema erweitert, keine DienstUser angelegt und so können Sie rückwärts die Einstellungen entfernen:

  • OrganizationLevel
    Wenn Sie nur eine einzelne Partnerschaft auflösen wollen, dann reicht des die OrganizationRelationship aufzulösen
Remove-OrganizationRelationship `
   -identity
  • FederationTrust
    Wenn Sie die komplette Verbindung mit dem Microsoft Federation Gateway abbauen wollen, dann können Sie den Eintrag per GUI oder PowerShell löschen:
Remove-FederationTrust
  • DNS-Eintrag
    Vergessen Sie nicht die TXT-Einträge im DNS ebenfalls zu entfernen, welche Sie anfangs bei der Einrichtung des Microsoft Federation Gateway angelegt haben.
  • Zertifikate
    Eventuell lokal vorliegende Selbstzertifikate, welches mit dem Federation Gateway genutzt wurden, können Sie auch löschen.
Get-ExchangeCertificate `
   | ?{$_.friendlyname -eq "Exchange Federated Delegation"} `
   | Remove-ExchangeCertificate

Damit sollten alle Spuren ihrer Federation wieder rückgängig gemacht worden sein.

Weitere Links