4
Intranet-Website wird Internet-Zone zugeordnet - Authentifizierungsfehler HTTP 400
Eine Intranet-Website wird vom Internet Explorer (7 und 8 getestet) nur bei bestimmten Usern der Internet-Zone zugeordnet. Daraufhin wird NTLM statt Kerberos als Authentifizierung benutzt und die Website gibt den Fehlercode "HTTP 400 Ungültige Anforderung" zurück
Hallo zusammen!
Ich muss ein bisschen ausholen.
Wir verwenden einen Internet-Proxyserver (ISA) und eine Proxy.pac zur Konfiguration des Webbrowsers. Es ist der Internet Explorer 7 und 8 im Einsatz. In der Proxy.pac wird festgelegt, dass alle Intranet-Websites den Proxy-Server umgehend. Das funktioniert auch, die internen Websites gehen nicht über den Proxy. Als Zoneneinstellung für das "Lokale Intranet" ist festgelegt "Intranetnetzwerk automatisch ermitteln". Auch das funktioniert prinzipiell gut. Ich habe ein Problem mit einer bestimmten Website im Intranet. Sie lautet beispielsweise "http://meinserver/meinverzeichnis".
Diese Website wird im Internet-Explorer der Zone "Internet" zugeordnet. Dadurch wird nicht die Kerberos-Authentifizierung verwendet, sondern NTLM. Das unterstützt die Website wohl nicht und gibt den HTTP 400-Fehler zurück. Und jetzt wird es ganz skuril: Das Phänomen tritt nur bei einigen wenigen Usern auf - mir sind zwei User bekannt. Wenn diese User allerdings statt des Hostnamens die IP-Adresse des Server eingeben, also beispielsweise http://192.168.100.101/meinverzeichnis - dann geht es! Und dennoch: Es ist kein DNS-Problem. Die Namensauflösung funktioniert tadellos. Die Anfrage kommt ja auch beim Webserver und und läuft auf den HTTP 400-Fehler.
Und es geht noch ein bisschen seltsamer: Egal, was ich versuche und die Site-Einstellung im Internet Explorer manuell mache, d. h. http://meinserver/meinverzeichnis als Site der lokalen Intranetzone hinzufüge, die Site ist und bleibt in der Zone "Internet". Mit dem Firefox lässt sich die Site übrigens ohne Probleme aufrufen.
Ein Problem mit der Website selbst kann es nicht sein. 1000 andere User können die Site aufrufen. Es muss irgendetwas im User-Objekt im AD hängen, dass den Internet Explorer manipuliert. Das Erneuern des lokalen Benutzerprofils hat auch keine Besserung gebracht. Ich bin mit meinem Latein wirklich am Ende.
Vielen Dank im Voraus für die Unterstützung!
Michael
Ich muss ein bisschen ausholen.
Wir verwenden einen Internet-Proxyserver (ISA) und eine Proxy.pac zur Konfiguration des Webbrowsers. Es ist der Internet Explorer 7 und 8 im Einsatz. In der Proxy.pac wird festgelegt, dass alle Intranet-Websites den Proxy-Server umgehend. Das funktioniert auch, die internen Websites gehen nicht über den Proxy. Als Zoneneinstellung für das "Lokale Intranet" ist festgelegt "Intranetnetzwerk automatisch ermitteln". Auch das funktioniert prinzipiell gut. Ich habe ein Problem mit einer bestimmten Website im Intranet. Sie lautet beispielsweise "http://meinserver/meinverzeichnis".
Diese Website wird im Internet-Explorer der Zone "Internet" zugeordnet. Dadurch wird nicht die Kerberos-Authentifizierung verwendet, sondern NTLM. Das unterstützt die Website wohl nicht und gibt den HTTP 400-Fehler zurück. Und jetzt wird es ganz skuril: Das Phänomen tritt nur bei einigen wenigen Usern auf - mir sind zwei User bekannt. Wenn diese User allerdings statt des Hostnamens die IP-Adresse des Server eingeben, also beispielsweise http://192.168.100.101/meinverzeichnis - dann geht es! Und dennoch: Es ist kein DNS-Problem. Die Namensauflösung funktioniert tadellos. Die Anfrage kommt ja auch beim Webserver und und läuft auf den HTTP 400-Fehler.
Und es geht noch ein bisschen seltsamer: Egal, was ich versuche und die Site-Einstellung im Internet Explorer manuell mache, d. h. http://meinserver/meinverzeichnis als Site der lokalen Intranetzone hinzufüge, die Site ist und bleibt in der Zone "Internet". Mit dem Firefox lässt sich die Site übrigens ohne Probleme aufrufen.
Ein Problem mit der Website selbst kann es nicht sein. 1000 andere User können die Site aufrufen. Es muss irgendetwas im User-Objekt im AD hängen, dass den Internet Explorer manipuliert. Das Erneuern des lokalen Benutzerprofils hat auch keine Besserung gebracht. Ich bin mit meinem Latein wirklich am Ende.
Vielen Dank im Voraus für die Unterstützung!
Michael
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 118582
Url: https://administrator.de/contentid/118582
Printed on: April 23, 2024 at 07:04 o'clock
4 Comments
Latest comment
Hallo Michael,
möglichlicherweise ist eine Group-Policy dafür verantwortlich.
Darüber kann man die Zonenzugehörigkeit steuern. Die Policy würde manuelle Änderungen immer wieder überschreiben.
Gruss,
Destry
möglichlicherweise ist eine Group-Policy dafür verantwortlich.
Darüber kann man die Zonenzugehörigkeit steuern. Die Policy würde manuelle Änderungen immer wieder überschreiben.
Gruss,
Destry
"Wenn diese User allerdings statt des Hostnamens die IP-Adresse des Server eingeben, also beispielsweise http://192.168.100.101/meinverzeichnis - dann geht es! Und dennoch: Es ist kein DNS-Problem."
Anwort selber geliefert: Muss es wohl dann sein. Auch die Antwort, mit Firefox geht es ist einleuchtend.
1. Host.conf vergleichen
2. Firewall-Rules
3. Proxy-Conf
4. Active Directory Conf. --> Rules
Firefox nutzt generell nicht die Einstellungen der Windows-Api (wie einige andere (selbstgebastelter) Browser auch!).
Kann dir leider kein konkreten Rat geben, da ich schliesslich nicht selber vor der Kiste hocke und einfach deine Begebenheiten/Netzwerk nicht wirklich kenne.
Greetz
Anwort selber geliefert: Muss es wohl dann sein. Auch die Antwort, mit Firefox geht es ist einleuchtend.
1. Host.conf vergleichen
2. Firewall-Rules
3. Proxy-Conf
4. Active Directory Conf. --> Rules
Firefox nutzt generell nicht die Einstellungen der Windows-Api (wie einige andere (selbstgebastelter) Browser auch!).
Kann dir leider kein konkreten Rat geben, da ich schliesslich nicht selber vor der Kiste hocke und einfach deine Begebenheiten/Netzwerk nicht wirklich kenne.
Greetz
Hi
Hatte das gleiche Problem und ist nun gelöst. Problem war, dass der Benutzer in zu vielen AD-Gruppen Mitglied war und dieser im http-header field nicht mehr Platz hatten. Hab den IIS auf NTLM-only umgeschalten und dann hat es geklappt.
Lösungsbeschreibung hab ich hier gefunden: http://www.marc-antho-etc.net/blog/post/HTTP11-400-Bad-Request-(Header- ...
Mit dem Befehl: cscript adsutil.vbs set w3svc/1/root/NTAuthenticationProviders "NTLM" konnte ich das Problem lösen.
Gruss,
Wolfgang
Hatte das gleiche Problem und ist nun gelöst. Problem war, dass der Benutzer in zu vielen AD-Gruppen Mitglied war und dieser im http-header field nicht mehr Platz hatten. Hab den IIS auf NTLM-only umgeschalten und dann hat es geklappt.
Lösungsbeschreibung hab ich hier gefunden: http://www.marc-antho-etc.net/blog/post/HTTP11-400-Bad-Request-(Header- ...
Mit dem Befehl: cscript adsutil.vbs set w3svc/1/root/NTAuthenticationProviders "NTLM" konnte ich das Problem lösen.
Gruss,
Wolfgang
Danke!
Genau das hat auch hier geholfen! Endlich!
Genau das hat auch hier geholfen! Endlich!
