Ich bin vor kurzem auf ein interessantes Problem gestoßen. Das wäre sicher auch jedem aufgefallen, wenn man mal drüber nachdenkt. :)
Ein Kunde wechselt im Zuge eines Serverwechsels von ADFS 2.0 auf ADFS 3.0. Das heißt in diesem Zusammenhang einfach nur, der ADFS Server wurde auf Windows Server 2012 R2 aktualisiert und der Web Application Proxy davor ebenfalls.
Jetzt ist es nur leider so, dass seitdem - der ADFS Service hat zuvor beim Authentifizieren von Außen über den WAP problemlos funktioniert – von Intern der ADFS Service nicht mehr erreichbar ist. Der Internet Explorer liefert die Meldung "Die Webseite kann nicht angezeigt werden".
Eher seltsam…
Der einzige wesentliche Unterschied der mir auffällt - intern komm ich halt direkt auf den ADFS Server, extern schlag ich auf dem WAP Server auf. Nur - was macht das für einen Unterschied?
Nun startet etwas längere drüber nachdenken - was hat sich von ADFS 2.0 auf 3.0 wirklich geändert?
Ja - das Betriebssystem natürlich und dementsprechend auch, ob im Hintergrund ein IIS läuft oder nur die HTTPS.sys Komponente. Damit gibt es auf dem 2012 R2 Server weniger Angriffsfläche für klassische IIS Attacken. Bei der Konfiguration ist es damit aber schwieriger geworden, da man zum Beispiel das Zertifikat nicht mehr einfach in der IIS Console ansehen kann. Ob der Server dort wirklich horcht, solche Sachen.
Nachsehen…
Was macht man also? Man bedient sich der guten alten netsh console. Mit dem Befehl…
netsh http show sslcert
…sieht man dann dass auf ADFStest.2und40.at:443 (mein ADFS Endpunkt heißt in dem Fall ADFSTest.2und40.at) mein SSL Zertifikat horcht.
Aber… kurz drüber nachgedacht…
Wenn da nix auf 0.0.0.0:443 horcht, dann muss der Client mit Server Name Indication melden wohin er eigentlich will - damit die HTTP.SYS weiß welchen Listener es nehmen soll.
Weiter drüber nachgedacht…
SNI ist ein Feature das mit TLS 1.2 hinzugefügt wurde. Ein kurzer Blick in die Internet Options des Internet Explorers:
Schon wäre geklärt warum das ned geht!
…und gelöst
Warum es deaktiviert ist? Ja - eine alte Web Applikation, die aus nicht erklärbaren Gründen (wahrscheinlich einfach alt) damit nicht umgehen kann und dann einfach nicht mehr funktioniert.
Nur - was machen wir jetzt damit ADFS wieder funktioniert? Wenn man weiß woran es scheitert, kann man jedenfalls leichter danach suchen.
TechNet: How to support non-SNI capable Clients with Web Application Proxy and AD FS 2012 R2
Danke für diesen Artikel - er erklärt simpel, wie man Clients die kein SNI Supporten (oder es einfach abgedreht haben) trotzdem mit ADFS 3.0 befüttern kann.
Einfach wie beschrieben:
netsh http add sslcert ipport=0.0.0.0:443 certhash=certthumprint appid={applicationguid}
ein Default Mapping hinzufügen und schon funktionierts auch mit dem Nachbarn!
LG Christoph