Exchange Partner Application

Für Exchange 2010/2013 gibt es das MFG Microsoft Federation Gateway, damit ein Exchange Server von einer anderen Exchange Organisation z.B. die Frei/Belegt-Zeiten abrufen kann. Das erfolgt aber durch den Server im Auftrag des Benutzers. Mit Exchange 2013 und neuer sind OAUTH und Exchange Partner Application der Nachfolger.

Zusammenhänge

Wenn ich Zugriff auf Daten in einem System erhalten möchte, dann muss ich mich in der Regel Anmelden (Authentifizierung) und ich muss die erforderlichen Berechtigungen (Autorisierung) erhalten haben. für Benutzer ist das ein schon lange bekannter Prozess, dass Sie sich erst am Active Directory anmelden müssen und dann mit der SID und ihren Gruppenmitgliedschaften auf z.B. Dateifreigaben zugreifen zu können, auf denen über ACLs entsprechende Rechte addiert wurden. für die Exchange Verwaltung mit RBAC werden auch Benutzer genutzt, die dann aber über Rollen entsprechende Berechtigungen erhalten.

Eine solche Authentifizierung und Autorisierung ist aber nicht immer nutzbar oder sinnvoll. Insbesondere wenn Server im Backend miteinander sprechen wollen und die Verbindung z.B. über das Internet (Stichwort Cloud) erfolgt und daher LDAP und Kerberos nicht möglich sind, funktioniert auch Kerberos Constraint Delegation nicht mehr. Genauso wenig ist es aber erwünscht dass ein Anwender eine Anmeldedaten quasi "in Klartext" an einen Server übergibt, damit dieser mit diesen Daten dann einen nachgeschalteten Dienst anspricht. Zwischen Servern wird daher immer mehr mit einem Dienstkonto oder einen Computerkonto gearbeitet. Aber auch dieses Verfahren löst nicht die Probleme der Kennworte, Ablaufzeiten und die Angreifbarkeit (Lock-Out Problematik) von Dienstkonten.

OAuth ist daher eine relativ neue Option, mit der ein anfragender Client oder Dienst sich am Service mit einem Zertifikat anmeldet. Zugegeben gibt es die Anmeldung mit X.509-Zertifikaten schon länger aber diese bauen auf den TCP-Stack auf, d.h. die Verbindung kommt erst zustande, wenn die Anmeldung per TLS erfolgt ist. Dazu müssen dann aber auch Firewalls diese Verbindungen zulassen und nicht immer ist eine mit TLS einhergehende Verschlüsselung der Daten erwünscht. Bei OAuth erfolgt die Anmeldung im HTTP-Playload und genau diesen Weg bietet Exchange 2013 für Dienste wie SharePoint und Lync an, damit diese Dienst mit privilegierten Rechten an Informationen in Exchange kommen können. Wenn die hierbei zum Einsatz kommenden Zertifikate lange genug laufen und auf dem anderen System "sicher" sind, dann ist dies ein sehr sicherer Weg.

Der Weg ist natürlich auch in die Gegenrichtung möglich. Ein Exchange OWA-Server kann z.B.: gegen BING Maps o.a. Dienste gehen um sich als "User" auszugeben und Daten zu erhalten. Dazu muss dann der Exchange Server auf der anderen Seite als "Partner Applikation" eingerichtet sein.

OAUTH erlaubt es unterschiedlichen Diensten als Benutzer auf andere Dienste zuzugreifen.

Beispiele

Ein gutes Beispiel ist ein Exchange 2019 Server, der aber schon mit Exchange 2016 und Exchange 2013 migriert wurde. Bei meinem Exchange 2019 OnPremises Server sind folgende Partner Applications im Laufe der Zeit eingerichtet worden:

