…Hallo Allerseits,

wie Marc kürzlich linke ich auch nochmal auf das Blog von Richard Hicks, der im Zusammenhang mit dem ISA Server einem HTTP-502er Statuscode  begegnete. Allerdings ganz im Gegensatz zu den aktuellen 502er Diskussionen hat er wirklich erstaunliches im Header entdeckt. Der Webserver auf den zugegriffen wurde liefert HTTP aus, allerdings in der Version 2.0:

http://tmgblog.richardhicks.com/2009/01/16/http-20-specification/

Nächtliche Grüße,

Karsten Hentrup…

|<-|

…Hallo Allerseits,

aus mehreren Onlinequellen zusammengetragen habe ich eine Liste der ISA und TMG Versionsnummern zusammengetragen. Ich versuche diese auch regelmäßig zu aktualisieren. Die Liste ist als pdf hier downloadbar:

http://www.aixperts.de/dox/isa-tmg-versionen.pdf

Falls jemand Ergänzungen oder Korrekturen hat, bitte per Mail an mich.

Viele Grüße und ein verspätetes frohes Neues!

Karsten Hentrup… aka Jens Mander…

|<-|

…Hallo Allerseits,

Im Rahmen eines Kundensupports habe ich mich mit der Radius-Implementation auf einem ISA Server 2004 Standard Edition (SP3) beschäftigt. Ziel der Aufgabe ist es ein sicheres Webpublishing für Exchange HTTP/RPC (aka Outlook-Anywhere bei Exchange 2007) mittels Radius-Authentifizierung zu realisieren. Ein spezieller Kundenwunsch sollte berücksichtigt werden: Auf der Webveröffentlichungsregel sollen ISA-Benutzersätze verwendet werden, die wiederum auf Radius-Gruppen verweisen. Wichtige Information vorab: Dieser Konfigurationswunsch ist meiner Meinung nach nicht möglich! Ebenfalls gegengetestet wurde dieses Szenario von mir mit dem aktuellen ISA Server 2006.

Eine kleine Dokumentation zu der Problematik findet ihr hier: http://www.aixperts.de/dox/ISA200xSE-Radius.pdf

Ich wünsch euch allen ein frohes Fest, guten Rutsch, beste Gesundheit und natürlich tolle Notebooks 😉 !

Karsten Hentrup… aka Jens Mander…

|<-|

…Hallo Allerseits,

