Exchange mit ADFS

Exchange OnPremise kann neben Basic, NLMT, Kerberos und Forms auch eine Anmeldung per SAML-Token anbieten oder anfordern. Warum sollten Sie dies tun und wie wird es konfiguriert? ADFS für Exchange OnPremise ist nicht Mainstream. Daher startet die Seite mit Erklärungen des Warum und Alternativen.

Klassische und Moderne Anmeldung

Ein Grundprinzip der sicheren Datenhaltung ist eine Authentifizierung der Anwender, die auf Informationen zugreifen, damit basierend auf den Anmeldedaten dann Zugriffe über Berechtigungen autorisiert werden können. Der erste Zugriffe eines Anwenders erfolgt daher meist "anonym" und der Server auf der anderen Seite liefert eine Fehlermeldung (Meist 401 Authentication Required), welche auch die möglichen Anmeldeverfahren enthält. Das Angebot kann dabei von der Art des Clients (Browser oder App oder Mobilgerät), dem Netzwerkstandort (Intern oder Internet) und anderen Faktoren abhängen.

Eine zwingende Anmeldung verhindert aber nicht nur einen nichtautorisierten Zugriff, sondern bieten natürlich auch Angreifern eine Angriffsfläche. Ein Angreifer kann z.B. einfach Kombinationen von Benutzername/Kennwort ausprobieren und auf zwei Arten Erfolge erzielen

  • Zugriff
    Es ist gar nicht einmal so unwahrscheinlich, dass ein Anwender auf mehreren Systemen das gleiche oder Kennworte mit nachvollziehbarem Muster verwendet. Wird dann durch einen "Breach" eine Kombination aus Benutzername/Kennwort bekannt, ist zu erwarten, dass Angreifer diese neuen Kombinationen durchprobieren und vielleicht einen Treffer landen. Gegen solche Angriffe helfen 2FA-Absicherungen, da der Angreifer dann dennoch nicht weiter kommt und der Betreiber die mehreren "Abbrüche" als Alarmzeichen deuten kann. Nur wie konfigurieren Sie so eine 2FA-Anmeldung mit Exchange?
  • Blockiert
    Das zweite Schadszenario ist ein "Account Lockout", d.h. der Angreifer versucht sehr oft einen bekannten Anmeldenamen mit falschem Kennwort und das interne Verzeichnis erkennt dies als Angriff und sperrt zur Sicherheit das Konto. Der Angreifer kam zwar nicht ins System aber der oder die Anwender sind auch erst einmal blockiert.

Genau solche Probleme betreffen alle Dienste, die aus dem Internet direkt oder per NAT oder einfache HTTP-Reverse-Poxy-Systeme erreichbar gemacht werden. Eine Absicherung ist notwendig und die "Moderne Anmeldung" mit SAML-Tokens ist ein Weg, die eigentliche Anmeldung an ein dafür spezialisiertes System abzugeben. Das kann z.B. das AzureAD/EntraID sein (Siehe Hybrid Modern Authentication (HMA) oder ein eigener SAML-Service, z.B.: ADFS oder Shibboleth). Es reicht dann diese System mit Regeln und zusätzlichen Sicherungen zu versehen. Die eigentlichen Dienste erwarten dann vom Client ein SAML-Token

Im Idealfall kann der Dienst sich auf "SAML Only" beschränken. Die Realität zeigt aber, dass dies nicht alle Clients können, so dass oft eine Mischfunktion angeboten wird. Das macht sogar Exchange Online, wie sie einfach prüfen können:

Invoke-WebRequest `
   -Uri "https://outlook.office.com/ews/exchange.asmx"``
   -Headers @{"authorization"="bearer"}

Es kommt ein 401-Fehler und die Exception liefert die mögliche Anmeldeverfahren.

Hier bietet Exchange Online "Bearer" über EntraID an, aber auch "Basic"

Ein normaler Exchange Server im LAN bietet hier "NEGOTIATE" und "NTLM" an.

Wenn der Zugriff z.B. auf /ECP oder /OWA geht, dann könne Sie auch eine "Formularbasierte Anmeldung" aktivieren, so dass sie hier keinen 401-Fehler sondern eine 200 OK bekommen und eine Webseite mit Eingabemasken zur Anmeldung auffordert.

Exchange Anmeldungen

Wir wollten aber Exchange OnPremises besser absichern aber nicht mit EntraID und Hybrid Modern Authentication (HMA) arbeiten, sondern einen eigenen Federation Service nutzen. Das wird in vielen Fällen ein Windows ADFS-Service sein, aber im Grunde kann es auch ein *nix-basierter Shibboleth-Server sein. Wir müssen Exchange nur beibringen, dass er eine Anmeldung über diesen Service unterstützt oder anfordert. Hier sind dann auch wieder Überlegungen anzustellen, die das Design und die Umsetzung betreffen. Exchange kann nämlich unterschiedlich  konfiguriert werden und die Einstellungen sind zudem pro virtuellem Verzeichnis möglich.

Einstellung Bedeutung

 

Exchange macht KEIN ADFS

Das ist die Standardeinstellung. Client können sich per NTLM/Kerberos anmelden oder über Formulare. Eine Anmeldung mit "Basic Authentication" ist optional konfigurierbar. Eine Anmeldung mittels "Formbased" oder "Basic-Authentication" sollte immer nur über eine TLS-Verschlüsselung möglich sein. Ansonsten könnte das Kennwort mitgelesen werden.

 

Exchange macht AUCH ADFS

Über eine entsprechende Konfiguration bietet Exchange in der 401-Meldung auch die Adresse des Federation-Service an, die der Client nutzen kann. Bei der Anmeldung auf OWA/ECP mit "Formularbasierte Anmeldung" haben Sie natürlich keine Wahl und werden direkt zu ADFS umgeleitet

 

Exchange macht NUR ADFS

Hier schalten Sie BASIC/NTLM/NEGOTIATE aktiv ab, d.h. alle Clients müssen über alle Protokolle sich immer erst ein Ticket über den Federation-Service holen. Das ist am sichersten, da keine lokale Anmeldung am Exchange mehr möglich ist. Allerdings müssen natürlich alle Clients dies unterstützen.

 

Die Standardeinstellungen eines Exchange Servers für OWA (muss identisch zu ECP sein) und EWS sind:

Sie sehen aber auch hier, dass einige Dinge wie "OAUTH" und "Windows SharePoint-Sicherheit" im Text lesbar sind. In der Konfiguration der Authentifizierung tauchen diese Optionen aber nicht auf

Auch eine ADFS-Konfiguration ist hier nicht per Browser sondern später nur per Exchange PowerShell möglich. Damit sie überhaupt ADFS mit Exchange einrichten können, sind meines Wissens folgende Mindestversionen erforderlich:

  • Exchange 2013 SP1 CU4
  • Exchange 2016
  • Exchange 2019 CU13 

Auch bei den Clients müssen die genauer hinschauen.  Bei Outlook muss es mindestens Build Nummer 16327.20200 oder höher sein.

In der Regel nutzen meine  Kunden nicht Exchange OnPremises mit ADFS zur Verbesserung der Absicherung. Intern ist Kerberos mit MAPI/HTTP mein Favorit ( RPC/HTTP kann kein Kerberos) und für externe Zugriffe gibt es leistungsfähige Alternativen

Extern/Intern und Web Application Firewall

Exchange unterscheidet zwar in der Konfiguration an vielen Stellen zwischen "InternalURL" und "ExternalURL" aber konfiguriert keine eigenen IIS-Instanzen für interne und externe Zugriffe. Ein Exchange Server hat daher erst einmal nur eine Webseite für HTTP-Zugriffe. Viele Dienste unterstützen aber keine Anmeldung mit Tokens und einen SAML-Service und daher ist es sehr wahrscheinlich, dass Sie die klassischen Anmeldeverfahren nicht abschalten können

Damit sollten Sie einen für ADFS-Anmeldung aktivierten Server nicht ungeschützt ins Internet stellen.

Sie sollten daher immer überlegen, wie die die Zugriffe von unsicheren oder nicht vertrauenswürdigen Clients und insbesondere Angreifern angemessen behandeln. Allein der Einsatz von ADFS als zusätzliches Authentifizierungsverfahren sichert ihren Exchange Server nicht ab, wenn er z.B. weiterhin NTLM oder BASIC anbietet. Damit kommt die Rolle der Reverse Proxy-Server und Web Application Firewalls. Es gibt viele Optionen, von denen ich ihnen drei vorstellen möchte:

  • Reverse Proxy mit SSL-Inspection
    Vieleicht haben Sie schon einen Loadbalancer, der die Anfragen der Clients annimmt, decodiert und je nach URL und anderen Kriterien an den Exchange Server weiter gibt. Solche Systeme können sehr oft auch die Anfragen und Antworten verändern. So könnte so eine System die Exchange Antwort auf eine externe Anfrage anpassen und die "WWW-Authenticate"-Header auf den "Bearer"-Eintrag reduzieren. Zudem sollten auch bei der Anfrage eine Anmeldeversuch per Basic/NTLM unterbunden werden. Angreifer müssen sich ja nicht an das Angebot halten
  • Reverse Proxy mit SSL-Inspection und PreAuth
    Die nächste Steigerung ist eine Preauthentication, d.h. dass der Reverse Proxy schon eine Anmeldung z.B. per SMAL-Token erzwingt ehe er denn die nachfolgenden Anforderungen an den nachgeschalteten Exchange Server weitergibt. Das kann dann wieder mi dem gleichen Token oder z.B. per Kerberos - Constraint Delegation erfolgen.
  • Reverse Proxy mit PreAuth ( z.B. Windows WAP - Web Application Proxy)
    Wenn Sie einen ADFS-Server installieren und Zugriffe aus dem Internet erwarten, müssen Sie auch ihren ADFS-Service aus dem Internet erreichbar machen. Microsoft stellt dazu den ADFS Proxy bereit, der nicht nur als Reverse Proxy für ADFS sondern auch für andere Dienste genutzt werden kann. Sie können ihre Exchange Server so über diesen Proxy "veröffentlichen". Der Proxy zwingt zumindest den externen Client sich erst ein SAML-Token zu holen. Der WAP Server ist aber nur sehr schwach was "SSL Inspection" angeht.
  • Azure AD Application Proxy
    Diese Funktion ist ein Reverse-Proxy in Azure, die aber nicht direkt mit dem lokalen ADFS-Server interagiert, sondern indirekt über Entra ID und entsprechend föderierte Domains den lokalen ADFS-Service einbezieht. Mit dem passenden ADFS-Proxy-Agent im lokalen Netzwerk müssen Sie ihren Exchange gar nicht mehr selbst direkt aus dem Internet erreichbar machen und damit die externe Angriffsfläche minimieren.

Alle vier Optionen können mit einem lokalen SAML-Service verbunden werden aber sie können auch unabhängig davon arbeiten.

Konfiguration (Classic)

Wenn Sie nun immer noch überzeugt sind dass sie ADFS für ihre Exchange OnPremises Umgebung aktivieren  müssen, dann sind hier die Schritte als Kurzfassung.

Microsoft beschreibt die Schritte recht ausführlich auf

Allerdings ist die Seite wohl etwas älter, da noch Windows 2012R2 als ADFS-Server beschrieben wird.

ADFS-Server 

Zuerst müssen sie auf dem ADFS-Server ein "Relying Party Trust" einrichten. Das können Sie per GUI oder PowerShell auf dem ADFS-Server machen. Damit  teilen wir dem ADFS-Server mit, wie die Tickets aussehen sollen, die er für Exchange ausstellen muss.

# Diese URLs müssen sie auf ihren Server anpassen
$OWAURL = "https://owa.msxfaq.de/owa/" 
$ECPURL = "https://owa.msxfaq.de/ecp/" 
$EASURL = "https://owa.msxfaq.de/Microsoft-Server-ActiveSync/"

$IssuingRule=@'
    @RuleTemplate = "AllowAllAuthzRule"
    => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit",
    Value = "true");
'@

$RequestRule=@'
    @RuleName = "ActiveDirectoryUserSID"
    c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]

    => issue(store = "Active Directory", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"), query = ";objectSID;{0}", param = c.Value); 

    @RuleName = "ActiveDirectoryGroupSID"
    c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] 

    => issue(store = "Active Directory", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid"), query = ";tokenGroups(SID);{0}", param = c.Value); 

    @RuleName = "ActiveDirectoryUPN"
    c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] 

    => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"), query = ";userPrincipalName;{0}", param = c.Value);
'@

Add-ADFSRelyingPartyTrust `
   -Name "Exchange OWA" `
   -Enabled $true `
   -Notes "Trust for $($OWAURL)" `
   -WSFedEndpoint $OWAURL  `
   -Identifier $OWAURL  `
   -IssuanceTransformRules $RequestRule `
   -IssuanceAuthorizationRules $IssuingRuleRegel

