Exchange OAuth

Seit Exchange 2013 gibt es ein "Organisationszertifikat". Diese Seite beschreibt die Hintergründe und wie Sie damit umgehen:

Authentifizierung per Zertifikat

Mit Exchange 2007 war es das erste Mal möglich, dass Exchange Server eine Organisation direkt mit Exchange Servern einer anderen Organisation Kontakt aufnehmen konnten, um z.B. Frei/Belegt-Zeit abzufragen. Siehe dazu auch Kalenderfederation:E2007. Damals musst der Administrator der abgebenden Organisation ein Dienstkonto samt Kennwort einrichten und diese Zugangsdaten an alle Administratoren der anfragenden Organisationen mitteilen. Eine Änderung des Kennwort bedeutete erneut viel Arbeit für die Administratoren und letztlich hatten mehre Administratoren die gleichen Zugangsdaten, die zugleich auch ein "DomainUser" war. Damit konnte also schon das ein oder andere angestellt werden. Mit Exchange 2010 wurde dann das Microsoft Federation Gateway bereitgestellt und die Exchange Server konnten sich damit ohne Benutzerkonten identifizieren und das Dienstkonto ist entfallen.

Allerdings gibt es nun natürlich weiterhin den Bedarf dass Dienste miteinander arbeiten. Im wesentlichen sind das Exchange, Skype for Business/Lync und SharePoint.

  • Skype For Business kann seine Kontakte in Outlook ablegen
    Siehe dazu Unified Contact Store. Exchange muss dazu natürlich verifizieren, dass der Zugriff "legitimiert" ist.
  • Exchange OWA und Presence
    Umgekehrt kann Exchange in Outlook on the Web auch serverseitig den Präsenzstatus des Anwender verwalten und je nach Version sogar chatten. Dazu möchte Skype for Business natürlich auch den Server identifizieren.
  • SharePoint und Benutzerprofile
    Benutzer können sowohl im Exchange als auch im SharePoint z.B. ihr Profilbild aktualisieren. Denkbar ist natürlich, dass auch andere Dienste auf diese Daten zugreifen.
  • Exchange On-Prem und Office 365 Online
    Auch die beiden Exchange Organisationen beim Hybrid-Mode nutzen OAUTH um sich gegenseitig zu identifizieren, z.B. für RMS, eDiscovery und In-Place Archive

Jeder Datenzugriff muss aber Authentifiziert erfolgen. Der Trick von OAUTH ist, dass der eine Server ein Ticket erstellen kann, von dem der anderen Server die Gültigkeit überprüfen kann. Das funktioniert über "Partner Applikationen". Dazu erstellt Exchange aber auch Skype for Business solch ein Schlüsselpaar und der der jeweils andere Server importiert sich den "Public Key" bei der Einrichtung der Partner Applikation.

Exchange Auth Zertifikat

Bei der Installation des ersten Exchange 2013 Servers generiert das Setup schon ein "Self Signed Zertifikat", welches per Default 5 Jahre gültig ist und auf alle Frontend Server repliziert wird

Exchange 2013 Setup creates a self-signed certificate with the friendly name Microsoft Exchange Server Auth Certificate. The certificate is replicated to all front-end servers in the Exchange 2013 organization.
Quelle: https://technet.microsoft.com/de-de/library/jj150480(v=exchg.160).aspx

Welche Zertifikat Exchange aktuell nutzt, ist mit Get-AuthConfig zu erhalten:

[PS] C:\>Get-AuthConfig

'RunspaceId                    : 63f481db-71dd-4989-a094-faaa15ef7100
CurrentCertificateThumbprint  : 03C46B33F33B00B5ABEF123456721E0463412B9C
PreviousCertificateThumbprint :
NextCertificateThumbprint     :
NextCertificateEffectiveDate  :
ServiceName                   : 00000002-0000-0ff1-ce00-000000000000
Realm                         :
DeploymentId                  :
IssuerIdentifier              :
Name                          : Auth Configuration
AdminDisplayName              :
ExchangeVersion               : 0.20 (15.0.0.0)
DistinguishedName             : CN=Auth Configuration,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de
Identity                      : Auth Configuration
Guid                          : 945453c1-64fe-4f00-8b16-c104448502be
ObjectCategory                : msxfaq.de/Configuration/Schema/ms-Exch-Auth-Auth-Config
ObjectClass                   : {top, container, msExchContainer, msExchAuthAuthConfig}
WhenChanged                   : 24.04.2013 14:13:57
WhenCreated                   : 24.04.2013 14:13:56
WhenChangedUTC                : 24.04.2013 12:13:57
WhenCreatedUTC                : 24.04.2013 12:13:56
OrganizationId                :
Id                            : Auth Configuration
OriginatingServer             : DC01.msxfaq.de
IsValid                       : True
ObjectState                   : Unchanged

Hier ist aber nur der "Thumbprint" des aktuellen Zertifikats sichtbar. Aber damit können Sie schon auf die Suche gehen. Mit einem "Get-ExchangeCertificate" sollte das Zertifikat auch erscheinen

[PS] C:\>Get-ExchangeCertificate -Thumbprint 03C46B33F33B00B5ABEF123456721E0463412B9C| fl

