HTTP Authentication

Öffentliche Webseiten kann ein Browser natürlich anonym erreichen und geschützte Informationen sind natürlich erst nach einer vorherigen Anmeldung möglich. Diese Seite beleuchtet die verschiedenen Optionen einer Authentifizierung per HTTP.

Basisfunktion

Bis die ersten Informationen von einem Server zu einem Client übertragen werden, muss ein Handshake die Verbindung aufbauen. Bei HTTP gibt es eine Dreistufigkeit:

  • TCP-Handshake
    Der Client muss über den Namen die IP-Adresse auflösen und eine TCP-Verbindung zur Gegenstelle aufbauen. Der Client startet mit einem "SYN"-Paket, welches der Server mit einem SYN/ACK beantwortet und der Client wieder bestätigt. Siehe auch TCP SYN ACK RES
  • TLS-Handshake
    Wenn die Basisverbindung steht aber HTTPS zum Einsatz kommt, wird nun die TLS-Verbindung aufgebaut. Der Client initiiert den Handshake mit einem "CLIENT_HELLO", worauf der Server dann in der Regel sein Zertifikat mit einem SERVER_HELLO sendet. Im weiteren Handshake prüfen die Endpunkte die Zertifikate, einigen sich auf Cryptoverfahren und tauschen symmetrische Schlüssel.
  • HTTP-Handshake

Erst wenn die TCP und TLS-Verbindung steht, kann der Client wieder aktiv werden und nun die gewünschte Information per HTTP anfordern. Der Client weiß zu dem Zeitpunkt aber noch nichts über den Server. Er sendet seinen Request quasi auf Verdacht los. Der Client kann hier aber schon den ein oder anderen Header setzen, z.B. ob er "Bearer" unterstützt oder noch gültige Cookies zu der Zieldomäne.

  • Anonym
    Nur wenn die vom Client angefragte Information ohne Authentifizierung zur Verfügung steht, antwortet der Server sofort mit einem 200OK und er Information oder einem 301/302 als Umleitung o.ä.
  • Authentication Required
    Wenn die Information aber nur einem eingeschränkten Benutzerkreis zugänglich ist, dann startet der Anmeldeprozess. Der Server sieht nur den Client aber weiß sonst nicht viel. Daher lehnt der Server die Anfrage mit einem "401 Authentication Required" ab. Das Paket enthält aber für den Client die Information, welche Anmeldeverfahren möglich sind
  • Authentication
    Nun ist wieder der Client dran, der entweder gleich die Anmeldedaten liefert oder in einer Extrarunde sich einen zweiten 401 einfängt. Das ist bei Kerberos und NTLM der Fall, da hier der Client im zweiten Paket erst dem Server anzeigt, dass er z.B. Kerberos oder NTLM kann und er in dem Zuge auch die Dialekte mitteilt. In dem Fall antwortet der Server wieder mit einem 401 und seiner Antwort bezüglich der vereinbarten Protokolle
  • Authentication NEGO
    Erst im dritten Anlauf kann der Client dann den Request samt kompletter Anmeldeinformationen senden

Es ist also durchaus normal, dass es vor dem erfolgreichen "200 OK" im Logfile ein oder zwei 401-Meldungen gibt.

Anonymer Zugriff

Der einfachste Zugriff ist natürlich der anonyme Zugriff ohne Anmeldung. Per Fiddler können Sie schön die HTTP-Header analysieren. Ein einfacher Zugriff auf die Seite Dreimal 401 mit Negotiate wird wie folgt angezeigt:

Im Request-Header ist keine Authentifizierung und im Reply kommt ein 200 OK mit den Nutzdaten. Der Browser ist Happy.

WWW-Authenticate-Optionen

Wenn nun aber die angesprochene Ressource nicht anonym erreichbar ist, dann lehnt der Server die Anfrage mit einem 401-Fehler ab und liefert mir mit der Rückmeldung auch die vom Server unterstützten Anmeldeverfahren. Beim ersten Beispiel habe ich per PowerShell einfach mal eine Autodiscover-Anfrage an Office 365 simuliert:

Invoke-WebRequest -Uri https://outlook.office365.com/autodiscover/autodiscover.xml?user=user1@uclabor.de

Der Server lehnt natürlich ab und in der Antwort steht, dass hier Office 365 auch nur "Basic" anbietet.

Das ist aber nur die halbe Wahrheit, da es auch noch weitere Authentifizierungsverfahren gibt. Dazu gleich noch mal mehr. Sie sehen hier unter "Miscellaneous" noch ein paar Werte, die erst mal nicht zu "WWW-Authenticate" gehören. Clients, die aber OAUTH und Federation unterstützen, können diese Werte aber dennoch lesen und einen ganz anderen Weg der Anmeldung gehen.

Alle anderen Clients müssen sich am "WWW-Authenticate" orientieren. Diese Rückantwort ist aber von der Konfiguration des Servers abhängig. Natürlich kann ich als Administrator konfigurieren, welche Anmeldeverfahren ich dem Client anbiete. Aber auch diese Einstellung kann ich bei Bedarf auch noch vom UserAgent des Clients abhängig machen. Insofern müssen Sie dies bei Tests beachten, ob Sie als "Browser" oder als EWS-DLL oder als PowerShell-Skript die Anfrage stellen. Als Browser bekommen Sie meist alle Optionen. Hier ein Test mit dem Browser

https://autodiscover.netatwork.de/autodiscover/autodiscover.xml?user=user@uclabor.de

Hier sehe ich, dass die Gegenseite mir Negotiate, NTLM und Basic anbietet.

Bei der Auflistung von "WWW-Authenticate" gibt es zwei Dinge zu beachten:

  • Reihenfolge
    Die Abfolge der Optionen gibt auch die Präferenz des Servers vor. Es ist aber Aufgabe des Clients das Verfahren zu nutzen, welches er nutzen kann. Wenn Negotiate oben steht aber der Client kein Kerberos-Ticket bekommt, dann kann er zu NTLM oder Basic zurück fallen. Der Server weiß nicht ja nicht, was der Client tatsächlich kann. Wenn sich ein Client für ein Verfahren entscheidet und das nicht funktioniert, dann versucht er in der Regel aber kein weiteres Verfahren.
  • Funktionsfähigkeit
    Insofern ist es wichtig, dass die angebotenen Verfahren zumindest auf der Seite des Servers funktionieren. Wenn ein Server z.B. NTLM anbietet, aber der Reverse-Proxy die Authentifizierung kaputt macht, dann kommt keine Anmeldung zustande.

Das ist insbesondere bei der Veröffentlichung von Diensten ins Internet zu verifizieren. Wer seinen Exchange Server direkt über NAT veröffentlicht, stellt extern damit eben auch NTLM und Kerberos bereit. Das ist soweit kein Problem da der Client aus dem Internet vermutlich kein Kerberos-Ticket bekommt und daher alleine NTLM nutzt.

Wenn Sie die Web-Dienste aber über einen Reverse-Proxy bereit stellen, der vielleicht noch eine Preauthentication macht, dann bestimmt der Reverse-Proxy über die angebotenen Anmeldeverfahren. Schließlich muss er die Daten ja auch verifizieren und ggfls. nach hinten weiter geben. 

Bearer/OAuth2

Neben der Anmeldung durch eine Übermittlung von Benutzername und Kennwort in der ein oder andere Form gibt es natürlich noch die Authentifizierung mittels Tokens. Das Schlüsselwort im Bereich "WWW-Authenticate" ist hier dann "Bearer". Um aber ältere Clients nicht zu verwirren, sendet der Server nur dann diese Antwort, wenn der Client mit der Anfrage schon mitteilt, dass er Bearer unterstützt: Sie sehen in dem Beispiel eine Anfrage von Outlook mit aktivierter "Modern Authentification" und dem "Authorization: Bearer" im Request:

Die Antwort vom WebServer ist weiterhin ein 401 aber das Feld "WWW-Authenticate" enthält nun die notwendige Information für den Client, wo er sich ein Ticket besorgen kann. Ich habe diese lange Zeile hier mal umgebrochen:

WWW-Authenticate: Bearer 
   client_id="00000002-0000-0ff1-ce00-000000000000", 
   trusted_issuers="00000001-0000-0000-c000-000000000000@*", 
   token_types="app_asserted_user_v1 service_asserted_app_v1", 
   authorization_uri="https://login.windows.net/common/oauth2/authorize",
   Basic Realm="",
   Basic Realm=""

Der Client kann nun über dies URL sich dann weiter hangeln, bis er nach erfolgreicher Authentifizierung mit einem Token wieder zurück kommt.

Weitere WWW-Authenticate-Formate

Wenn Sie mit Fiddler mal eine Zeit lang ihr System mitschneiden lassen, dann werden Sie weitere Authentifizierungsverfahren finden, die Sie vielleicht noch nicht gehört haben. Es steht nämlich jedem Hersteller frei, eigene Verfahren und Werte zu definieren. Entsprechend interessant ist dann auch die Fiddler-Liste.

Wenn Sie genau hinschauen, dann finden sie neben "Bearer" und "Basic" auch noch:

  • skype_token
    Anscheinend baut Skype/Teams seine eigene Token-Issuing-API auf.
  • SmartScreenHash
    Diese Requests dürften von Windows Defender kommen um den Wert einer Malware oder das Gerät zu identifizieren
  • WLID
    Gehört auch zu Microsoft und könnte als "Windows Live ID" abgekürzt sein
  • SAPISIDHASH
    Habe ich bislang nur bei Google gesehen. Wenn es nicht SAP ist, dann ein SAPIS IDHash. Das dürfte auch eher eine Identifikation denn eine Anmeldung sein
  • AidLogin
    Noch ein Anmeldestring von Google

Zudem können Sie schon sehen, dass auch verschiedene Hosts unter der gleichen Domain das gleiche Token nutzen und "netrics.api.drift.com" das Bearer klein schreibt. Sie sehen aber auch, dass je nach Tenant schon ModernAuth genutzt wird oder nicht.

Das Feld "Authentication" enthält also nicht immer entsprechende Anmeldedaten oder Credentials, sondern wird auch gerne mal bei eigentlich anonymen Zugriffen missbraucht, um den Client identifizieren zu können.

Forms

Die Anmeldung in einem Dialog, welcher der Browser aufgrund einen 401 aufblendet, kann ein Sicherheitsrisiko sein. Der Browser hat hier die Anmelddaten und ohne weitere Vorkehrungen ist eine klassische Abmeldung nicht möglich. Über ein "Zurück" ist es oft möglich eine frühere Session wieder aufzunehmen. So können Sie einen per Kennwort gesicherten Zugang natürlich nur nutzen, wenn Sie hinterher alle Instanzen des Browsers beenden. Ein unbequemes und auf öffentlichen Surf-Stationen oft unmögliches Unterfangen.

Daher hat es sich schon viele Jahre eingebürgert, dass der Anwender bei einem anonymen Zugriff eine Seite mit einem Formular angezeigt bekommt. So kann der Anbieter schon Informationen vor der eigentlichen Anmeldung bereitstellen. Der Anwender füllte dann seinen Benutzernamen und Kennwort in einem HTML-Form aus, welches hoffentlich per HTTPS verschlüsselt zum Server gesendet wird. Der Server prüft die Anmeldung und liefert dann z.B. die gewünschte Seite und einen Cookie mit der Information über den Anwender und einer Verfallszeit aus.

Der Client sendet diesen Cookie mit jedem Request wieder an den Server, der diese Information als Authentifizierung nutzt und ggfls. den Cookie auch wieder erneuert.

Jede weitere Kommunikation kann, durch den Cookie authentifiziert, natürlich wieder die unterschiedlichsten Dienste und URLs nutzen.

Ein "Logout-Button" nutzt dann einfach die Funktion, dass der WebServer den Client anweist, den Cookie zu löschen und der Server den Cookie auf seiner Seite auch als abgelaufen zu kennzeichnen. Damit kann niemand die Session wieder aufnehmen.

WSSecurity

Manchmal können Sie in Fiddler aber auch folgende Requests sehen: Hier greift ein Skype for Business Client per EWS auf Exchange zu aber es gibt keinen Authentication-Header und trotzdem wird die Anfrage mit einem 200OK quittiert.

Der eigentliche HTTP-Zugriff erfolgt also komplett Anonym und der WebServer selbst prüft keine Anmeldedaten. Die zur Authentifizierung erforderliche Information ist hier im Payload versteckt:

Das Verfahren kommt primär bei WebServices vor, bei denen der Client einfach sich mit dem Server verstehen muss. Die Informationen zur Authentifizierung können durch den Programmierer selbst bestimmt werden. So wäre die Nutzung von Zertifikaten zur Signierung und Verschlüsselung auch möglich. Der zweite Teil des Payload ist dann in "s:body" hinterlegt. Hier sehen Sie, dass der Client anscheinend einen Subscribe auf einen Ordner ausführt.

So umgeht man natürlich alle Probleme mit WWW-Authentication, Proxy-Servern und anderen Systemen, die bei der Übertragung die Pakete verändern könnten. Allerdings ist hier dann auch direkt der Webservice die Instanz, die über die Authentifizierung entscheidet. Für eine vorgelagerte Firewall oder einen Reverse Proxy ist es einfach ein anonymer HTTP-Zugriff.

Zertifikate

In eine ganz andere Kategorie fällt die Anmeldung per Zertifikat. Sie kann eigentlich nicht mit einer der anderen Anmeldeverfahren direkt kombiniert werden, da beim klassischen Verfahren der Server schon beim TLS-Handshake den Client um ein Zertifikat bittet. Also nachdem der TCP-Handshake erfolgt ist, sendet der Client einen "Client Hello" und der Server antwortet entsprechend. Optional liefert der Server auch gleich eine Liste der Stammzertifizierungsstellen mit, denen er vertraut, so dass der Client ein passendes Zertifikat herausfiltern kann. Der Webserver bekommt dann das Zertifikat des Clients und entnimmt darauf z.B: den CN, welcher als Anmeldenamen genutzt wird. Wenn der Client kein Zertifikat vorweisen kann, dann bemerkt das der Server natürlich auch und kann eine entsprechende Fehlermeldung zurück geben. Der Server kann aber statt einer Fehlermeldung mangels Clientzertifikat natürlich auch ganz einfach auf eine andere Anmeldeseite umleiten oder alternative Anmeldeverfahren bereit stellen. Daher gibt es mit Zertifikaten quasi drei Optionen:

  • Server fordert Anmeldung direkt und nur mit Zertifikat
    Wenn der Client dann kein Zertifikat liefern kann, dann bekommt er einen Access Denied.
  • Zertifikat zuerst mit Fallback auf andere Verfahren
    Ein Webserver kann wie in der ersten Variante vom Client ein Zertifikat abfordern aber ohne Clientzertifikat statt einer Fehlermeldung einen Redirect auf eine andere Seite ausführen oder andere Anmeldeverfahren anbieten. Quasi als "Fallback"
  • Formular mit Link zur Anmeldung per Zertifkat
    So macht es z.B. ADFS, wenn ich die Funktion aktivieren. Ich kann mich mit Benutzername und Kennwort anmelden aber auch alternativ ein Zertifikat verwenden.

Ich finde Zertifikate sehr interessant, da ich so zumindest auf einem Firmencomputer auch aus dem Internet kein weiteres Kennwort angeben muss. Leider unterstützt ADFS nicht die Option, erst nach einem Zertifikat zu fragen, um dann auf das Anmeldeformular zurück zu wechseln.

Exchange und Authentifizierung

Ein Sonderfall bei der Authentifizierung ist Exchange mit Outlook, ActiveSync und EWS. Sie wissen sicher, dass die Exchange Clients über das Verfahren Exchange - Autodiscover erst einmal den Zugang zum Postfach ermittelt. Ganz am Anfang kennt der Autodiscover-Client natürlich noch gar nicht und muss es auf den ersten 401 ankommen lassen. Nachdem der Client dann angemeldet ist, bekommt er aber vom Exchange Server eine lange XML-Struktur, in der alle Zugänge und auch die Authentifizierungsverfahren hinterlegt sind. Hier ein Auszug eines Office 365 Postfachs.

Exchange Online liefert mit für OWA die Information, dass die Anmeldung "FBA" (Form Based Authentication) genutzt wird. Für EXHTTP hingegen bietet er mir erst einmal "BASIC" an. Das ist sicher die richtige Antwort für Legacy Clients, die noch nichts mit Bearer und "Modern Auth" am Hut haben. Aber was der Client letztlich nutzt, hängt auch davon ab, was er vorab an den Server sendet und wie dieser antwortet. Hier sieht man schon, dass Outlook 2016 beim Request ein "Authorization Bearer" mitliefert und der Server mit einer passenden Antwort anzeigt, dass er dies unterstützt.

Schaue ich z.B. auf einem lokalen Exchange 2016 Server mir die OWA und EWS-Einstellungen aus Sicht von Exchange an, dann sehe ich:

[PS] C:\>Get-OwaVirtualDirectory| fl name,*auth*

Name                          : owa (Default Web Site)
ClientAuthCleanupLevel        : High
InternalAuthenticationMethods : {Basic, Fba}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : True
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}

[PS] C:\>Get-WebServicesVirtualDirectory | fl name,*auth*

Name                            : EWS (Default Web Site)
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

Schaue ich mir aber die Einstellungen zu EWS im IIS an, dann gibt es schon Abweichungen. Zwar stimmen die Werte für Basic, NTLM, Windows überein, aber "WSSecurity" und "OAuth" sind im IIS nicht zu sehen.

Auch scheint die PowerShell die Reihenfolge anders zu interpretieren. Denn dort steht NTLM vor Windows Integrated, während im IIS die NTLM-Funktion innerhalb von "Windows Authentication" an zweiter Stelle auftaucht. Das ist gleich für Skype for Business noch mal ein Thema.

Der Trick, wie Exchange eine Anmeldung per OAUTH oder WSSecurity erlaubt ist in der Einstellung zu "Anonymous Authentication" verborgen. Der IIS erlaubt damit grundsätzlich auch einen Zugriff ohne Anmeldung. Die dahinter gebundene Applikation bekommt den Request als auf jeden Fall und kann nun entscheiden, ob in den übermittelten Daten schon ausreichend Belege für einen legitimen Zugriff enthalten oder ob die Anfrage mit einem 401 abgelehnt wird und der IIS dann eine Authentifizierung durchführt.

Sonderfall Skype for Business

Der Skype for Business Client nutzt ja nun auch neben SIP, TP und MAPI über Outlook den direkten Weg zum Exchange Server über EWS. Diese Anbindung führt in vielen Firmen erst einmal einer kritischen Betrachtung. Viele Firmen hatten bislang nämlich ihren Exchange Server z.B.: nur für OWA und ActiveSync erreichbar gemacht. Outlook Clients wurden über VPN eingebunden, da man so auch verhindern kann, dass nicht verwaltete Geräte sich eine Kopie des Postfachs ziehen. Skype for Business funktioniert natürlich am besten ohne VPN und mit direkten Verbindungen.

Angeblich ist im Skype Client für die Anmeldung am EWS die Authentifizierung per NTLM fest codiert und kommt damit in Konflikt, wenn der Webserver stattdessen "Kerberos,NTLM" liefert. Allerdings gibt es in der Dokument zu ADAL eine interessante Aussage:

  • AllowAdalForNonLyncIndependentOfLync=0
    1. The Skype for Business Desktop and Lync 2013 clients connect to Skype for Business Server by using NTLM or the Kerberos authentication protocol, a user name and password, or Windows Integrated Authentication.
    2. After you sign in, Skype for Business or Lync 2013 connects to the user’s mailbox in Exchange Online by using Exchange Web Services (EWS). Although the EWS service advertises OAuth settings (the authorization URI), the client ignores this and falls back to a non-MFA sign-in by using an OrgID channel. This limits sign-in protocols to a user name and password or to Windows Integrated Authentication.
  • AllowAdalForNonLyncIndependentOfLync=1
    1. The Skype for Business Desktop or Lync 2013 clients connects to Skype for Business Server by using NTLM or the Kerberos authentication protocol. Specifically, a user name and password or Windows Integrated Authentication will be required for a successful connection (as it was previously).
    2. After you sign in, Skype for Business or Lync 2013 connects to Exchange Web Services (EWS). If the EWS service advertises OAuth settings (authorization URI), the client uses MFA. Additionally, if a credentials refresh is necessary, the user will be prompted through the Modern Authentication dialog box.

Quelle: Information about the AllowAdalForNonLyncIndependentOfLync setting in Skype for Business, Lync 2013, and Exchange Online
https://support.microsoft.com/en-us/help/3082803/allowadalfornonlyncindependentoflync-in-sfb-lync-exchange-online

Auch andere Quellen suggerieren hier eine Abhängigkeit:

Autodiscover and EWS service do NOT support FBA (form based authentication).
The client need the XML file straight and without authentication webpage, than access the EWS URL need to be authenticated at the Exchange CAS server. Authentication must be NTLM over HTTPS. (So do not use http, the password would be submitted in clear text). The NTLM authentication is hard-coded in Lync Client.”..
...On the Exchange CAS Servers, you also should check manually on the EWS and the Default Website, if NTLM is the first choice for authentication and NEGOTIATE the second option.
Quelle: “Publishing EWS service via Reverse Proxy: http://www.uclabs.blog/2013/01/lync-and-exchange-web-services-ews-and.html

Ich habe leider noch keine Quelle bei Microsoft gefunden, die eine Umstellung der Reihenfolge der angebotenen Anmeldeverfahren empfiehlt oder tatsächlich als Ursache für vermehrtes Auftreten einer Kennwortbox

Sie können es natürlich dennoch versuchen, diese Einstellungen im IIS zu verändern

REM IIS6, Exchange 2010 Server
cscript adsutil.vbs get w3svc/1/root/NTAuthenticationProviders 
cscript adsutil.vbs set w3svc/1/root/NTAuthenticationProviders "NTLM,Negotiate"
net stop IISADMIN
net start IIADMIN

Die folgenden Befehle ändern den Default auf dem WebServer über die CMD-Shell. Bei II7 kann dies auch den IIS Manager erfolgen:

REM Konfiguration anzeigen
appcmd list config /section:windowsAuthentication

REM zuerst einmal Negotiate entfernen
Appcmd.exe set config /section:windowsAuthentication /-providers.[value=’Negotiate’]

REM dann NEGOTIATE wieder hinten anhaengen
appcmd.exe set config -section:system.webServer/security/authentication/windowsAuthentication /+"providers.[value=’Negotiate’]" /commit:apphost

REM Kontrolle der Konfiguration
appcmd list config /section:windowsAuthentication

REM Technisch aendern diese Befehle die web.config des WebServres

Ob diese Änderungen aber tatsächlich helfen, konnte ich noch nicht abschließend klären.

Analyse von 401-Fehlern

Ich habe einfach mal ein paar URLs per PowerShell und per Browser angesprochen, so dass die Server mir mit einem 401 und den entsprechenden Authentication-Header geantwortet haben. Die Auswahl der URLs soll eine breite Basis liefern und verschiedene Varianten aufzeigen. Es ist aber natürlich eine Momentaufnahme. Insbesondere die Zunahme von Anmeldungen per "Formular" macht es schon kniffliger sich noch einen klassischen 401 einzufangen. Keine der Methoden auf PowerShell als HTTP-Client liefert beim ersten 401 die Rückantwort, sondern wirft entweder eine Exception ohne weitere Details oder folgt ggfls. einem Redirect oder versucht sogar eine Authentifizierung. Als habe ich auf Basis der TCPClient-Klasse mir doch mal schnell einen einfachen HTTP-Requester geschrieben. Den Code dazu finden Sie auf Powershell und TCP.

  • Viele WebServer prüfen den User-Agent auf "Mozilla/5.0" um so einen Browser zu erkennen und dann ggfls. ein Formular oder MFA-Fenster anzuzeigen.
  • Ein weiteres Feld im Request ist "Authorization"
    Dieses Feld ist in der Regel nicht da, es sei denn der Client unterstützt z.B. Bearer-Authentifizierung

Die hier abgefragten URL können nicht geheim sein. Wer Exchange im Internet erreichbar mach und die Konfiguration der Clients per Autodiscover ermöglicht, verrät automatisch auch die Plattform (Cloud oder On-Premises) und über Namen im Zertifikat oder Redirects oft auch den EWS/ActiveSync-Zugang. Der einfache anonyme Abruf der URL passiert täglich millionenfach durch Bots und Malware Scanner auf der Suche nach ungeschützten Systemen. Wer natürlich im zweiten Schritt dann Benutzernamen und Kennworte durchprobiert, begibt sich auf sehr dünnes Eis. Das ist dann schon der Versuch einen unerlaubten Zugriff zu erhalten und dürfte ein Gericht wohl als versuchter Einbruch werten.

URL User-Agent Authorization:
Bearer im Request
401 Auth-Felder

Exchange EWS intern  https://server//ews/exchange.asmx

Mozilla/5.0

Nein

X-WSSecurity-Enabled: True
X-WSSecurity-For: None
X-OAuth-Enabled: True
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="EX01"

Exchange EWS extern https://serverFQDN//ews/exchange.asmx

Mozilla/5.0

Nein

X-WSSecurity-Enabled: True
X-WSSecurity-For: None
X-OAuth-Enabled: True
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="EX01"

https://outlook.office365.com/EWS/Exchange.asmx

Mozilla/5.0

Nein

X-WSSecurity-Enabled: True
X-WSSecurity-For: Logon
X-FederationTrustTokenIssuerUri: urn:federation:MicrosoftOnline
X-WSSecurity-SymmetricKey-Enabled: True
X-WSSecurity-X509Cert-Enabled: True
X-OAuth-Enabled: True
WWW-Authenticate: Basic Realm=""

https://outlook.office365.com/EWS/Exchange.asmx

PowerShell

Nein

X-WSSecurity-Enabled: True
X-WSSecurity-For: Logon
X-FederationTrustTokenIssuerUri: urn:federation:MicrosoftOnline
X-WSSecurity-SymmetricKey-Enabled: True
X-WSSecurity-X509Cert-Enabled: True
X-OAuth-Enabled: True
WWW-Authenticate: Basic Realm=""

https://outlook.office365.com/EWS/Exchange.asmx

egal

Bearer
WWW-Authenticate: Bearer client_id="00000002-0000-0ff1-ce00-000000000000", 
   trusted_issuers="00000001-0000-0000-c000-000000000000@*", 
   token_types="app_asserted_user_v1 service_asserted_app_v1", 
   authorization_uri="https://login.windows.net/common/oauth2/authorize",
   Basic Realm=""

https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml

Egal

Nein

X-SOAP-Enabled: True
X-WSSecurity-Enabled: True
X-WSSecurity-For: Logon
X-FederationTrustTokenIssuerUri: urn:federation:MicrosoftOnline
X-WSSecurity-SymmetricKey-Enabled: True
X-WSSecurity-X509Cert-Enabled: True
X-OAuth-Enabled: True
WWW-Authenticate: Basic Realm=""

https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml

Egal

Bearer
WWW-Authenticate: Bearer client_id="00000002-0000-0ff1-ce00-000000000000", 
   trusted_issuers="00000001-0000-0000-c000-000000000000@*", 
   token_types="app_asserted_user_v1 service_asserted_app_v1", 
   authorization_uri="https://login.windows.net/common/oauth2/authorize"
WWW-Authenticate: Basic Realm=""

https://autologon.microsoftazuread-sso.com/carius.de/winauth/sso

Egal

nein

Access-Control-Allow-Origin: https://login.microsoftonline.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, OPTIONS
WWW-Authenticate: Negotiate

https://autologon.microsoftazuread-sso.com/carius.de/winauth/sso

Egal

Bearer
HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=utf-8
Access-Control-Allow-Origin: https://login.microsoftonline.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, OPTIONS

Bei der Analyse einige Firmen ist mir aufgefallen, dass bei vielen Domänen der Zugriff per HTTPS gar nicht mehr möglich ist. Wenn ich dann aber per HTTP zugegriffen habe, dann habe ich immer häufiger einen "HTTP/1.1 302 Moved Temporarily" mit dem Ziel "Location: https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml" erhalten. Es gibt also schon mehr Firmen, die anscheinend komplett oder zumindest zum großen Teil nach Office 365 gewechselt sind, z.B. "rwe.com", "avanade.de". Viele andere Firmen scheinen aber ganz von "autodiscover" abzugehen, da es trotz MX-Record und Exchange extern keine entsprechende Auflösung gibt. Einige Firmen, z.B. roller.de leiten den Client auf eine Authentifizierungsserver um.

Andere Dienste wie z.B. Wordpress-Installationen scheren sich nicht um den UserAgent und zeigen einfach immer das Formular. Nicht jede Software nutzt diese Information als Weiche sondern stellen für Apps und andere nicht interaktive Zugänge eben getrennte URls bereit.

Was mich hier allerdings wundert ist die Tatsache, dass viele Seiten nur ein "BASIC" oder Formulare anbieten. Natürlich wird Kerberos von extern nicht funktionieren aber NTLM wäre schon eine bessere Alternative. SSL ist nur solange sicher, wie kein Proxy per Inspektion sich diese Daten extrahieren kann. Bei NTLM würden die Zugangsdaten schon mal besser geschützt sein.

Weitere Links