Exchange Partner Application

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 Contraint 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 (LockOut 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

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

Wenn. wenn PowerShell-Skripte möglichst alles alleine machen aber ich möchte 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.

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

Weitere Links