Hallo Leutz,
der folgende Artikel beschreibt die Neuerungen in Microsoft Forefront TMG.
http://www.it-training-grote.de/download/tmg.pdf
Weitere Veroeffentlichungen rund um ISA Server, Windows, Exchange und anderen IT Themen:
http://www.it-training-grote.de/veroeffentlichungen.php
Gruss Marc
Hallo Leutz,
der Veroeffentlichungstermin von Microsoft Forefront TMG (und anderen Produkten der Forefront Familie) wurde fuer das 4. Quartal 2009 angekuendigt:
http://blogs.technet.com/forefront/archive/2009/04/03/schedule-update-for-forefront-stirling.aspx
Gruss Marc
Tach Allerseits,
Anfang März wurde in der deutschen ISA-Newsgroup die Frage gestellt, ob sich ein Konfigurationsspeicherserver (CSS) einer ISA-Server-Enterprise-Umgebung “verschieben” läßt. Die Idee hierbei: ein Sekundärer CSS soll zum primären CSS ernannt und der frühere primäre CSS gelöscht werden. Marc und ich philosophierten via EMail über das Thema und debatierten ob ein Transfer der FSMO Rollen für das Szenario nötig sei.
Wie es der Zufall so will wurde gestern auf dem offiziellen ISA-Blog ein passendes Workaround zu besagtem Thema veröffentlicht: http://blogs.technet.com/isablog/archive/2009/03/31/transferring-configuration-storage-server-fsmo-roles.aspx.
Mit der in dem Artikel dargestellten Verfahrensweise sollte sich die Anforderung umsetzen lassen.
Karsten Hentrup aka Jens Mander…
|<-|
…Tach Allerseits,
Anfang letzter Woche ging folgende Meldung durch den Heise-Newsletter: http://www.heise.de/newsticker/Transparente-Proxies-ebnen-Angreifern-den-Weg-ins-lokale-Netz–/meldung/134333. Hier stellt sich natürlich die berechtigte Frage, ob der ISA-Server auch von dieser Sicherheitslücke betroffen ist (vor allen Dingen, wo der Status beim CERT für Microsoft als “Unknown” gelistet wird). Ein flotter Test mit einer Telnet-Konsole wie beim Heise-Artikel beschrieben beweist, das ein aktueller ISA2006 mit SP1 nicht betroffen ist. Eine ausführliche Diagnose hat Adrian Dimcev durchgeführt und beschrieben: http://www.carbonwind.net/blog/post/2009/03/21/ISA-Server-vs-US-CERT-VU435052-e28093-A-Quick-Test.aspx.
Karsten Hentrup aka Jens Mander…
|<-|
…Tach Allerseits,
Anfang des Jahres habe ich eine ISA-Installation bei einem Kunden durchgeführt, der ein sicheres OWA-Publishing inklusive Password-Change-Option wünschte. Als ich nach zwei Tagen Installation, Konfiguration und Dokumentation den OP-Tisch verließ lief alles einwandfrei. Doch Ende letzter Woche klingelte bei mir das Telefon mit einem traurigen Admin am anderen Ende der Leitung. Ihr ahnt es schon: die Password-Change-Option hatte ihren Geist aufgegeben und funktionierte bereits seit einiger Zeit nicht mehr.
Einmal mehr ein Fall für den ISA-Arztkoffer. Diesen flott gepackt, zum Kunden gefahren und ein wenig “herumgedoktort”. Folgende Diagnose konnte gestellt werden:
Die Password-Change-Option auf der Form-Based-Authentication (FBA) des ISAs verweigerte den Dienst mit der Fehlermeldung:”An error occurred while trying to change the password. Please contact technical support for your organization”
Diese Fehlermeldung ist mir inzwischen hinreichend bekannt. Sie tritt auf, wenn z.B. keine domänenintegrierte CA vorhanden ist (wird für die Password-Change-Option zwingend benötigt), oder wenn einer der am Szenario beteiligten Server (DCs, ISAs) die CA nicht kennt, oder verwaiste DCs im AD herumgeistern (http://www.it-training-grote.de/blog/?p=538). Nicht so in unserem vorliegenden Fall. Hier begegnete mir zum ersten Mal folgender Event-Log-Eintrag auf einem der DCs: “Die automatische Zertifikatregistrierung für “lokaler Computer” konnte ein Zertifikat “Domänencontroller” (0x80070005) nicht registrieren. Zugriff verweigert.”
Im Unternehmen stehen zwei DCs. Einer der beiden DCs hat sein passendes Domänencontroller-Zertifikat beim Aufsetzen der CA erhalten (deshalb funktionierte die Password-Change-Option direkt nach der Installation bzw. Konfiguration, da der ISA mit genau diesem DC kommunizierte), der zweite DC mochte die Pille allerdings nicht so recht und wies obige Fehlermeldung auf. Die gute Nachricht: Dem Patienten konnte geholfen werden!
Meine Therapieempfehlung: Fügen Sie im Wartungsfenster die Gruppe der “Domänencontroller” der Gruppe “CERTSVC_DCOM_ACCESS” hinzu. Daraufhin einmal Replizieren und Rebooten und eine flotte Genesung dürfte sich einstellen (sprich: der zweite DC erhält daraufhin von der domänenintegrierten CA sein Domänencontroler-Zertifikat)!
Mit den besten gesundheitlichen Wünschen verabschiede ich mich für heute:
Karsten Hentrup aka Jens Mander…
|<-|
Hallo Leutz;
ISA Server 2006 hat nach einem langen Evaluierungsverfahren CC EAL 4+ erreicht:
http://download.microsoft.com/download/A/3/3/A33D3307-025E-49AD-A276-DCF0F29E28B0/isa2006-cc-certificate.pdf
BSI Info:
http://www.bsi.de/zertifiz/zert/reporte.htm#Firewalls.
Allgmeine Informationen:
http://www.microsoft.com/forefront/edgesecurity/isaserver/en/us/common-criteria.aspx.
Gruss Marc
Tach Allerseits,
heute lächelte mir eine spaßige Fehlermeldung entgegen (In der Endpunktezuordnung sind keine weiteren Endpunkte verfügbar), als ich versuchte die MMC vom TMG-MBE zu öffnen:
Keine Ahnung wie hoch mein Punktestand war. 😉 Ein beherzter Neustart linderte die Situation und die MMC ließ sich wieder öffnen.
Karsten Hentrup aka Jens Mander…
|<-|
Tach Allerseits,
Frank Pusch hat heute in der deutschen ISA-Newsgroup ein interessantes Posting zum oben genannten Thema verfasst:
**************************************************
Heute möchte ich mal keine Frage stellen, sondern eine Info geben.
Problem: ISA 2006 EE mit integriertem NLB im Unicast Mode (Standard) in
VMware ESX-Umgebungen funktioniert nicht.
Ich habe oft gelesen, dass dann Multicast Mode genommen werden muss/soll.
Das hat aber auch seine Nachteile und ist nicht leicht zu konfigurieren.
Bei uns hat es gereicht, die virtuellen Switche im ESX Server 3.5 (bzw. der
Portgruppe im vSwitch) so zu konfigurieren, dass es auch im Unicast Mode
funktioniert. Es muss nur “Switche benachrichtigen: NEIN” eingestellt sein.
siehe hierzu KB1556 in kb.wmware.com
(http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1556).
(Umgebung bei uns: Mitglieder eines Array liegen auf unterschiedlichen
ESX-Server).
Vielleicht findet diese Info der eine oder andere ebenso nützlich wie ich.
MfG,
Frank Pusch
**************************************************
Vielen Dank für die nützliche Info Frank!
Karsten Hentrup aka Jens Mander…
|<-|
Hallo Leutz,
wir schreiben den 02.03.2009 und seit 12:00 Uhr bin ich hier auf der CeBIT an meinem Arbeitsstand fuer die naechsten 6 Tage. Die meisten organisatorischen Fragen sind geklaert, jetzt kann es an die Arbeit gehen.
Gruss Marc
…Tach Allerseits,
bei meiner ISA-Implemantation in Oberhausen “spuckte” uns ein Router ein wenig in die Suppe. Das Netz meines Kunden war bis heute durch einen Router mit integriertem IP-Paketfilter vom Internet getrennt. Dies wurde von uns durch eine Back-to-Back-Lösung mit einem ISA2006SE-Server ergänzt. Ich traf heute morgen die Hardware in bestem Zustand an, OS inkl. aktuellem Patchlevel zu allen Schandtaten bereit. Flux das LAN-Kabel des Routers gezogen und mit der externen Seite des ISAs verbunden (erst direkt aufgepatcht, später testweise mit zwischengeschaltetem Switch). Die Back-to-Back-Lösung sollte somit auch eine physikalische Trennung erfahren, folgende Topologie wurde von uns angestrebt:
Internet – Router (mit 2 ISP-Anbindungen) – ISA – Intranet
An den Router des ISPs sind zwei externe ADSL-Modems der Telekom angeschlossen. Als wir das LAN-Kabel des Routers zogen und neu patchten, stellte sich folgender (für mich zumindest) äußerst merkwürdiger Effekt ein: die Modems verloren die Synchronisation mit der Gegenüberstelle. Flux das LAN-Kabel auf den Core-Switch des Kunden zurückgepatcht – beide Modems syncen einwanfrei. Dieses Verhalten ist reproduzierbar. Es wurde kein Crossover-Kabel zwischen Router und ISA verwendet. Ein eigenständiger Switch zwischen Router und ISA schaffte keine Abhilfe. Ich hätte in dem Fall gedacht, das die Modems “aus Sicht” des Routers extern sind und nichts mit der internen Verkabelung zu tun haben. Aber sobald ich den Router vom Core-Switch runternehme ist Ende im Gelände angesagt, der Sync mit der DSL-Gegenstelle geht ins Nirvana (jau, wir haben wirklich lange gewartet).
Als Notlösung (uns wäre die physikalische Trennung lieber gewesen) haben wir folgendes gemacht: Der Router bleibt mit seiner LAN-Seite auf den Core-Switch gepatcht, der ISA mit seiner externen NIC ebenfalls. Die verwendeten IPs der internen NIC des Routers, sowie der externen NIC des ISAs sind aus einem komplett anderen IP-Segment. Wo wir schon keine physikalische Trennung hinbekommen können, haben wir sie wenigstens “virtuell” vollzogen.
Verrückte Geschichte das. Falls hierzu jemand ein paar Infos hat, bin für jede “Erleuchtung” dankbar (hentrup@aixperts.de).
Karsten Hentrup aka Jens Mander…
|<-|