Etwas ungewöhnliches Szenario bei einem Kunden:

ADFS-Farm mit zwei Servern (Windows Server 2019) intern, wir nennen sie nun mal ADFS1 und ADFS2. Zusätzlich zwei Web Application Proxies (WAP1 und WAP2) in der DMZ.

ADFS1 ist der primäre Knoten in diesem Verbund. Aufgrund von Netzwerkanforderungen muss der WAP1 direkt mit ADFS1 sprechen (hosts-Datei) und der WAP2 direkt mit ADFS2. Bei WAP1 ist der Aufbau des Trusts einwandfrei gelaufen. Beim WAP2 schlägt das Hinzufügen zum ADFS mit einem HTTP-Fehler 400 (Bad Request) fehl.

Hintergrund: Der WAP2 erzeugt ein Client-Auth-Zertifikat und schickt dieses über den Endpunkt /adfs/proxy/establishtrust an den ADFS2. Da dieser nicht der primäre Knoten ist, schickt ADFS2 das Zertifikat über den Aufruf von /adfs/proxy/primarywriter/establishtrust an den ADFS1 weiter.

In diesem Aufruf ist nun der Hostname des Ziel-ADFS-Servers enthalten, in diesem Fall also ADFS1. Allerdings schlägt dieser fehl, da der ADFS-Server den Hostname mit den registrierten Hostnames abgleicht. Und wenn man sich mit Get-ADFSFarmInformation die registrierten Servernamen anschaut, steht dort der FQDN drin, also adfs1.firma.de.

Lösung: ADFS2 einreißen und neu zur Farm hinzufügen, aber diesmal mit dem FQDN des ADFS1, also adfs1.firma.de. Danach funktioniert auch der Aufbau des Trusts von WAP2 über den Stellvertreter ADFS1.

Und wo findet man diesen Fehler: Im AD FS Tracing des Event-Logs (das muss aktiviert werden) findet sich in diesem Fall eine Informations-Meldung mit ID 54:
“HTTPListener: Unexpected exception: The host name adfs1 in the incoming request did not match the AD FS host name.”

Merke: ADFS-Nodes immer mit FQDN des Primary Nodes hinzufügen.