Add-ADFSRelyingPartyTrust  `
   -Name "Exchange ECP" `
   -Enabled $true  `
   -Notes "Trust for $($ECPURL)" `
   -WSFedEndpoint $ECPURL  `
   -Identifier $ECPURL  `
   -IssuanceTransformRules $RequestRule `
   -IssuanceAuthorizationRules $IssuingRuleRegel

#Nur für ADFS Server 2016:
Add-AdfsNonClaimsAwareRelyingPartyTrust `
   -Name "Exchange ActiveSync" `
   -Notes "trust for EAS" `
   -Identifier $EASURL `
   -IssuanceAuthorizationRules '=>issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");'

Damit sollte die ADFS-Konfiguration abgeschossen sein 

ADFS Signing Zertifikat

Wir müssen natürlich Exchange mitteilen, welcher Aussteller die SAML-Tokens digital signiert. Dazu brauchen wir den Thumbprint des Zertifikats.

$ADFSSigningCert = Get-AdfsCertificate -CertificateType Token-Signing
$ADFSSigningCert[0].Thumbprint

# Optional exportieren als Datei
$certBytes=$ADFSSigningCert[0].Certificate.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert)
[System.IO.File]::WriteAllBytes("c:\temp\adfs-token-signing.cer", $certBytes)

Die meisten ADFS-Server stellen ihre "Federation Metadata" per HTTPS bereit. Damit können Sie Informationen ebenfalls abrufen. Ich nutze diese Funktion z.B. um die Restlaufzeit zu überwachen.

Exchange OrganizationConfig

Die Einstellungen zu ADFS sind "Organisationsweit". Über  "Set-OrganizationConfig" teilen wir Exchange mit, wohin er die Clients umleiten soll.

Set-OrganizationConfig `
   -AdfsIssuer "https://<FQDN-ADFSserver>/adfs/ls/" `
   -AdfsAudienceUris @("https://<FQDN-Exchange>/owa","https://<FQDN-Exchange>/ecp") `
   -AdfsSignCertificateThumbprints "ADFSCertificateThumbPrint"

