Policy Based Routing mit Juniper SRX Firewalls

Eine häufig nachgefragte Funktionalität ist jene, dass bestimmte Daten, bestimmte Protokolle anders geroutet werden sollen als der Rest. Speziell in der Welt der ScreenOS basierten Firwalls hat sich hierfür der Begriff Policy Based Routing (PBR) etabliert. In ScreenOS gibt es hierfür ganz konkrete Befehle innerhalb des Virtual Router Kontextes.

Umsteiger auf JUNOS suchen erst einmal vergeblich nach einem Pendant. Erst einmal womöglich erfolglos. Denn in JUNOS gibt es keine konkreten Befehle für PBR. Vielmehr kann man das allgemeine Konzept der Firewall Filter, das wir so einsetzen können, dass das gewünschte Resultat dabei herausschaut.

Nehmen wir einmal folgendes Szenario: Eine SRX Firewall ist an zwei Internet Service Provider angeschlossen. Der Web Traffic des Webservers soll über Provider B geroutet werden, aller anderer Verkehr über Provider A.

Der eingehende Traffic muss nicht speziell behandelt werden. Das zu ISP B zugewandte Interface mit auf die passende IP-Adresse konfiguriert und es wird eine Destination NAT Regel angelegt. Jedoch: Die Antwort-Pakete des Webservers würden über ISP A hinausgeleitet. Grund ist: Die Default-Route 0.0.0.0/0 verweist mit besserer Metrik auf ISP A. Wir hätten also die Situation des asymetrischen Routings. Um dies zu beheben gehen wir wie folgt vor:

Als erstes brauchen wir eine zusätzliche Routing-Instanz die eine Default-Route zu ISP B enthält:

set routing-instances HTTP-Redirect instance-type forwarding
set routing-instances HTTP-Redirect routing-options static route 0.0.0.0/0 next-hop 2.1.1.1

Als zweites erstellen wir einen Firewall Filter der bewirkt, dass unser gewünschter Verkehr in diese Routing Instanz "umgeleitet" wird.

set firewall family inet filter HTTP-Redirect-Filter term term1 from source-address 192.168.1.10/32
set firewall family inet filter HTTP-Redirect-Filter term term1 from destination-port http
set firewall family inet filter HTTP-Redirect-Filter term term1 then routing-instance HTTP-Redirect
set firewall family inet filter HTTP-Redirect-Filter term term2 then accept

Dabei unterstellen wir, dass 192.168.1.10 die IP-Adresse unseres Webservers ist. Als nächstes müssen wir den Filter an das Interface binden, an das der Webserver angeschlossen ist. In unserem Beispiel ist das ge-0/0/2.0:

set interfaces ge-0/0/2 unit 0 family inet filter input HTTP-Redirect-Filter

Jedoch ist dies noch nicht genug: Das Problem hierbei liegt daran, dass die Router in der Routing-Tabelle aus unserer neuen Instanz nicht aktiv wird. Es fehlen nämlich die lokalen und die direkten Routers die normalerweise durch das Setzten der IP-Adresse erzeugt werden. Z.B. hat unser Interface zu ISP B die IP-Adresse 2.1.1.2/24. Dadurch wird automatisch die Route 2.1.1.2/32 und die Route 2.1.1.0/24 erzeugt. Beide sind Voraussetzungen dafür, dass eine Route mit Next Hop 2.1.1.1 überhaupt aktiv werden kann.

Zur Lösung gibt es in JUNOS dafür das Konzept der RIB Gruppe. Konkret kopieren wir die direkten und lokalen Routes von der Standard-Routingtabelle inet.0 in unsere Instanz.

set routing-options interface-routes rib-group inet MyRIB-Group
set routing-options rib-groups MyRIB-Group import-rib inet.0
set routing-options rib-groups MyRIB-Group import-rib HTTP-Redirect.inet.0

Die erste Routing-Tabelle ist immer die Quelle, die zweite das Ziel.

Mit Hilfe dieses technischen Konstrukts können wir die Routing Tabelle korrekt befüllen und haben alle notwendigen Arbeiten für das PBR abgeschlossen.

Im Firewall Filter könnte man weitere Bedingungen in der from Klausel unterbringen und damit unter Umständen noch aufwendigere Szenarien zu realisieren.

Clustering mit Juniper SRX 210 Firewall

Um die Verfügbarkeit zu erhöhen ist die Methode des Clusterns, also Verbinden von zwei oder mehr baugleichen Geräten zu einer Einheit, eine erprobte Technik. Auch bei den Juniper SRX Firewalls steht diese Technologie zur Verfügung. Ich habe einen Sonntag Nachmittag zugebracht dies mit zwei SRX 210 Geräten auszuprobieren.

Schritt 1
Als erstes sollten wir das JUNOS Betriebssystem auf den letzten Stand bringen. Das ist zum heutigen Datum JUNOS 9.6 Release 2. Speziell wurden hier etliche Fehler in Zusammenhang mit Clustering beseitigt. Da ich davon ausgehe, dass jeder mit dem Upgrade-Vorgang vertraut ist, überspringe ich diesen Teil.

Schritt 2
Nicht zwingend notwendig aber meiner Meinung nach Best Practice: Wir beginnen mit der Factory-Default Konfiguration. Durch das Clustering bekommen wir ohendies andere Interface-Namen sodass sich bestehende Konfigurationen nur bedingt übernehmen lassen. Jedenfalls weiß man was man hat, wenn man von einem definierten Punkt ausgeht.

Die Auslieferungskonfiguration lässt sich mit in drei einfachen Schritten herstellen:

1. load factory-default
2. set system root-authentication plain-text-password sowie Eingabe des Root-Kennworts
3. commit

Schritt 3
Als nächstes müssen wir die beiden Geräte verkabeln. Welche Ports verbunden werden müssen ist von Gerät zu Gerät unterschiedlich. Das JUNOS Handbuch verrät die Belegung für jeden Typ. Hier z.B. die entsprechende Schaltung für die SRX 210:


Es gibt dabei zwei Verbindungen: Der Control Link dient zum Austausch des Heartbeat Signals, zum Abgleich der Konfiguration sowie dem Abgleich der Realtime Objects (RTO). RTOs sind z.B. aktive Sessions, NAT Tabellen usw.

Der Fabrik Link kommt Active-Active Konfigurationen zum Tragen. Wenn nämlich Daten in Knoten 0 eingehen und über Knoten 1 hinausgeschickt werden, werden sie über den Fabriklink von Knoten 0 zu Knoten 1 weitergeleitet. Daher muss hier auch immer eine Gigabit-Verbindung verwendet werden um die entsprechende Kapazität zur Verfügung zu stellen.

Schritt 4
Jetzt aktivieren wir den Cluster-Modus. Zuerst auf dem zukünftigen Knoten 0, danach auf Knoten 1. Als Cluster ID stehen die Zahlen 1 bis 15 zur Verfügung. Sollten mehrere Cluster in einem Netzwerk verwendet werden müssen diese verschiedene Cluster-IDs haben. Dies deswegen weil die Cluster-ID zur Bildung von (virtuellen) MAC-Adressen der redundanten Interfaces herangezogen werden und es sonst zu uneindeutigen MAC-Adressen kommen könnte.

Wichtig: Die folgenden Befehle werden im Operations und nicht wie man glauben könnte, im Configuration-Mode, abgesetzt:

1. Auf Knoten 0: set chassis cluster cluster-id 1 node 0 reboot
2. Der Knoten 0 startet neu, wir warten ab bis er den Reboot Vorgang abgeschlossen hat
3. Auf Knoten 1: set chassis cluster cluster-id 1 node 1 reboot
4. Der Knoten 1 startet neu, wir warten ab bis er den Reboot Vorgang abgeschlossen hat

