Hi All,

One of my user has this very strange problem when accessing one of our
Intranet website which uses Integrated Windows Authentication.  The case is
as below.

She is using Intenet Explorer 6 and when she tries to access the website,
she gets a prompt to logon.  The website is on 2 Windows 2003 web servers
which are NLB.  We are using ISA 2000 as our proxy server.  I try the
following steps to troubleshoot.

1) Confirm that the URL (FQDN) was in the bypass proxy exception list and
even added the URL into the Intranet zone.  Ensure that "Automatic logon
only in Intranet zone" and "Enable Integarted Windows Authentication" was
selected.
2) I check on the permission on both web servers and make sure she has
access.  Can't find any clue.
3) I logon to her computer using my account and I do not get the prompt.
4) I export the registry key
 HKEY_USERS\MySID\Software\Microsoft\Wind
ows\CurrentVersion\Internet Settings
which was created when I logon to her computer and import it into her
 HKEY_CURRENT_USER\Software\Microsoft\Win
dows\CurrentVersion\Internet
Settings key.  It doesn't work.
5) Created a new website on the web server which also uses Integrated
Windows Authentication and she can access without getting the prompt.
6) Using her account, I logon to another computer and try to access the
problematic web site and this time I do not get the prompt.
7) Back to her computer and logon using her account and access the
problematic web site using only the host name and it works.  Try using IP
address and it works (the IP address is also in the exception list).
8) I monitor the ISA server and access the problematic web site using FQDN
at the same time and confirm that it is not going through the ISA proxy
server.

What I can conclude now is when she logon to her computer using her account
and access the web site using FQDN then she gets the logon prompt.  I really
have no idea how can this happens.  The last thing I will do is to re-create
her profile on her computer.

If anyone of you have some suggestions, please do let me know.


Thank you very much,
Alex

[ Post a follow-up to this message ]

Hi Alex,

If you change her Internet option->Intranet zone->Custom level to
'Automatic logon with current usenam and password', will the her
account still meet the prompt up behavior? The behavior is really
weird. I think you've performed comprehensive tests except capturing
network monitor trace... Perhaps you may check her account's access
records in IIS log. If the problem is actually IE hasn't sent
credential to IIS server. You should only see 401.1 return without a
username(cs-username).

Internet Explorer May Prompt You for a Password
http://support.microsoft.com/?id=258063

Best regards,

WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

[ Post a follow-up to this message ]

Hi Alex,

I wonder if you've got any progress or findings about this issue?

Best regards,

WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

[ Post a follow-up to this message ]

Hi WenJun,

The user is not in the office so I can't try anything yet.  I will post the
update once I get my hand on her laptop.

Anyway, I have forgotten to mention that I have also tried the "Automatic
logon with current username and password" option.

Here is an extract from the IIS log file.  I have remove the server and
client IP addresses.  From styles.css onwards, the client is accessing the
customize access denied webpage.

2004-08-04 07:01:21 WebServer_IP_Address GET /eforms - 80 -
Client_IP_Address Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 401 2
2148074254
2004-08-04 07:01:21 WebServer_IP_Address GET /eforms - 80 -
Client_IP_Address Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 401 1 0
2004-08-04 07:01:21 WebServer_IP_Address GET /eforms - 80 -
Client_IP_Address Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 401 1
2148074252
2004-08-04 07:01:28 WebServer_IP_Address GET /eforms - 80 -
Client_IP_Address Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 401 2
2148074254
2004-08-04 07:01:28 WebServer_IP_Address GET /eforms - 80 -
Client_IP_Address Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 401 1 0
2004-08-04 07:01:28 WebServer_IP_Address GET /eforms - 80 -
Client_IP_Address Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 401 1
2148074252
2004-08-04 07:01:30 WebServer_IP_Address GET /styles.css - 80 -
Client_IP_Address Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 200 0 6
4
2004-08-04 07:01:30 WebServer_IP_Address GET /AccessDenied.jpg - 80 -
Client_IP_Address Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 200 0 6
4
2004-08-04 07:01:30 WebServer_IP_Address GET /corplogo.gif - 80 -
Client_IP_Address Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 200 0 0
2004-08-04 07:01:30 WebServer_IP_Address GET /button1A.jpg - 80 -
Client_IP_Address Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 200 0 6
4
2004-08-04 07:01:30 WebServer_IP_Address GET /button1B.jpg - 80 -
Client_IP_Address Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 200 0 6
4
2004-08-04 07:01:30 WebServer_IP_Address GET /button1C.jpg - 80 -
Client_IP_Address Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 200 0 6
4

Thanks,
Alex



""WenJun Zhang[msft]"" wrote:

