22.03.2024, aktualisiert um 22:14:14 Uhr

2264

Microsoft ADFS Server 2022 Cluster Farm Konfiguration

Liebe Administrator Gemeinde,

ich benötige mal wieder einen Denkanstoß.

Folgendes Vorhaben soll realisiert werden:

Es sollen zwei virtuelle Windows Server 2022 auf einem VMWare Cluster bereitgestellt werden, welche die Rolle "Active Directory Federation Services" inne halten. Diese beiden Systeme sollen als Cluster fungieren, sodass bei Windows Updates, Neustart oder Ausfall eines ADFS Server eine SSO Anmeldung weiterhin möglich ist.

Was ist bisher konfiguriert:
Die zwei virtuellen Server sind installiert und mit der Rolle "ADFS" ausgestattet.
Die entsprechenden SSL Zertifikate sind auf den Systemen publiziert und die ersten Systemen können bereits per SAML mit dem ADFS Verbund sprechen.

ADFS Server Topologie:

ADFS01
IP: 10.192.31.41/24
DNS-Name: AS-ADFS01

ADFS02
IP: 10.192.31.42/24
DNS-Name: AS-ADFS02

SQL01 (SQL Server 2019 Standard)
IP: 10.190.11.10/24
DNS-Name: DB-SQL01

DNS Alias für den Zugriff auf den ADFS Verbund:
adfs.ad.unternehmen.de
Diese zeigt im DNS aber aktuell als CNAME nur auf AS-ADFS01

Thema 1 über das wir uns den Kopf zerbrechen:
In der AD FS Konsole -> Rechtsklick auf "AD FS" -> Verbundsdiensteigenschaften
Hier trage ich einen Anzeigenamen ein.
Ebenfalls muss ein Verbunddienstname und ein Bezeichner des Verbundsdiensts gefelgt werden.

Nun fangen die Probleme an...
Auf beiden Systemen ist es aktuell wie folgt konfiguriert:

Anzeigename: SSO | Firmenname
Verbunddienstname: adfs.ad.unternehmen.de
Bezeichner des Verbunddiensts: http://adfs.ad.unternehmen.de/adfs/services/trust

Ist das soweit korrekt oder müssen da die lokalen Hostnames der Systeme rein?

Thema 2:
Wir realisieren wir einen HA der beiden Systeme?
Im Internet findet man den Hinweis auf die Rolle "Windows Failover Cluster".
Wir betreiben intern aber auch ein Citrix ADC Netscaler paar, welches bereits Loadbalancing Dienste zur Verfügung stellt.

Grundsätzlich erstelle ich auf dem Netscaler die Server, daraus eine ServiceGroup und einen entsprechenden Loadbalancer mit der IP-Adresse: 10.197.22.98/24

Wenn ich nun den CNAME Eintrag "adfs.ad.unternehmen.de" als A-Eintrag auf diese IP-Adresse anlegen habe ich die halbe miete.
Aber wie werden dann die ADFS Server korrekt angesprochen?
In beiden Systemen ist als Verbunddienstname ja "adfs.ad.unternehmen.de" konfiguriert....

Im Internet findet man leider nur spärliche Informationen zum Microsoft ADFS Server 2022.
Wenn man was brauchbares findet, fehlt mir der "HA / Cluster" Part.

Hat hier vielleicht jemand den korrekten Weg oder einen Denkanstoß für uns?

Ziel soll es sein, das ein Loadbalancer / Cluster Service auf den Namen "adfs.ad.unternehmen.de" lauscht und die Anfragen entsprechend auf beide ADFS Server aufteilt. Bei der Kommunikationsunterbrechung zu einem ADFS Server, soll dieser natürlich keine Anfragen mehr erhalten.

Aktuell funktioniert der Verbund bereits, doch sobald wir den AS-ADFS01 neu starten / herunterfahren ist eine SSO Anmeldung am vCenter z.B. schon nicht mehr möglich.