Nach kurzer Zeit sollte das HA Lämpchen auf beiden Geräten Grün leichten. Dies ist das Zeichen dafür, dass ich die Knoten gefunden und ihre Konfiguration abgeglichen haben. Wir können dies Überprüfen, indem wir auf einem der beiden Knoten den Befehl show chassis cluster status absetzen:

Cluster ID: 1
Node name Priority Status Preempt Manual failover

Redundancy group: 0 , Failover count: 1
node0 1 primary no no
node1 1 secondary no no

Weiters müssen wir beachten, dass sich nun die Bezeichnungen der Interfaces geändert haben. Auf Knoten 0 bleibt alles so wie es ist, auf Knoten 1 hat es aber eine Verschiebung gegeben. Das ge-0/0/0 Interface heißt jetzt ge-2/0/0, fe-0/0/2 nun fe-2/0/2 usw. Eine genaue Liste wie die Interface-Namen sich verändern liefert dieser Teil des JUNOS-Handbuchs.

Schritt 5
Die Interfaces des Fabrik-Links müssen in der Konfiguration angegeben werden. Wir tun dies per

set interfaces fab0 fabric-options member-interfaces ge-0/0/1
set interfaces fab1 fabric-options member-interfaces ge-2/0/1

Schritt 6
Es gibt einige Konfigurationselemente die auf den jeweiligen Knoten anders sind. Z.B. der Hostname des Knotens oder die IP-Adresse des Out of Band Management Interfaces. Letzteres fehlt bei der SRX 210, wir müssen uns also nur um den eindeutigen Hostnamen kümmern. Man stellt dies mit zwei Apply-Gruppen ein:

set groups node0 system host-name node0 set groups node1 system host-name node1

Um die Apply-Gruppen anzuwenden setzen wir noch ab:

set apply-groups "${node}"

Wir können nun commiten.

Schritt 7
Wir können uns nun der Konfiguration der redundanten Interfaces zuwenden. In unserer simplen Konfiguration möchte ich folgendes herstellen:


Wir benötigen hier zwei redundante Interfaces: Ein Trust und ein Untrust Interface. In der Praxis würde man hier auch jeweils zwei Switches verwenden um sich nicht noch einen Single-Point-of-Failure einzuhandeln. In unserem einfachen Fall ist das aber völlig ausreichend. Wir verwenden dafür die Interfaces ge-0/0/0 und ge-2/0/0 und fe-0/0/2 und fe-2/0/2.

Damit beide Interfaces unabhängig voneinander ein Failover durchführen können, werden wir das redundante Interface in jeweils eine eigene Redundanzgruppe einbringen.

Zuerst müssen wir dem System bekannt geben, dass wir zwei redundante Interfaces benötigen:

set chassis cluster reth-count 2

Danach legen wir die Konfiguration der einzelnen Redundanzgruppen an. Ich möchte das immer der Konten 0 aktiv ist solange möglich, aber ohne automatisches Failback. Weiters soll ein Failover ausgelöst werden, wenn eines der beteiligten Interfaces down geht und es aber gerade aktiv ist.

set chassis cluster redundancy-group 1 node 0 priority 100
set chassis cluster redundancy-group 1 node 1 priority 50
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/0 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-2/0/0 weight 255
set chassis cluster redundancy-group 2 node 0 priority 100
set chassis cluster redundancy-group 2 node 1 priority 50
set chassis cluster redundancy-group 2 interface-monitor fe-0/0/2 weight 255
set chassis cluster redundancy-group 2 interface-monitor fe-2/0/2 weight 255

Das Gewicht 255 bei den Interfaces verdient noch etwas Beachtung. Unter Umständen möchte man ein Failover nicht schon bei einem Interface sondern erst wenn zumindest zwei oder mehrer Interfaces ausgefallen sind. Damit kann man jedem Interface ein individuelles Gewicht geben. Überschreitet die Summe der Gewichte der ausgefallenen Interfaces 255, wird ein Failover ausgelöst. Da uns schon ein Interface ausreicht, vergeben wir hier jeweils 255.

