Hohe Verfügbarkeit für Microsoft Active Directory Federation Services mit NGINX Plus

Mithilfe von Microsoft Active Directory Federation Services (AD FS) können Organisationen, die Anwendungen auf Windows Server hosten, den Single Sign-On (SSO)-Zugriff auf Mitarbeiter vertrauenswürdiger Geschäftspartner über ein Extranet erweitern. Der Austausch von Identitätsinformationen zwischen den Geschäftspartnern wird als Föderation bezeichnet.

In der Praxis bedeutet der Einsatz von AD FS, dass sich Mitarbeiter von Unternehmen in einem Verbund immer nur in ihrer lokalen Umgebung anmelden müssen. Wenn sie auf eine Webanwendung eines vertrauenswürdigen Geschäftspartners zugreifen, übergibt der lokale AD FS-Server ihre Identitätsinformationen in Form eines Sicherheitstokens an den AD FS-Server des Partners. Das Token besteht aus mehreren Ansprüchen , bei denen es sich um einzelne Attribute des Mitarbeiters (Benutzername, geschäftliche Rolle, Mitarbeiter-ID usw.) handelt, die im lokalen Active Directory gespeichert sind. Der AD FS-Server des Partners ordnet die Ansprüche im Token den Ansprüchen zu, die von den Anwendungen des Partners verstanden werden, und ermittelt dann, ob der Mitarbeiter für die angeforderte Art des Zugriffs autorisiert ist.

Für AD FS 2.0 und höher können Sie Hochverfügbarkeit (HA) aktivieren und so die Authentifizierungsdienste für Ihre Anwendungen belastbarer und skalierbarer machen. In einem AD FS HA-Cluster (auch AD FS- Farm genannt) werden mehrere AD FS-Server in einem einzigen Rechenzentrum oder über mehrere Rechenzentren verteilt bereitgestellt. Ein für vollständig aktives HA konfigurierter Cluster benötigt einen Lastenausgleich, um den Datenverkehr gleichmäßig auf die AD FS‑Server zu verteilen. Bei einer Aktiv-Passiv-HA-Bereitstellung kann der Load Balancer ein Failover auf den AD FS-Backup-Server bereitstellen, wenn der primäre Server ausfällt.

In diesem Beitrag wird erläutert, wie NGINX Plus konfiguriert wird, um HA in Umgebungen bereitzustellen, in denen AD FS 3.0 und AD FS 4.0 Server 2012 R2 bzw. Windows Server 2016 ausgeführt wird.

Standard-HA-Topologie für AD FS

In diesem Beitrag wird zur Veranschaulichung eine standardmäßige AD FS-Farmtopologie verwendet. Es handelt sich hierbei weder um eine Empfehlung, noch soll es alle möglichen Bereitstellungsszenarien abdecken. Bei lokalen Bereitstellungen besteht eine Standardfarm aus einem oder mehreren AD FS-Servern im Unternehmensintranet, denen ein oder mehrere Web Application Proxy (WAP)-Server in einem DMZ-Netzwerk vorgeschaltet sind. Die WAP-Server fungieren als Reverse-Proxys, die externen Benutzern den Zugriff auf die im Unternehmensintranet gehosteten Webanwendungen ermöglichen.

WAP verfügt allerdings nicht über eine integrierte Möglichkeit, einen Servercluster zu konfigurieren oder HA zu unterstützen. Daher muss vor den WAP-Servern ein Load Balancer bereitgestellt werden. An der Grenze zwischen DMZ und Intranet wird außerdem ein Load Balancer platziert, um HA für AD FS zu ermöglichen. In einer standardmäßigen AD FS-Farm fungiert die Netzwerklastenausgleichsfunktion (NLB) von Windows Server 2012 und 2016 als Lastenausgleich. Schließlich werden Firewalls typischerweise vor der externen IP-Adresse des Load Balancers und zwischen Netzwerkzonen implementiert.

Verwenden von NGINX Plus in der Standard-HA-Topologie

