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 OneTime 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.

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

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:

  1. Anfrage an Exchange mit "Authorization: Bearer"
    Der Client verbindet sich mit dem Exchange Server und meldet über diesen Header, dass er OAUTH kann
  2. 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
  3. 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.
  4. Redirect zum ADFS-Server
    Wenn die UPN-Domain "federiert" ist, dann wird der Client wieder zum lokalen ADFS-Service weiter geleitet
  5. Client fordert Ticket from 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
  6. ADFS-Stell 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
  7. Client sendet Request mit ADFS-Ticket zum evoSTS
    Erst dann kann der Client fortsetzen, was er im Paket 3 schon anonym begonnen hat
  8. 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
  9. 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.
  10. evoSTS sendet Token zum Client
  11. 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
  12. 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.

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.

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

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:

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 Update

SBAs fallen aber nicht darunter, da sie keine Authentifizierung durchführen.

SIP-Domain

Sie 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/SfB2019

Es 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 Server

Die 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:
Auf der Dokumentation https://docs.microsoft.com/en-us/office365/enterprise/hybrid-modern-auth-overview#do-you-meet-modern-authentication-prerequisites stand es bis zum 5.12 2019 noch falsch

Exchange Server Version: 2013 CU19, 2016CU8 und 2019 CU1 oder höher

Exchange 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"-Mode

Min-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.
https://docs.microsoft.com/en-us/Exchange/clients/outlook-for-ios-and-android/use-hybrid-modern-auth?view=exchserver-2019

Anforderungen an die Clients

Modern Auth wird vom Server dem Client nur angeboten, wenn der Client das richtige Protokoll nutzt und den Server über seine Tauglichkeit informiert.

  • Outlook 2013/2016 mit MAPI/HTTP
  • Outlook 2016 MAC mit EWS
  • IOS ActiveSync ab Version 11
  • Outlook/IOS/Android

Mittlerweile sollte aber quasi jede Firma schon diese Voraussetzungen erfüllen.

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.

Prüfpunkt Erfüllt

Tenant mit Modern Auth

Basieren 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

  • NoOverride
    Nutze die Einstellung, die global für den Tenant vorgegeben ist, wobei ich noch nicht die Stelle gefunden habe, an der die "Tenant authentifizierung" konfiguriert wird. Daher stelle ich das siherheitshalber pro Dienst explizit ein.
  • Allowed
    Aktiviere Modern Auth, auch wenn es global nicht aktiviert ist.
  • Disallowed
    Deaktiviere ModernAuth für Skype fpr Business Online, auch wenn es global aktiviert ist

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

Clients

Damit 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 Authentifizierung

Damit 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)
Quelle: https://docs.microsoft.com/en-us/office365/enterprise/hybrid-modern-auth-overview

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 eintragen

Sowohl 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 Access

Ehe 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 einschalten

Nun sollten alle Vorarbeiten erfolgt sein und wir schalten wir 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 einschalten

Auch 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-Aus

Eigentlich 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 Exchang 
Set-AuthServer `
   -Identity EvoSTS `
   -IsDefaultAuthorizationEndpoint $false
Set-OrganizationConfig `
   -OAuth2ClientProfileEnabled $false
# NotAus für HMA mit SFB
Set-CsOAuthConfiguration `
   -ClientAuthorizationOAuthServerIdentity ""

"Legacy Authentication 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.

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 "Basic auth" in der Cloud unterbinden.

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

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"

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.

Modern Authentication wieder abschalten

Solange die Authentication-Dienste von Office 365/AzureAD verfügbar und erreichbar sein, werden Sie Modern Auth auf den OnPremises 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 OnPrem
Set-AuthServer -Identity evoSTS -IsDefaultAuthorizationEndpoint $false

#SFB OnPrem
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

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 OnPrem
Set-OrganizationConfig -OAuth2ClientProfileEnabled $false
Set-AuthServer -Identity evoSTS -IsDefaultAuthorizationEndpoint $false

#Exchange Online
Set-OrganizationConfig -OAuth2ClientProfileEnabled:$false

#SFB OnPrem
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