Get-EcpVirtualDirectory `
| Set-EcpVirtualDirectory `
     -AdfsAuthentication $true  `
     -BasicAuthentication $false  `
     -DigestAuthentication $false  `
     -FormsAuthentication $false  `
     -WindowsAuthentication $false

Get-OwaVirtualDirectory `
| Set-OwaVirtualDirectory  `
    -AdfsAuthentication $true  `
    -BasicAuthentication $false  `
    -DigestAuthentication $false  `
    -FormsAuthentication $false  `
    -WindowsAuthentication $false

Sie sehen hier, dass wir nur die virtuellen Verzeichnisse OWA und ECP entsprechend konfigurieren. ActiveSync und insbesondere die EWS-Schnittstelle sind in Exchange OnPremises bislang so noch nicht gesichert. Da aber viele Dienste EWS nutzen, z.B. Outlook Free/Busy-Abfragen etc. ist dieser Weg nicht durch die Beschränkung auf ADFS-Tokens gesichert. Das Commandlet "Set-WebServicesVirtualDirectory" kennt z.B. gar keinen Parameter für "-AdfsAuthentication". Die Exchange PowerShell unter "/PowerShell" wird ja wohl hoffentlich niemand aus unsicheren Netzwerken erreichbar machen.

Konfiguration (Modern Auth mit Exchange 2019 CU13)

Wenn Sie die Einrichtung des Hybrid Mode oder Hybrid Modern Authentication (HMA) anschauen, dann sehen Sie eine leicht andere Art, einen Federation Service in Exchange OnPremises einzubinden, damit Zugriff von Exchange Online über OAUTH möglich sind. Dazu gibt es "AuthServer" und OAUTH2, welche von aktuellen ADFS-Servern ebenfalls unterstützt werden. Voraussetzung sind dazu

  • Exchange 2019 CU13 oder neuer
  • ADFS 2019 oder neuer.
  • Outlook 16.0.17628.10000 oder neuer
  • Windows 11 22H2 +  Update vom 14. März 2023

Erst dann unterstützt Exchange "ModernAuth". Die Empfehlung von Microsoft ist natürlich die Nutzung von Hybrid Modern Authentication (HMA)


Quelle: https://learn.microsoft.com/en-us/exchange/plan-and-deploy/post-installation-tasks/enable-modern-auth-in-exchange-server-on-premises?view=exchserver-2019#overview

Die Quelle ist zugleich auch die Referenz zur Konfiguration.

# Erst einmal Modern Auth als Default abschalten
New-AuthenticationPolicy "Block Modern Auth" `
   -BlockModernAuthWebServices  `
   -BlockModernAuthActiveSync  `
   -BlockModernAuthAutodiscover  `
   -BlockModernAuthImap -BlockModernAuthMapi  `
   -BlockModernAuthOfflineAddressBook -BlockModernAuthPop  `
   -BlockModernAuthRpc 

# Eigene Richtline anlegen, um Modern Auth später pro Benutzer testweise zu aktivieren
# Exchange legt die Policy ohne Blockade von ModernAuth an.
New-AuthenticationPolicy "Allow Modern Auth" 