Der ADFS Server soll aktuell rein intern erreichbar sein und diverse Dienste / Anwendungen per SSO bedienen.
Im späteren step kommt vielleicht noch ein ADFS Proxy / WAP in der DMZ hinzu, damit z.B. auch unsere Nextcloud von extern per ADFS arbeiten kann.

Vielen Dank für's lesen und schon einmal ein schönes Wochenende

Edit 1:
Noch eine Randfrage...
Im Windows Eventlog unter "Serverrollen -> ADFS" sind aktuell im 5 Sekunden Takt folgende Meldungen zu sehen.
Event ID: 1021
Benutzer: DOMAIN\gmsa_adfs

Fehler bei der OAuth-Tokenanforderung. 

Zusätzliche Daten 

Ausnahmedetails: 
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthJWTBearerException: MSIS9426: Es wurde eine ungültige OAuth-JWT-Trägeranforderung empfangen. Die JWT-Trägernutzlast muss "scope" enthalten.  
   bei Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateJWTBearer()
   bei Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateCore()

Vielleicht hat dazu auch jemand noch eine Idee?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 31041864406

Url: https://administrator.de/contentid/31041864406

Ausgedruckt am: 21.11.2024 um 18:11 Uhr

5 Kommentare

Neuester Kommentar

Moin,

ADFS Server Topologie:

Was soll ein hochverfügbarer AD FS Service bringen, wenn der SQL-Server ein Single Node System ist. Du verlagerst das Problem vom Frontend ins Backend. Fehler #1.

DNS Alias für den Zugriff auf den ADFS Verbund:

Fehler #2. Niemals in DNS mit einem Alias arbeiten, sondern mit einem A und PTR Eintrag für den FQDN des AD FS Clusters.

Auf beiden Systemen ist es aktuell wie folgt konfiguriert:

Fehler #3. Wenn du beide Nodes unabhängig von einander konfigurieren kannst (sprich Änderungen sind nicht synchron in der MMC des jeweiligen Server zu shen) ist es kein AD FS Cluster und nutzt damit auch nicht keine gemeinsamen SQL Datenbanken. Gehe zurück auf Anfang.

Wir realisieren wir einen HA der beiden Systeme?
Im Internet findet man den Hinweis auf die Rolle "Windows Failover Cluster".
Wir betreiben intern aber auch ein Citrix ADC Netscaler paar, welches bereits Loadbalancing Dienste zur Verfügung stellt.

Wenn du einen echten L4 LB schon hast, nutze diesen. Der WSFC ist für arme und schwäbische Unternehmen erfunden worden. Funktioniert, aber ist einem LB funktional weit unterlegen.

Die entsprechenden SSL Zertifikate sind auf den Systemen publiziert

Fehler #4. Es muss auf beiden AD FS Server das identische (gleicher Fingerprint) SSL Zertifikat eingespielt werden. Danach kann das SSL Zertifikat den Diensten problemlos zugewiesen werden. Wenn du bisher zwei verschiedene SSL-Zertifikat installiert hast ist das ein weiterer Hinweis, dass es kein AD FS Cluster ist.

Aber wie werden dann die ADFS Server korrekt angesprochen?

Mit dem FQDN welcher du als Verbundname definierst hat. Der FQDN, welcher als A-Record definiert ist, zeigt auf die IP-Adresse, welche du auf dem LB eingerichtet hast.

Im Internet findet man leider nur spärliche Informationen zum Microsoft ADFS Server 2022.

Ich finde eine Menge Links, leider auch viel Mist. Versteife dich nicht auf die Version 2022.

Aktuell funktioniert der Verbund bereits, doch sobald wir den AS-ADFS01 neu starten / herunterfahren ist eine SSO Anmeldung am vCenter z.B. schon nicht mehr möglich.

Nochmals in Hinweis, dass es kein vollwertiger AD FS Cluster ist.

Im Windows Eventlog unter "Serverrollen -> ADFS" sind aktuell im 5 Sekunden Takt folgende Meldungen zu sehen.

Deutsche Installation kannst du bei AD FS knicken. Da suchst du die Stecknadel im Heuhaufen. Stelle die Kisten auf Englisch und dann findest du den Fehlermeldungen auch entsprechende Treffer.

Im späteren step kommt vielleicht noch ein ADFS Proxy / WAP in der DMZ hinzu, damit z.B. auch unsere Nextcloud von extern per ADFS arbeiten kann.

Ich bin mir nicht sicher, ob das eine gute Idee. Weil es fehlen dir wohl aktuell die Grundlagen für AD FS. Ich bin mal gespannt wie einer sicherer, stabiler Betrieb im LAN aussehen soll (Stichwort Golden SAML). Weil nur ein AD FS zu installieren, heißt leider nicht, dass es auch ein sicherer Betrieb ist. Bei Erreichbarkeit über das Internet steigt das Gefahren Potenzial mehrfach.

Gruß,
Dani

Guten Abend Dani,

vielen Dank für deine Antwort.
Wie immer sehr ausführlich und zielführend, großen Dank für deine Unterstützung.

Zitat von @Dani:

Moin,

ADFS Server Topologie:

Was soll ein hochverfügbarer AD FS Service bringen, wenn der SQL-Server ein Single Node System ist. Du verlagerst das Problem vom Frontend ins Backend. Fehler #1.

Temporär arbeiten wir erst einmal nur mit einem einzelnen SQL-Server.
Sobald das System "Produktiv" geht und entsprechend allen Endbenutzern zur Verfügung steht, wird die Datenbank auf ein SQL Server Cluster auf einem anderem VMWare Cluster umziehen.
Wir probieren und vorab mit den "ersten Gehversuchen".
Aktuell haben wir diverse IT-Backend Systeme per SAML angebunden und probieren uns aus.
z.B. Netbox, 3 VMWare vCenter, Zabbix Monitoring, Wiki,js
In Zukunft soll der ADFS für Industrie Software zum Einsatz kommen, welche als IDM "Keycloak" verwendet.
Unsere Benutzer arbeiten derzeit mit diversen "betagten" .net Anwendungen, welche Sukzessiv auf Webanwendungen umgestellt werden. Es handelt sich um einen 24/7 Schichtbetrieb und die Kollegen wollen nicht 30x am Tag Ihre Anmeldeinformationen eingeben. Daher der Ansatz des ADFS mit SSO funktionalität.

DNS Alias für den Zugriff auf den ADFS Verbund:

Fehler #2. Niemals in DNS mit einem Alias arbeiten, sondern mit einem A und PTR Eintrag für den FQDN des AD FS Clusters.

Super Hinweis an der Stelle. Wird auch direkt umgesetzt.

Auf beiden Systemen ist es aktuell wie folgt konfiguriert:

Sobald ich eine Änderung am AS-ADFS01 durchführe, ist diese auch in der Konsole auf dem AS-ADFS02 ersichtlich.
Die Farm wurde gemeinsam mit einem IT Dienstleister eingerichtet. Am Ende des Tages möchten wir aber selber Erfahrungen damit sammeln und uns nicht immer nur auf die ext. Dienstleister verlassen. Know How sollte schon intern vorliegen. Für mich arbeitet der Verbund daher korrekt.

Wenn du einen echten L4 LB schon hast, nutze diesen. Der WSFC ist für arme und schwäbische Unternehmen erfunden worden. Funktioniert, aber ist einem LB funktional weit unterlegen.

Hast du ggf. eine brauchbare Anleitung Griffbereit?
Für den F5 BigIP habe ich was in die Richtung gefunden, aber bei dem Thema Citrix Netscaler sieht es mau aus.
Mir geht es dabei primär z.B. um die Monitoring Rule...ich probiere mich Montag mal an einer einfachen HTTP 200 Meldung.