Marc erwähnte vor ein paar Tagen eine kleinen Diskussion von uns beiden zum Thema URL-Filter umgehen (http://www.it-training-grote.de/blog/?p=263). Wie angedroht möchte ich hier auf eine kleine Doku verlinken, die ich zu dem Thema erstellt habe: www.aixperts.de/dox/url-filter-umgehen.pdf

Gruss, Karsten…

|<-|

Vor ein paar Tagen habe ich einen kleinen Erfahrungsbericht zu einem aktuellen Kundenprojekt in die deutschsprachige ISA-NG gestellt. Diesen poste ich als ersten fachlichen Beitrag noch einmal hier:

Für besagten Kunden haben wir ein ISA2006 Enterprise-Array bestehend aus zwei Knoten eingerichtet. Haupteinsatzzweck ist momentan Reverse-Proxying zwecks sicherem Zugriff auf OWA und EAS.

Nachdem wir das NLB aktiviert hatten fingen die ersten Probleme an: das Array und die Swichte wollten nicht miteinander atmen. Die Firmware auf den Switchen konnte mit dem NLB nicht umgehen. Einen der installierten ISAs haben wir daraufhin auf Eis gelegt und den anderen via modifizierter masksourcemac mit den Switchen zum sprechen gebracht (http://support.microsoft.com/kb/193602).
Nach passenden strategischen Vorbereitungen wurden die zwei redundant ausgelegten Core-Switche auf eine aktuelle (NLB-fähige) Firmware gepatcht. Kein Vorgang, der mal eben so schnell erledigt werden konnte. Wir reden hier von einer recht sensiblen Infrastruktur, in der man sich so gut wie keinerlei Ausfälle leisten kann. Ergo mussten alle Backbone-Admins zum Core-Switch-patchen antanzen, da der gesammte Backbone an den guten Teilen hängt.
Lange Rede kurzer Sinn: Switche gepatcht, VLAN aufgespannt – NLB-Funktionalität auf den Switchen für das VLAN eingeschaltet – ISAs ins VLAN reingehängt – masksourcemac rausgenommen – beide ISA-Knoten hochgefahren um das Array zu vervollständigen.

Erste Tests ergaben, das die eingehende Last (wie gesagt hauptsächlich reverse-proxy für OWA und EAS) nur auf einem der ISA-Knoten hängt (nämlich auf dem, der eh die letzten Wochen/Monate lief). Der neue (aus dem dornröschenschlaf erweckte) ISA hatte nur ein paar ausgehende Connects zu verzeichnen (aus der Admin-Abteilung selber), eingehende aber gar keine. Um dies zu forcieren und die Redundanz zu testen haben wir auf dem “alten” ISA den Firewalldienst beendet. Jetzt wurde es spannend: es klappten keinerlei Zugriffe mehr aufs OWA/EAS. Wir bekamen von Extern noch via telnet einen “offenen Port” auf dem Zielsocket angezeigt (IP:443), aber sobald wir mit dem Browser aufs OWA zugreifen wollten kam es zu einer absolut nichtssagenden Fehlermeldung, gleiches Verhalten via EAS, sprich pushmail.

Wir versuchten das Problem einzugrenzen und haben einige Tests vorgenommen, bei denen wir folgendes festgestellt haben: ausgehende Zugriffe (WPC) klappten einwandfrei! Flux einen neuen Http-Listener gebaut und unverschlüsselt sowie unauthentifizert auf eine interne Http-Präsenz zugegriffen: einwandfrei! Die Webveröffentlichungsregel modifiziert (extern http – intern https): einwandfrei! Sobald ich allerdings in den Webveröffentlichungsregeln den fürs OWA/EAS angelegten Https-Listener verwendet habe fuhr uns die Karre an die Wand, sprich: Fehlermeldung. Nebenbei sei erwähnt, das die Authentifizierungsmethoden und -delegierungen korrekt eingestellt waren. Auch die Switchte auf der internen und externen Seite konnten wir ausschließen, da die Connects schon bis zum ISA durchgereicht wurden.

Dann klingelte es bei mir irgendwo im Hinterstübchen. Keine Ahnung ob ich darüber mal in einer der einschlägigen ISA-Ngs was gelesen habe, oder bei Dr.Tom. Ich hatte durch die Tests bestätigt bekommen, das eigentlich alles funzt, nur die Https-Connects zu diesem einen jetzt neu in Betrieb genommenen ISA scheiterten. Zertifikatsfehler oä Signifikantes waren aber nirgendswo irgendswo ersichtlich (ja, die Zertifikate sitzen im richtigen Zertifikatsspeicher). Unnötig zu erwähnen, das sämtliche Logs clean waren.

Ich habe daraufhin den Weblistener geöffnet und unter der Registerkarte “Zertifikate” über die Schaltfläche “Zertifikate auswählen” das passende OWA-Zertifikat nochmals ausgewählt und dieses nochmal übernommen (obwohl dies ja schon passend konfiguriert war). Tata, die Zugriffe funktionierten direkt einwandfrei auf allen Array-Members. Unfassbar. Vor dem Aktualisieren des NLB sind auf beiden ISA-Hosts die Zertifikate importiert worden. In stiller Abwesenheit von einem ISA-Knoten (aufgrund der oben genannten Switch-Problematik) haben wir einen Weblistener auf der per NLB eingerichteten VIP gebaut. Als dann nach dem Switchupdate der zweite Host reanimiert wurde hat er diese Konfiguration (warum auch immer) nicht einwandfrei übernommen oder umgesetzt. Erst wo beide Knoten online waren und ich dann das Zertifikat nochmals zugeordnet habe klappt das Ganze.

Vielleicht sagen jetzt einige von euch: ja klar, ist doch logisch, liegt da und daran. Mir wars ehrlich neu und hat uns auch einige Zeit und Energie gekostet (für einen an und für sich lapidaren Konfigurationsschritt).

Jens Mander…

|<-|