AccessRules        :
CertificateDomains : {Federation}
HasPrivateKey      : True
IsSelfSigned       : True
Issuer             : CN=Federation
NotAfter           : 11.01.2017 15:42:32
NotBefore          : 11.01.2012 15:42:32
PublicKeySize      : 2048
RootCAType         : None
SerialNumber       : 73529A9ABCDEF3894C43135E40BA7353
Services           : SMTP
Status             : Valid
Subject            : CN=Federation
Thumbprint         : 03C46B33F33B00B5ABEF123456721E0463412B9C

Das Zertifikat ist per Default 5 Jahre gültig und das "NotBefore"-Datum ist ein guter Indikator, wann in dieser Umgebung das erste mal Exchange 2013 oder Exchange 2016 installiert wurde. Das gleiche Zertifikat wird übrigens auch für die Verbindung zum Microsoft Federation Gateway genutzt.

AuthServer in Office 365

Ähnlich wie bei ADFS-Servern "vertraut" Exchange per Default nicht jedem dahergelaufenen Server. Über die "AuthServer" Einstellungen wird Exchange mitgeteilt, von welchen Servern Exchange ausgestellte Tokens akzeptiert.

An authorization server is a server or service that issues tokens trusted by Microsoft Exchange for access by partner applications.
Quelle: https://technet.microsoft.com/en-us/library/jj218613(v=exchg.160).aspx

Ein Get-AuthServer liefert in Office 365 am 23.11.2016 folgende Liste:

# Office 365 AuthServer (Stand 23.11.2016
PS C:\> Get-AuthServer | ft name,tokenissuingendpoint -au

Name                TokenIssuingEndpoint
----                --------------------
MicrosoftSts        https://accounts.accesscontrol.windows.net/tokens/OAuth/2
EvoSts              https://login.windows.net/common/oauth2/token
Facebook            https://graph.facebook.com/oauth/access_token
LinkedIn            https://api.linkedin.com/uas/oauth/accessToken
SandboxFacebook     http://fakedEndPoint
SandboxLinkedIn     http://fakedEndPoint
SandboxGoogle       http://fakedEndPoint
SandboxTwitter      http://fakedEndPoint
SandboxYahoo        http://fakedEndPoint
Dropbox             https://api.linkedin.com/uas/oauth/accessToken
SandboxSinaWeibo    http://fakedEndPoint
OutlookMobileGoogle http://fakedEndPoint
Box                 https://api.linkedin.com/uas/oauth/accessToken
OwaUserVoice        https://outlook.Uservoice.com/oauth/request_token
GoogleId            https://www.googleapis.com/oauth2/v4/token
SubstrateSts        https://localhost:444/SubstrateTokenIssuer/tokens/1
ebClientGoogle      http://fakedEndPoint

OnPremises sind die Einträge deutlich kürzer.

Renewal und Reparatur

Exchange legt bei der Installation ein 5 Jahre lang gültiges Zertifikat ab. Es gibt aber keinen Prozess dieses Zertifikat automatisch zu verlängern. Das können Sie sich also schon mal in den Kalender schreiben, um die folgenden Befehle dann auszuführen:

New-ExchangeCertificate `
   -KeySize 2048 `
   -PrivateKeyExportable $true `
   -SubjectName "cn=Microsoft Exchange Server Auth Certificate" `
   -DomainName "*.<primaryMaildomain>" `
   -FriendlyName "Microsoft Exchange Server Auth Certificate" `
   -Services SMTP

An einigen Quellen kommt als Name auch "Microsoft Exchange ACS Certificate" vor

Die Angabe eines "Service" ist erforderlich, auch wenn das Zertifikat dazu später nicht eingesetzt wird. Das Commandlet wird nach der Generierung nachfragen, ob das eventuell bestehende Zertifikat überschrieben werden soll. Da antworten Sie natürlich mit "NEIN". Das neue Zertifikat müssen Sie natürlich noch aktiv schalten. Das geht mit:

Set-AuthConfig `
   -NewCertificateThumbprint your_certificate’s_thumbprint_goes_here `
   -NewCertificateEffectiveDate (get-date)

Das Zertifikat muss natürlich noch "veröffentlicht" werden. Auch das geht mit der Powershell

Set-AuthConfig `
   -PublishCertificate

Wenn das alles funktioniert hat, dann sollten Sie das vorherige Zertifikat auch wieder entfernen.

Set-AuthConfig `
   -ClearPreviousCertificate

Am Ende ist ein IISRESET erforderlich, damit die Dienste das neue Zertifikat nutzen.

Wenn Sie Exchange Hybrid nutzen, dann müssen Sie hier natürlich auch noch das Zertifikat zu Exchange Online übertragen.

Exchange Hybrid

Das OAUTH-Zertifikat wird von Exchange Online ebenfalls genutzt, um Free/Busy-Zeiten zu erhalten. Wenn Sie das lokale Zertifikat ändern, dann müssen Sie dies auch in die Cloud hochladen. Am einfachsten geht dies über den Hybrid Configuration Wizard.

Über die AzureAD-Powershell können Sie sehen, welches Zertifikat die Cloud kennt

Get-AzureADServicePrincipal -SearchString "Office 365 Exchange Online" | Get-AzureADServicePrincipalKeyCredential

Das Vorgehen hat Microsoft gut beschrieben:

Konfigurieren der OAuth-Authentifizierung zwischen Exchange- und Exchange Online-Organisationen
https://docs.microsoft.com/de-de/exchange/configure-oauth-authentication-between-exchange-and-exchange-online-organizations-exchange-2013-help

Exchange Partner Applikation

Die Funktion und Einrichtung einer "Partner App" habe ich auf Exchange Partner Application beschrieben.

Weitere Links