Tach Allerseits…
Vor zwei Wochen bin ich nochmal in die Verlegenheit gekommen eine ISA-2006-Inplace-Migration durchzuführen. Der Kunde sitzt bei mir vor Ort in Aachen und das wirklich besondere an ihm ist, das ich ihn innerhalb von 10 Minuten zu Fuß erreichen kann!
Vor Ort installiert war eine ISA-2004-SE. Ein Upgrade auf ISA-2006-SE war vom Kunden gewünscht. Zielsetzung war insbesondere die Password-Change-Option auf dem mit FBA versehenen Weblistener. Weitere Konfigurationswünsche: Regelwerkoptimierung, Patchlevel aktualisieren, SSL-Bridge statt Serververpublish für OWA und HTTPS/RPC alias Outlook Anywhere.
Als erstes haben wir die aktuelle ISA-2004 Konfiguration, sowie die vorhandenen Logfiles gesichert (auf einem hausinternen Fileserver). Danach wurde das OS-Patchlevel geradegezogen. Nach einem leckeren Mittagessen vor Ort warfen wir die ISA-2006-SE-CD ins Laufwerk und starteten das Inplace-Upgrade. Mir persönlich wäre eine Neuinstallation der Kiste lieber gewesen um manche Altlasten in Sachen Softwareinstallation nicht mitzunehmen (z.B. ist – warum auch immer – auf der Maschine NLB auf sämtlichen NICs aktiviert gewesen), dies ist aber manchmal leider nicht möglich. Nach der Installation noch flott das ISA-2006-SP1 draufgesetzt. Finger weg vom Post-SP1-UDP-DNS-Patch, der Kunde macht VPN mit dem ISA! Kiste durchgestartet – Eventlog gecheckt – alles wunderbar!
Bis hierhin lief alles wunderprächtig, auch die Regelwerkoptimierung für die ausgehenden Zugriffe verliefen reibungslos. Als letztes hatten wir noch den eingehenden Verkehr zu regeln, sprich OWA und HTTPS/RPC. Für die Password-Change-Option die wir anvisierten installierten wir eine domänenintegrierte CA auf einem internen Webserver. Auf dem Exchange- und dem ISA-Server rollten wir die benötigten Zertifikate aus und richteten die SSL-Bridge ein. Zugriff von extern aufs OWA gegengetestet – klappt.
Als letzten Konfigurationsschritt richteten wir die Password-Change-Option auf dem mit FBA versehenen Listener ein und bauten die noch fehlende Regel für‘s HTTPS/RPC. Daraufhin fingen unsere Probleme an:
Die Password-Change-Option wurde auf der FBA einwandfrei angezeigt und das Ändern des Passwortes für einen Testbenutzer funktionierte genau einmal. Bei allen weiteren Versuchen bekamen wir die üblich nichtssagende „man solle doch an jemanden anrufen, der etwas davon verstehe“-Fehlermeldung. J
Die Passwort-Änderung, die stellvertretend durch den ISA durchgeführt wird (Proxy halt) wird vom ISA zu den internen DCs mit LDAPS durchgeführt. Dieser Umstand wird in einem Microsoft-Whitepaper zu diesem Thema in einem Nebensatz erwähnt. Das bedeutet, das eine domänenintegrierte CA zwingend benötigt wird und alle DCs jene auch kennen. Damit dies gegeben ist hatten wir sämtliche DCs neu gestartet anstatt aufs Auto-Enrollment des Zertifizierungsinstanzzertifikates (eines meiner Lieblingswörter) zu warten. Positiver Nebeneffekt hierbei: das Patchlevel haben wir in einem Rutsch direkt gerade gezogen. Trotz der intensiven und korrekten Vorbereitung quittierte uns die Password-Change-Option die mir bekannte Fehlermeldung, die erscheint, wenn man keine hausinterne CA besitzt, bzw. einer der DCs diese noch nicht kennt. Auf mehrfaches Nachfragen meinerseits wurde mir vom Kunden versichert es gäbe nur zwei DCs. Nach einiger Zeit des Forschens, Rebootens und Testens öffnete ich die MMC für Active Directory-Standorte und -Dienste und siehe da: ein lustiger mir bisher nicht bekannter DC winkte mir fröhlich entgegen. Ein paar Fragen später stellte sich heraus, dass diese Maschine eigentlich kein DC, sondern nur ein hausinterner Backupserver sein durfte. Ein dcpromo bestätigte den nicht vorhandenen Service. Anscheinend ein nicht sauber aus dem AD ausgetragener Ex-DC. Nur referenziert das AD weiterhin auf ihn, den Computernamen gibt es auch noch, nur das halt kein DC auf der Maschine läuft. Bei der Passwort-Änderung scheint unser guter ISA-Server via LDAPS mit ihm kommuniziert zu haben und die Änderung ging ins Nirvana. Der Spuk hatte ein Ende, nachdem der verwaiste DC korrekt aus dem AD ausgetragen wurde. Notiz an mich selber: Immer erst im AD kontrollieren wieviele DCs tatsächlich im AD eingetragen sind.
Etwas länger schlugen wir uns allerdings mit dem HTTPS/RPC herum. Flux eingerichtet und von einem Notebook des Kunden gegengetestet (welches sich angeblich im Internet befindet). Die Zugriffe schlugen fehl. Ein Authentifizierungsfenster in Outlook ließ mich fälschlicherweise vermuten, ich kommuniziere bereits mit dem ISA. Ein Fehler wie ich später in einer VM bei mir im Home-Office bemerkte. Outlook zaubert beim HTTPS/RPC-Szenario anscheinend automatisch ein Popup-Fenster, auch wenn keinerlei Connect zu irgendeinem Zielsystem existiert. Recht verwundert war ich allerdings durch die Tatsache, das der HTTPS/RPC mit meinen Outlook von zuhause aus einwandfrei funktionierte. Tags darauf wieder beim Kunden vor Ort der gleiche Effekt wie am Vortag: keine Verbindung möglich. Ich möchte euch die verzweifelten Versuche meinerseits ersparen, die ich durchgetestet habe um das gute Teil zum fliegen zu bringen und direkt auf die Lösung hinweisen. Das Laptop des Kunden (mit dem wir die Verbindungen getestet haben) befand sich keineswegs im Internet, sondern in dem Transfernetz zwischen dem ISA Server und der Frontendfirewall. Da wir aber zum Testen immer den öffentlichen FQDN genommen haben wurde ein Connect durch die Frontendfirewall raus und wieder rein versucht, welcher hoffnungslos scheiterte. Wir modifizierten auf dem Rechner im Transfernetz die Host-Datei und drehten den öffentlichen FQDN gegen die externe IP des ISA Servers und schon war alles in Butter. Notiz an mich selber: Teste externe Verbindungsversuche immer mit dem eigenen Laptop via UMTS/HSPA.
Die Ursachen für die Probleme mögen recht trivial sein, in der Situation an sich kann man an solchen Nettigkeiten schon mal ein wenig verzweifeln.
Karsten Hentrup aka Jens Mander…
|<-|
