Proxy-Authentication mit IE 7

[mturba 10]

Hallo,

ich habe ein Problem mit Proxy Authentication in Zusammenhang mit Internet Explorer 7. Vielleicht hat hier noch jemand eine Idee für eine Lösung dieses Problems, mir sind die Ideen ausgegangen.

 

Das Szenario ist folgendes: wir setzen zur Zeit eine ASA (mit Version 7.2) ein, um HTTP Proxy Authentication in unserem Gästenetz durchzuführen. Sobald also ein Gast versucht, eine Webseite zu öffnen, bekommt er die Anmeldeseite gezeigt. Nach erfolgreicher Authentfizierung wird vom RADIUS-Server die entsprechende Benutzer-Accessliste an die ASA übermittelt, die dann die normale Accessliste (für diesen Benutzer) ersetzt.

 

Während das mit dem Firefox oder IE 6 wunderbar funktioniert, gibt es seit IE 7 Probleme. Dieser möchte nämlich vor der Verbindung auf Stammzertifikats-Updates prüfen:

 

 

GET /msdownload/update/v3/static/trustedr/en/authrootseq.txt HTTP/1.1
Accept: */*
User-Agent: Microsoft-CryptoAPI/5.131.2600.2180
Host: www.download.windowsupdate.com
Connection: Keep-Alive
Cache-Control: no-cache
Pragma: no-cache

 

 

Dieser Verbindungsversuch wird von der ASA natürlich auch abgefangen und - wie bei einem ganz normalen HTTP-Verbindungsversuch auch, mit einem "moved temporarily" kommentiert:

 

HTTP/1.1 302 Moved Temporarily
Server: Adaptive Security Appliance HTTP/1.1
Location: [url]https://10.0.0.1:1443/netaccess/redirect.html?sid=2148668464[/url]
Connection: close

 

 

Daraufhin öffnet der IE 7 eine neue Verbindung, um auf Zertifikatsupdates zu prüfen, und zwar so lange, bis die ASA alle Connections resettet (in Abhängigkeit der Konfigurationsoption "aaa proxy-limit", standardmässig 16).

 

 

Die einzigen Workarounds, die mir bisher eingefallen sind, sind alle nicht so richtig zufrieden stellend:

 

1. Einen anderen Browser zur Authentifizierung verwenden (z.B. Firefox), der dieses Verhalten nicht zeigt. Dies ist problematisch, da Gäste nicht immer alternative Browser installiert haben und nicht über administrative Rechte auf ihrem Rechner verfügen, um einen Browser installieren zu können.

 

2. "Aktualisierung von Stammzertifikaten" deinstallieren:

* Start --> Systemsteuerung

* Software --> Windowskomponenten hinzufügen/entfernen

* Haken vor "Aktualisierung von Stammzertifikaten" entfernen

* Weiter --> Fertig stellen

Dies ist natürlich auch nur dann möglich, wenn Administratorrechte vorhanden sind. Zudem wird schnell vergessen, anschliessend die Aktualisierung von Stammzertifikaten wieder zu installieren.

 

3. Freigeben der IP-Adressen in der Accessliste des Gästenetzes

Leider scheint die Namensauflösung von http://www.download.windowsupdate.com eine schier unendliche (und sich ständig ändernde) Liste von IP-Adressen zu ergeben, so dass dies auch nicht praktikabel ist.

 

4. Die einzige Lösung kann also m.E. sein, eine Freigabe abhängig von der URL zu machen, zu der die HTTP-Verbindung aufgebaut werden soll. Dies lässt sich mit einer entsprechenden Policy-Map ja erreichen. Allerdings soll diese dann sinnvollerweise nicht mehr in Kraft treten, sobald die Authentifizierung durchgeführt wurde. Soweit ich weiß, kann man aber so etwas wie "per-user-override", was bei einer Accessliste ja möglich ist, bei service-policys nicht angeben.

 

Hat irgend jemand einen Hinweis, wie man da rangehen könnte?

 

 

Danke schonmal und viele Grüße,

Martin

[Wordo 11]

Heisst, Verbindung vom Client zum Proxy-Auth wird hergestellt, IE kennt das Root-CA nicht, und versucht dann von MS auf Updates zu pruefen ob eine neue Version vorliegt in der das Root-CA enthalten sein koennte?

[mturba 10]

Genau - solange der IE7 das allerdings nicht erfolgreich tun konnte, zeigt er dem Benutzer auch nicht die Proxy-Authentifizierungsseite.

[Wordo 11]

Und wenn du dem Client vorher das Root-CA installierst, macht ers dann auch?

[mturba 10]

Ja, das macht der Client immer, zumindest sobald die Windows-Komponente "Aktualisierung von Stammzertifikaten" installiert ist. Der IE7 prüft vor jedem ersten Verbindungsaufbau den Hashwert, der unter

http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt

zu finden ist und führt vermutlich, falls sich dieser geändert hat, entsprechende Updates der Stammzertifikate durch. Allerdings zeigt der IE7 keine Seite an, solange es nicht möglich war, diese Adresse zu erreichen.