Jetzt konfigurieren wir die beiden Redundanzinterfaces reth0 und reth1:

set interfaces reth0 redundant-ether-options redundancy-group 1
set interfaces reth0 unit 0 family inet address 192.168.0.1/24
set interfaces reth1 redundant-ether-options redundancy-group 2
set interfaces reth1 unit 0 family inet dhcp

Das Untrust-Interface soll seine IP-Adresse per DHCP vom Provider bekommen. Beim Trust Interface legen wir 192.168.0.1/24 fest.

Danach binden wir die physischen Interfaces an das jeweilige redundante Interface:

set interfaces ge-0/0/0 gigether-options redundant-parent reth0
set interfaces ge-2/0/0 gigether-options redundant-parent reth0
set interfaces fe-0/0/2 fastether-options redundant-parent reth1
set interfaces fe-2/0/2 fastether-options redundant-parent reth1

Zum Schluss benötigen wir noch ein paar Firewall-spezifische Konfigurationen:

Wir fügen die redundanten Interfaces jeweils einer Zone hinzu und erlauben den notwendigen eingehenden Traffic:

set security zones security-zone trust interfaces reth0.0 host-inbound-traffic system-services all
set security zones security-zone untrust interfaces reth1.0 host-inbound-traffic system-services dhcp

Weiters müssen wir noch Source NAT aktivieren:

set security nat source rule-set outgointNAT from zone trust
set security nat source rule-set outgointNAT to zone untrust
set security nat source rule-set outgointNAT rule rule1 match source-address 0.0.0.0/0
set security nat source rule-set outgointNAT rule rule1 match destination-address 0.0.0.0/0
set security nat source rule-set outgointNAT rule rule1 then source-nat interface

Der Client muss derweil statisch konfiguriert werden, einen DHCP-Server auf der SRX einzurichten erspare ich mir. :-)

Das ganze noch commiten und schon ist unser Cluster fertig. Bei einem Link-Fehler geht 1 Ping verloren, beim Ausfall einer ganzen Box dauert es ca. 8 Pings bis das System sich wieder stabilisiert hat.

Viel Spaß beim Nachmachen!

Kapazitätsberechnung bei Switches

