Office 365 - ADFS intern

Auf den beiden Seiten Office 365 ADFS und Office 365 ADFS Setup bin ich schon auf die ADFS Grundfunktion und die Einrichtung für Office 365 eingegangen. Diese Seite schaut etwas hinter die Kulissen und soll ihnen zeigen, wie ADFS funktioniert und so Sie bei einem Fehler korrigierend oder prüfend eingreifen können-

ADFS installiert ?

Wir sprechen hier nur von der Version ADFS 2.0. Die in Windows 2008R2 und früher enthaltene ADFS-Funktion ist nur die Version 1.0 und nicht für Office 365 geeignet.

Download Microsoft Active Directory Federation Services 2.0
http://technet.microsoft.com/en-us/evalcenter/ee476597

Ob ADFS bereits installiert ist, können Sie natürlich in der Systemsteuerung - Software erkennen. Sie müssen aber die "Updates"-Ansicht aktivieren, denn das ADFS 2.0 Setup wird in der Systemsteuerung als "Update" eingetragen:

Ein weiter Faktor sind Updates für ADFS. Im Sep 2013 war das Rollup2 aktuell, der als Hotfix nur auf Anforderung versendet wird.

  • 2681584 Description of Update Rollup 2 für Active Directory Federation Services (AD FS) 2.0

ADFS im IIS

Der ADFS-Server kann auf einem eigenen Server oder mit auf einem Domaincontroller installiert werden. Der Speicherbedarf ist überschaubar, da er sich im wesentlichen als kleiner Dienst mit einer IIS-Applikation darstellt.

Ich habe schon virtuelle Windows 2008 Server mit gerade mal 1 GB Hauptspeicher als ADFS-Server eingesetzt. Die für den Betrieb von Servern heute erforderlichen Agenten zu Überwachung, Virenschutz und Backup benötigen hier oft schon mehr Speicher.

Überwachung

Aus dem Internet werden Sie in der Regel nur den Pfad "/ADFS" freigeben und auch interne Clients nutzen immer nur diesen Pfad. Da ADFS ein "WebService" ist, können Sie diesen auch abfragen:

Weiterhin gibt es auch einen weitere URL, die eine XML-Datei liefert.

Beide URLs sind insofern ein guter Test, ob ADFS erreichbar ist, das SSL-Zertifikat gültig ist, Firewalls offen sind und der Dienst Informationen liefert.

Interne "automatische" Authentication

Wenn ein Client von einem angesprochenen Dienst zum ADFS-Server verwiesen wird, dann muss er sich natürlich auch am ADFS-Server authentifizieren. Diese Zugriffe und die Anmeldung müssen im IISLog sichtbar sein. Eine fehlerhafte Anmeldung ist hier gut zu erkennen. (IIS-Log gekürzt):

#Software: Microsoft Internet Information Services 7.5
#Version: 1.0
#Fields: cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
GET /adfs/ls/ vv=&username=user%40domain.tld&wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline 443 - 192.168.100.12 Mozilla/4.0+(compatible;+MSIE+7.0) 302 0 0 234
GET /adfs/ls/auth/integrated/ vv=&username=user%40domain.tld&wtrealm=urn:federation:MicrosoftOnline 443 -  Mozilla/4.0+(compatible;+MSIE+7.0) 401 2 5 0
GET /adfs/ls/auth/integrated/ vv=&username=user%40domain.tld&wtrealm=urn:federation:MicrosoftOnline 443 - Mozilla/4.0+(compatible;+MSIE+7.0) 401 1 3221226331 0
GET /adfs/ls/auth/integrated/ vv=&username=user%40domain.tld&wtrealm=urn:federation:MicrosoftOnline 443 - Mozilla/4.0+(compatible;+MSIE+7.0) 401 1 3221226331 0

GET /adfs/ls/auth/integrated/ vv=&username=user%40domain.tld&wtrealm=urn:federation:MicrosoftOnline 443 NETATWORK\fcarius Mozilla/4.0+(compatible;+MSIE+7.0) 200 0 0 234

