0

In my network we're behind a proxy (pac script), when try to access a site in the following url format:

http://serverName.domain.com:8080/somePath

IE (9.0.8112.16421) is unable to browser the site (which requires http auth NTLM), but I'm able to open the home page at http://serverName.domain.com:8080/ (which it's actually the web server apache tomcat home page)

Please see last update, looks like the issue is more related to the NTLM auth

However I noticed that Chrome browses perfectly to the site and by opening the Developer tools (F12) in Internet explorer and setting the User Agent string to "Chrome", then IE is able to browse to the site without any other change.

Now the question is, is there any issue with proxy+http auth+ie ? <<udpate: wasn't the proxy>> what else changes when I use Chrome User Agent strings, why works in that way ?

I've been reading and know there are some ways to change IE9 (9.0.8112.16421) User agent like "permanently" using IEM (http://technet.microsoft.com/en-us/library/cc770379.aspx) and the windows register, but need admin rights and don't know if that's the issue or there's something else.

Note: When checking the "Network" tab in Dev Tools (IE) the results says "Aborted" and there's no even request headers/body just the response headers are available:

Key Value
Response    HTTP/1.1 401 Unauthorized
Server  Apache-Coyote/1.1
WWW-Authenticate    NTLM TlRMTVNTUAACAAAAAAAAACgAAAABggAAAAICAgAAAAAAAAAAAAAAAA==
Content-Type    text/html;charset=utf-8
Content-Length  951
Date    Fri, 16 Jan 2015 17:04:36 GMT
Cache-Control   proxy-revalidate
Proxy-Connection    Keep-Alive
Connection  Keep-Alive
Proxy-support   Session-based-authentication

Update I checked with partners in other country and they're able to open the site without switching their User Agent string, the proxy script looks pretty much the same, the information about the DNS from ipconfig command looks the same, I can only think there's something in our proxy server (where the pac script is placed) <<update: wasn't the proxy>>

I think I can discard any about the DNS servers, since by switching the User Agent I can reach the site but please comment if you know I'm not right about it.

Update 2 Just realized that setting ANY other custom User Agent I'm able to open the site, I even set the word "hello" and worked. After several try/fail also realized that the "MSIE" part in the string of the User Agent is the one causing the failure (besides any other bad config in the proxy server).

By removing the "MSIE" or even just the one character, I can browse the site, but If I include those 4 characters in ANY other User Agent string then I'm unable to browse the site.

Update 3 So far my teammates in other countries can access the site without using other User Agent string, everything points to the proxy+http auth messing up with active directory auth or something like that I have read some issues with the kerberos auth, but I'm no knowledge so far how does it works and why IE is having issues.

Update 4 I just checked the requests/responses from my teammates and it looks pretty much the same, they also use NTLM auth, but they are able to access to the site using Internet Explorer without modify the User Agent String.

Update 5 Well we got a domain migration for our local accounts, besides not going through "another networks" (we're latin american based and seems to me that our old domain was in asia or something like that, didnt' get much information from IT side) don't know of anyother change made it, but now it works., still if someone want to share any good idea about what could be possible have changed or how impacts the NTLM auth I would appreaciate comments/answers

Notes The web server is Apache Tomcat/7.0.33 and uses http auth, do you know/think is this a permission related thing in active directory ? I have the server name and IP, if this is by permissions, what kind of permission could I be missing ? When switching the User Agent to Chrome I dont'see the NTLM headers on fiddler, Why I do have access with Chrome User Agent (without NTLM auth) but not with IE (NTLM auth) <<update: after the domain migration I have access with IE and using NTLMT auth>> ?

Improve this question
9
  • The site you are visiting might be serving up different code based on the user agent string. Difficult to troubleshoot without knowing the actual site.
    – Alistair McMillan
    Jan 16, 2015 at 17:31
  • I believed that, but other partners (cross country) are able to browser the site with same IE version I'm using and alos with a pac proxy (pretty much the same code). The site is not public (that's why I used dummy names). So that reduce my problem to IE or the proxy, or both (I'm asking if my foreign partners did change their User Agent with IEM or by windows register, but wouldn't get answer until next week)
    – Allende
    Jan 16, 2015 at 18:07
  • When you say they are using the same IE version do you mean you are all on IE9? Cause it is worth checking the exact version (for example 9.00.8112.16599). We've had instances in the past where a bunch of customers were all on the one version of IE but a handful were crashing their browser when visiting a particular site. Turned out that handful hadn't been receiving IE patches.
    – Alistair McMillan
    Jan 16, 2015 at 18:50
  • Mmmm we're supposed to be in the exact same version since the IE is managed in centralized way and we're supposed to have installed same version, anyway will confirm so I don't skip that, now that could be the issue, but still the web page/IE does not actually crash, I'm just not able to browse it when IE 9 (9.0.8112.16421) use the default User Agent string
    – Allende
    Jan 16, 2015 at 19:40
  • I have seen several examples of this kind of thing happening, and all of them have been a server-side issue. Have you tried using an IE addon that spoofs the user agent?
    – BlueBuddy
    Jan 16, 2015 at 19:51

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .