I'm a computer consultant; my notebook computer is a member of my company's domain, not my clients' domains. One client company has an ISA 2004 SP2 firewall, to which my notebook is a web proxy client. I have a Domain Admin account on their network. ISA computer is a WS2003SP1 domain member.
This worked fine until about a week ago, when I kept getting prompted for credentials by ISA when I'd try to browse a web page. It would not accept my credentials on the company's domain.
Here's where it gets really weird: If I use Control Panel/User Accounts to cache my credentials for this server, IE prompts me for credentials, and when I finally give up, I get this ISA error page "Error Code: 407 Proxy Authentication Required. The ISA Server requires authorization to fulfill the request. Access to the Web Proxy service is denied. (12209)".
The Security log on the ISA 2004 computer shows this event: Logon Failure: Reason: Unknown user name or bad password User Name: `‚|+ ‚p0‚l $0" *†H‚÷ *†H†÷ +‚7 ¢‚B‚>`‚ Domain: <internaldomainname> Logon Type: 3 Logon Process: Advapi Authentication Package: Negotiate Workstation Name: SERVER4A Caller User Name: NETWORK SERVICE Caller Domain: NT AUTHORITY Caller Logon ID: (0x0,0x3E4) Caller Process ID: 3668 Transited Services: - Source Network Address: - Source Port: -
The user name, obviously, is not being passed correctly. Password is probably messed up, too, though there's no way to tell that. Account Lockout Tool does not show any bad passwords, but that would likely be because the username being furnished is gibberish so there's no account in AD to check the password against.
If I delete the credentials for that server from the Windows cache, IE7 doesn't even prompt me for credentials, and just times out. The Security log on the ISA computer show no logon/logoff events in this scenario.
I'm not aware of any changes to the ISA computer or my notebook coincident with the behavior change. I can connect to other network resources with the same credentials without problems. In fact, there's an ISA 2000 firewall on the same system that will soon be retired. It, too, requires authentication. If I make myself a Web Proxy client to the ISA 2000 firewall, I can browse the web.
I also find I can browse the ISA server via Explorer from other computers, but not from mine. When I try, I'm again prompted for credentials that are not accepted.
When I repeat these scenarios with another user account, I have the same result, so that at least rules out a problem with my user account.
So...we have a failure that can be reproduced on only ONE client computer and against only ONE server. Any idea where I look for the problem?
I don't have a solution for you but if its any consolation I can tell you you're not alone. I've been getting exactly the same problem for the past few weeks/months.
I've been working around it by supplying different proxy credentials (another user name and password that I have) and was waiting for my computer to be replaced in the hope that would fix it. The replacement happened this week and the problem hasn't gone away, in fact its got worse -- now my alternate user name doesn't work either and I've started using a third user name for the proxy credentials. This is obviously not a good situation, especially if I end up using a lot of alternate user names(!)
I've noticed the following about this problem: - If I boot my computer and log in, the problem usually doesn't happen straight away. Often I can happily browse the web for half an hour or more on my primary user name before ISA starts rejecting it and I have to use an alternate user name. - If I VPN into our network through the ISA Server from a remote location and proxy out through ISA to the 'net, I never have a problem.
It's a very weird problem that has had me and my colleagues stumped. Would be great if we can work out what's going on or if someone can come to our aid.
I've tried alternate credentials but had the same results as with my account.
Since my first post, I've tried connecting remotely via VPN and see the same thing you do; web proxy works that way.
I've been planning on replacing my notebook in the next couple months and have been hoping this problem would go away then. But if my experience matches yours, I probably shouldn't get my hopes up.
This MS Article (http://support.microsoft.com/kb/239869) does not reflect the OS's in your scenario, but it does address one thing about authentication that you may want to look into, NTLM. If the ISA Servers are configured in integrated mode and the primary webproxy Access rule requires authenticated users, the Domain controllers, ISA Servers and clients must be configured in a compatible or backwards compatible NTLM authentication mode, otherwise you will run into authentication problems. It's worth a look.
LMCompatibilityLevel is 0 on my WinXP client computer, 1 on the WS2003 ISA computer. Those should be compatible settings.
I think the seriously garbled username in the Event I posted must surely be a key. Can't say for sure it's unrelated to LMCompatibiltyLevel but I suspect it is.
I've also now duplicated Simon's observation that right after a client reboot, Web Proxy works, but a few minutes later, the problem reoccurs.
And as of late today, it's now affecting a 2nd computer and user account. The new computer is a domain member that was just set up. That's scary...as a part time consultant I can work around it on my computer, but I sure don't want it happening on their computers.
OK, when I change my HTTP/HTTPS/FTP rule to allow "All Users" instead of the custom "Internet Access" group, I can browse the web from both computers. When I again restrict it to the "Internet Access" group, the problem returns on both computers.
I also tried removing FWC; it did not change the behavior.
I also observed something else interesting. If I create a local user account in the ISA computer's SAM, and make it a member of "Internet Access", I can authenticate using that account when I'm prompted. But at least after the first 30 minutes or so since the local account was created, it still works.If this turns out to be consistent over time, then it looks like the problem only occurs with domain credentials.
So your authentication is setup on the access rule, which is fine. Does your Internal network also require all users to authenticate? What authentication Methods are enabled on your Internal Network?(basic, Integrated, etc.)
"Internal Network" is set to Basic & Integrated authentication. "Require all users to authenticate" is turned off. The default domain is set to the domain in which the users & computers (including ISA) are members.
LMCompatibilityLevel is 0 on my XP client computer, 1 on the WS2003 ISA computer, 1 on the WS2003 DCs, 1 on the XP client that just started having the problem. Those should be compatible settings.
I don't have FF or IEWatch. If I install FF, what do I need to look for?
Install Firefox and then get an add-on/extension called Live HTTP Headers.
Once that's done, open Firefox and type the following in the Address bar: about:config Then type "auth" in the filter field Make sure that the following are set to false: network.automatic-ntlm-auth.allow-proxies network.negotiate-auth.allow-proxies network.negotiate-auth.using-native-gsslib
Set the browser to use your ISA Server
Then launch Live HTTP Headers from the Tools Menu
And browse the Internet, you should be prompted for authentication, go ahead and login with your domain credentials. Look in the Live HTTP Header window and locate the Proxy-Authenticate: Is it showing Basic or NTLM?
If you authenticate with your domain credentials, what's the result?
Last you may want to set Basic authentication on your Internal Network, and de-select the Integrated to see if the problem is within Integrated NTLM.
And try the entire exercise again, what's the result?
We're starting to get hit with this error as well.
I've managed to dig up some information though, and some kind of a workaround.
In our case, we're connecting from WinXP workstations through ISA 2004 to the internet. All internet access is authenticated, and different groups of users from Active Directory are allowed different degrees of access.
Now, we've rolled out IE7 to all our PCs, and the peoblem only appears to have arisen since then.
I've looked at the headers sent/received by an IE7 machine in comparison to an IE6 machine and noticed the following. On IE6 the authentication with the proxy server is using NTLM. On IE7 by default it's using Negotiate (which is Kerberos). IE6 was not able to perform kerberos auth with a proxy server, only with web servers (and I've verified that it does indeed use kerberos on an IIS server and NTLM for the proxy). IE7 can apparently use kerberos for both the proxy and a web server and is certainly trying to do so.
If I change the web proxy settings on the ISA server to not use Integrated Windows Authentication and instead use Basic then authentication will always succeed however you have to type the username/password (or cache it).
If I turn Integrated Auth back on at the server, then in IE7 go to Tools, Internet Options, Advanced, scroll down to the bottom and untick "Enable integrated windows authentication" then close and re-open IE7 it will start using NTLM auth again instead of Kerberos. This seems to make everything start working again.
So to me it looks like either the new-fangled support-for-kerberos-authentication-to-proxies in IE7 is broken, or the previously not used very much accept-authentication-by-kerberos code in ISA SP2 is broken.
No solution here, yet. As my 2 accounts are the only ones it has affected so far, and I have workarounds, I've put it on the back burner. But I've found myself wondering about IE7, myself.
IE7 is only installed on a few machines. Not all IE7 machines have the problem; just these 2 that I'm aware of. I've planned to uninstall IE7 to see if that avoids the problem...now you've given me an even easier test. Thanks for the heads up...I'll report back on what I find.
[Edit]
Yup...turning off "Enable integrated windows authentication" allowed me to browse the web from both problem accounts on both problem computers. I think you've got it. I have a case open with MS PSS on the partner newsgroups; I'll forward this info to my tech tonight. Thanks for the insight!
At a quick glance, I don't see that this setting is settable via Group Policy with the IE7 .adm files. Also haven't found it in the obvious places in HKCU\Software\Microsoft\Internet Explorer or HKCU\...\Windows\CurrentVersion\Internet Settings. I'll be looking for a way to set this globally so we can roll out IE7 via WSUS in advance of a fix from MS...any ideas on that?
[Edit 2]
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\EnableNegotiotate = DWORD:0 to use NTLM, DWORD:1 for Kerberos.
I still don't see it in IE7 version of inetres.adm. So unless I find it, will probably set this value with Desktop Standard Registry Extensions.
< Message edited by JeffVandervoort -- 15.Jan.2007 7:50:20 PM >
Good to see that there's at least two of us with the same issue and the same workaround. We have ~20 users out of 1300 with the problem and turning off integrated auth has solved the problem for all of them, but it's a nasty workaround and it would be nice to know what's wrong and fix it properly!
PSS cites this article which says that IE7, like its predecessors, does not support Kerberos authentication against a proxy server, only against remote web servers:
Assuming that's true, it appears that successful browsing sessions are negotiating NTLM for some reason that is not immediately apparent to me, and our minority cases, where the user is prompted for authentication, are negotiating Kerberos.
Here's where it gets interesting: The article says
quote:
and does not respond to a negotiate challenge from a proxy server
That statement appears to be false. Which will be my next question to PSS.
Interesting. I'm relatively sure I came across an article the other day that stated that this was a new feature in IE7, but of course I can't find it again now!
I can certainly confirm that it is indeed trying to negotiate kerberos, and in fact in some cases even manages to do so correctly.
It looks like either the article is incorrect, or IE7 has the code in it to negotiate kerberos with a proxy but it's broken and so MS is saying it doesn't support it instead of fixing it.
From the MS Partner IE newsgroup comes this reply from MS PSS to my thread on this issue:
quote:
Based on my further research and discussing with other engineer, we notice this is a problem in ISA Server with IE7 and ISA deployment is hitting this issue.
You will need to disabled "Enabled Windows Integrated Authentication" in IE7 Advanced Options to workaround this temporarily. Please note that this will disable Kerberos auth completely so IE will not use Kerberos for authenticating against internal web servers which may be needed.
I do understand your concerns. From my point of view, I understand your feeling and how frustrated when you find that our product cannot meet your needs. So, it is my pleasure to help you to reflect your recommendation to the proper department for their consideration.
In addition, please feel free to submit your suggestion on our product to the following link. Our Product Group reviews the suggestions submitted by our customers. Your feedback is valuable for us to improve our products and increase the level of service provided.
So, there we have it. In plain English, more or less.
I still have a thread open on the ISA partner newsgroup with no response to the issue yet. When they respond, I'll update this thread if there's anything new.
My guess is we'll see a patch come down the WSUS pipe one of these days that either kills Kerberos against ISA and makes IE7 work like the KB article says it does, or else allows it to reliably authenticate against ISA using Kerberos. My hope is that it's the latter because it would be better for the customer, but the former would be more expedient for Microsoft.
Meantime, I guess I need to decide if I'm going to push the EnableNegotiate=DWORD:0 registry key by GPO or set it one-at-a-time on the problem clients. So far, I have a much higher failure rate but a much smaller sample size than micm, so it's a tricky decision.
I've pushed out the registry change to all my client PCs. After some investigation and polling of users, the problem ratio was probably about 10% which to me represents a fairly large user base (too many to have to advise individually through support channels).
It's nice to see that MS are admitting there is a problem. As you say I suspect there will be a patch that disables kerberos to ISA which brings it in line with the KB articles, though it would be ncie if it could be fixed and supported. NTLM hashes are not the best thing to have floating over your network, especially when Windows has pretty much moved wholesale to Kerberos.
I'll see if I can push this via support channels that I have also.
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
Printable Version
All Forums >> [ISA Server 2004 Cache] >> Web Proxy client >> Proxy authentication problem 
Proxy authentication problem - 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread