ADFS Authentifizierung

Auf der Seite Kerberos Browser habe ich beschrieben, Wie sie verschiedene Browser dazu bringen können, Kerberos als Anmeldung an Webseiten zu unterstützen. Mit einem IIS als WebServer ist die Konfiguration von "Negotiate" einfach, aber ADFS2012 ist kein Webserver mehr, sondern nutzt komplett alleine den HTTP-Service.

In der Welt von Office 365 kommt der Funktion "ADFS" eine tragende Rolle bei der Authentifizierung zu. Anwender greifen auf Dienste der Cloud z.B. per Browser zu, werden aber dann auf den ADFS-Server der Firma geleitet, um sich erst gegen das lokale Active Directory zu authentifizieren. Hier soll natürlich am Besten keine weitere Kennwortabfrage kommen. Der Browser muss also Kerberos oder NTLM unterstützen.

ADFS kann Negotiate

ADFS selbst unterstützt natürlich "Negotiate", womit Kerberos und NTLM möglich wird. Allerdings bietet ADFS diese Anmeldung nur an, wenn Sie aus dem internen LAN kommen. Wenn ein ADFS-Proxy "davor" steht, erkenne der ADFS-Server dies und schaltet auf eine formularbasierte Anmeldung um.

Interne Clients bekommt aber auch nicht immer die Windows integrierte Anmeldung (WIA) angeboten. Der ADFS-Server macht dies am User-Agent fest.

PS C:\> (Get-AdfsProperties).wiaSupportedUserAgents
MSAuthHost/1.0/In-Domain
MSIE 6.0
MSIE 7.0
MSIE 8.0
MSIE 9.0
MSIE 10.0
Trident/7.0
MSIPC
Windows Rights Management Client

Der erste Schritt ist es, die gewünschten "kompatiblen" User-Agenten zu addieren. Sie sollten dies natürlich erst tun, wenn die Clients entsprechend vorbereitet sind. Sollte der Client nämlich keine Anmeldung per Kerberos unterstützen, dann sieht der Anwender nicht mehr das ADFS-Formular, sondern eine Anmeldebox.

Set-ADFSProperties `
   -WIASupportedUserAgents @("MSAuthHost/1.0/In-Domain", "MSIE 6.0", "MSIE 7.0", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0", "Trident/7.0", "MSIPC", "Windows Rights Management Client", "Mozilla/5.0", "Safari/7.0")

Damit ist es aber noch nicht getan, denn ADFS2012 hat zudem die Funktion "ExtendedProtectionTokenCheck" eingeschaltet ist. Diese zusätzliche Sicherheitsprüfung kann aktuell wohl nur der IE. Sie muss abgeschaltet werden, dann auch die Browser vom Typ "Safari, Chrome und Firefox" sich anmelden können. Der Befehl dazu ist:

Set-ADFSProperties -ExtendedProtectionTokenCheck None

Die Einstellung wird bei einer ADFS-Farm automatisch repliziert. Allerdings müssen die ADFS-Dienste neu gestartet werden.

ADFS Auth Logging

In Ermangelung von IISLogs kann ein Administrator nicht mehr einfach nach fehlerhaften Anmeldungen forschen. Der erste Schritt ist einfach die Aktivierung der Überwachung

z.B.: per Kommandozeile

auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable

Oder natürlich auch per GUI:

Danach sollte ein "gpupdate /force" dabei helfen, die Richtlinie umgehend anzuwenden um die Anmeldeversuche im Security Eventlog zu sehen. Ein Zugriff von Extern kann wie folgt aussehen:

Log Name:      Security 
Source:        AD FS Auditing 
Event ID:      403 
Task Category: (3) 
Level:         Information 
Keywords:      Classic,Audit Success User:          msxfaq\User1 
Computer:      adfs.msxfaq.net
Description: 
An HTTP request was received. 

Activity ID: 00000000-0000-0000-940d-0080010000c6 

Request Details: 
    Date And Time: 2014-04-20 12:16:16 
    Client IP: 80.66.17.140 
    HTTP Method: GET URL Absolute Path: /adfs/ls/ 
    Query string: ?cbcxt=&popupui=&vv=&Username=User1%40msxfaq.net...... 
    Local Port: 443 
    Local IP: 192.168.178.23 User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:37.0) Gecko/20100101 Firefox/37.0 
    Content Length: 0 
    Caller Identity: - 
    Certificate Identity (if any): - 
    Targeted relying party: - 
    Through proxy: True 
    Proxy DNS name: adfs.msxfaq.net

Hier ist auch gut zu sehen, dass der Server die Anfrage als "Extern" eingestuft hat und damit sicher keine Windows Integrierte Authentifizierung angeboten hat.

Interessant ist in dem Zuge aber noch ein anderes Eventlog, welches die Header  der HTTP-Request anzeigt:

Log Name:      Security 
Source:        AD FS Auditing 
Event ID:      410 
Task Category: (3) 
Level:         Information 
Keywords:      Classic,Audit Success User:          MSXFAQ\User1
Computer:      adfs.msxfaq.net
Description: 
Following request context headers present : 

Activity ID: 00000000-0000-0000-840d-0022010000c6   

X-MS-Client-Application: - 
X-MS-Client-User-Agent: - 
client-request-id: - 
X-MS-Endpoint-Absolute-Path: /adfs/ls/ 
X-MS-Forwarded-Client-IP: - 
X-MS-Proxy: adfs.msxfaq.net

Hier ist das Feld "X-MS-Proxy" interessant, da damit der ADFS-Server erkennt, dass die Anfrage über einen Proxy-Server gereicht wurde. Wenn Sie also entgegen der Empfehlung von Microsoft einen eigenen Proxy einsetzen wollen, dann sollte dieser zumindest diesen Eintrag addieren.

Wer noch tiefer einsteigen will, kann im Eventviewer zuerst die Anzeige der Analyse und DebugLogs aktivieren und dann bei "AD FS Tracing" die Funktion einschalten. Vergessen Sie aber nicht nach der Analyse diese Funktion wieder abzuschalten

Dies ist aber dann schon eine sehr tiefe Analyse.

ADFS hinter Proxy

Wenn der ADFS-Dienst aus dem Internet erreichbar sein soll, dann fordert Microsoft hierfür die Installation eines ADFS-Proxy davor. Die wesentliche Aufgabe dieses Systems ist es, die ADFS-Anfragen von Extern als Reverse Proxy auf den ADFS-Server nach intern weiter zu geben. Natürlich übernimmt der ADFS-Proxy dabei auch Schutzfunktionen, z.B. indem ungültige URLs gleich abgewehrt werden.

Wichtiger ist aber noch, dass der Proxy einen "Header" addiert, mit dem der eigentliche ADFS-Server die externen Zugriffe von den internen Zugriffe unterscheiden kann. Der Reverse Proxy muss dazu das Feld "X-MS-Proxy" in den Request addieren.

If you are using a third-party proxy, it must be configured to do the following:
- Send an HTTP header named x-ms-proxy. The value of this header should be the DNS name of the proxy host.
- Send an HTTP header named x-ms-endpoint-absolute-path. The value of this header should be set to the name of the proxy endpoint that received the request.

Otherwise, an AD FS 2.0 federation server proxy must be deployed behind the third-party proxy.
Quelle: Limiting Access to Office 365 Services Based on the Location of the Client https://technet.microsoft.com/en-us/library/hh526961(v=ws.10).aspx

Weitere Links