ADFS Implementierung - ein Beispiel

Microsoft ADFS (Active Directory Federation Services) ist eine Windows-Server-Rolle für föderierte Authentifizierung und Single Sign-on in Unternehmensumgebungen. Eine typische hochverfügbare Beispielinstallation besteht aus zwei internen ADFS-Servern als Farm und zwei Web Application Proxy (WAP) Servern in der DMZ für den externen Zugriff. Dieses Design verbessert Verfügbarkeit, Sicherheit und Skalierbarkeit, weil ADFS nicht direkt aus dem Internet erreichbar ist und WAP als vorgeschalteter Reverse Proxy arbeitet. Im Unternehmenskontext eignet sich dieses Modell besonders für Microsoft-365-Föderation, Claims-basierte Anwendungen und hybride Identitätsarchitekturen.

Was ist Microsoft ADFS? Definition und Beispielinstallation mit 2 ADFS- und 2 WAP-Servern

Microsoft Active Directory Federation Services (ADFS) ist eine Serverrolle in Windows Server, mit der Unternehmen zentrale Authentifizierung, Single Sign-on und föderierte Identitäten für interne und externe Anwendungen bereitstellen können. ADFS wird häufig eingesetzt, wenn Benutzer sich mit ihrem Active-Directory-Konto an Cloud-Diensten, Webanwendungen oder organisationsübergreifenden Plattformen anmelden sollen. In produktiven Umgebungen wird ADFS meist nicht als Einzelserver betrieben, sondern als hochverfügbare Farm mit vorgeschaltetem Web Application Proxy. allskills Training Berlin bieten zu diesem Themenfeld Schulungen für Planung, Aufbau, Administration und Troubleshooting an.

Wann lohnt sich eine ADFS-Installation für Unternehmen?

Eine ADFS-Umgebung lohnt sich vor allem dann, wenn Unternehmen zentrale Authentifizierung für mehrere Anwendungen, externe Partnerzugriffe oder hybride Microsoft-Infrastrukturen bereitstellen möchten. Besonders relevant ist ADFS in Umgebungen mit erhöhten Anforderungen an Identitätskontrolle, Claims-Regeln, Legacy-Anwendungen oder föderierte Anmeldeszenarien. Für neue Umgebungen sollte jedoch immer geprüft werden, ob moderne Alternativen wie Microsoft Entra ID besser geeignet sind, da ADFS heute vor allem in speziellen On-Premises- oder Hybrid-Szenarien genutzt wird.

Wie sieht die Beispielinstallation mit 2 ADFS- und 2 WAP-Servern aus?

Die Beispielarchitektur besteht aus zwei internen ADFS-Servern in einer gemeinsamen Farm und zwei WAP-Servern in der DMZ, die den externen Zugriff absichern. Vor den ADFS- und WAP-Knoten befinden sich jeweils Loadbalancer oder virtuelle IP-Adressen, damit Anfragen hochverfügbar verteilt werden können. Dieses Design ist bewährt, weil externe Clients nur mit den WAP-Systemen kommunizieren, während die eigentliche Authentifizierung geschützt im internen Netzwerk stattfindet.

Beispieltopologie

• Internes Netzwerk

  • adfs01.corp.local
  • adfs02.corp.local
  • Interner Loadbalancer oder DNS-Name, z. B. adfs.corp.local

• DMZ / Perimeter

  • wap01.company.de
  • wap02.company.de
  • Externer Federation-Service-Name, z. B. fs.company.de

• Backend

  • Active Directory Domain Services mit mindestens zwei Domain Controllern
  • Öffentlich vertrauenswürdiges TLS-Zertifikat für fs.company.de auf ADFS und WAP

Welche Komponenten werden technisch benötigt?

Für diese ADFS-Beispielinstallation werden aktuelle Windows-Server-Versionen, ein funktionierendes Active Directory, ein Servicekonto und passende Zertifikate benötigt. Microsoft empfiehlt für ADFS- und WAP-Bereitstellungen eine saubere Netztrennung, aktuelle Sicherheitsupdates und ein konsistentes DNS- sowie Zertifikatskonzept. In vielen mittelgroßen Umgebungen wird die ADFS-Farm mit Windows Internal Database betrieben, weil dieses Modell ohne separaten SQL Server auskommt.

Wie wird die ADFS-Farm mit zwei Servern eingerichtet?

Zuerst wird auf dem ersten Server die ADFS-Rolle installiert und eine neue Farm erstellt. Dabei werden Federation Service Name, Zertifikat und Dienstkonto definiert. Danach wird der zweite Server mit identischem Zertifikat der bestehenden Farm hinzugefügt, damit beide Systeme denselben Authentifizierungsdienst bereitstellen.

Technische Reihenfolge

1. ADFS-Rolle auf adfs01 installieren.
2. Neue Farm erstellen und den Federation Service Namen, z. B. fs.company.de, konfigurieren.
3. gMSA oder Dienstkonto für den ADFS-Service zuweisen.
4. Token-Signing- und Token-Decrypting-Zertifikate prüfen.
5. Auf adfs02 die Rolle installieren und den Server der bestehenden Farm hinzufügen.
6. Interne Erreichbarkeit über einen Loadbalancer oder ein internes DNS-Alias sicherstellen.

Wie werden die zwei WAP-Server eingebunden?

Die beiden WAP-Server werden in der DMZ installiert und jeweils mit der internen ADFS-Farm verbunden. Während der Konfiguration wird auf jedem WAP-Server eine Vertrauensstellung zum Federation Service aufgebaut und dasselbe öffentliche Zertifikat eingebunden. Der externe DNS-Name fs.company.de zeigt anschließend auf den externen Loadbalancer, der die Anfragen auf wap01 und wap02 verteilt.

Technische Einbindung