# ADFS Server als AuthServer in Exchange OnPremises eintragen. 
# Über die Federation MetaData kann Exchange das Token Signing Certificate selbst holen und aktualisieren

New-AuthServer `
   -Type ADFS -Name "MSXFAQ STS" `
   -AuthMetadataUrl https://adfs.msxfaq.de/FederationMetadata/2007-06/FederationMetadata.xml

# AuthServer als Default setzen, damit er in der 401 als Bearer-Endpunkt geliefert wird.
Set-AuthServer `
   -Identity "MSXFAQ STS" `
   -IsDefaultAuthorizationEndpoint $true


# OAUTH2 auf Organisationslevel aktivieren. Sollte in Hybrid-Umgebungen schon aktiv sind
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true
# Auf dem Benutzer die Anmeldung per ModernAuth bekannte geben (Autodiscover)
Set-User -Identity User -AuthenticationPolicy "Allow Modern Auth"

Die Änderung der AuthenticationPolicy kann laut Microsoft bis zu 30 Minuten dauern. Ursache ist nicht die AD-Replikation, sondern ein Caching der Exchange Frontend Server. Ein IISReset der Frontend Server beschleunigt die Anwendung. Damit ihre Outlook Clients ihrem eigenen ADFS-Service vertrauen, müssen Sie auf jedem Outlook Client die URL hinterlege. Das geht per Gruppenrichtlinie, Intune-Policy oder eigene Software-Verteilungen. Microsoft beschreibt den Weg per PowerShell.

New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains" -Force
(Get-Item HKLM:).OpenSubKey("SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains", $true).CreateSubKey("https://adfs.msxfaq.de/")
(Get-Item HKLM:).OpenSubKey("SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains", $true).CreateSubKey("https://adfs.msxfaq.de")

Set-ItemProperty `
   -Path "HKLM:\SOFTWARE\Microsoft\Office\16.0\Common\Identity\" `
   -Name "EnableExchangeOnPremModernAuth" `
   -Type DWord `
   -Value 1

Kontrolle

Der einfachste Weg ist ein Browser, mit dem sie auf Outlook Web App des lokalen Exchange Servers zugreifen. Anstelle einer "integrierten Anmeldung" oder das Exchange Formular sollte der Zugriff sie direkt auf den ADFS-Server umleiten, an dem Sie sich erst authentifizieren müssen und dann wieder zum Exchange Server zurückgeroutet werden. Diese Sprünge sind in der Adressleiste und durch ein gewisses "Flackern" sichtbar. Mit dem im Browser eingebauten Chromium Debugger oder Fiddler können Sie die HTTP-Request mitschneiden und die generelle Funktionsweise analysieren.

Ob Outlook sich per ADFS und SAML-Token am Exchange Server anmeldet, sehen Sie am einfachsten im "Verbindungsstatus". Wie schon bei Exchange Online erscheint dann ein "Träger" oder "Bearer" in der Spalte "Authentication"

In Exchange Online ist OAUTH/SAML ja schon seit ca. 2017 die einzige Option. Wenn hier allerdings ein NTLM, Negotiate oder gar Basic steht, dann nutzt Outlook für diese Verbindung noch keine "Modern Authentication"

Einschätzung

Es gibt sicher Umgebungen, in denen eine Authentifizierung an Exchange OnPremises über einen lokalen ADFS-Service gewünscht oder gefordert sein kann. Bedenken Sie aber, dass ihre Konfiguration von den üblichen Einstellungen und Standards abweicht. Sie ist komplexer, da nun mehr Dienste für die Anmeldung zusammenarbeiten müssen und auch um das jährliche Rotieren der Signing-Zertifikate müssen Sie sich selbst kümmern. Ein Sicherheitsgewinn ist aber nur dann gegeben, wenn sie die Anmeldung am ADFS-Server entsprechend absichern. Im Gegensatz zu Kerberos oder NTLM kann ein ADFS-Service einen Zugriff aus dem Internet über einen ADFS-Proxy unterschiedlich behandeln.

Dennoch bin ich weiter der Überzeugung, dass Sie besser ihre Exchange über Web Application Firewalls mit entsprechender HT-Request/Response-Behandlung und PreAuthentication veröffentlichen. Hier haben Sie deutlich mehr Möglichkeiten zum Schutz und Angriffsbehandlung und ersparen sich eine eher "seltene" Konfiguration in Exchange OnPremises, mit der vielleicht nicht alle 3rd-Party-Produkte umgehen können.

Weitere Links