Wie erwähnt kann NLB den Lastenausgleich für eine AD FS-Farm durchführen. Der Funktionsumfang ist jedoch recht einfach (nur grundlegende Integritätsprüfungen und eingeschränkte Überwachungsfunktionen). NGINX Plus verfügt über viele für HA in AD FS-Produktionsumgebungen wichtige Funktionen und ist dennoch leichtgewichtig.

Bei der Bereitstellung der hier beschriebenen Standardtopologie ersetzt NGINX Plus NLB, um den Datenverkehr für alle WAP- und AD FS-Farmen auszugleichen. Beachten Sie jedoch, dass wir NGINX Plus nicht veranlassen, SSL-Verbindungen für die AD FS-Server zu beenden, da für den ordnungsgemäßen Betrieb von AD FS das tatsächliche SSL-Zertifikat vom WAP-Server angezeigt werden muss (Einzelheiten finden Sie in diesem Microsoft TechNet-Artikel ).

Wir empfehlen, dass Sie in Produktionsumgebungen auch HA für NGINX Plus selbst implementieren. Dies zeigen wir hier jedoch nicht. Anweisungen finden Sie unter „Hochverfügbarkeitsunterstützung für NGINX Plus in lokalen Bereitstellungen“ im NGINX Plus-Administratorhandbuch.

Konfigurieren von NGINX Plus zum Lastenausgleich von AD FS-Servern

Die NGINX Plus-Konfiguration zum Lastenausgleich von AD FS-Servern ist unkompliziert. Wie oben erwähnt, muss ein AD FS-Server das tatsächliche SSL-Zertifikat von einem WAP-Server sehen. Daher konfigurieren wir die NGINX Plus-Instanz an der DMZ-Intranet-Grenze so, dass SSL-verschlüsselter Datenverkehr an die AD FS-Server weitergeleitet wird, ohne ihn zu beenden oder anderweitig zu verarbeiten.

Zusätzlich zu den obligatorischen Anweisungen nehmen wir diese Anweisungen in die Konfiguration auf:

• Zone weist einen Bereich im gemeinsam genutzten Speicher zu, in dem alle NGINX Plus-Arbeitsprozesse auf Konfigurations- und Laufzeitstatusinformationen zu den Servern in der Upstream-Gruppe zugreifen können.
• Hash stellt basierend auf der Quell-IP-Adresse (des Clients) die Sitzungspersistenz zwischen Clients und AD FS-Servern her. Dies ist erforderlich, auch wenn Clients nur eine einzige TCP-Verbindung mit einem AD FS-Server herstellen, da es unter bestimmten Umständen bei einigen Anwendungen zu mehreren Anmeldeumleitungen kommen kann, wenn die Sitzungspersistenz nicht aktiviert ist.
• status_zone bedeutet, dass die NGINX Plus-API Metriken für diesen Server sammelt, die auf dem integrierten Dashboard zur Live-Aktivitätsüberwachung angezeigt werden können ( API und Dashboard werden separat konfiguriert ).

Stream { Upstream adfs_ssl { Zone adfs_ssl 64k ; Server 10.11.0.5:443; # AD FS-Server 1 Server 10.11.0.6:443; # AD FS-Server 2 Hash $remote_addr ; } Server { Statuszone adfs_ssl ; Listen 10.0.5.15:443; Proxy-Pass adfs_ssl; } }

　
Damit der Datenverkehr von den WAP-Servern über NGINX Plus zu den AD FS-Servern fließen kann, müssen wir auch den Namen des Verbunddiensts (in unserem Beispiel fs.example.com ) der IP-Adresse zuordnen, auf der NGINX Plus lauscht. Fügen Sie für Produktionsbereitstellungen einen DNS-Host- A -Eintrag in der DMZ hinzu. Für Testbereitstellungen reicht es aus, einen Eintrag in der Hosts- Datei auf jedem WAP-Server zu erstellen. Das tun wir hier, indem wir fs.example.com in einer Hosts -Datei an 10.0.5.15 binden:

Um zu testen, ob der Datenverkehr von den WAP-Servern die AD FS-Server erreicht, führen wir den Befehl ipconfig /flushdns aus, um DNS zu leeren, und melden uns dann in unserem Browser auf der SSO-Seite https://fs.example.com/adfs/ls/idpinitiatedsignon.htm bei AD FS an:

Konfigurieren von NGINX Plus zum Lastenausgleich von WAP-Servern

Wir konfigurieren jetzt NGINX Plus so, dass die Last von HTTPS-Verbindungen von externen Clients zu den WAP-Servern ausgeglichen wird. Die bewährte Methode sieht vor, dass der Datenverkehr weiterhin SSL-verschlüsselt ist, wenn er die AD FS-Server erreicht. Daher verwenden wir einen von zwei Ansätzen, um NGINX Plus so zu konfigurieren, dass HTTPS-Datenverkehr an die WAP-Server weitergeleitet wird: SSL-Passthrough oder SSL-Neuverschlüsselung.

Konfigurieren von SSL Pass‑Through

Die einfachere Konfiguration besteht darin, dass NGINX Plus SSL-verschlüsselten TCP-Verkehr unverändert an die WAP-Server weiterleitet. Hierzu konfigurieren wir einen virtuellen Server im Streamkontext ähnlich dem vorherigen zum Lastenausgleich der AD FS-Server .

Hier lauscht NGINX Plus auf externem Datenverkehr auf einer anderen eindeutigen IP-Adresse, 10.0.5.100. Für Produktionsumgebungen muss der externe FQDN der veröffentlichten Anwendung in Form eines DNS-Host -A- Eintrags in der öffentlichen Zone auf diese Adresse verweisen. Zum Testen genügt ein Eintrag in der Hosts- Datei Ihres Client-Rechners.

Notiz: Wenn Sie zusätzliche HTTPS-Dienste im Stream -Kontext so konfigurieren möchten, dass sie auf derselben IP-Adresse wie dieser Server lauschen, müssen Sie die Server Name Indication (SNI) mithilfe der Direktive „ssl_preread“ mit einer Zuordnung aktivieren, um den Datenverkehr korrekt an verschiedene Upstreams weiterzuleiten. Dies geht über den Rahmen dieses Blogs hinaus, aber die NGINX-Referenzdokumentation enthält Beispiele .

stream { upstream wap {
zone wap 64k;
server 10.11.0.5:443; #WAP-Server 1
server 10.11.0.6:443; #WAP-Server 2
least_time connect;
}

server {
status_zone wap_adfs;
listen 10.0.5.100:443;
proxy_pass wap;
}
}

Konfigurieren der HTTPS-Neuverschlüsselung

Als Alternative zum SSL-Pass-Through können wir die vollständigen Layer-7-Funktionen von NGINX Plus nutzen, indem wir einen virtuellen Server im HTTP- Kontext so konfigurieren, dass er HTTPS-Verkehr akzeptiert. NGINX Plus beendet die HTTPS-Verbindungen von Clients und erstellt neue HTTPS-Verbindungen zu den WAP-Servern.

Die Zertifikats- und geheimen Schlüsseldateien example.com.crt und example.com.key enthalten den externen FQDN der veröffentlichten Anwendung in der Eigenschaft „Common Name“ ( CN ) oder „Subject Alternative Name“ ( SAN ). In diesem Beispiel lautet der FQDN fs.example.com .

Die Anweisungen proxy_ssl_server_name und proxy_ssl_name aktivieren den erforderlichen SNI-Header (Server Name Indication) und geben einen Remote-Hostnamen an, der im SSL Client Hello gesendet werden soll. Der Header muss mit dem externen FQDN der veröffentlichten Anwendung übereinstimmen, in diesem Beispiel fs.example.com .

Wir verwenden proxy_set_header -Direktiven, um relevante Informationen an die WAP-Server zu übergeben und sie auch in den Protokollen zu erfassen:

• Der X-Real-IP- Header enthält die Quell-IP-Adresse (des Clients), wie sie in der Variable $remote_addr erfasst ist.
• X-Forwarded-For überträgt diesen Header aus der Client-Anforderung, wobei die IP-Adresse des Clients daran angehängt ist (oder nur diese Adresse, wenn die Client-Anforderung nicht über den Header verfügt).
• Der x-ms-proxy- Header gibt an, dass der Benutzer über einen Proxyserver weitergeleitet wurde, und identifiziert die NGINX Plus-Instanz als diesen Server.

Zusätzlich zu den hier gezeigten Anweisungen bieten NGINX und NGINX Plus eine Reihe von Funktionen, die die Leistung und Sicherheit von SSL/TLS verbessern können. Weitere Informationen finden Sie in unserem Blog .

http { Upstream Wap { Zone Wap 64k; Server 10.0.5.11:443; Server 10.0.5.10:443; Least_Time-Header; } Server { Listen 10.0.5.100:443 SSL; Statuszone fs.example.com; Servername fs.example.com; SSL-Zertifikat /etc/ssl/example.com/example.com.crt; SSL-Zertifikatsschlüssel /etc/ssl/example.com/example.com.key; Standort / { Proxy-Passwort https://wap; # „https“ aktiviert die erneute Verschlüsselung von Proxy-SSL-Servername auf ; Proxy-SSL-Name $host ; Proxy-Set-Header Host $host; Proxy-Set-Header X-Real-IP $remote_addr; proxy_set_header X-Weitergeleitet-Für $proxy_add_x_forwarded_for; proxy_set_header x-ms-proxy $server_name; } } }

Konfigurieren von NGINX Plus in einer Topologie ohne WAP-Server

Wenn Sie externen Clients den Zugriff auf Ihre AD FS-Server ermöglichen, empfiehlt es sich, den externen Datenverkehr an der Grenze zwischen der DMZ und dem Unternehmensintranet zu beenden und externe Authentifizierungsversuche durch Einfügen des Headers „x-ms-proxy“ zu identifizieren. WAP-Server führen beide Funktionen aus, aber wie im vorherigen Abschnitt konfiguriert, tut dies auch NGINX Plus.

Für einige Anwendungsfälle sind WAP-Server nicht erforderlich, beispielsweise wenn Sie keine erweiterten Anspruchsregeln wie IP-Netzwerk und Vertrauensebenen verwenden. In solchen Fällen können Sie WAP-Server eliminieren und NGINX Plus an der Grenze zwischen DMZ und Intranet platzieren, um Anfragen an interne AD FS-Server zu authentifizieren. Dadurch reduzieren sich Ihre Hardware-, Software- und Betriebskosten.

Diese Konfiguration ersetzt die für die Standard-HA-Topologie . Sie ist nahezu identisch mit der HTTPS-Neuverschlüsselungskonfiguration zum Lastenausgleich von WAP-Servern, allerdings verteilt NGINX Plus hier die Last externer Anfragen direkt auf die AD FS-Server im internen Netzwerk.

Upstream adfs { Zone adfs 64k;
Server 192.168.5.5:443; # AD FS-Server 1
Server 192.168.5.6:443; # AD FS-Server 2
least_time-Header;
}

Server {
Listen 10.0.5.110:443 ssl;
Statuszone adfs_proxy;
Servername fs.example.com;
SSL-Zertifikat /etc/ssl/example.com/example.com.crt;
SSL-Zertifikatschlüssel /etc/ssl/example.com/example.com.key;

Standort / {
Proxy-Passwort https://adfs;
Proxy-SSL-Servername ein;
Proxy-SSL-Name $host;
Proxy-Set-Header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Weitergeleitet-Für $proxy_add_x_forwarded_for;
proxy_set_header x-ms-proxy $server_name;
}
}

Testen Sie NGINX Plus in Ihrer AD FS-Bereitstellung – starten Sie noch heute eine kostenlose 30-Tage-Testversion oder kontaktieren Sie uns , um Ihren Anwendungsfall zu besprechen.