Heute hat mich ein guter bekannter ganz aufgelöst angerufen:

Warum zeigt unser neuer Load Balancer alls AD FS Knoten down an?

Die Antwort ist so einfach wie kompliziert: AD FS (Active Directory Federation Services) antwortet nicht wie die Load Balancer es erwarten, deswegen markieren diese alle Knoten als Down. Wenn man sich den Traffic genauer ansieht (Zum Beispiel mit WireShark) sieht man, dass die AD FS Server einen SSL Protokoll Error zurückgeben. Das ganze hat damit zu tun, wie Microsoft das ganze SSL hHandling für SNI (Server Name Indication) in AD FS implementiert hat. Das Microsoft WAP (Web Application Proxy) kommt im Gegensatz zu den meisten Load Balancen damit dann auch zurecht.

Das folgende in einer Shell (elevated, also als Administrator gestartet) eingeben:

netsh
http add sslcert ipport=...:443 certhash=*** appid={5d89a20c-beab-4389-9447-324788eb944a} certstorename=MY
http add sslcert ipport=...:49443 certhash=*** appid={5d89a20c-beab-4389-9447-324788eb944a} certstorename=MY

Das *** muss noch gegen eueren Zertifikats Hash getauscht werden und die APPID sollte zur Sicherheit auch noch geprüft werden. Das geht ganz einfach wie folgt: netsh http show sslcert

Die Instanz auf Port 443 ist das normale AD FS (also auch das was der Benutzer ab und an zu sehen bekommt), aus Port 49443 wir die Device Registrierung behandelt. Wenn ihr also keine Device Registrierung über AD FS nutzen wollt, dann könnt ihr euch das sparen, es schadet aber auch nicht!

Wichtig ist, dass die Befehle oben auf allen Knoten einer AD FS Farm ausgeführt werden müssen! Diese Information wird nicht zwischen den Knoten einer Farm geteilt.

Der Load Balancer sollte innerhalb kürzester Zeit (also nach dem nächsten Probe) die Knoten als Verfügbar anzeigen und Ihnen auch Traffic zukommen lasen.

Ich habe die Befehle oben mit NGINX als Reverse Proxy getestet (Aber wirklich nur getestet). Ich nutze es seit einiger Zeit mit HAProxy und bin damit sehr zufrieden (Und es erspart die WAP Server). Einige Kunden haben das genauso mit KEMP und F5 als Load Balancers gemacht und keinerlei Probleme damit.

Ich hatte das ganze bereits vor einiger Zeit als Gist veröffentlicht:

# Turn off Certificate Rollover
Set-AdfsProperties -AutoCertificateRollover $false

# Allow Login via Mail (And UPN)
Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID mail -LookupForests $ADDom


<#
  Enable SNI (Might be needed)

  I have no idea why I need to go to the NetSH Shell to execute that, but the command line does NOT work

  I need to do this to use the existing load balancer instead of the WAP/WIP for ADFS
  If not, the LB marks the ADFS Back ends as down. Has something to do with the lag of SNI support in ADFS

  Replace the ** with your Certificate Hash and check the APPID: netsh http show sslcert
#>

netsh
http add sslcert ipport=0.0.0.0:443 certhash=*** appid={
	5d89a20c-beab-4389-9447-324788eb944a
} certstorename=MY
http add sslcert ipport=0.0.0.0:49443 certhash=*** appid={
	5d89a20c-beab-4389-9447-324788eb944a
} certstorename=MY


<#
  Enable the Group Managed Service Account
#>
# Replace the DOMAIN.TLD - Mind the single slash :)
New-ADServiceAccount -name MSAadfs -DNSHostName adfs.DOMAIN.TLD -AccountExpirationDate $null -ServicePrincipalNames http/adfs.DOMAIN.TLD
Set-ADServiceAccount -Identity MSAadfs -PrincipalsAllowedToDelegateToAccount "Domain Admins"

<#
  Enable the ADFS Device registration feature (With our Group managed service account)
#>

# Enter Domain Admin credentials now!
$Credential = (Get-Credential)

# Mind the $ (Try a single quote next time) - Replace the DOMAIN.TLD and DOMAIN and ACCOUNT
Initialize-ADDeviceRegistration -ServiceAccountName "DOMAIN\ACCOUNT`$" -DeviceLocation 'DOMAIN.TLD' -RegistrationQuota 10 -MaximumRegistrationInactivityPeriod 90 -Credential $Credential -Force
Enable-AdfsDeviceRegistration -Credential $Credential -Force