Die entsprechenden SSL Zertifikate sind auf den Systemen publiziert

Auf beiden Systemen ist selbstverständlich das gleiche Zertifikat gebunden. (Ich hatte von der Mehrzahl gesprochen, weil es ja auch die Token Signatur Zertifikate noch gibt)

Aber wie werden dann die ADFS Server korrekt angesprochen?

Mit dem FQDN welcher du als Verbundname definierst hat. Der FQDN, welcher als A-Record definiert ist, zeigt auf die IP-Adresse, welche du auf dem LB eingerichtet hast.

Soweit verstanden und vorgemerkt für den Loadbalancer auf Citrix Netscaler Ebene.

Im Internet findet man leider nur spärliche Informationen zum Microsoft ADFS Server 2022.

Ich finde eine Menge Links, leider auch viel Mist. Versteife dich nicht auf die Version 2022.

Grundsätzlich fehlen halt die Erfahrungen auch mit früheren Versionen...daher war uns nicht bewusst, ob es gravierenden Unterschiede zwischen z.B. Server 2016 / Server 2019 und 2022 gibt. Im Netz findet man das meiste für Windows Server 2012R2. Teilweise weichen die Benamungen in der Konsole vom 2022 ab.

Aktuell funktioniert der Verbund bereits, doch sobald wir den AS-ADFS01 neu starten / herunterfahren ist eine SSO Anmeldung am vCenter z.B. schon nicht mehr möglich.

Nochmals in Hinweis, dass es kein vollwertiger AD FS Cluster ist.

Aktuell definitiv nicht, weil der DNS Name ja als CNAME auf den ersten ADFS-Server zeigt. Wenn der aus ist, geht natürlich eine Anmeldung nicht mehr.

Im Windows Eventlog unter "Serverrollen -> ADFS" sind aktuell im 5 Sekunden Takt folgende Meldungen zu sehen.

Deutsche Installation kannst du bei AD FS knicken. Da suchst du die Stecknadel im Heuhaufen. Stelle die Kisten auf Englisch und dann findest du den Fehlermeldungen auch entsprechende Treffer.

Ist auch mein favorisierter Weg. Grundsätzlich installiere ich Serversysteme als "Core" und mit Englischer Iso.
Leider schreien meine Kollegen dann immer auf, die "Windows Klicki Bunti" favorisieren und im Englischen nicht sehr bewandert sind. Werde mal versuchen das Englische Sprachpaket nach zu installieren, vielleicht hilft das ja schon

Im späteren step kommt vielleicht noch ein ADFS Proxy / WAP in der DMZ hinzu, damit z.B. auch unsere Nextcloud von extern per ADFS arbeiten kann.

Daher unternehmen wir zur Zeit die ersten "Gehversuche" nur im LAN und mit Anwendungen, die lediglich in der IT zum Einsatz kommen. Wir möchten A) nicht, dass unsere Benutzer als "Testkaninchen" verwendet werden und B) potentielle Sicherheitslücken aufmachen.

Ob wir den WAP / ADFS Proxy wirklich umsetzen steht auch noch zur Diskussion.
Wir haben lediglich unsere Nextcloud per Netscaler nach außen gegeben (auch nur mit MFA erreichbar) ebenso wie unser Citrix Gateway für Virtual Apps and Desktops.
Am Ende des Tages, werden wir in Zukunft vermutlich alle Logins über unser Cisco ISE Cluster schicken, damit lediglich ein System überprüft werden muss.
Es war der Wunsch von weiter oben die Nextcloud dann von extern auch per ADFS anzusprechen, um die "User Experience" auf allen Systemen gleich zu gestalten.
Es greifen aber im Monat (wenn es Hoch kommt) 8-10 Personen von extern auf die Nextcloud zu. Das sind im Regelfall Dienstleister, die SPS Firmware Updates in unser Netz laden oder Behörden, welchen wir Logdateien bereit stellen.

