Internet Explorer May Improperly Prompt a User for Credentials

Retired KB Content Disclaimer

This article was written about products for which Microsoft no longer offers support. Therefore, this article is offered "as is" and will no longer be updated.


Under certain conditions, Internet Explorer will improperly prompt a user for credentials even though the user is logged on as an authorized user.

The conditions for this problem occur when a user has multiple instances of Internet Explorer 5.5 browsers running in a given session. Under these circumstances, it is possible that a properly authenticated user could be prompted for credentials when accessing a Web server. This is a problem when the target Web server uses the Windows NT LAN Manager (NTLM) challenge and response security scheme.


This behavior occurs when the browser is using the .ins configuration file. This problem is isolated, and occurs when the first instance of the browser attempts to read zone security information from the registry, and that instance of the browser is unable to determine the proper security zone of the Web site. This happens because the other instance of the browser is in the process of accessing the same registry keys. Under these conditions, the first instance of Internet Explorer falls back to the most restrictive mode, which is to prompt the logged-on user for the user credentials.


To resolve this problem, obtain the latest service pack for Internet Explorer version 5.5. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
276369 How to Obtain the Latest Internet Explorer 5.5 Service Pack
The English version of this fix should have the following file attributes or later:

Date Time Version Size File name
10/20/2000 03:50p 5.50.4522.1800 4,153,296 Advpack.dll
03/12/2001 10:17a 5.50.4522.1800 31,080
09/19/2000 04:42p 5.50.4522.1800 10,240 Instcat.exe
03/12/2001 10:17a 5.50.4522.1800 7,470
03/12/2001 10:17a 5.50.4522.1800 1,552 Q286338.inf
03/08/2001 11:41a 5.50.4522.1800 456,976 Urlmon.dll
11/21/1997 08:10a 5.50.4522.1800 21,504 Verinst.exe
10/20/2000 03:50p 5.50.4522.1800 2,272 W95inf16.dll
10/20/2000 03:50p 5.50.4522.1800 4,608 W95inf32.dll


To work around this problem, comment out the zone settings key in the .ins configuration file.

Example: Previous Configuration of the .INS File

[Security Imports]

Example: Recommended Configuration of the .INS File

[Security Imports]


Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. This problem was first corrected in Internet Explorer version 5.5 Service Pack 2.

More Information

When Internet Explorer is configured to use an .ins file, the .ins file will run various .inf files, which customize Internet Explorer. One of the customizations is the Zone customization, which is defined in the Seczones.inf file.

When Internet Explorer downloads the .ins file and configures it, it does various registry operations, one of which is deleting and re-creating the Internet settings\zonemap key. Internet Explorer keeps a handle to this key internally, and uses this handle to access any information under this key. When a new instance of Internet Explorer is opened, it once again downloads the .ins file and configures it. While configuring it, Internet Explorer once again deletes, and re-creates the zonemap key.

It is possible that the first instance will attempt to use the registry key, and that Internet Explorer will close because the operating system marks this key as deleted, and any registry operation will not succeed. This happens because the second instance of Internet Explorer is performing open and deletion operations on the zonemap registry keys. When this happens, the user sees the authentication dialog in the first instance of Internet Explorer because the first instance of Internet Explorer will be unable to determine the zonemap for a given URL, and fails to the safest configuration, which is to prompt the user for credentials.

Because the zone settings key is under both HKCU, and HKLM, and because both are identical, this prevents Internet Explorer from deleting the HKCU portion of the zonemap key, which solves the problem.

The impact of the suggested change is, that for any users on that computer, Internet Explorer will now no longer write to the HKCU key, and it reads all the information from HKLM key.

This is perfectly fine in almost all cases except for the following two:
  • If the administrator has locked down the HKLM key for write access, and you want to add/remove to the list of domains that you consider as Intranet, or change any zone settings, this may not work because HKLM key is locked down.
  • If the .ins file is rebuilt, the customer needs to remember to comment out this line at that time.

Article ID: 286338 - Last Review: Jun 19, 2014 - Revision: 1