Hybrid Modern Authentication (HMA)
Ein Administrator hat mit Office 365 mit MFA und Conditional Access umfangreiche Steuerungsmöglichkeiten, um die Clients und Sicherheitsanforderungen zu steuern. Auch On-Premises gibt es schon lange entsprechende kommerzielle Lösungen. Sei es durch One-Time-Tokens, Smartcards o.ä. Mit der Konfiguration von "Hybrid Modern Authentication" können Sie aber die Funktionen von Office 365 auch für ihre lokalen Exchange und Skype for Business Server mit nutzen.
Mit Exchange 2019 CU13 (Mai 2023) kann Exchange 2019 auch OAUTH2 mit einem lokalen ADFS-Service ohne Exchange Online oder AzureAD.
Wenn Sie AzureAD P1 oder P2 haben, dann sollten sie sich unbedingt HMA als zusätzliche Schutzlösung anschauen. Weiterhin könnte auch der Azure AD Application Proxy für interne Webseiten neben lokalen Exchange und Skype for Business-Installationen interessant sein.
Achtung: Hybrid Modern Auth ist nicht kompatibel mit Exchange Modern Hybrid. Siehe Exchange Hybrid Agent
Hinweis: Der Schutz erfordert einen Zugriff mit Outlook per MAPI/HTTP. Das ist auch der Weg, wie Sie das Rollout schrittweise umsetzen können. Sie zwingen bzw. belassen alle Anwender auf RCP/HTTP und stellen die Piloten auf MAPI/HTTP schrittweise um, ehe Sie dann alle aktivieren.
Funktionsweise Exchange/SfB
Ohne Hybrid Modern Authentication melden Sie sich an ihrem Skype for Business Server oder Exchange Server über die gewohnten Optionen an. Das ist in der Regel Basic-Auth, NTLM und intern auch Kerberos oder natürlich die formularbasierte Anmeldung. Ein weiterer Schutz erfordert dann Drittprodukte.
In Office 365 erfolgt die Anmeldung an den Cloud Diensten aber etwas anders. Der Service leitet den Client zum "EvoSTS" von Microsoft um, der abhängig von Bedingungen und gültigen Anmeldedaten ein OAUTH2-Token für die jeweilige Applikation aus. Bei Hybrid Modern Authentication wird nun genau die gleiche Infrastruktur genutzt, die auch Exchange Online und andere Online-Dienste von Microsoft nutzen.
Am Beispiel von Exchange mit ADFS werden folgende Schritte durchlaufen:
- Anfrage an Exchange mit "Authorization:
Bearer"
Der Client verbindet sich mit dem Exchange Server und meldet über diesen Header, dass er OAUTH kann - Exchange meldet wie gewohnt einen 401
Unauthorized
Wenn auf dem Exchange Server OAUTH aktiv ist, dann erkennt er den Header und sendet dem Client neben den normalen Anmeldeverfahren auch die URLs zum Token-Server. Bei Exchange Online wird nur noch "Basic" parallel mit angeboten
Der WWW-Authenticate-Header enthält auch die URL zum OAuth Server
- Verbindung zum OAUTH-Server
Der Client verbindet sich dann mit diesem Server um ein Ticket anzufragen. Die nächsten Schritt 4-7 gelten nur, wenn der OAUTH-Server seinerseits einen ADFS-Server nutzt. Ansonsten fragt der OAUTH-Server nach entsprechenden Anmeldedaten, ehe er dann bei Schritt 8 weiter macht. - Redirect zum ADFS-Server
Wenn die UPN-Domain "federiert" ist, dann wird der Client wieder zum lokalen ADFS-Service weiter geleitet - Client fordert Ticket vom ADFS an
Diese Paket kann mehrfach kommen, da der Client zuerst anonym anfragt und sich dann bis zu zwei 401-Fehler einfängt, eher er gültige Anmeldedaten übermitteln kann - ADFS stellt Ticket für EvoSTS aus
Wenn der ADFS letztlich die Anmeldung überprüft und die Claim-Rules angewendet hat, dann wird ein Ticket für den EvoSTS ausgestellt - Client sendet Request mit ADFS-Ticket
zum EvoSTS
Erst dann kann der Client fortsetzen, was er im Paket 3 schon anonym begonnen hat - EvoSTS prüft MFA und Conditional Access
Der EvoSTS verifiziert das Ticket und extrahier daraus den UPN. Abhängig davon prüft er nun weitere Bedingungen, ehe er ein Ticket erstellt. Diese zusätzliche Logik ist quasi der Grund, warum wir überhaupt Hybrid Modern Authentication umsetzen. Wir wollen den Mehrwert eines Schutz und Protokollierung der Cloud nutzen - AzureAD gibt sein OK
Wenn die Prüfung durch das AzureAD erfolgreich ist, bekommt der EvoSTS dies gemeldet. Ohne die schritte 4-7 mit ADFS übernimmt das AzureAD auch die Authentifizierung des Benutzres anhand PTA oder PHS. - EvoSTS sendet Token zum Client
- Client fordert Daten beim Service an
Erst jetzt kann der Client seine Anfrage von Schritt 1 mit einem gültigen Ticket an den Exchange Server senden - Exchange prüft und beantwortet
Meist liefert Exchange nicht direkt ein e Antwort, sondern setzt auch "Session Cookies", damit in der Folge nicht jedes Mal das Token übermittelt werden muss.
Wenn Sie keinen ADFS-Service nutzen, sondern z.B. PHS oder PTA mit Seamless Single Sign On, dann sieht das Bild wie folgt aus:
Das System funktioniert sehr ähnlich auch mit Skype for Business On-Premises, nur dass hier die erste Anmeldung per SIP bzw. Lyncdiscover erfolgt und der Client dann den Webticket-Service des Skype for Business Servers anspricht. Der leitet dann den Client zum EvoSTS weiter, eher dann nach Rückkehr mit einem Ticket ein Zertifikat ausstellt.
- SfB online Client Sign in and
Authentication Deep Dive
Part 1: http://www.babylon365.net/sfb-online-client-sign-in-and-authentication-deep-dive-part-1/
Part 2 http://www.babylon365.net/sfb-online-client-sign-in-and-authentication-deep-dive-part-2
Part 3 http://www.babylon365.net/sfb-online-client-sign-in-and-authentication-deep-dive-part-3/ - SfB online Client Sign in and
Authentication Deep Dive
Part 7 (Hybrid) http://thewindowsupdate.com/2019/05/20/sfb-online-client-sign-in-and-authentication-deep-dive-part-7-hybrid/
Funktion mit anderen Diensten
Die Integration von Exchange On-Premises und Skye for Business On-Premises mit EvoSTS ist eine sehr effektive und einfache Möglichkeit auch diese lokalen Dienste mit Conditional Access weiter abzusichern. Die Funktion ist aber auch für beliebige andere Webseiten und Webdienste möglich. Sie müssen dazu die Anfragen über einen Reverse-Proxy leiten, der eine Preauthentication macht. Dafür gibt es natürlich auch schon länger eine Lösung in Form des WAP - Web Application Proxy, der auch einen ADFS-Server fragen kann. Interessanter ist aber die Nutzung eines Azure AD Application Proxy in der Cloud.
So können Sie quasi jede interne Applikation über MFA und Conditional Access absichern.
Einschränkungen
Wo viel Licht ist, ist der Schatten häufig nicht weit. Die Einrichtung von Hybrid Modern Auth geht sehr schnell von statten aber bedenken Sie folgende Randbedingungen
- Azure AD P1 Lizenz
Die Nutzung von Conditional Access oder Web Application Proxy in der Cloud erfordern mindestens eine Azure AD P1-Lizenz in der Cloud. Das ist mit Mehrkosten verbunden, die aus meiner Sicht aber gut investiert sind, denn ohne diese Komponente kann z.B. jeder Anwender alleine mit Benutzername (UPN) und Kennwort sich auf jedem PC der Welt Zugriff zu seinen Daten verschaffen, Office Desktop Apps installieren und Mails per Outlook OST-Datei und Dateien per OneDrive auf diesem unsichereren unbekannten Client ablegen.
Insofern "wollten" sie eigentlich Office 365 E-Pläne gar nicht ohne Azure AD P1 nutzen, welches Sie einzeln oder als Bestandteil von EMS E3 oder Microsoft E3 hinzu lizenzieren können - Abhängigkeit zum AzureAD
Die größere Einschränkung ist natürlich, dass der Client bei jeder Anmeldung sich mit dem EvoSTS im AzureAD verbinden muss und dort auch die Authentifizierung erfolgt. Wenn der Client also nicht schon ein OAUTH-Ticket im Cache hat und verlängern kann, sondern eine Neuevaluierung der Anmeldeinformationen erforderlich ist, dann muss sowohl die Internetverbindung als auch die AzureAD Anmeldung funktionieren. Ist dies gestört, kann sich der Client nicht mehr anmelden obwohl er rein technisch den Server vielleicht erreichen kann.
In dem Fall könnten Sie aber die Hybrid Modern Authentication unter Verlust von Conditional Access kurzfristig deaktivieren. Solange der Server dann "nur" intern erreichbar ist, wäre das ein Notbetrieb bei einem längeren Ausfall. - Mindestvoraussetzungen
Hybrid Modern Auth geht nur mit neueren Versionen der Clients und Server. Sowohl Lync 2013 oder Exchange 2010 sind außen vor und auch Office 2013 braucht einige Updates und Konfigurationseinstellungen. Wenn ein Client aber noch nicht "Bearer" unterstütz, dann kann er weiterhin die alten Verfahren nutzen, bis Sie diese deaktivieren. - Exchange nur MAPI/HTTP und EWS
Die Anmeldung mit Hybrid Modern Authentication funktioniert nur über MAPI/HTTP, EWS und ActiveSync. Zugänge per RPC/HTTP oder gar MAPI/RPC sind so nicht zu sichern. OWA müssen Sie auch anders absichern, z.B. durch einen Azure AD Application Proxy - Alte Verfahren deaktivieren
Der zusätzliche Schutz durch AzureAD, EvoSTS und Conditional Access greift natürlich nur, wenn die Clients auch OAUTH nutzen. Wenn ein Client absichtlich kein "Authorization: Bearer" meldet, dann wird der Server auch keine URL nennen und der Client könnte sich über andere Verfahren weiterhin anmelden.
Zumindest aus dem Internet sollten die Server also nicht zusätzlich so erreichbar sein. Bei Skype for Business ist dies recht einfach zu lösen, das interne und externe Webseite unterschiedliche IIS-Instanzen sind und daher Basic/NTLM auf den virtuellen Verzeichnissen deaktiviert werden können. Bei Exchange ist dies nicht direkt einstellbar und wäre z.B. durch eigene Frontend-Services oder auf einem Reverse Proxy zu konfigurieren.
Voraussetzungen
In Office 365 ist "Modern Auth" bei allen nach 31. Aug 2017 angelegten Tenants schon aktiviert und die bestehenden Tenants können durch den Administrator umgestellt werden. Solange Microsoft aber auch noch "Legacy"-Authentifizierungen unterstützt, können Client natürlich auch noch das "alte Verfahren" nutzen. Aber Microsoft wird diesen Weg sehr bald abschalten, so dass zumindest in der Cloud alle Clients er Modern Authentication angemeldet werden
- Exchange Online - Modern Authentication
and Conditional Access Updates
https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Exchange-Online-Modern-Authentication-and-Conditional-Access/ba-p/609306 - Upcoming changes to Exchange Web Services (EWS) API for
Office 365
https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Upcoming-changes-to-Exchange-Web-Services-EWS-API-for-Office-365/ba-p/608055
Ab 13. Okt 2020 wird Modern Auth bei Exchange Online Pflicht. - All Skype for Business IP Phones must be
firmware updated by January 15, 2020 to
continue to sign into Office 365
https://tomtalks.blog/2019/04/all-skype-for-business-ip-phones-must-be-firmware-updated-by-july-1st-2019-to-continue-to-sign-into-office-365/
Insofern sollten die meisten Clients eh schon "ModernAuth" können. Dennoch ist ein Check ratsam.
Die zweite Komponente ist die Kombination der Authentifizierung im Hybrid Mode von Exchange und Skype for Business. Microsoft unterstützt hier 6 Szenarien:
- Skype for Business topologies supported
with Modern Authentication
https://docs.microsoft.com/de-de/skypeforbusiness/plan-your-deployment/modern-authentication/topologies-supported
Szenario | Exchange On Prem | Exchange Online | SfB On Prem | SfB Online |
---|---|---|---|---|
1. Benutzer sind schon in Exchange Online aber nutzen SfB On-Premises |
|
MA |
Legacy |
- |
2. Benutzer sind in Exchange On Prem aber nutzten SfB Online |
Legacy |
- |
|
MA |
3. Benutzer in Exchange und EXO (mit MA) und SfB OnPrem |
Legacy |
MA |
Legacy |
- |
4. Benutzer in Exchange ON Prem und in beiden SfB Welten |
Legacy |
- |
Legacy |
MA |
5. Mitarbeiter sind auf allen Systemen verteilt. |
Legacy |
MA |
Legacy |
MA |
6. Mitarbeiter sind auf allen Systemen verteilt und MA aktiv |
MA |
MA |
MA |
MA |
Sie sollten aber auch sofort sehen, dass "Modern Auth" auf der lokalen Umgebung immer nur erlaubt ist, wenn sowohl Exchange als auch Skype for Business entsprechend aktiviert sind. Je nach Betriebsart kann der Anwender durchaus mehrere Anmeldedialoge zu sehen bekommen, insbesondere bei Zugriffen auf öffentliche Ordner oder Stellvertreter, wenn in dem fall unterschiedliche Anmeldeverfahren (Legacy vs. MA) gemischt werden.
Auch für die verschiedenen Versionen gibt es entsprechende Voraussetzungen zu beachten. Im Nov 2019 waren dies:
Prüfpunkt | Erfüllt |
---|---|
SfB 2015 mit May 2017 UpdateSBAs fallen aber nicht darunter, da sie keine Authentifizierung durchführen. |
|
SIP-DomainSie muss in Office 365 als Federated Domain eingetragen sein. Auch das sollte spätestens beim SfB Hybrid Mode eh erfüllt sein |
|
Koexistenz SfB 2015/SfB2019Es ist möglich, beide Versionen parallel zu betreiben aber Lync 2013 oder gar Lync 2010 ist nicht mehr möglich. |
|
Internet-Zugriff für SfB ServerDie SfB On-Premises Server müssen mit Office 365 kommunizieren können. Wenn dies nur über einen HTP-Proxy möglich ist, dann müssen die beiden web.config-Dateien der WebTicket-Services (IIS) angepasst werden: Hier ein Auszug <system.identityModel.services> <system.net> <defaultProxy> <proxy proxyaddress="https://proxy.msxfaq.de:8080" bypassonlocal="true" /> </defaultProxy> </system.net> </system.identityModel.services> Achtung: |
|
Exchange Server Version: 2013 CU19, 2016CU8 und 2019 CU1 oder höherExchange 2007/2010 wird nicht unterstützt und wie schon beim MRS ist SSL-Offloading nicht erlaubt. SSL-Reencryption ist aber möglich. |
|
Exchange "Classic Hybrid"-ModeMin-Hybrid oder Modern Hybrid ist aktuell offiziell nicht unterstützt, auch wenn ich keinen Grund wüsste, der dagegen spricht. Hybrid
Modern Authentication is not
supported with the Hybrid
Agent. |
|
Anforderungen an die ClientsModern Auth wird vom Server dem Client nur angeboten, wenn der Client das richtige Protokoll nutzt und den Server über seine Tauglichkeit informiert.
|
|
Mittlerweile sollte aber quasi jede Firma schon diese Voraussetzungen erfüllen.
- Hybrid Modern Authentication overview
and prerequisites for using it with On-Premises
Skype for Business and Exchange servers
https://docs.microsoft.com/de-de/office365/enterprise/hybrid-modern-auth-overview#what-changes-when-i-use-modern-authentication - Using hybrid Modern Authentication with
Outlook for iOS and Android
https://docs.microsoft.com/Exchange/clients/outlook-for-ios-and-android/use-hybrid-modern-auth - Alternate Login ID
- Hybrid Modern Authentication with Alternate-ID
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configuring-alternate-login-id#hybrid-modern-authentication-with-alternate-id
Ausgangssituation
Nur für den Fall, dass Sie ihre bestehende Umgebung mit einer Basiskonfiguration vergleichen müssen, habe ich hier hinterlegt, wie meine Basis gestartet ist.
# Skype for Business 2015 PS C:\> Get-CsOAuthConfiguration Identity : Global PartnerApplications : {} OAuthServers : {} Realm : ServiceName : 00000004-0000-0ff1-ce00-000000000000 ClientAuthorizationOAuthServerIdentity : ExchangeAutodiscoverUrl : ExchangeAutodiscoverAllowedDomains : PS C:\> Get-CsOAuthServer
Per Default sind keine OAuth-Server hinterlegt und ClientAuthorizationOAuthServerIdentity ist auch nicht gesetzt.
Einrichtung
Die Hauptarbeit zu Hybrid Modern Authentication haben Sie vermutlich schon durchgeführt aber ich führe die Tätigkeiten trotzdem noch mal in einer Checkliste auf. Da die Umstellung sowieso nur für Skype for Business On-Premises und Exchange On-Premises parallel erfolgen darf, ist die Liste für beide Plattformen passend.
- Hybrid Modern Authentication overview
and prerequisites for using it with On-Premises
Skype for Business and Exchange servers
https://docs.microsoft.com/de-de/office365/enterprise/hybrid-modern-auth-overview - How to configure Skype for Business On-Premises
to use Hybrid Modern Authentication
https://docs.microsoft.com/de-de/office365/enterprise/configure-skype-for-business-for-hybrid-modern-authentication - How to configure Exchange Server On-Premises
to use Hybrid Modern Authentication
https://docs.microsoft.com/de-de/office365/enterprise/configure-exchange-server-for-hybrid-modern-authentication
Prüfpunkt | Erfüllt |
---|---|
Tenant mit Modern AuthBasieren auf der obigen Liste muss der Office 365 Tenant auf "Modern Auth" umgestellt sein. Wenn ihr Tenant also älter als 31.8.2017 ist, dann sollten Sie die erst mal prüfen: Get-CsOAuthConfiguration | fl ClientADALAuthOverride Mögliche Werte sind
Wenn der Wert von "ClientADALAuthOverride auf "Allowed" steht, dann ist Modern Authentication bereits eingeschaltet. Ansonsten müssen die Modern Authentication erst aktivieren: # Zuerst Exchange Set-OrganizationConfig -OAuth2ClientProfileEnabled $true # denn SfB Set-CsOAuthConfiguration -ClientAdalAuthOverride Allowed
|
|
ClientsDamit Hybrid Modern Authentication überhaupt funktionieren kann, müssen die Clients die derartige Anmeldung unterstützen. Es ist nämlich der Client, der bei der ersten Anfrage ein "Authentication: Bearer" an den Service sendet und anhand dessen der Service dann den Client zum konfigurierten OAUTH-Service weiter leitet. Es ist möglich, dass Sie per Gruppenrichtlinien den Clients verbieten, die Fähigkeit "Bearer" zu melden und der Service wird dann eine Legacy-Anmeldung anbieten. Denken Sie dran, dass ActiveSync-Clients ein neues Profil einrichten müssen. Outlook/IOS und Outlook/Android aber nicht
|
|
Cloud-Identitäten und AuthentifizierungDamit der EvoSTS für die Anwender überhaupt ein Ticket ausstellen kann, muss sich der Anwender an der Cloud authentifizieren können. Sie müssen Sie also die Benutzer mit dem UPN idealerweise mit ADSync dort anlegen und eine Authentifizierung muss natürlich auch möglich sein. Um die Anmeldefenster zu minimieren, sollten Sie unbedingt Seamless Single Sign On aktivieren oder ADFS nutzen. |
|
Internetzugriff (Client und Server)Es sollte keine Überraschung sein, dass ihre Client zumindest den EvoSTS auch erreichen können, damit Sie überhaupt ein Token bekommen können. Ohne Token kein Zugriff und damit ist natürlich ihr On-Premises System abhängig von der Verfügbarkeit des Internets und der Office 365-Anmeldedienste. Aber auch der Server möchte sich die "FederationMetaData" von EvoSTS herunter laden, die Sie später noch konfigurieren. All SfB
Front Ends must have
connections outbound to the
internet, to Office 365
Authentication URLs (TCP
443) and well known
certificate root CRLs (TCP
80) listed in Rows 56 and
125 of the 'Microsoft 365
Common and Office' section
of Office 365 URLs and IP
address ranges. (https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges) Die URL auf "https://login.windows.net/common/FederationMetadata/2007-06/FederationMetadata.xml -AcceptSecurityIdentifierInformation" wird später noch konfiguriert. |
|
URLs einsammeln und in Office 365 eintragenSowohl Exchange als auch Skype schicken den Client zum EvoSTS und liefern eine URL mit, für die sich der Client ein Ticket besorgen soll. Diese URLs müssen Sie in Office 365 natürlich freischalten und diese gilt es erst mal einzusammeln. Es sind quasi sie "InternalURL" und "ExternalURL" der verschiedenen Dienste. Wir fangen mit Exchange an: Zuerst müssen wir kontrollieren, dass alle virtuellen Verzeichnisse für OAUTH aktiviert sind und die URLs brauchen wir für den nächsten Schritt. #Exchange Get-MapiVirtualDirectory | FL server,*url*,*auth* Get-WebServicesVirtualDirectory | FL server,*url*,*oauth* Get-ActiveSyncVirtualDirectory | FL server,*url*,*oauth* Get-OABVirtualDirectory | FL server,*url*,*oauth* Get-AutoDiscoverVirtualDirectory | fl server,*oauth* Wenn die Verzeichnisse nicht für OAUTH aktiviert sind, dann müssen Sie dies erst aktivieren. Die eingesammelten URL werden von den Clients zu Office 365 angefragt. Die müssen Sie nun alle, sofern noch nicht passiert, in der Cloud eintragen. $x= Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 $x.ServicePrincipalnames.Add("https://outlook.msxfaq.de/") $x.ServicePrincipalnames.Add("https://owa.msxfaq.de/") Set-MSOLServicePrincipal ` -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 ` -ServicePrincipalNames $x.ServicePrincipalNames Dann sollten Sie noch kontrollieren, ob der EvoSTS schon vorhanden ist. #Kontrolle, dass der OAUTH Server hinterlegt ist. Get-AuthServer | where {$_.Name -eq "EvoSTS"} |
|
Das gleiche vorgehen steht nun noch für Skype for Business an. #SfBOnline Get-CsService -WebServer | Select-Object PoolFqdn, InternalFqdn, ExternalFqdn | fl # Anzeige der bestehenden Einträge Get-MsolServicePrincipal -AppPrincipalId 00000004-0000-0ff1-ce00-000000000000 ` | select -ExpandProperty ServicePrincipalNames https://api.skypeforbusiness.com/ 00000004-0000-0ff1-ce00-000000000000/*.infra.lync.com 00000004-0000-0ff1-ce00-000000000000/*.online.lync.com 00000004-0000-0ff1-ce00-000000000000 Hier müssen wir nun die anderen URLs mit addieren. Auch der "Lync Client" muss ja das Recht haben die Exchange URLs anzusprechen. $x= Get-MsolServicePrincipal -AppPrincipalId 00000004-0000-0ff1-ce00-000000000000 $x.ServicePrincipalnames.Add("https://sfb01.uclabor.de/") $x.ServicePrincipalnames.Add("https://exchange.uclabor.de/") Set-MSOLServicePrincipal ` -AppPrincipalId 00000004-0000-0ff1-ce00-000000000000 ` -ServicePrincipalNames $x.ServicePrincipalNames Damit legitimieren wir EvoSTS entsprechenden Token für diese Applikationen zu liefern. Die Nummer "00000004-0000-0ff1-ce00-000000000000" steht für "Microsoft Lync". In einem Tenant sind in der Regel viele Applikationen schon vordefiniert. Sie können diese einfach wie folgt anzeigen. On-Premises müssen wir natürlich den EvoSTS noch addieren. New-CsOAuthServer ` -Identity EvoSTS ` -MetadataURL https://login.windows.net/common/FederationMetadata/2007-06/FederationMetadata.xml ` -AcceptSecurityIdentifierInformation $true ` -Type AzureAD |
|
Conditional AccessEhe Sie nun die Anmeldung auf HMA umstellen, sollten Sie überlegen, wie Sie Conditional Access und MFA aus der Cloud mit einbeziehen. Bislang war es immer so, dass die Anmeldung am "On-Premises" Exchange Server und Skype for Business Server nur per Benutzername und Kennwort genutzt wurde. OWA wurde manchmal einen vorgelagerten Reverse Proxy um eine weitere Authentifizierung bereichert. ActiveSync konnte über die ActiveSync Quarantäne abgesichert werden, wenn keine eigene MDM/MAM-Lösung eingesetzt wurde. Durch HMA können Sie nun natürlich auch die Funktionen von Office 365 nutzen um über Regeln in Azure AD die Ausstellung der OAUTH-Tokens zu steuern. Bedenken Sie, dass durch die Aktivierung von HMA die neuen Regeln aktiv werden und Sie sehr schnell ggfls. die vorhandenen Lösungen umbauen müssen. |
|
HMA mit Exchange einschaltenNun sollten alle Vorarbeiten erfolgt sein und wir schalten die Funktion in Exchange frei: Set-AuthServer ` -Identity EvoSTS ` -IsDefaultAuthorizationEndpoint $true Set-OrganizationConfig ` -OAuth2ClientProfileEnabled $true Die Änderung bedeutet, dass ein Client, der "Bearer" anfordert nun auch einen Redirect zum EvoSTS bekommt. Clients, die das noch nicht machen, funktionieren aber weiter. |
|
HMA mit Skype for Business einschaltenAuch in Skype for Business aktivieren wir die Einstellung: # Aktivieren, d.h. ab nun bieten Skype Webticket Services auch bearer an Set-CsOAuthConfiguration ` -ClientAuthorizationOAuthServerIdentity EvoSTS # Ich habe danach immer etwas gewartet, bis die CMS-Replikation abgeschlossen war und # dann mit einem Enable-CSComputer die Konfiguration auf den Frontend Servern aktualisiert. Wie bei Exchange bekommen die Client einen Redirect zum EvoSTS, die bei der Anfrage auch mit einem "Bearer" ankommen. |
|
NOT-AusEigentlich läuft nun alles aber wenn es wider erwarten doch Probleme gibt, dann können sie zwar einige Minuten darauf verwenden den Fehler zu finden. Es könnte aber auch erforderlich sein, die Anmeldung per HMA wieder abzuschalten. Das geht recht einfach durch die Exchange On-Premises PowerShell und Skype for Business PowerShell. # NotAus für HMA mit Exchange Set-AuthServer ` -Identity EvoSTS ` -IsDefaultAuthorizationEndpoint $false Set-OrganizationConfig ` -OAuth2ClientProfileEnabled $false # NotAus für HMA mit SfB Set-CsOAuthConfiguration ` -ClientAuthorizationOAuthServerIdentity "" |
|
"Legacy Authentication abschaltenDer wirklich letzte Schritt ist die Abschaltung aller klassischen Anmeldeverfahren wie Basic, NTLM, Kerberos für den Zugriff der Clients. Damit sperren Sie natürlich alle "inkompatiblen" Clients aus. Dieser Schritt steht irgendwann natürlich an, wenn Sie die Unsicherheit einer Legacy Anmeldung beseitigen wollen.
|
|
Prüfung mit Test-HMAEAS.ps1
Microsoft hat auf https://microsoft.github.io/CSS-Exchange/Hybrid/Test-HMAEAS/ ein eigenes PowerShell-Skript zur Überprüfung der Anmeldung mittels Hybrid Modern Auth bereitgestellt. Es arbeitet von intern oder extern und ermittelt zuerst einmal die Autodiscover-Anfrage zu einem Postfach. Diese URL verweist dann natürlich auf die hoffentlich richtige URL. Es reicht erst einmal die Mailadresse
.\Test-HMAEAS.ps1 user1@msxfaq.de
Im zweiten Schritt greift das Skript dann mit "Bearer" auf die URL zu und die Antwort sollte den Verweis zum EvoSTS-Service liefern.
Hinweis: Das Skript von Nov 2021 funktioniert nur mit der alten PowerShell 2 und nicht PowerShell 7
Wenn Sie dann noch die Anmeldung selbst prüfen wollen, dann können Sie die ebenfalls angeben
.\Test-HMAEAS.ps1 -SMTP admin@giz.de -TestEAS
Sofern das Modul noch nicht vorhanden ist, installiert die PowerShell dann "Microsoft.IdentityModel.Clients.ActiveDirectory" nach und fragt natürlich dann auch nach Anmeldedaten und beim Einsatz von MFA auch über ein Browser-Fenster. So können Sie HMA relativ einfach testen.
- Test-HMAEAS.ps1
https://microsoft.github.io/CSS-Exchange/Hybrid/Test-HMAEAS/
HMA und Microsoft Middleware
Seit ca. 2024 propagiert Microsoft hat sein "neues Outlook" und auch Outlook Mobile (IOS, Android), welches durch die Aquisition von Acompli zu Microsoft gekommen ist, nutzen keine direkte Verbindnug zum Postfachserver, sondern gehen über eine Middleware von Microsoft. Der Client verbindet sich mit einem Service bei Microsoft per HTTP und übergibt entsprechende Anmeldeinformationen, damit sich dann dieser Client am eigentlichen Postfachserver anmelden kann.
Outlook for iOS and Android is a
cloud-backed application. This characteristic indicates that
your experience consists of a locally installed app powered
by a secure and scalable service running in the Microsoft
Cloud.
Quelle:
https://learn.microsoft.com/en-us/exchange/clients/outlook-for-ios-and-android/use-hybrid-modern-auth?#microsoft-cloud-architecture-for-hybrid-exchange-server-customers
Sie müssen hier ihren Exchange OnPremises Server also mindestens von den Exchange Online Servern erreichbar machen. Dies sind folgen beiden IP-Bereiche und Port 443/TCP
52.125.128.0/20 52.127.96.0/23
- Using Hybrid Modern Authentication with
Outlook for iOS and Android
https://learn.microsoft.com/en-us/microsoft-365/enterprise/configure-exchange-server-for-hybrid-modern-authentication?view=o365-worldwide#using-hybrid-modern-authentication-with-outlook-for-ios-and-android
Ich habe auch schon Zugriff von 40.x.x.x gesehen. Die Dokumentation von Microsoft scheint hier nicht immer aktuell zu sein. Office 365 Netzwerkziele
Hier muss nun natürlich auch sichergestellt sein, dass die Microsoft Middleware später sich korrekt am jeweiligen Backend-Server anmelden kann. Wenn Sie einen klassischen POP3/IMAP4-Server nutzen, wie diese im privaten Umfeld natürlich üblich ist, dann wird das Benutzername/Kennwort per TLS sein. Mit Exchange OnPremises kommt auch das vom Backend geforderte Anmeldeverfahren zum Einsatz. auch das ist meistens "BasicAuth", damit die Middleware die letzten vier Wochen in die Cloud "synchronisieren kann.
The Exchange ActiveSync (EAS) connection
between Exchange Online and the on-premises environment
enables synchronization of the users' on-premises data and
includes four weeks of email, all calendar data, all contact
data, and out-of-office status in your Exchange Online
tenant. This data will be removed automatically from
Exchange Online after 30 days when the account is deleted in
Microsoft Entra ID.
Data synchronization between the on-premises environment and
Exchange Online happens independent of user behavior. This
independency ensures that we can send new messages to the
devices quickly.
Quelle:
https://learn.microsoft.com/en-us/exchange/clients/outlook-for-ios-and-android/use-hybrid-modern-auth?view=exchserver-2016#microsoft-cloud-architecture-for-hybrid-exchange-server-customers
Mit dem Einsatz von Hybrid Modern Auth bedeutet dies aber, dass auch die auf Exchange online basierende Middleware sich per OAUTH am Backend anmelden muss. Dazu ändert die Einrichtung die Default Authentication.
One of the on-premises configuration changes that occur enables the OAuth endpoint to the Microsoft Cloud as the default authorization endpoint. When this change is made, clients can start negotiating the use of OAuth.
Auch das können Sie z.B. mit Test-Bearer schnell prüfen. Im WWW-Authenticate-Header muss "Bearer" an erster Stelle stehen, z.B.
------- WWW-Authenticate Header --- Bearer client_id="00000002-0000-0ff1-ce00-000000000000" trusted_issuers="00000001-0000-0000-c000-000000000000@7e53e2a7-7b50-44b5-bde0-443772826922" token_types="app_asserted_user_v1 service_asserted_app_v1" authorization_uri="https://login.windows.net/common/oauth2/authorize" issuer_kind="AzureAD" Basic realm="owa.mscfaq.de"
Zuletzt muss natürlich auch die Microsoft Middleware dann auch all ihre bereitgestellten Dienste erkennen und nutzen. Hier hilft ihnen dann IIS - Webserver Troubleshooting zum Aufzeichnen der an den IIS gesendete Request.
- Test-Bearer
- IIS - Webserver Troubleshooting
- Office 365 Netzwerkziele
- Using hybrid Modern Authentication with
Outlook for iOS and Android
https://learn.microsoft.com/en-us/exchange/clients/outlook-for-ios-and-android/use-hybrid-modern-auth - How to configure Exchange Server on-premises
to use Hybrid Modern Authentication
https://learn.microsoft.com/en-us/microsoft-365/enterprise/configure-exchange-server-for-hybrid-modern-authentication?view=o365-worldwide
testconnectivity.microsoft.com
Microsoft betreibt unter der Url https://testconnectivity.microsoft.com einen Service, um die unterschiedlichsten Verbindungen zu Diensten zu überprüfen. Damit ist auch ein test gegen ActiveSync möglich, den ich natürlich auch mit HMA ausprobiert habe. Leider scheint die aktuelle Version immer noch nicht mit dieser Anmeldung arbeiten zu können.
Die Antwort ist ein "Dieses Toll unterstützt derzeit keine lokalen Szenarien mit moderner Authentifizierung". Leider sagt mir auch der Fehler des lokalen Servers nicht viel
2000003 The hostname component of the audience claim value 'https://outlook.office.com' is invalid
Nur auf meiner eigenen Seite finde ich einen Hinweis.
Fehler: SfB und Federation Metadata
Wenn Sie bei der Konfiguration aufgepasst haben, dann sehen Sie die Konfiguration einer "FederationMetadata"-Url bei Skype for Business. Die Skype Frontend Server verbinden sich regelmäßig mit dieser URL um die "Signing-Zertifikate" des EvoSTS zu laden und ggfls. zu aktualisieren. Der EvoSTS hat ja den passenden Private-Key zur Signatur. Die SfB Server müssen diese URL erreichen und wenn dies nicht möglich ist, schlagen alle Authentifizierungen fehlt. Häufige Ursache ist hier ein HTTP-Proxy, der z.B. den Server mit der Identität "Network Service" nicht authentifizieren kann oder auf dem Server wurde schlicht kein Proxy-Server konfiguriert.
Der Fehler passiert schnell, weil auch die Anleitung (https://docs.microsoft.com/en-us/office365/enterprise/hybrid-modern-auth-overview#do-you-meet-modern-authentication-prerequisites) bei Microsoft lange Zeit falsch war. Sie finden dies reicht einfach heraus, wenn Sie per CLSLogging das Szenario "UCWA" starten und danach in den LogFiles nach "JwtSecurityToken" suchen. Hier ein exemplarischer Auszug eines Logs, welches dieses Fehlerbild liefert.
TL_NONE(TF_IIS) [sfbfepool\FE01]2F30.6CFC::12/03/2019-15:47:30.709.000A20CE (WebInfrastructure,CAuthHelperGlobalModule::DumpEvent:SslNgMod.cpp(1603)) [2147485126] Event: 3a2a4e84-4c21-4981-ae10-3fda0d9b0f83:0x0:1:GENERAL_REQUEST_START, httpContext: 000001FD427B7A70, items: ContextId=null,SiteId=34578,AppPoolId=LyncExtSignin,ConnId=15132094762460382661,RawConnId=0,RequestURL=https://sfbwebext.msxfaq.de:4443/WebTicket/WebTicketService.svc/OAuth,RequestVerb=POST TL_NONE(TF_IIS) [sfbfepool\FE01]2F30.6CFC::12/03/2019-15:47:30.709.000A20CF (WebInfrastructure,CAuthHelperGlobalModule::DumpEvent:SslNgMod.cpp(1603)) [2147485126] Event: 3a2a4e84-4c21-4981-ae10-3fda0d9b0f83:0x8:1:FILTER_START, httpContext: 000001FD427B7A70, items: ContextId=null,FilterName=C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_filter.dll TL_NONE(TF_IIS) [sfbfepool\FE01]2F30.6CFC::12/03/2019-15:47:30.709.000A20D0 (WebInfrastructure,CAuthHelperGlobalModule::DumpEvent:SslNgMod.cpp(1603)) [2147485126] Event: 3a2a4e84-4c21-4981-ae10-3fda0d9b0f83:0x8:2:FILTER_END, httpContext: 000001FD427B7A70, items: ContextId=null,NotificationStatus=134217730 TL_NONE(TF_IIS) [sfbfepool\FE01]2F30.6CFC::12/03/2019-15:47:30.710.000A20D1 (WebInfrastructure,CAuthHelperGlobalModule::DumpEvent:SslNgMod.cpp(1603)) [2147485126] Event: aff081fe-0247-4275-9c4e-021f3dc1da35:0xf:1:AspNetStart, httpContext: 000001FD427B7A70, items: ConnID=0, Context ID={800005C6-0003-D200-B63F-84710C7967BB},Data1=POST,Data2=/WebTicket/WebTicketService.svc,Data3= TL_ERROR(TF_COMPONENT) [sfbfepool\FE01]2F30.8F3C::12/03/2019-15:47:30.712.000A20D2 (WebInfrastructure,LyncOAuthTokenValidator.GetCertificateFromMex: lyncoauthsecuritytokenvalidators.cs(176)) (0000000001B8BDBA)Mex data for https://login.windows.net/common/FederationMetadata/2007-06/FederationMetadata.xml cannot be retrieved at this time. TL_ERROR(TF_COMPONENT) [sfbfepool\FE01]2F30.8F3C::12/03/2019-15:47:30.712.000A20D3 (WebInfrastructure,LyncOAuthTokenValidator.GetCertificateFromMex: lyncoauthsecuritytokenvalidators.cs(181)) (0000000001B8BDBA)Mex data for https://login.windows.net/common/FederationMetadata/2007-06/FederationMetadata.xml does not contain the expected cert: 041F0278556AC9A1AB18DB9E8492222F875F8F3C TL_ERROR(TF_COMPONENT) [sfbfepool\FE01]2F30.8F3C::12/03/2019-15:47:30.712.000A20D4 (WebInfrastructure,LyncOAuthTokenValidator.GetIssuerData:lyncoauthsecuritytokenvalidators.cs(231)) (0000000001B8BDBA)Cert not found for sts.windows.net@5bbab28c-def3-4604-8822-5e707da8dba8, expected thumbprint 041F0278556AC9A1AB18DB9E8492222F875F8F3C TL_ERROR(TF_COMPONENT) [sfbfepool\FE01]2F30.8F3C::12/03/2019-15:47:30.712.000A20D5 (WebInfrastructure,OCSOAuthCommonCredentials.BeginVerify: credentialsimpl.cs(1073)) [2147485126]Exception: Microsoft.Rtc.Internal.WebServicesAuthFramework.LyncJsonTokenValidationException: Exception of type 'Microsoft.Rtc.Internal.WebServicesAuthFramework.LyncJsonTokenValidationException' was thrown. at Microsoft.Rtc.Internal.WebServicesAuthFramework.LyncOAuthTokenValidator.GetIssuerData(String issuer, String expectedThumbprint, Boolean& acceptSid, Boolean& isAzureAd) at Microsoft.Rtc.Internal.WebServicesAuthFramework.ValidateJwtTokenAndClaimsAsyncResult. GetIssuerDataFromStoredOAuthConguration(String issuer, String thumbprint, Boolean& acceptSid, Boolean& isAzureAd) at Microsoft.Rtc.Internal.WebServicesAuthFramework.ValidateJwtTokenAndClaimsAsyncResult.Begin(JWTSecurityToken jwtSecurityToken) at Microsoft.Rtc.Internal.WebServicesAuthFramework.OcsJwtTokenCredentials.BeginValidateTokenAndClaims(AsyncCallback callback, GenericAsyncResult`1 result) at Microsoft.Rtc.Internal.WebServicesAuthFramework.OCSOAuthCommonCredentials.BeginVerify(AsyncCallback callback, Object state) TL_ERROR(TF_COMPONENT) [sfbfepool\FE01]2F30.8F3C::12/03/2019-15:47:30.713.000A20D6 (WebInfrastructure, OCSAuthModule.GetOcsInfoAsyncResult.Callback:iismodule.cs(1699)) [2147485126]Exception: Microsoft.Rtc.Internal.WebServicesAuthFramework.LyncJsonTokenValidationException: Exception of type 'Microsoft.Rtc.Internal.WebServicesAuthFramework.LyncJsonTokenValidationException' was thrown. at Microsoft.Rtc.Internal.WebServicesAuthFramework.AsyncResult.End[TAsyncResult](IAsyncResult result) at Microsoft.Rtc.Internal.WebServicesAuthFramework.OCSAuthModule.GetOcsInfoAsyncResult.Callback(IAsyncResult result) TL_ERROR(TF_COMPONENT) [sfbfepool\FE01]2F30.8F3C::12/03/2019-15:47:30.713.000A20D7 (WebInfrastructure,OCSAuthModule.SetHttpResponseOnException:iismodule.cs(1864)) [2147485126]Add warning header InvalidToken
Hier ist gut zu sehen, dass der Skype for Business Server keine Verbindung zu "https://login.windows.net/common/FederationMetadata/2007-06/FederationMetadata.xml" aufbauen kann und damit das Token Signing Zertifikat nicht überprüfen kann. Auf dem Client konnte man nur sehen, dass die Anfrage mit einem "No authentication methods configured" zurück gekommen ist.
Ein zweiter Request, der in Fiddler sehr einfach dann zu sehen ist, ist die Abfrage nach https://<skype-external-webostname>/WebTicket/WebTicketService.svc/mex, über den der Client als XML-Antwort auch eine OAuth_policy bekommen muss:
Sie können auch einfach die URL ohne Fiddler im Browser eingeben. Mit Hybrid Modern Authentication sehen sie dann:
Bei einem Server ohne HMA sieht die XML-Antwort etwas so aus:
Denken Sie aber immer daran, dass ein Client, der vom Server eine OAUTH-URL angeboten bekommt, auch dorthin geht, sich ein Ticket besorgt und zurück kommt. Die verschiedenen Teilstücke habe ich am Anfang ja aufgezeichnet und können z.B. mit Fiddler auf dem Client problemlos nachvollzogen werden.
Exchange Legacy abschalten
Wenn Sie im Internet recherchieren, wie sie alte unsichere Authentifizierungsverfahren mit Exchange abschalten, dann landen sie immer auf Seiten, die sich um die Abschaltung in Exchange Online kümmern. Auch wenn Microsoft in Exchange Online erst im Oktober 2020 die Anmeldung per "OAuth" erzwingt, können sie schon vorher die Nutzung von "BasicAuth" in der Cloud unterbinden.
- BasicAuth Ende mit POP3/IMAP4 umgehen
- How to disable legacy authentication in
Microsoft Exchange to enable MFA
https://www.csoonline.com/article/3435778/how-to-disable-legacy-authentication-in-microsoft-exchange-to-enable-mfa.html - Enable Modern Authentication for Office
2013 on Windows devices
https://docs.microsoft.com/en-us/office365/admin/security-and-compliance/enable-modern-authentication?view=o365-worldwide - Disable Basic authentication in Exchange
Online
https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online - Three ways to disable basic
authentication and legacy protocols in
Exchange Online
https://www.itpromentor.com/block-basic-auth/
Für eine Deaktivierung "On-Premises" ist erst mal gar nicht so einfach, da es bei Exchange immer pro Frontend-Server immer nur genau einen IIS gibt. Die IIS-Instanz des Backend Servers ignorieren wir hier, da alle Clients immer über den Frontend-Server arbeiten. Der kann aber allein anhand des Requests erst einmal nicht unterscheiden, ob der Client nun von Extern kommt oder von intern.
Bislang habe ich keine öffentliche Quelle gefunden, die hier einen empfohlenen Weg beschreibt
Sie können natürlich direkt auf den virtuellen Verzeichnissen der Frontend Server einfach die Authentifizierung ändern. Ein Exchange 2016 Server hat hier erst mal nur folgende Einstellungen:
[PS] C:\>Get-MapiVirtualDirectory | fl *auth* IISAuthenticationMethods : {Ntlm, OAuth, Negotiate} InternalAuthenticationMethods : {Ntlm, OAuth, Negotiate} ExternalAuthenticationMethods : {Ntlm, OAuth, Negotiate} [PS] C:\>Get-webservicesVirtualDirectory | fl *auth* CertificateAuthentication : InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth} ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth} LiveIdNegotiateAuthentication : WSSecurityAuthentication : True LiveIdBasicAuthentication : False BasicAuthentication : True DigestAuthentication : False WindowsAuthentication : True OAuthAuthentication : True AdfsAuthentication : False [PS] C:\>Get-oabVirtualDirectory | fl *auth* BasicAuthentication : False WindowsAuthentication : True OAuthAuthentication : True InternalAuthenticationMethods : {WindowsIntegrated, OAuth} ExternalAuthenticationMethods : {WindowsIntegrated, OAuth} [PS] C:\>Get-AutoDiscoverVirtualDirectory | fl *auth* InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth} ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth} LiveIdNegotiateAuthentication : False WSSecurityAuthentication : True LiveIdBasicAuthentication : False BasicAuthentication : True DigestAuthentication : False WindowsAuthentication : True OAuthAuthentication : True AdfsAuthentication : False
Beachten Sie dabei, dass die Einstellungen bei "InternalAuthenticationMethods" und "ExternalAuthenticationMethods" erst einmal nur Autodiscover mitteilen, was die Clients erfahren wollen. Die anderen Einstellungen steuern aber, was der Server tatsächlich macht. Bei meinem MAPIVirtualDirectory muss ich also zuerst einmal OAUTH noch mit aktivieren.
Ehe Sie nun aber "NTLM", "WindowsIntegrated" und "Basic" abschalten, sollten Sie erst mal prüfen, dass wirklich alle Clients auch Hybrid Modern Auth nutzen. Das beginnt mit einem Check der Versionen
- Outlook 2013 oder neue mit
entsprechendem RegistryKey
Siehe https://docs.microsoft.com/en-us/office365/enterprise/modern-auth-for-office-2013-and-2016 - Outlook 2016 for Mac oder neuer
- Outlook for iOS und Android
- Mail for iOS 11.3.1 oder neuer
Aber selbst dann gibt es ja noch ganz viele andere Prozesse, die z.B. per EWS arbeiten und noch nicht OAUTH nutzen.
Hier empfehle ich im IISLogs (Siehe IIS Authentication) auch die Authentifizierung protokollieren zu lassen. Dann sehen Sie am besten, wer sich noch mit welchem Verfahren am Server anmeldet
Leider habe ich auch noch keinen Weg gefunden, dass die Protokolle IMAP4 und POP3 einer On-Premises Installation mit OAUTH funktionieren. Der Parameter "LoginType" von "Set-IMAPSettings unterstützt nur die drei Optionen "PlainTextLogin"."PlainTextAuthentication" oder "SecureLogin"
- Set-ImapSettings
https://docs.microsoft.com/en-us/powershell/module/exchange/client-access/set-imapsettings?view=exchange-ps
SfB Legacy abschalten
Der wirklich letzte Schritt ist die Abschaltung aller klassischen Anmeldeverfahren wie Basic, NTLM, Kerberos für den Zugriff der Clients. Damit sperren Sie natürlich alle "inkompatiblen" Clients aus. Dieser Schritt steht irgendwann natürlich an, wenn Sie die Unsicherheit einer Legacy Anmeldung beseitigen wollen. Die Steuerung erfolgt über das Commandlet "Set-CsAuthConfig". Der Scope kann auf "Global" oder auch pro Pool angewendet werden. Microsoft rät aber von einer Konfiguration je Pool deutlich ab. Über den Parameter "-Scenario" können Sie eines von fünf möglichen Konfigurationen umsetzen.
Szenario | Interne Anmeldung | Externe Anmeldung |
---|---|---|
AllowAllExternallyAndInternally |
MA + Win |
MA + Win |
BlockWindowsAuthExternally |
MA + Win |
MA |
BlockWindowsAuthExternallyAndInternally |
MA |
MA |
BlockWindowsAuthExternallyAndModernAuthInternally |
Win |
MA |
BlockModernAuthInternally |
Win |
MA+Win |
Ich habe die Farbe hier erst einmal nur für die externe Authentifizierung eingesetzt, da hier eher ein Angriff mit DDoS, Password Spray oder Brute Force zu erwarten ist. Aber auch das "interne Netzwerk" ist nicht automatisch als sicher anzusehen. Mit den passenden Hilfsmitteln können Sie hier aber die Quelle besser identifizieren, was im Internet ein hoffnungsloses Unterfangen ist.
Nach jeder Änderung dieser Einstellung ist ein "Enabled-CSComputer" auf jedem Skype for Business Server erforderlich, damit so die geänderten Einstellungen in den Diensten übernommen werden. Prüfen Sie davor aber zur Sicherheit, dass die CMS-Replikation erfolgreich abgeschlossen wurde.
- Set-CsAuthConfig
https://docs.microsoft.com/en-us/powershell/module/skype/set-csauthconfig?view=skype-ps - Planning to turn off Legacy
authentication methods internally and
externally to your network.
https://docs.microsoft.com/de-de/skypeforbusiness/plan-your-deployment/modern-authentication/turn-on-modern-auth
Modern Authentication wieder abschalten
Solange die Authentication-Dienste von Office 365/AzureAD verfügbar und erreichbar sein, werden Sie Modern Auth auf den On-Premises Servern vermutlich nicht abschalten. Es gibt aber Situationen, bei denen Sie vielleicht temporär oder dauerhaft die Hybrid Modern Auth-Einstellung deaktivieren müssen. MIr fallen da ein
- Ausfall Office 365/AzureAD
Es kann ja passieren, dass die Cloud keine Tokens ausstellen kann und sie temporär - Internet-Verbindung
Wenn AzureAD Tickets ausstellen würde aber ihre Internet-Anbindung unterbrochen ist, da reicht schon ein Konfigurationsfehler/Umbauten der Firewall oder ein Baggerschaden, dann können Sie Modern Authentication temporär ausschalten - Unterbrochene Authentifizierungsketten
Grade die Firmen, die noch ADFS oder Pass-Through Authentifizierung (PTA) nutzen, haben hier gegenüber Password Hash Sync (PHS) - Inkompatibilitäten
Normal testet man vorher die verschiedenen Szenarien aber es kann ja immer passieren, dass nach der Aktivierung etwas doch nicht geht
Maßgeblich ist hier immer der lokale Service. und den kann man ganz schnell wieder anweisen den Anwender nicht zum EvoSTS zu verweisen. Die Befehle sind in der jeweiligen PowerShell auszuführen.
#Exchange On-Prem Set-AuthServer -Identity EvoSTS -IsDefaultAuthorizationEndpoint $false #SfB On-Prem Set-CsOAuthConfiguration -ClientAuthorizationOAuthServerIdentity ""
Nachdem die Einstellungen im AD repliziert sind und die IIS-Applications diese übernommen haben, wird der Exchange Server auch vorher gültige Tickets nicht mehr annehmen und die Anforderung mit einem 401 ablehnen. Der Client wird sich dann neu mit einem der noch angebotenen Anmeldeverfahren authentifizieren müssen.
Das sollte alles unbemerkt von Anwender durch Outlook erfolgen. Ic habe aber aber noch keine Werte, wie schnell die Server ohne Neustart die Änderungen übernehmen
- Set-AuthServer
https://docs.microsoft.com/en-us/powershell/module/exchange/organization/set-authserver?view=exchange-ps - Set-CsOAuthConfiguration
https://docs.microsoft.com/en-us/powershell/module/skype/set-csoauthconfiguration?view=skype-ps - Removing or disabling Hybrid Modern
Authentication from Skype for Business and
Exchange
https://docs.microsoft.com/de-de/office365/enterprise/remove-or-disable-hybrid-modern-authentication-from-skype-for-business-and-excha
Kompletter Rückbau
Um Hybrid Modern Auth abzuschalten, reicht es schon die Verweise zum EvoSTS zu entfernen. Natürlich können Sie auch alle anderen Einstellungen wieder zurück stellen.
#Exchange On-Prem Set-OrganizationConfig -OAuth2ClientProfileEnabled $false Set-AuthServer -Identity EvoSTS -IsDefaultAuthorizationEndpoint $false #Exchange Online Set-OrganizationConfig -OAuth2ClientProfileEnabled:$false #SfB On-Prem Set-CsOAuthConfiguration -ClientAuthorizationOAuthServerIdentity "" #SfB Online Set-CsOAuthConfiguration -ClientAdalAuthOverride Disallowed
Removing or disabling Hybrid Modern
Authentication from Skype for Business and
Exchange
https://docs.microsoft.com/de-de/office365/enterprise/remove-or-disable-hybrid-modern-authentication-from-skype-for-business-and-excha
Weitere Links
- Test-Bearer
- Exchange OAuth
- Seamless Single Sign On
- CLSLogging
- Fiddler
- SAML und Preauthentication - Kann ein Reverse Proxy/Proxy mit SSL-Inspection auch die Bearer-Authentication prüfen?
-
How modern authentication works for Office
2013 and Office 2016 client apps
https://docs.microsoft.com/en-us/office365/enterprise/modern-auth-for-office-2013-and-2016 - https://aka.ms/ModernAuthOverview
- How to configure Exchange Server On-Premises
to use Hybrid Modern Authentication
https://docs.microsoft.com/de-de/office365/enterprise/configure-exchange-server-for-hybrid-modern-authentication - Exchange Online - Modern Authentication
and Conditional Access Updates
https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Exchange-Online-Modern-Authentication-and-Conditional-Access/ba-p/609306 - Hybrid Modern Authentication for Skype
for Business
https://techcommunity.microsoft.com/t5/Skype-for-Business-Blog/Hybrid-Modern-Authentication-for-Skype-for-Business/ba-p/134751 - Deep Dive: How Hybrid Authentication
Really Works
https://blogs.technet.microsoft.com/exchange/2017/05/24/deep-dive-how-hybrid-authentication-really-works/ - Skype for Business topologies supported
with Modern Authentication
https://docs.microsoft.com/de-de/skypeforbusiness/plan-your-deployment/modern-authentication/topologies-supported - Skype for Business topologies supported
with Modern Authentication
https://docs.microsoft.com/de-de/skypeforbusiness/plan-your-deployment/modern-authentication/topologies-supported - Hybrid Modern Authentication overview
and prerequisites for using it with On-Premises
Skype for Business and Exchange servers
https://docs.microsoft.com/de-de/office365/enterprise/hybrid-modern-auth-overview - New access and security controls for
Outlook for iOS and Android
https://blogs.office.com/2015/06/10/new-access-and-security-controls-for-outlook-for-ios-and-android/ - How modern authentication works for
Office 2013 and Office 2016 client apps
https://support.office.com/en-us/article/How-modern-authentication-works-for-Office-2013-and-Office-2016-client-apps-e4c45989-4b1a-462e-a81b-2a13191cf517 - Discussing Authentication and
Authorization in Skype for Business
https://docs.microsoft.com/de-de/skypeforbusiness/plan-your-deployment/modern-authentication/modern-authentication - Announcing Hybrid Modern Authentication
for Exchange On-Premises
https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Announcing-Hybrid-Modern-Authentication-for-Exchange-On-Premises/ba-p/607476 - Using hybrid Modern Authentication with
Outlook for iOS and Android
https://docs.microsoft.com/en-us/Exchange/clients/outlook-for-ios-and-android/use-hybrid-modern-auth?view=exchserver-2019 - Enable Exchange Online for modern
authentication
https://support.office.com/en-us/article/Enable-Exchange-Online-for-modern-authentication-58018196-f918-49cd-8238-56f57f38d662
Set-OrganizationConfig -OAuth2ClientProfileEnabled:$true - Disabling Legacy Authentication in
Exchange Server 2019
https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Disabling-Legacy-Authentication-in-Exchange-Server-2019/ba-p/712048 - Hybrid Modern Authentication overview
and prerequisites for using it with On-Premises
Skype for Business and Exchange servers
https://docs.microsoft.com/en-us/office365/enterprise/hybrid-modern-auth-overview - Exchange Online - Modern Authentication
and Conditional Access Updates
https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Exchange-Online-Modern-Authentication-and-Conditional-Access/ba-p/609306 - Use OAuth on Exchange On-Premises
without Hybrid Modern Authentication
https://practical365.com/exchange-server/configure-hybrid-modern-authentication-for-exchange-server/
https://practical365.com/configure-hybrid-modern-authentication-for-exchange-server/