Kürzlich bei der Implementierung von MS ForeFront Thread Management Gateway (=Nachfolger vom ISA Server)…
Auf den TMG Server erstellen wir einen Listener der mittels LDAP eine Pre-Authentifizierung durchführt. Soweit so gut – hat alles funktioniert.
Nachdem wir dann beschlossen hatten, dass es keine gute Idee ist, Benutzernamen/Passwörter unverschlüsselt in der Gegend herumzuschicken, wollte wir den Listener auf LDAPS umstellen.
Also, Zertifikat auf den DCs eingespielt, Listener rekonfiguriert und…nichts geht mehr. TMG kann keine Verbindung mit dem DC über LDAPS herstellen. Sämtliche Versuche mit allen möglichen Tools (LDP, etc.) schlagen fehl.
Nachdem wir Stunden damit verbrachten, diverseste technische Ursachen in Betracht zu ziehen (Verschlüsselungsalgorithmen udgl.) war die Lösung, wie so oft, recht einfach:
Durch das aktivieren des SCHANNEL Error-Loggings, welches sämtliche SSL Vorgänge aufzeichnet, stellten wir fest, dass TMG beim Certificate Subjectname des DCs den Hostname und nicht den FQDN erfordert – im Zertifikat war aber nur der FQDN angegeben – somit kam natürlich keine Verbindung zu Stande. Auf jeden Fall aber sehr komisch, da wir im Listener den FQDN angegeben hatten.
Wieso also versteift sich TMG auf den Hostname? Auch hier war die Lösung einfach: Wir hatten dem TMG alle Namen zur Auflösung in die HOSTS-Datei eingetragen. Ein Kollege war dabei etwas „übereifrig“ und hat sowohl den HOSTNAME als auch den FQDN eingetragen.
Wenn Windows einen Secure Channel aufbaut wird offenbar ein Reverse-Lookup durchgeführt – und genau da lag der Hund begraben: Der HOSTNAME war der erste Eintrag in der HOSTS…
Nachdem wir den HOSTNAME gelöscht hatten, funktionierte die LDAPS Verbindung auf Anhieb!