1. TLS-Zertifikat auf beiden WAP-Servern importieren.
2. Rolle Web Application Proxy installieren.
3. Verbindung zur ADFS-Farm mit administrativen Berechtigungen herstellen.
4. Externe Veröffentlichung für den Federation Service aktivieren.
5. Firewall-Regeln so beschränken, dass Internetzugriffe nur per HTTPS auf WAP möglich sind und WAP ausschließlich per HTTPS mit ADFS kommuniziert.

Wie läuft die Authentifizierung in dieser Architektur ab?

Ein externer Benutzer greift zunächst auf den öffentlichen Federation-Service-Namen zu, der auf die WAP-Systeme zeigt. Der WAP-Server leitet die Anfrage an die interne ADFS-Farm weiter, wo die Authentifizierung gegen Active Directory erfolgt und anschließend ein signiertes Sicherheitstoken ausgestellt wird. Interne Benutzer umgehen den WAP in der Regel und authentifizieren sich direkt gegen die ADFS-Farm über den internen Zugriffspfad.

Vereinfachter externer Ablauf

1. Benutzer ruft eine föderierte Anwendung auf.
2. Die Anwendung leitet zur ADFS-Anmeldung unter fs.company.de um.
3. Der externe Loadbalancer verteilt die Verbindung auf wap01 oder wap02.
4. WAP leitet die Anfrage sicher an adfs01 oder adfs02 weiter.
5. ADFS prüft die Identität gegen Active Directory und stellt ein Token aus.
6. Das Token wird an die Zielanwendung zurückgegeben.

Welche Vorteile hat das 2+2-Design?

Das 2+2-Design erhöht die Ausfallsicherheit, weil weder ein einzelner ADFS-Server noch ein einzelner WAP-Server zum Single Point of Failure wird. Gleichzeitig verbessert sich die Sicherheit, weil die ADFS-Farm nicht direkt im Internet veröffentlicht wird und eine administrative Trennung zwischen internem Identitätsdienst und externer Proxy-Schicht möglich ist. Dieses Modell eignet sich deshalb gut für produktive Unternehmensumgebungen mit hohen Anforderungen an Verfügbarkeit und kontrollierten externen Zugriff.

Welche Sicherheits- und Betriebsaspekte sind wichtig?

Microsoft empfiehlt für ADFS und WAP ein konsequentes Patch-Management, restriktive Firewall-Regeln, Monitoring und eine saubere Zertifikatsverwaltung. Besonders für externe Zugriffe sollte Multi-Faktor-Authentifizierung eingeplant werden, wenn die angebundenen Anwendungen und Richtlinien dies unterstützen. Für Migrationen oder Modernisierungen ist ein stufenweiser Aufbau neuer Knoten innerhalb derselben Farm eine verbreitete und dokumentierte Vorgehensweise.

FAQ

Was ist der Unterschied zwischen ADFS und WAP?

ADFS ist der eigentliche Identitäts- und Föderationsdienst, der Benutzer authentifiziert und Claims-basierte Tokens ausstellt. WAP ist dagegen ein vorgelagerter Reverse Proxy, der ADFS-Dienste und Webanwendungen sicher nach außen veröffentlicht. In einer sicheren Architektur kommunizieren externe Benutzer deshalb nicht direkt mit ADFS, sondern immer zuerst mit WAP.

Warum werden zwei ADFS-Server eingesetzt?

Zwei ADFS-Server erhöhen die Verfügbarkeit des Föderationsdienstes und reduzieren das Risiko eines Ausfalls durch Hardware-, Software- oder Wartungsereignisse. Beide Server gehören zur selben Farm und stellen denselben Federation Service bereit. Dadurch bleibt der Dienst auch bei Wartungsfenstern oder Störungen eines Knotens erreichbar.

Warum sind zwei WAP-Server sinnvoll?

Zwei WAP-Server sorgen dafür, dass externe Zugriffe auch dann weiterlaufen, wenn ein Proxy-Knoten ausfällt oder aktualisiert wird. Zusätzlich lässt sich die Last verteilen, was bei größeren Benutzerzahlen und vielen Authentifizierungsanfragen stabiler arbeitet. Für produktive Umgebungen ist diese Redundanz deutlich robuster als eine Einzelserverbereitstellung.

Reicht die Windows Internal Database für eine ADFS-Farm aus?

Ja, für viele mittelgroße Umgebungen ist die Windows Internal Database ausreichend und wird in der Praxis häufig eingesetzt. Sie unterstützt Farmen mit mehreren ADFS-Knoten, wobei ein Server die Primärrolle übernimmt und die Konfiguration repliziert. Ein separater SQL Server wird meist erst bei sehr großen oder speziellen Anforderungen relevant.

Welche Zertifikate werden benötigt?

Erforderlich ist mindestens ein TLS-Zertifikat für den Federation Service Namen, etwa fs.company.de, das auf ADFS und WAP installiert wird. Zusätzlich verwaltet ADFS eigene Token-Signing- und Token-Decrypting-Zertifikate für die Ausstellung und Absicherung von Sicherheitstokens. Die korrekte Zertifikatsplanung ist kritisch, weil Fehler in diesem Bereich zu Anmeldeproblemen und Vertrauensfehlern führen.

Ist ADFS heute noch zeitgemäß?

ADFS ist weiterhin relevant, wenn lokale Föderation, spezielle Legacy-Szenarien oder bestimmte Hybrid-Anforderungen bestehen. Für reine Cloud- oder Modern-Identity-Szenarien werden heute jedoch häufig Microsoft Entra ID und andere cloudbasierte Identitätsmodelle bevorzugt. Die Entscheidung sollte deshalb immer anhand von Architektur, Compliance, Altanwendungen und Betriebsmodell getroffen werden.