{"id":538,"date":"2009-02-26T10:40:10","date_gmt":"2009-02-26T09:40:10","guid":{"rendered":"http:\/\/www.it-training-grote.de\/blog\/?p=538"},"modified":"2009-02-26T10:40:42","modified_gmt":"2009-02-26T09:40:42","slug":"der-isa-ist-nicht-schuld-fallbeispiel-9998938","status":"publish","type":"post","link":"https:\/\/www.it-consulting-grote.de\/blog\/?p=538","title":{"rendered":"Der ISA ist nicht schuld – Fallbeispiel 9998938:"},"content":{"rendered":"

Tach Allerseits…<\/span>\u00a0<\/span><\/p>\n

Vor zwei Wochen bin ich nochmal in die Verlegenheit gekommen eine ISA-2006-Inplace-Migration durchzuf\u00fchren. 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\u00df erreichen kann!<\/span><\/p>\n

Vor Ort installiert war eine ISA-2004-SE. Ein Upgrade auf ISA-2006-SE war vom Kunden gew\u00fcnscht. Zielsetzung war insbesondere die Password-Change-Option auf dem mit FBA versehenen Weblistener. Weitere Konfigurationsw\u00fcnsche: Regelwerkoptimierung, Patchlevel aktualisieren, SSL-Bridge statt Serververpublish f\u00fcr OWA und HTTPS\/RPC alias Outlook Anywhere.<\/span><\/p>\n

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\u00f6nlich w\u00e4re 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\u00e4mtlichen NICs aktiviert gewesen), dies ist aber manchmal leider nicht m\u00f6glich. 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 \u2013 Eventlog gecheckt \u2013 alles wunderbar!<\/span><\/p>\n

Bis hierhin lief alles wunderpr\u00e4chtig, auch die Regelwerkoptimierung f\u00fcr die ausgehenden Zugriffe verliefen reibungslos. Als letztes hatten wir noch den eingehenden Verkehr zu regeln, sprich OWA und HTTPS\/RPC. F\u00fcr die Password-Change-Option die wir anvisierten installierten wir eine dom\u00e4nenintegrierte CA auf einem internen Webserver. Auf dem Exchange- und dem ISA-Server rollten wir die ben\u00f6tigten Zertifikate aus und richteten die SSL-Bridge ein. Zugriff von extern aufs OWA gegengetestet \u2013 klappt.<\/span><\/p>\n

Als letzten Konfigurationsschritt richteten wir die Password-Change-Option auf dem mit FBA versehenen Listener ein und bauten die noch fehlende Regel f\u00fcr\u2018s HTTPS\/RPC. Daraufhin fingen unsere Probleme an:<\/span><\/p>\n

Die Password-Change-Option wurde auf der FBA einwandfrei angezeigt und das \u00c4ndern des Passwortes f\u00fcr einen Testbenutzer funktionierte genau einmal. Bei allen weiteren Versuchen bekamen wir die \u00fcblich nichtssagende \u201eman solle doch an jemanden anrufen, der etwas davon verstehe\u201c-Fehlermeldung. <\/span>J<\/span><\/span><\/span><\/p>\n

Die Passwort-\u00c4nderung, die stellvertretend durch den ISA durchgef\u00fchrt wird (Proxy halt) wird vom ISA zu den internen DCs mit LDAPS durchgef\u00fchrt. Dieser Umstand wird in einem Microsoft-Whitepaper zu diesem Thema in einem Nebensatz erw\u00e4hnt. Das bedeutet, das eine dom\u00e4nenintegrierte CA zwingend ben\u00f6tigt wird und alle DCs jene auch kennen. Damit dies gegeben ist hatten wir s\u00e4mtliche DCs neu gestartet anstatt aufs Auto-Enrollment des Zertifizierungsinstanzzertifikates (eines meiner Lieblingsw\u00f6rter) 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\u00e4be nur zwei DCs. Nach einiger Zeit des Forschens, Rebootens und Testens \u00f6ffnete ich die MMC f\u00fcr Active Directory-Standorte und -Dienste und siehe da: ein lustiger mir bisher nicht bekannter DC winkte mir fr\u00f6hlich entgegen. Ein paar Fragen sp\u00e4ter stellte sich heraus, dass diese Maschine eigentlich kein DC, sondern nur ein hausinterner Backupserver sein durfte. Ein dcpromo best\u00e4tigte 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\u00e4uft. Bei der Passwort-\u00c4nderung scheint unser guter ISA-Server via LDAPS mit ihm kommuniziert zu haben und die \u00c4nderung 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\u00e4chlich im AD eingetragen sind.<\/span><\/p>\n

Etwas l\u00e4nger 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\u00df mich f\u00e4lschlicherweise vermuten, ich kommuniziere bereits mit dem ISA. Ein Fehler wie ich sp\u00e4ter 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\u00f6glich. Ich m\u00f6chte euch die verzweifelten Versuche meinerseits ersparen, die ich durchgetestet habe um das gute Teil zum fliegen zu bringen und direkt auf die L\u00f6sung 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 \u00f6ffentlichen 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 \u00f6ffentlichen 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.<\/span><\/p>\n

Die Ursachen f\u00fcr die Probleme m\u00f6gen recht trivial sein, in der Situation an sich kann man an solchen Nettigkeiten schon mal ein wenig verzweifeln.<\/span><\/p>\n

Karsten Hentrup aka Jens Mander\u2026<\/span><\/p>\n

|<-|<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

Tach Allerseits…\u00a0 Vor zwei Wochen bin ich nochmal in die Verlegenheit gekommen eine ISA-2006-Inplace-Migration durchzuf\u00fchren. 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\u00df … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[5],"tags":[],"_links":{"self":[{"href":"https:\/\/www.it-consulting-grote.de\/blog\/index.php?rest_route=\/wp\/v2\/posts\/538"}],"collection":[{"href":"https:\/\/www.it-consulting-grote.de\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.it-consulting-grote.de\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.it-consulting-grote.de\/blog\/index.php?rest_route=\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.it-consulting-grote.de\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=538"}],"version-history":[{"count":2,"href":"https:\/\/www.it-consulting-grote.de\/blog\/index.php?rest_route=\/wp\/v2\/posts\/538\/revisions"}],"predecessor-version":[{"id":540,"href":"https:\/\/www.it-consulting-grote.de\/blog\/index.php?rest_route=\/wp\/v2\/posts\/538\/revisions\/540"}],"wp:attachment":[{"href":"https:\/\/www.it-consulting-grote.de\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=538"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.it-consulting-grote.de\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=538"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.it-consulting-grote.de\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=538"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}