Eigentlich sind die Active-Directory-Verbunddienste (AD Federation Services, ADFS) in ihrem Einsatzbereich zunehmend rückläufig, gibt es doch mit PHS oder PTA gute Alternativen zur Authentifizierung lokaler Benutzer gegen das Azure Active Directory. Auch die Verwendung von Enterprise-Applikationen im Azure AD – statt zum Beispiel "Relying Party Trusts" in ADFS – führt dazu, dass die Verbunddienste zunehmend eine nachgelagerte Rolle spielen.

Viele Unternehmen setzen jedoch nach wie vor darauf, denn es handelt sich um einen seit Jahren etablierten Dienst, der sich nicht einfach nebenbei abschalten lässt. ADFS-Umgebungen mit einer großen Anzahl an Vertrauensstellungen sind in gewachsenen Landschaften keine Seltenheit. ADFS bietet auch eine gute Koexistenz in der Microsoft-Authentifizierungslandschaft und kann eine strategisch wichtige Bedeutung im Identity-Portfolio haben.

Zahlreiche Abhängigkeiten
Die Implementierung von ADFS unterliegt zahlreichen Abhängigkeiten, die bei Nichtbeachtung den Betrieb stören können. Da ist zum einen das Active Directory, in dem sich das Dienstkonto befindet, unter dessen Kontext der jeweilige ADFS-Service läuft. Der Account hat zwar keine speziellen Berechtigungen, die es zu überwachen gilt, aber ein gesperrtes Konto kann dennoch für Unmut sorgen. Gleiches gilt für die im AD verwalteten Service Principal Names (SPN). Läuft hier etwas schief, weil etwa ein SPN doppelt registriert wurde, dann ist die Fehlersuche meist schwierig. Eine bis dato intakte ADFS-Farm sorgt dann aus heiterem Himmel und scheinbar ohne Anlass für teilweise massive Probleme.

Darüber hinaus sind Zertifikate eine der häufigsten Fehlerquellen im Federation-Server-Umfeld. Sie sind nicht ewig gültig und ein Dienst oder eine Vertrauensstellung, die auf einem Zertifikat basiert, ist eben nur so lange intakt, wie das Zertifikat vorzeigbar ist. Die Liste der Abhängigkeiten ist aber noch länger: Egal ob die Verbunddienste in einer Farm laufen – also die Konfigurationen auf einem SQL-Server liegen – oder ob eine WID (Windows Internal Database, ehemals SQL Express) zum Einsatz kommt: Die SQL-Datenbank ist in jedem Fall wichtig. Zwar speichert ADFS keinerlei Anwenderdaten, sondern nur Konfigurationsdaten, und wenn der SQL-Server Probleme hat, werden trotzdem noch SAML-Token ausgestellt.

Haben Sie sich in der Farm aber beispielsweise für den Einsatz einer WID entschieden und der primäre ADFS-Server geht mit einem Defekt in die Knie, sind Änderungen an der Konfiguration der Farm nicht mehr möglich, obwohl ADFS erst einmal weiter authentifiziert. Dieses Problem taucht ohne Monitoring somit erst später auf.

Bei der Menge an Abhängigkeiten ist es schwierig, etwaige Fehler zu lokalisieren. Problembild und Ursache liegen oft weit auseinander. Umso wichtiger ist es daher, sich in ruhigen Zeiten Gedanken über das Monitoring zu machen.

Monitoring mit AD Connect Health
Sollten Sie Azure AD Connect für die Synchronisation verwenden und gleichzeitig Azure AD Connect Health für die Überwachung, kann es sinnvoll sein, für das Monitoring das Health Dashboard für ADFS in Erwägung zu ziehen. Dieses bietet einen zentralen Ort zur Überwachung. Der Vorteil dieses Ansatzes ist es, dass sich neben dem Monitoring von ADFS auch Nutzungsdaten für die Analyse auswerten lassen. Sie können diverse Metriken grafisch über einen Zeitraum darstellen und haben so einen guten Eindruck bezüglich der Auslastung der ADFS-Farm.

Im Dashboard finden Sie die Option "Benachrichtigungseinstellungen", um bei Problemen E-Mails an angegebene Empfänger zu versenden. Recht komfortabel ist hier die Option, pauschal alle "globalen Administratoren" zu adressieren. So bleibt es Ihnen erspart, mit spezifischen E-Mail-Adressen zu hantieren. Das ist besonders sinnvoll für Admin-Teams, wenn dort Mitarbeiter häufig wechseln.

Das Installationspaket für den Agenten finden Sie mit den entsprechenden Schlagworten bei Microsoft auf den Downloadseiten und die Installation ist mit wenigen Mausklicks durchgeführt. Spannend wird es bei der Registrierung des Agenten, damit er mit Azure kommunizieren kann, Hierfür benutzen Sie das Cmdlet "Register-AzureADConnect-HealthADFSAgent".

Die Meldungen in der PowerShell-Konsole geben Hinweise darauf, ob es Probleme bei der Registrierung gegeben hat und ob der Agent Monitoringdaten zu Azure senden kann. Schwierigkeiten kann es zum Beispiel geben, wenn das "Audit" auf dem Server nicht aktiviert ist. Neben dem genannten Cmdlet für die Registrierung hält das mit dem Agenten installierte PowerShell-Modul "ADHealth-ADFS" noch ein paar weitere überaus hilfreiche Kommandos parat. So können Sie beispielsweise mittels "Test-Azure -ADConnectHealthConnectivity" dem Health-Agenten auf den Zahn fühlen, sollten Sie nicht sicher sein, ob das Monitoring wirklich intakt ist.

Übrigens dient der Agent sowohl zur Installation auf ADFS-Servern als auch für die Webanwendungs-Proxyserver (WAP) ihrer Farm. Weitere Details zum Health-Agenten finden Sie in einem Microsoft-Artikel.

ln/Klaus Bierschenk

Im zweiten Teil der Workshopserie geht es um den Server-Manager als Schaltzentrale und das Eventlog als Datenbasis.