Gruß,
Dani

Grüße

Moin,

Hast du ggf. eine brauchbare Anleitung Griffbereit?

Ne, Citrix kommt bei uns nichts in Haus.

Grundsätzlich fehlen halt die Erfahrungen auch mit früheren Versionen...daher war uns nicht bewusst, ob es gravierenden Unterschiede zwischen z.B. Server 2016 / Server 2019 und 2022 gibt.

Die Doku von Microsoft ist keine Option für euch (gewesen)?

Für den F5 BigIP habe ich was in die Richtung gefunden, aber bei dem Thema Citrix Netscaler sieht es mau aus.

Das Produkt spielt doch dabei keine Rolle. Wichtig ist doch, was und wie du es überwachen möchtest. Da gibt es bei AD FS nicht all zu viele Möglichkeiten.

Auf beiden Systemen ist selbstverständlich das gleiche Zertifikat gebunden. (Ich hatte von der Mehrzahl gesprochen, weil es ja auch die Token Signatur Zertifikate noch gibt)

In diesem Fall habe ich nichts gesagt. Doch nutzen für Communication, Signing und Decryption ein und das selbe Zertifikat. Hier verschiedene zu nutzen, macht in 95% der Fälle keinen Sinn.

Leider schreien meine Kollegen dann immer auf, die "Windows Klicki Bunti" favorisieren und im Englischen nicht sehr bewandert sind.

Dafür gibt es Kurse.

Wir haben lediglich unsere Nextcloud per Netscaler nach außen gegeben

Maßgeblich ist doch, ob aktuell das AD angebunden und damit im Worst Case auslesen werden kann.

Am Ende des Tages, werden wir in Zukunft vermutlich alle Logins über unser Cisco ISE Cluster schicken, damit lediglich ein System überprüft werden muss.

Welche Vorteile seht ihr im Cisco ISE im Vergleich zu AD FS? Weil wenn ich mit den Support anschauen, ist der Cisco Support einfach zäh und oftmals schwierig. Bei Microsoft hingegen geht es schnell und meistens gleich zum Senior Support Engineer. Weil ein 24x7 Service sollte dann auch alle Aspekte abdecken, auch den Support Fall durch den Hersteller.

Gruß,
Dani

Zitat von @Dani:

Moin,

Hast du ggf. eine brauchbare Anleitung Griffbereit?

Ne, Citrix kommt bei uns nichts in Haus.

Wie kommt's?

Grundsätzlich fehlen halt die Erfahrungen auch mit früheren Versionen...daher war uns nicht bewusst, ob es gravierenden Unterschiede zwischen z.B. Server 2016 / Server 2019 und 2022 gibt.

Die Doku von Microsoft ist keine Option für euch (gewesen)?

Jein.
A) nicht genug recherchiert
B) nehme ich lieber Erfahrung von Gleichgesinnten, als mich auf "Theorie" zu verlassen.

Für den F5 BigIP habe ich was in die Richtung gefunden, aber bei dem Thema Citrix Netscaler sieht es mau aus.

Das Produkt spielt doch dabei keine Rolle. Wichtig ist doch, was und wie du es überwachen möchtest. Da gibt es bei AD FS nicht all zu viele Möglichkeiten.

Das ist korrekt, nur der Netscaler hat bei seiner Syntax manchmal so eine Angewohnheiten...
Ich werde es mal mit folgendem Monitor im Netscaler probieren:

Type:
HTTP-ECV
Send String: 
GET /federationmetadata/2007-06/federationmetadata.xml"  
Receive String: 
adfs.ad.unternehmen.de/adfs/services/trust

Auf beiden Systemen ist selbstverständlich das gleiche Zertifikat gebunden. (Ich hatte von der Mehrzahl gesprochen, weil es ja auch die Token Signatur Zertifikate noch gibt)