Interessant sind hier die Fehlermeldungen am Ende der Zeilen:

  • 401.2
    Diese Meldung der zweiten GET-Zeile ist noch i.O. da der Client so erst mal einen Hinweis bekommt, dass und wie er sich anmelden kann.
  • 401.1 3221226331
    Dieser Code führt dann auf die Spur des Fehlers. Konvertiert man 3221226331 nach Hex (C000035B) und sucht danach, dann findet sich ein Artikel in der MSDN über Extended Protection
    (Integrated Windows Authentication with Extended Protection http://msdn.microsoft.com/en-us/library/dd639324(v=vs.90).aspx)
  • 200 (abgesetzte Zeile
    Eine erfolgreiche Ticketanforderung erkennen Sie an einem 200 als Statuscode.

Die "Integrierte Anmeldung" funktioniert für Clients natürlich nur, wenn diese auf dem Client auch aktiviert ist.

 

Ansonsten wird der Anwender nach den Anmeldedaten gefragt. Natürlich spielen hier noch IE Zoneneinstellungen, der verwendete Browser und insbesondere Firewalls und Proxy-Server eine weitere Rolle.

Kerberos

Damit die interne Authentifizierung nicht nur per NTLM sondern auch per Kerberos möglich ist, legt das Setup ein Dienstkonto an. Dies ist erforderlich, wenn in einer ADFS-Farm mehrere Server die Dienste hinter einen Loadbalancer anbieten und daher das gleiche Ticketkennwort verwenden müssen. Im Active Directory können Sie am Dienstkennwort überprüfen, ob ein ServicePrincipalName (SPN) gepflegt ist.

Nur dann kann der Anwender sich per Kerberos am ADFS authentifizieren.

Externe Anmeldung meist nur "Basic" aber bitte mit SSL

Versuchen Sie bitte nicht NTLM von Extern über einen Reverse Proxy auf die interne ADFS-Webseite zu lenken. Das "kann" aber muss nicht gehen. Sehr viele Proxies, Firewalls etc. machen jeden Versuch zunichte, NTLM zu benutzen.

Auch der Zugriff mittels Kerberos von einem Client im Internet ist in der Regel nicht nutzbar, da dazu der Client erst mit einem DC Kontakt haben muss, um ein entsprechendes Ticket zu erhalten. Das kann zwar auch gehen, z.B. wenn der Client per VPN oder insbesondere Direct Access angebunden ist, aber die Regel ist das noch nicht.

Insofern sollten Sie immer auch gewährleisten, dass die Anmeldung per "Basic Authentication" möglich ist, wenn gleich sie dann im Gegenzug natürlich einen SSL-Zwang vorschreiben sollten. Nicht dass die Anmeldedaten bestehend aus Domäne, Benutzername und Kennwort im Klartext übermittelt werden.

IIS Authentiation und Extended Protection

So schön Kerberos ist, so knifflig können geänderte Default-Einstellungen unter Windows 2008R2 dies erschweren. Microsoft hat aus Performance-Gründen nämlich die Authentifizierung als "Kernelmode"-Modul konfiguriert. Damit kann der IIS aber nur dann ein Kerberos-Ticket decodieren, wenn der Zugriff auch auf den Computernamen erfolgt aber nicht, wenn Sie z.B.: in einer ADFS-Farm mehrere Server nutzen die ein gemeinsames Dienstkonto verwenden.

Zugegeben wird das in kleinen Installationen nicht auffallen, wenn intern NTLM weiter funktioniert und von extern wie gehabt die Authentifizierung per "Basic" erfolgt. Je größer aber die Firma wird uns insbesondere wenn intern viele Clients sich ein ADFS-Ticket besorgen, sollte die Anmeldung mit Kerberos auch in einer ADFS-Farm funktionieren. Zeit dies im IIS zu ändern:

Die Standardeinstellungen sind.

Pfad Authentication Advanced Provider

\adfs

Anonymous

Entfällt

Kein

\adfs\ls

Anonymous
Windows Authentication

Accept enhanced
No Kernel Auth

Negotiate
NTLM

Die Einstellungen sind unter Authentication hinterlegt, in der die "Enable Kernel-Mode" Authentication"-Einstellung deaktiviert sein muss. Zudem können Sie hier die Extended Protection" aktivieren, damit ein Angreifer sich nicht in die Mittel zwischen Client und ADFS-Server einbinden kann.

Interessant sind vielleicht auch die folgenden Artikel:

ADFS im Eventlog

Wie jeder "gute" Dienst nutzt ADFS auch das Windows Eventlog, um beim Start und im Betrieb die ein oder andere Information zu protokollieren. Interessanter sind hier natürlich etwaige Fehlermeldungen, die Sie überwachen sollten. Hier ein "normaler" erfolgreicher Start:

Eine vollständige Auflistung der Fehler und deren Ursachen kann habe ich nicht. Aber mit dem Fehler und einer Suchmaschine ihrer Wahl können Sie viele Ursachen finden. Die folgende Seite zeigt ihnen sogar, wie sie die Debug-Logs für ADFS aktivieren

ADFS URLS

Active Directory Federation Services basiert auf HTTPS und nutzt verschiedene URLs. Hier mal eine Liste von URLs, die eventuell angesprochen werden

The Federation Service started successfully. The following service hosts have been added: 
Federation Server Proxy ServiceHost
https://adfs.msxfaq.de:443/adfs/services/proxytrustpolicystoretransfer

AD FS 1.x Trust Information Service
https://adfs.msxfaq.de/adfs/fs/federationserverservice.asmx

SAML Token Issuance ServiceHost
net.tcp://localhost:1501/samlprotocol
https://adfs.msxfaq.de/adfs/services/trust/samlprotocol/proxytrust

Issuance ServiceHost
http://localhost:80/adfs/services/trust/mexsoap
https://adfs.msxfaq.de:443/adfs/services/trust/proxymexhttpget/

Issuance ServiceHost
https://adfs.msxfaq.de/adfs/services/trust/proxymex
https://adfs.msxfaq.de:443/adfs/services/trust/proxymexhttpget/

Issuance ServiceHost
https://adfs.msxfaq.de/adfs/services/trust/2005/windowstransport
https://adfs.msxfaq.de/adfs/services/trust/2005/certificatemixed
https://adfs.msxfaq.de/adfs/services/trust/2005/certificatetransport
https://adfs.msxfaq.de/adfs/services/trust/2005/usernamemixed
https://adfs.msxfaq.de/adfs/services/trust/2005/kerberosmixed
https://adfs.msxfaq.de/adfs/services/trust/2005/issuedtokenmixedasymmetricbasic256
https://adfs.msxfaq.de/adfs/services/trust/2005/issuedtokenmixedsymmetricbasic256
https://adfs.msxfaq.de/adfs/services/trust/13/kerberosmixed
https://adfs.msxfaq.de/adfs/services/trust/13/certificatemixed
https://adfs.msxfaq.de/adfs/services/trust/13/usernamemixed
https://adfs.msxfaq.de/adfs/services/trust/13/issuedtokenmixedasymmetricbasic256
https://adfs.msxfaq.de/adfs/services/trust/13/issuedtokenmixedsymmetricbasic256
net.tcp://localhost:1501/adfs/services/trusttcp/windows
https://adfs.msxfaq.de/adfs/services/trust/proxytrust
https://adfs.msxfaq.de/adfs/services/trust/proxytrust13
https://adfs.msxfaq.de/adfs/services/trust/proxytrustprovisionusername
https://adfs.msxfaq.de/adfs/services/trust/proxytrustprovisionissuedtoken

SAML Metadata
https://adfs.msxfaq.de/FederationMetadata/2007-06/

Diese URLs können natürlich auch "geprobt" werden.

Zertifikate

Und zuletzt hat ADFS natürlich immer etwas mit Zertifikaten zu tun. ADFS nutzt für die Ausstellung der Tickets ein "SelfSigned"-Zertifikat. Das ist unkritisch, da Sie als Administrator sowieso diese Zertifikat (Ohne Private Key) in die Office 365 Cloud hochladen, damit die Office 365 Services die Tickets prüfen können und Sie als Admin damit diese Zertifikat de facto als "Trusted" addieren. Ein Blick in die MMC zeigt diese Zertifikate an:

Interessant ist hier natürlich, wann so ein Zertifikat abläuft, damit es rechtzeitig erneuert werden kann.

ACHTUNG: Das Token-Signing Zertifikat läuft regelmäßig ab und wenn man es ändert, muss es auch an die Dienste verteilt werden, die auf ihrem ADFS-Server aufsetzen. Wer also hier nicht nur Office 365 nutzt, sollte sich vielleicht ein Zertifikat mit längerer Laufzeit ausstellen.

ADFS-Datenbank

Wer bei der Installation aufgepasst hat, hat die Installation der "Windows Internal Database" gesehen, die genau genommen eine SQL-Instanz ist, die aber als SQL-Express technisch weniger limitiert ist. Dafür darf diese Datenbank nur von Microsoft für Windows-Dienst genutzt werden. Die Dateien und Endungen sollten ihnen bekannt vorkommen:

Wer einen SQL-Enterprise Manager installiert hat, kann sogar recht einfach als Administrator mal einen Blick in die Datenbank wagen:

Letztlich ist es primär eine Konfigurationdatenbank, die ADFS zur Ablage der Informationen nutzt.

ADFS und PowerShell

Wer ADFS nicht per GUI verwalten will oder Einstellungen ändern möchte, die nicht in der GUI vorhanden sind, muss zwangsläufig per Kommandozeile arbeiten. Dazu gibt es ein passendes PSSnapIn zur Verwaltung von ADFS

PS C:\Windows\system32> Get-PSSnapin  Microsoft.Adfs.PowerShell | fl

Name        : Microsoft.Adfs.PowerShell
PSVersion   : 1.0
Description : This PowerShell snap-in contains cmdlets used to manage Microsoft Identity Server resources.

Nach dem Import des Snapins können Sie auf eine ganze menge von Befehlen zugreifen und ADFS quasi komplett automatisiert verwalten.

PS C:\Windows\system32> Get-Command *adfs*

CommandType     Name
-----------     ----
Cmdlet          Add-ADFSAttributeStore
Cmdlet          Add-ADFSCertificate
Cmdlet          Add-ADFSClaimDescription
Cmdlet          Add-ADFSClaimsProviderTrust
Cmdlet          Add-ADFSRelyingPartyTrust
Cmdlet          Disable-ADFSClaimsProviderTrust
Cmdlet          Disable-ADFSEndpoint
Cmdlet          Disable-ADFSRelyingPartyTrust
Cmdlet          Enable-ADFSClaimsProviderTrust
Cmdlet          Enable-ADFSEndpoint
Cmdlet          Enable-ADFSRelyingPartyTrust
Cmdlet          Get-ADFSAttributeStore
Cmdlet          Get-ADFSCertificate
Cmdlet          Get-ADFSClaimDescription
Cmdlet          Get-ADFSClaimsProviderTrust
Cmdlet          Get-ADFSEndpoint
Cmdlet          Get-ADFSProperties
Cmdlet          Get-ADFSProxyProperties
Cmdlet          Get-ADFSRelyingPartyTrust
Cmdlet          Get-ADFSSyncProperties
Cmdlet          New-ADFSClaimRuleSet
Cmdlet          New-ADFSContactPerson
Cmdlet          New-ADFSOrganization
Cmdlet          New-ADFSSamlEndpoint
Cmdlet          Remove-ADFSAttributeStore
Cmdlet          Remove-ADFSCertificate
Cmdlet          Remove-ADFSClaimDescription
Cmdlet          Remove-ADFSClaimsProviderTrust
Cmdlet          Remove-ADFSRelyingPartyTrust
Cmdlet          Revoke-ADFSProxyTrust
Cmdlet          Set-ADFSAttributeStore
Cmdlet          Set-ADFSCertificate
Cmdlet          Set-ADFSCertSharingContainer
Cmdlet          Set-ADFSClaimDescription
Cmdlet          Set-ADFSClaimsProviderTrust
Cmdlet          Set-ADFSEndpoint
Cmdlet          Set-ADFSProperties
Cmdlet          Set-ADFSProxyProperties
Cmdlet          Set-ADFSRelyingPartyTrust
Cmdlet          Set-ADFSSyncProperties
Cmdlet          Set-MsolADFSContext
Cmdlet Update-ADFSCertificate
Cmdlet Update-ADFSClaimsProviderTrust
Cmdlet Update-ADFSRelyingPartyTrust

In diese Liste haben Sich hier aber auch ein fremdes Commandlets eingeschlichen, die nur ein ADFS im Namen haben:

Cmdlet          Set-MsolADFSContext

Dieses ist für Office 365 natürlich hilfreich, um einen ADFS-Server auszuwählen, wenn der ADFS Server auf einem anderen Server installiert ist.

Troubleshooting und Debugging

Zum Thema Troubleshooting hat Microsoft selbst eine sehr gute Anleitung geliefert, auf die ich gerne verweise.

Weitere Links