ISA-Password-Change vs. Zertifikatsfehler…

…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…

|<-|

ebay + sixt vs. creative autoupdate…

…Tach Allerseits,

ein frisch installiertes 64bit-Vista auf meiner neuen Hardware erquickte meine Surf-Sessions, bis ich auf Ebay und Sixt landete. Dort angekommen ist man der Meinung, ich sei mit einem mobilen Client unterwegs und zauberte mir die Versionen für mobile User Agents auf meinen 24″ Monitor.

 

Flux den HTTP-Header analysiert und den Störenfried gefunden. Die Creative-Autoupdate-Funktion meiner X-FI-Titanium verewigte sich unter anderem in meinem UA-Header.

Das Deaktivieren der Creative-Addons im Browser brachte keine Abhilfe.

Wohl aber das Löschen des folgenden Registry-Keys (nur den Creative-REG_SZ löschen reicht aus):

Die Autoupdate-Software von Creative (Creative Software AutoUpdate) welche mit der Titanium-Treiber-CD mitinstalliert wird, funktioniert trotzdem weiterhin noch. Somit kann ich nun einfach meine Treiber aktuell halten und bei Sixt meine Autos ersteigern, sowie bei Ebay meine Auktionen mieten. 😉

Karsten Hentrup aka Jens Mander…

|<-|