In diesem Fall habe ich nichts gesagt. Doch nutzen für Communication, Signing und Decryption ein und das selbe Zertifikat. Hier verschiedene zu nutzen, macht in 95% der Fälle keinen Sinn.

Wir differenzieren zwischen "Service Communication" und "Token Decrypt & signing.
Hat uns der Dienstleister zu geraten...

Leider schreien meine Kollegen dann immer auf, die "Windows Klicki Bunti" favorisieren und im Englischen nicht sehr bewandert sind.

Dafür gibt es Kurse.

Dafür muss auch der Wille da sein...

Wir haben lediglich unsere Nextcloud per Netscaler nach außen gegeben

Maßgeblich ist doch, ob aktuell das AD angebunden und damit im Worst Case auslesen werden kann.

Gebe ich dir vollkommen recht. Wir versuchen auch immer den Ansatz, dass nur Benutzer per LDAP in Drittanbieter Software landen, die 1:1 per Filter geladen werden.

Am Ende des Tages, werden wir in Zukunft vermutlich alle Logins über unser Cisco ISE Cluster schicken, damit lediglich ein System überprüft werden muss.

Wir sind als Bundes Behörde unterwegs und entsprechend greifen wir auf Rahmenverträge zurück.
Bei Cisco sind wir mit dem 24/7 Service mehr als zufrieden. (Cisco HyperFlex, Cisco Catalysts, Cisco Nexus, Cisco FirePowers, DNA Center, ISE, Anyconnect, Cybervision)
Bei Microsoft muss der "Servicekontakt" immer unsere Zentrale aufgebaut werden, was teilweise sehr langjährig ist, da kein 24/7 Service besteht. Wir agieren in unserem Bundesland relativ autark und kommen mit Cisco daher super aus.
Ebenfalls dienst das ISE Cluster bei uns als zentrales Netzwerk-, Security-, Identiy- und Accessmanagement System.
Daher war der Vorschlag von extern und auf ein System zu fokussieren und so den Schulungs- / Administrationsaufwand geringer halten.

Klappt wieder nur in der Theorie, weil die Authentifizierungsdienste auf der ISE erst noch vollständig integriert werden müssen. Vor 2 Jahren hatten wir noch ne Sophos Firewall mit "Alllow Any" im Betrieb. Daher kann ich immer nur "Teilerfolge" verzeichnen und sagen: Mühsam nähert sich das Eichhörnchen

Dazu kommt : Öffentlicher Dienst...
Ich komme aus der privaten Wirtschaft und falle nach wie vor manchmal vom glauben ab, wie mit IT und vor allem Informationssicherheit umgegangen wird.

Gruß,
Dani

Moin,

Wie kommt's?

gehört hier nicht her.

Jein.
A) nicht genug recherchiert
B) nehme ich lieber Erfahrung von Gleichgesinnten, als mich auf "Theorie" zu verlassen.

nennt sich Faulheit, oder?

Wir differenzieren zwischen "Service Communication" und "Token Decrypt & signing.
Hat uns der Dienstleister zu geraten...

Aus welchen Gründen hat der DL dazu geraten? Sag bitte nicht, weil wir das immer so machen.

Gebe ich dir vollkommen recht. Wir versuchen auch immer den Ansatz, dass nur Benutzer per LDAP in Drittanbieter Software landen, die 1:1 per Filter geladen werden.

Potenzielle Angreifer schert den Filter nicht. Es gibt da andere Wege, um alle Objekte im AD auslesen und damit weitere Angriffsflächen zu Tage zu fördern.

Bei Cisco sind wir mit dem 24/7 Service mehr als zufrieden. (Cisco HyperFlex, Cisco Catalysts, Cisco Nexus, Cisco FirePowers, DNA Center, ISE, Anyconnect, Cybervision)

Es ist die Frage für welche Themen und wie hoch die Messlatte hängst. Den Cisco Jungs muss man leider auch öfters mal Feuer machen.