> Hi Alex,
>
> I wonder if you've got any progress or findings about this issue?
>
> Best regards,
>
> WenJun Zhang
> Microsoft Online Support
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> Get Secure! - www.microsoft.com/security
>
>

[ Post a follow-up to this message ]

Hi Alex,

That's ok. I'm looking forward to your further test results.

The log shows the authentication failed with return codes:

401.2

401.1

401.1

The most possible cause of the last 401.1 error is client-side sent
an invalid credential to the server-side. If the failure is
permission related, the return code will become 401.3. A typical
successful IE - IIS auto integrated authenication(NTLM) process
should be:

401.2 (IE first tries anonymous access, IIS returns 401.2 - failed
due to server doesn't allow this auth type)

401.1 (IE and IIS exchange the NTLM hash in HTTP header )

200 (Authentication is passed)

I think you may run webfetch to perform some tests. It's a quite
greater client than IE to troubleshoot this kind of authentication
issues:

HOW TO: Use Wfetch.exe to Troubleshoot HTTP Connections
http://support.microsoft.com/defaul...kb;en-us;284285

Select Kerberos or NTLM explicitly and input her problematic account
to test the access. If this works, the problem should be confirmed on
her IE.

Best regards,

WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

[ Post a follow-up to this message ]

Hi WenJun,

I have use wfetch to confirm that it is not her account that is causing the
problem.  However, I manage to solve the problem after narrowing down the
possibilities.  The latest suspect I have in mind is the wrong logon
credential for that web-site was cache somewhere in her laptop and true
enough I found it in Control Panel -> User Accounts, Advanced tab, Manage
Passwords.  The url was in the list with the wrong logon credential
associated with it.  I remove the url and it works.

Thanks for helping me on the troubleshooting process.  You have provided me
valueable information and wfetch is a good tool.


Best Regards,
Alex



""WenJun Zhang[msft]"" <v-wzhang@online.microsoft.com> wrote in message
news:OStXAcrfEHA.3340@cpmsftngxa06.phx.gbl...
> Hi Alex,
>
> That's ok. I'm looking forward to your further test results.
>
> The log shows the authentication failed with return codes:
>
> 401.2
>
> 401.1
>
> 401.1
>
> The most possible cause of the last 401.1 error is client-side sent
> an invalid credential to the server-side. If the failure is
> permission related, the return code will become 401.3. A typical
> successful IE - IIS auto integrated authenication(NTLM) process
> should be:
>
> 401.2 (IE first tries anonymous access, IIS returns 401.2 - failed
> due to server doesn't allow this auth type)
>
> 401.1 (IE and IIS exchange the NTLM hash in HTTP header )
>
> 200 (Authentication is passed)
>
> I think you may run webfetch to perform some tests. It's a quite
> greater client than IE to troubleshoot this kind of authentication
> issues:
>
> HOW TO: Use Wfetch.exe to Troubleshoot HTTP Connections
> http://support.microsoft.com/defaul...kb;en-us;284285
>
> Select Kerberos or NTLM explicitly and input her problematic account
> to test the access. If this works, the problem should be confirmed on
> her IE.
>
> Best regards,
>
> WenJun Zhang
> Microsoft Online Support
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> Get Secure! - www.microsoft.com/security
>

[ Post a follow-up to this message ]

Alex,

I'm very glad to hear you've found out the root cause. The result of
you also makes much sense for me to troubleshoot 401.1 error on XP
clients in further.

Pleasure to work with you on this case. Whenever you meet any problem
related to IIS, please don't hesitate to post in this group. I'm
always here to be of assistance.

Best regards,

WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

[ Post a follow-up to this message ]

This was the answer I was searching for a long time. I can't believe there i
s
not a Knowledge base article on this exact issue of 'Password Caching'. I
have had this problem for awhile and knew it was a 'local' machine problem
but could not track it down. Thank you very much Alex.

"Yukon" wrote:

> Hi WenJun,
>
> I have use wfetch to confirm that it is not her account that is causing th
e
> problem.  However, I manage to solve the problem after narrowing down the
> possibilities.  The latest suspect I have in mind is the wrong logon
> credential for that web-site was cache somewhere in her laptop and true
> enough I found it in Control Panel -> User Accounts, Advanced tab, Manage
> Passwords.  The url was in the list with the wrong logon credential
> associated with it.  I remove the url and it works.
>
> Thanks for helping me on the troubleshooting process.  You have provided m
e
> valueable information and wfetch is a good tool.
>
>
> Best Regards,
> Alex
>
>
>
> ""WenJun Zhang[msft]"" <v-wzhang@online.microsoft.com> wrote in messag
e
> news:OStXAcrfEHA.3340@cpmsftngxa06.phx.gbl... 
>
>
>

[ Post a follow-up to this message ]