Der Exchange Server "vertraut" hier quasi vier unterschiedlichen Applikationen, die mit einem entsprechenden Token sich gegenüber dem lokalen Exchange Server ausweisen können. Wenn Sie z.B. Microsoft Teams in Microsoft 365 nutzen und auf ihren Kalender zugreifen wollen, der in einem OnPremises-Postfach liegt, dann muss Teams nur nur irgendwie auf das lokale Exchange per EWS zugreifen, sonder sich anmelden. Microsoft Teams geht dann zum Azure Authentication Service und fordert ein OAUTH/SAML-Token für den Benutzer als Applikation "00000002-0000-0ff1-ce00-000000000000" an, und startet einen HTTP-Request gegen den lokalen Exchange Server. Damit der lokale Exchange Server damit arbeiten kann, sind zwei Dinge erforderlich:

  • Exchange muss die Applikation kennen
  • Exchange muss dem Ausstellenden Authentication Service vertrauen

Ob das der Fall ist, können Sie per PowerShell einfach prüfen. Die Applikation finden Sie mit Get-PartnerApplication:

[PS] C:\>Get-PartnerApplication "Exchange Online" |fl

Enabled                             : True
ApplicationIdentifier               : 00000002-0000-0ff1-ce00-000000000000
CertificateStrings                  : {}
AuthMetadataUrl                     :
Realm                               :
UseAuthServer                       : True
AcceptSecurityIdentifierInformation : False
LinkedAccount                       : msxfaq.de/Users/Exchange Online-ApplicationAccount
DeploymentId                        :
IssuerIdentifier                    :
AccountType                         : OrganizationalAccount
AppOnlyPermissions                  :
ActAsPermissions                    :
AdminDisplayName                    :
ExchangeVersion                     : 0.20 (15.0.0.0)
Name                                : Exchange Online
Identity                            : Exchange Online
ObjectCategory                      : netatwork.de/Configuration/Schema/ms-Exch-Auth-Partner-Application
ObjectClass                         : {top, msExchAuthPartnerApplication}
WhenChanged                         : 19.11.2018 11:37:28
WhenCreated                         : 24.04.2013 14:13:57
WhenChangedUTC                      : 19.11.2018 10:37:28
WhenCreatedUTC                      : 24.04.2013 12:13:57
OrganizationId                      :
Id                                  : Exchange Online
OriginatingServer                   : DC01.msxfaq.de
IsValid                             : True
ObjectState                         : Unchanged

Prüfen Sie, dass "Enabled: $true" ist oder aktivieren Sie die Partner Application

Get-PartnerApplication `
| Where-Object {$_.ApplicationIdentifier -eq "00000002-0000-0ff1-ce00-000000000000" -and $_.Realm -eq ""} `
| Set-PartnerApplication -Enabled $true

Die Authentication Server finden Sie mit Get-AuthServer.

Für Office 365 ist der evoSTS der ausstellende Token-Server 

Funktionsweise

Microsoft beschreibt auf der folgenden Seiten sehr gut, wie Exchange eine eingehende Anfrage einer Partnerapplikation bearbeitet.

When Exchange 2013 receives an access request from a partner application via Exchange Web Services (EWS), it parses the www-authenticate-header of the https request, which contains the access token signed by the calling server using its private key. The auth module validates the access token using the partner application configuration. It then grants access to resources based on the RBAC permissions granted to the application. If the access token is on behalf of a User, the RBAC permissions granted to the User are checked.
Quelle: https://technet.microsoft.com/de-de/library/jj150480(v=exchg.160).aspx

Der eigentliche Zugriff über den IIS erfolgt also erst einmal "anonym" und statt eines Authentication Headers mit Benutzername/Kennwort, NTLM-Token oder Kerberos-Ticket wird ein signiertes Zugriffstoken mit gesendet.

Einrichtung

Die Einrichtung dieser "Partner Applikationen" erfolgt per Exchange PowerShell., welche entsprechende Objekte im Active Directory anlegt. Dass ist zum einen ein Dienstkonto, RBAC-Rollen und Rollenzuweisungen und zuletzt auch die Information mit welchem Zertifikat z.B. SharePoint oder Lync die Verbindung zum Exchange aufbaut

Ehe Sie nun aber direkt mit "New-PartnerApplication" loslegen, sollten sie folgenden Absatz können:

In Exchange 2013 wird die OAuth-Konfiguration mit Partneranwendungen wie SharePoint 2013 und Lync Server 2013 nur durch die Verwendung des Skripts Configure-EnterpriseApplication.ps1 unterstützt. Durch die Automatisierung der Aufgabe vereinfacht das Skript die Konfiguration der Authentifizierung mit Partneranwendungen und reduziert Konfigurationsfehler
Quelle: Konfigurieren der OAuth-Authentifizierung (http://technet.microsoft.com/de-de/library/jj649094(v=exchg.150).aspx )

Für die Integration von Exchange in SharePoint oder Lync Umgebungen gibt es also ein eigenes PowerShell-Script, welches die erforderlichen Einstellungen vornimmt. Hier meine Aufrufe. Beachten Sie, dass sie einen "." vor das Skript machen müssen, damit es ausgeführt wird.

#Sharepoint
. "C:\Program Files\Microsoft\Exchange Server\V15\Scripts\Configure-EnterprisePartnerApplication.ps1" `
   -AuthMetadataURL https://mysite.msxfaq.net/_layouts/15/metadata/json/1 `
   -ApplicationType Sharepoint

#Lync
. "C:\Program Files\Microsoft\Exchange Server\V15\Scripts\Configure-EnterprisePartnerApplication.ps1" `
   -AuthMetadataURL https://lyncpool.msxfaq.net/metadata/json/1 `
   -ApplicationType Lync

#Fremde Anwendung
. "C:\Program Files\Microsoft\Exchange Server\V15\Scripts\Configure-EnterprisePartnerApplication.ps1" `
   -AuthMetadataURL https://crm.msxfaq.net/metadata/json/1 `
   -ApplicationType Generic

Das Script selbst liegt im "Scripts"-Verzeichnis von Exchange 2013 und kann problemlos eingesehen werden. Weitere Parameter gibt es aber auch nicht. Der Name sagt schon, dass dieses Skript die Konfiguration durchführt. Danach erlaubt Exchange den Zugriff dieser Applikationen, wenn Sie denn die korrekten OAuth-Tokens mit senden.

Technische Funktion

Auch wenn PowerShell-Skripte möglichst alles alleine machen möchte ich dennoch verstehen, was dahinter passiert. Daher habe ich einfach mal die Pakete auf dem LAN mit Wireshark mitgeschnitten und mit der PFX-Datei des SharePoint Server decodiert. Es ist gut zu sehen, dass ein einzelner SSL-Handshake zustande kommt und der Exchange Server zum SharePoint einfach nur ein GET auf die URL auflöst.

https://<tenantname>.sharepoint.com/autodiscover/metadata/json/1
https://outlook.office365.com/autodiscover/metadata/json/1

Interessanterweise kommen bis auf das ACK aber keine Daten zurück. In der Exchange Configuration Partition wurde dann ein neuer Eintrag angelegt

dn: CN=SharePointEnterprise-ec56f75c7089425e8307918ffb603f99,CN=Partner Applications,CN=Auth Configuration,CN=Net at Work 
GmbH,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=netatwork,DC=de
changetype: add
objectClass: top
objectClass: msExchAuthPartnerApplication
cn: SharePointEnterprise-ec56f75c7089425e8307918ffb603f99
distinguishedName: 
 CN=SharePointEnterprise-ec56f75c7089425e8307918ffb603f99,CN=Partner Applicatio
 ns,CN=Auth Configuration,CN=Net at Work GmbH,CN=Microsoft Exchange,CN=Services
 ,CN=Configuration,DC=netatwork,DC=de
name: SharePointEnterprise-ec56f75c7089425e8307918ffb603f99
objectGUID:: siKF+sOQ34566w76TrMZzg==
systemFlags: 1073741824
objectCategory: 
 CN=ms-Exch-Auth-Partner-Application,CN=Schema,CN=Configuration,DC=netatwork,DC
 =de
msExchVersion: 88218628259840
msExchAuthLinkedAccount: 
 CN=SharePointEnterprise-ApplicationAccount,CN=Users,DC=netatwork,DC=de
msExchAuthMetadataURL: 
 https://intranet.netatwork.de/_layouts/15/metadata/json/1
msExchAuthApplicationIdentifier: 00000003-0000-0ff1-ce00-000000000000
msExchAuthRealm: 0fb5b3a9-4993-4eae-80e1-82a164b25ab7
msExchAuthFlags: 5
msExchAuthCertificateData:: 
 MIIERjCCAi6gAwIBAgIQwZpDOlqBdrZM6upInexrbDANBgkqhkiG9w0BAQuFADBaMQswCQYDVQQGEw
 JVuzESMBAGA1uEChMJTWljcm9zb2Z0MRMwEQYDVQQLEwpTaGFyZVBvaW50MSIwIAYDVQQDExlTaGFy
 ZVBvaW50IFJvb3QgQXV0aG9yaXR5MCAXDTEzMDgyODEwMTAxNFoYDzk5OTkwMTAxMDAwMDAwWjBiMQ
 swCQYDVQQGEwJVuzESMBAGA1uEChMJTWljcm9zb2Z0MRMwEQYDVQQLEwpTaGFyZVBvaW50MSowKAYD
 VQQDEyFTaGFyZVBvaW50IFNlY3VyaXR5IFRva2VuIFNlcnZpY2uwggEiMA0GCSqGSIb3DQEBAQuAA4
 IBDwAwggEKAoIBAQCy5nz6/F6DhdMs4gnRXG0fE/GvEjMlamA0bv9t9EwNv3w3NKMZvsbCDvJNOqDt
 9Ounh4b6WopG/J0j21/vK3vPN6TuvbtKdn7ncQAX/zjCamNgcEpkmYfgZH4lacXLF5SF4MrAimbuQG
 CQMpDPBvyA0rjAApavmir0oL4eAT2gukpYiAAEhqL2bbQzeeuDhS9z1Vul4mbi0yMxWIjAqLF/PInV
 pG5w4Q+q/bv4BwewavmrRuGyWrbooJDDCquQXdDbQPrfoLaIRwfNJJT0d1kumQF7YcgG0CyurCq9M7
 jcXCD/jvH+Tyu4bWd93tgATxVBotMN3DKkSjEqKnAujuVPAgMBAAEwDQYJKoZIhvcNAQEFBQADggIB
 AIRQ+bEzoMoAlSDL8ghV8QqfQy+bC3p0VxcAWnHoEQMlOqvTiyHfvm/3k7HxcOwZu2wVEBaNEOKA6C
 BGGJ+OIo+MsXB0cgkLx6Woo+QHsyHe377ccshxVs+bib1DurrBwQ8NcdcF9oPYSfmhT6YrPgvqZIv8
 IRLLoIFao1Fx8wa87dq/dPRvg+NcT36djmAtrzncYFEy5af9n7w5JLjdau87eQ+EbWD8g6tPxbEw16
 dw9gFG5DXhzzydpVCsaFfQLy4dGOTBvsGv+C2IrNqVvuRqgiTZ82lxFE7ibvY2PFvp++FyqLJ6Axg/
 EgAIXxkn+xxtjYNC4NzujWA7eQaWEsFaomb66egFHIIvOq7kvAba/JVBR54FTHQcHcY8Vxw97mvlYq
 Fxa7yphNJAMCVce6gSdEXMfmMTsA6EfRMuLKo/P9JtgKpZYVY6gHM0i8LWmThNYQWuyAR5i7wYFnAG
 zRHWaJXBvFdXaXgbnaFsq4i57bt1auw3kVrEkeXsHuRgpoZdgH5ykgYnoZtL+hIwJw1orczE/DjHXZ
 o0dQnguZpTJbZorCdeiu/QIlWg0iwDVhFSDuh2nCNCzut+ntmPldFFwcr6Hu2GtZT2lx+MXuhhH8I9
 r2shaBiOB7QISnBNB4utOeHwgvwllL2j/GF/Mnk7LLb2YWZn+JfN1hFEOqP8

Interessant ist hier wohl der Eintrag "msExchAuthCertificateData", der meiner Ansicht nach den Public Key des SharePoint Servers enthält, mit der die OAuth-Tokens signiert werden. Leider findet sich dazu noch nicht viel in MSDN oder Suchmaschinen.

Entfernen

Einer Applikation das Vertrauen zu entziehen geht sehr schnell.

Weitere Links