Das Ethernet hat seinen Siegeszug in mittlerweile fast alle Bereiche getragen. Entsprechende Bedeutung hat eine der zentralen Komponenten in einem Ethernet-Netzwerk – der Switch. Daher ist es wichtig, seine Kapazität zu berechnen. Einem Datenblatt des Juniper EX4200-48P Switches entnehme ich z.B. folgende Angaben (http://www.juniper.net/us/en/local/pdf/datasheets/1000215-en.pdf):

Packet Switching Capacity: 136 Gbps
Layer 2 Throughput: 101 Mpps (wire speed)

Doch wie lassen sich diese Werte berechnen? Zuerst zur Kapazität der Backplane. Der Switch unterstützt 48 Gigabit Ports sowie zwei 10 GbE Ports. Jeder der Ports kann im Full-Duplex Betrieb arbeiten und jeweils 1 GbE senden und empfangen (bzw. 10 GbE bei den 10 GbE Ports). Das ergibt in Summe

2 x 48 + 2 x 20 = 136

Das ist (nicht ganz zufällig J) die angegebene Backplane Kapazität. Diese ist also stark genug um selbst bei Maximalauslastung die Daten schnell genug transportieren zu können.

Was hat es nun mit der Angabe Mpps auf sich? Diese steht für Mega Packets per Second. Dabei geht es eigentlich um Frames, genauer um Ethernet II Frames bzw. Frames nach 802.1q, das sind Frames mit VLAN Tagging. Diese Frames können verschiedene Größen haben. Um mit einer hohen maximalen Frameanzahl zu glänzen messen die Switch-Hersteller Frames der kleinsten Größe – 64 Bytes. Allerdings geht jedem Frame eine sogenannte Präambel voraus – eine Folge von 101010…, 8 Byte lang. Außerdem folgt jedem Frame eine Sendepause, das sogenannte Interframe Gap. Es ist 96 mal so lange wie die Übertragungsdauer eines Bits dauert. Wir können also genauso rechnen als würden 96 Bit Daten übertragen. Die Gesamtlänge eines Frames beträgt also 672 Bit.

Damit kann ein Gigabit Port genau

1 GBit/s / 672 Bit = 1.597.830 Frames pro Sekunde übertragen

Ein 10 GbE Port entsprechend 10x so viel. Auf die 48 Port sowie zwei 10 GbE Ports aufgerechnet ergibt dies

48 x 1.597.830 + 2 x 10 x 1.597.830 = 108.652.440 Frames pro Sekunde

bzw. 104 Mpps. Der Unterschied zu 101 Mpps ergibt sich durch kleine Abweichungen der Theorie zur Praxis. Die Behauptung „Wire Speed“ des Herstellers trifft also zu.

Stolz

Es macht einen doch immer ein wenig Stolz, wenn man einen Bug reported und es dann in letzter Instanz einen Hotfix gibt. Ich hatte vor einigen Monaten bemerkt, dass bei SBS 2008 Systemen die angebotene Remoteunterstzüng fehlschlägt. Nach Eskalationen ist der ganze Case dann beim Entweickeler-Team in Redmond gelandet und es gibt nun - auch offiziell - einen Hotfix:

Error message when you try to offer Remote Assistance from an expert computer that is running Windows Server 2008 or Windows Vista: "Windows Remote Assistance is closing"
http://support.microsoft.com/kb/970907/en-us

Viel Spaß beim Patchen.

Fehler 675 mit Code 0x19 auf Domänen-Controller

Kürzlich sind mir auf dem Domänen-Controller eines Kunden viele 675er Fehler im Sicherheitsprotokoll aufgefallen, nachdem dieser Windows Server 2008 Server in seinem Netzwerk eingeführt hatte. Fehler wie diese:

Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 675
Date: 5/21/2009
Time: 6:03:07 PM
User: DOMAIN\USER
Computer: SERVER
Description:
Pre-authentication failed:
User Name: Administrator
User ID: DOMAIN\USER
Service Name: krbtgt/domain.tld
Pre-Authentication Type: 0x0
Failure Code: 0x19
Client Address: 192.168.0.1

Der Fehlercode 0x19 steht für KDC_ERR_PREAUTH_REQUIRED. Das findet man mit dem Programm err.exe heraus. Wer es noch nicht kennt findet hier mehr zu dazu.

Auf den ersten Blick ist das ganze ein wenig irritierend, weil der entsprechende User die Pre-Authentication nicht deaktiviert hatte, also die Standardeinstellungen belassen wurden.

Aber dann führt eine Recherche zu folgendem Artikel auf Technet:

Kerberos Enhancements
http://technet.microsoft.com/en-us/library/cc749438.aspx

Darin wird angeführt, dass unter Windows Vista (und damit auch bei Windows Server 2008) die AES Verschlüsselung für Kerberos eingeführt wurde. Vorher (in Windows 2000 und 2003) gab es nur DES und 3DES. AES ist nun nicht nur möglich sondern auch die Standardeinstellung. Das klappt aber nur dann, wenn sowohl der Domänen-Controller als auch der zugreifende Client mindestens Windows Vista oder höhere ausführen.

Bei meinem Kunden war der Domänen-Controller aber noch eine Windows Server 2003 Maschine, die die Kerberos Pre-Authentication mit AES zurückgewiesen hat. Dabei loggt er dann die 675er Fehlermeldung die ich im Sicherheitsprotokoll gefunden habe. Vista und höher fällt dann automatisch auf 3DES zurück sodass es beim zweiten Versuch immer klappt.

Gehen einem diese Fehlermeldungen auf die Nerven kann man Vista und Windows Server 2008 dazu bringen, standardmässig 3DES statt AES zu verwenden. Das geht mit folgendem Registry-Key:

Schlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Name: DefaultEncryptionType
Typ: DWORD
Wert: 0x17

Ein Neustart und die Sache ist vorbei. Allerdings wäre natürlich der bessere Weg, die Domänen-Controller auf Windows Server 2008 upzugraden damit die stärkere AES Verschlüsselung zur Anwendung kommen kann.

Benutzerkonto kann auf Server nicht abgemeldet werden

Kürzlich kam mir bei einem Kunden folgendes Problem unter. Nachdem ich mich auf einem seiner Server angemeldet hatte, konnte ich mich nicht wieder abmelden. Auf den Befehl Abmelden aus dem Startmenü reagierte die Maschine nicht. Auch Herunterfahren oder Neustarten (das ja den Abmeldevorgang beinhaltet) konnte man nicht durchführen. Nur mit Hilfe des Befehls shutdown.exe und dessen Schalter -f (für force, zu deutsch erzwingen) konnte die Maschine zum Neustart bewegt werden. Das Problem konnte erst seit kurzem bestanden haben da laut übereinstimmender Aussage des lokalen IT Personals der Abmeldevorgang vor kurzem noch anstandslos funktioniert hatte.

Im Ereignisprotokoll fand sich folgende Warnung:

Event Type: Warning
Event Source: USER32
Event Category: None
Event ID: 1073
Date: 23.05.2009
Time: 19:35:29
User: DOMAIN\Administrator
Computer: SERVER
Description: The attempt by user DOMAIN\Administrator to restart/shutdown computer SERVER failed
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data: 0000: 80 48 3e 77 €H>w

Typisch in so einem Fall ist, dass Programme noch einen Handle auf eine Datei und/oder die Registry des aktuell angemeldeten Benutzers offen lassen und so das Entladen des Profils verhindern. Um diese Theorie zu untermauern habe ich zuerst das User Environment Loggin aktiviert:

How to enable user environment debug logging in retail builds of Windows
http://support.microsoft.com/kb/221833/EN-US/

Das Logfile war leider beim Abmeldevorgang nicht ergiebig und zeigte überhaupt keinen Eintrag. Eine genauere Analyse zeigte, dass man nach dem Neustart sich einmal abmelden konnte. Ab der zweiten Abmeldung schlug diese fehl. Die erste Abmeldung schien zu klappen:

USERENV(1630.1624) 17:50:05:768 LibMain: Process Name: C:\WINDOWS\system32\userinit.exe
USERENV(180.184) 17:50:10:037 UnloadUserProfile: Entering, hProfile = <0x828>
USERENV(180.184) 17:50:10:053 UnloadUserProfile: In console winlogon process
USERENV(180.184) 17:50:10:053 UnloadUserProfileP: Entering, hProfile = <0x828>
USERENV(180.184) 17:50:10:053 GetExclusionListFromRegistry: Policy list is empty, returning user list = USERENV(180.184) 17:50:10:053 CSyncManager::EnterLock
USERENV(180.184) 17:50:10:053 CSyncManager::EnterLock: No existing entry found
USERENV(180.184) 17:50:10:053 CSyncManager::EnterLock: New entry created
USERENV(180.184) 17:50:10:053 CHashTable::HashAdd: S-1-5-21-1801674531-1677128483-839522115-500 added in bucket 5
USERENV(180.184) 17:50:10:053 UnloadUserProfileP: Wait succeeded. In critical section.
USERENV(180.184) 17:50:10:491 MyRegUnLoadKey: Returning 1.
USERENV(180.184) 17:50:10:491 UnloadUserProfileP: Succesfully unloaded profile
USERENV(180.184) 17:50:10:678 MyRegUnLoadKey: Returning 1.
USERENV(180.184) 17:50:10:678 UnLoadClassHive: Successfully unmounted S-1-5-21-1801674531-1677128483-839522115-500_Classes
USERENV(180.184) 17:50:10:678 UnloadUserProfileP: Successfully unloaded user classes
USERENV(180.184) 17:50:10:710 UnloadUserProfileP: Impersonated user
USERENV(180.184) 17:50:10:710 UnloadUserProfileP: Writing local ini file
USERENV(180.184) 17:50:10:710 UnloadUserProfileP: Reverting to Self
USERENV(180.184) 17:50:10:710 UnloadUserProfileP: exitting and cleaning up
USERENV(180.184) 17:50:10:710 CSyncManager::LeaveLock
USERENV(180.184) 17:50:10:710 CSyncManager::LeaveLock: Lock released
USERENV(180.184) 17:50:10:710 CHashTable::HashDelete: S-1-5-21-1801674531-1677128483-839522115-500 deleted USERENV(180.184) 17:50:10:710 CSyncManager::LeaveLock: Lock deleted
USERENV(180.184) 17:50:10:710 UnloadUserProfileP: Leave critical section.
USERENV(180.184) 17:50:10:710 UnloadUserProfileP: Leaving with a return value of 1
USERENV(180.184) 17:50:10:710 UnloadUserProfile: UnloadUserProfileP succeeded
USERENV(180.184) 17:50:10:710 UnloadUserProfile: returning 1
USERENV(fe0.ac4) 17:52:43:285 InitializePolicyProcessing: Initialised Machine Mutex/Events
USERENV(fe0.ac4) 17:52:43:285 InitializePolicyProcessing: Initialised User Mutex/Events
USERENV(fe0.ac4) 17:52:43:285 LibMain: Process Name: \??\C:\WINDOWS\system32\winlogon.exe
USERENV(180.184) 17:52:46:333 LoadUserProfile: Yes, we can impersonate the user. Running as self

Doch bei der zweiten Anmeldung konnte man sehen, dass das Profil in Wahrheit gar nicht vollständig entladen werden konnte:

USERENV(128c.1270) 17:52:46:973 GetProfileType: Profile already loaded.

In so einem Fall ist immer installierte Drittanbieter-Software verdächtig. Hier hilft das Programm msconfig.exe mit deren Hilfe man selektiv Drittanbieterdienste deaktivieren kann:


Sukzessives Ab- und wieder Anschaltern der Dienste ergab den Bösewicht. Es war das Dienst LanSafe Power Monitor. Er gehört zur USV des Kunden und löst im Fall eines Stromausfalls einen kontrollierten Shutdown aus. Mithilfe des Process Explorer von Sysinternals (http://technet.microsoft.com/de-de/sysinternals/bb896653.aspx) zeigt sich, dass der Dienst als Kind auch ein Starmenü-Tray Applet als Kindprozess startet:


Nachdem der Dienst selbst nicht in der Benutzersitzung läuft richtet sich der Verdacht gegen das kleine Hilfsprogramm. Tatsächlich: Beendet man das Programm unsanft wird der Abmeldevorgang sofort anstandslos durchgeführt. Leider hatte der Kunde bereits die aktuelle Version der Software im Einsatz sodass ein Update auf eine neue Version nicht möglich war.

Nachdem der Fehler erst seit kurzem Aufgetreten war, setzte ich eine virtuelle Maschine auf um das Problem hier zu reproduzieren. Die Updates wurden der Reihe nach eingespielt und der Fehler zu reproduzieren versucht. Er trat auf nach dem Einspielen des Internet Explorer 7 bzw. 8. Tatsächlich hatte der Kunde vor kurzem auf den IE7 aktualisiert. Konkret war offenbar das Update IDNMitigationAPIs verantwortlich, das als Voraussetzung für den IE7 (und 8) installiert wird. Es findet sich leider recht wenig Information im Internet, was dieses Hotfix im Detail bewirkt.

Der Hersteller gibt weder in den Release Notes noch in der Dokumentation Probleme mit dem IE7 an, ich habe daher empfehlen den Hersteller zu kontaktieren und in der Zwischenzeit die Tray Applikation manuell zu beenden.