Why do I still get a user/password Login prompt with Integrate Authentication (for Virtual server 2005 Administration website)

When Integrated Authentication is enabled, users frequently wonder why they are still prompted for username/password. After all, isn't Integrated Authentication supposed to get rid of that?

Thus, the following question has come up several times when users install and use Virtual Server. While the problem looks like one with IIS or even Virtual Server somehow, it can be caused by the web browser's configuration, as described below.


I have just installed virtual server and am having problems with the administrative website. The host machine is Windows Server 2003 with SP1. The virtual server administrative website is set to allow integrated windows authentication yet when I try to access the page I am prompted for a username/password. If I enter username/password I can access the site. I have granted the appropriate permissions on the site home dir.

The administrative site address is:


If I enter the following address integrated windows authentication works and I am granted access to the site without being prompted for a username/password:


The site is not using host headers.

Any ideas would be appreciated


Actually, this problem is probably caused by your web browser not auto-authenticating to the VS 2005 admin website because it treats your two URLs as belonging in different Zones. One of the Zones is configured to auto-authenticate with current logged on user credentials and the other is not.

IE's default behavior is to auto-authenticate in Intranet Zone. "http://vsserver:1024" fits the pattern of an Intranet website. Meanwhile, "http://vsserver.north.root.domain.com:1024" fits the pattern of a dotted URL address, which is treated as the Internet Zone, which does not have auto-authenticate enabled.

Thus, IE does not auto-authenticate when you use the dotted URL address, meaning that when IIS requests your administrator credentials to access the VS2005 admin website, you get the user login popup.

To "fix" this, you either:

  1. Change the Zone which contains the second URL (dotted URL address)
  2. Change the auto-authenticate option of the existing Zone of the second URL

I suggest option #1 since you do not want the browser to auto-authenticate against arbitrary Internet websites.


Comments (32)

  1. Benny says:

    Great blog.  Hadme scrathing my head for a while.

  2. Chris Hedlund says:

    Thanks for the explanation – but could you tell us how to do that?

  3. David.Wang says:

    Chris – just look in IE’s "Internet Options" menu, "Security" tab, and it should be obvious how to:

    1. Add website addresses into each Security Zone

    2. Change "User AuthenticationLogon" behavior for each Security Zone


  4. Graham Russell says:

    Hi David,

    Many thanks for this, but unfortunately I am still having problems.

    I have added the sites but am now getting an error stating "The parameter is incorrect".

    This is only on the server (which is a vanilla Win 2003 server enterprise sp1 install).


  5. David.Wang says:

    Graham – IIS does not return such an error response, so can you provide the non-default configuration which you have performed.

    Since you say "this is only on the server" (I’m guessing things work from a remote client), I remind you of this known by-design issue:

    1. Use Integrated Authentication on the VS admin website (by default)

    2. Remote desktop into the Virtual Server Host machine

    3. From the remote desktop session, browse locally to the VS admin website (which uses a CGI EXE)

    This fails by design on Windows Server 2003 due to security restrictions. It does not happen if you use a local interactive console instead of RDP, or if you browse from a remote client (instead of on the server), or if you do not use Integrated authentication, or if the server application is not a CGI EXE.

    Otherwise… I really have no more suggestions because your configuration is arbitrary. Most VS Admin website "access" issues that users report end up coming from either:

    1. running DCPROMO on the machine

    2. joining a Domain with a Group Policy

    3. security lockdown applied by the user or person setting up the server initially

    The changes usually include:

    1. changing file system ACLs of random resources/directories/registry

    2. removing arbitrary unknown privileges from users/system that breaks IIS/Virtual Server

    3. changing IIS configuration

    In general, it is hard to diagnose these issues because it amounts to finding those needles-in-the-haystack changes on the system and reverting them. Some people end up running as LocalSystem to avoid the changes for security lockdown – which defeats the purpose of the lockdown. I usually suggest reinstalling and reproducing the claimed issue on a clean, non-domain joined machine – so that you can determine WHERE the bad changes are coming from so that you can get them corrected. It is bad to have your environment inherently breaking your server – you need to identify the arbitrary conflicting change in your environment and resolve it.


  6. Ken W says:

    I, also, have been getting that credential request, even though I have clicked the "remember my password" box.  

    I run VS on my DC, logging in from a member PC.  My URL responses are a little different, though.

    *   With nothin in my trusted sites list, if I use the long version of the URL, I get prompted for credentials.  If I launch the short version of the URL, I get an immediate 403 error.

    *   If I add the full URL of my VS admin web site to the "trusted sites" zone, rather than being prompted for my credentials, I get an immediate 403 error launching either short or long versions.

    *    Adding the short version of the URL to trusted sites seems to have no effect at all.

    I note that I seem to have similar behavior from the console of the server itself:  it prompts for credentials, and refuses to remember the password, even if I add itself to trusted sites.  This seems a little similar to the behavior I see, on 2003 servers, of prompting for approval to launch desktop shortcuts to local executables.


  7. David.Wang says:

    Ken W – Your problem is actually with the server returning 403s and not with login prompt nor "remember my password" box. The symptoms I describe are associated with 401s and not 403s.

    Now, your three observations are actually already explained by this blog entry:

    1. If you use the long version of the URL which has dots in it, IE thinks it is Internet Zone and thus will not auto-login and hence you get prompted for credentials. If you launch the short URL, IE auto-logins since it think it is Intranet Zone, and since your server is currently  broken to return 403s, that is what you immediately see

    2. If you add the full URL to the Trusted Zone, then IE will auto-login and immediately get the 403 response from your broken server. This matches what  happens for the short URL.

    3. Adding short URL to Trusted Zone has no effect since IE already auto-logins for a short URL in the Intranet Zone. Remember, you add the dotted long URLs to Trusted Zone because otherwise IE puts them in Internet Zone, which does not auto-login.

    You need to look in the IIS server logs for the exact 403 substatus code for investigation.

    I suspect you are getting a 403.19, which is typically caused by the IIS user identity servicing your VS Admin Website is missing certain user privileges such as "Adjust memory quotas" and "Replace process token". This frequently happens on a DC because a DC changes configuration of user privileges and it often breaks IIS.

    To test this theory, change the Application Pool Identity of the Application Pool servicing the VS Admin Website to "Local System" and see if things work. If it does, then you are seeing a user privileges issue caused by the DC. Since this is a DC, the secure way to fix the issue is to add those missing user privileges back to the Application Pool Identity that is servicing the VS Admin Website.


  8. Ken W says:

    Right direction, but different.  Looking in the logs (thanks for that tip), I appear to be getting 401.2 and 401.1 errors.  

    I tried the test you suggested, and was then able to get it to save the username and password, which I previously had to enter manually every time.  After switching the appropriate Application Pool Identity back to Network Service, and it still works: I no longer get prompted for credentials — at least, from this PC.  Haven’t tried another yet.  Not sure it’s a good fix, but it works for now.  

    Would you still suggest changing the priviledges on the Network Service account on this DC?  Oh, and any idea how I can get a full list of what those privs should be?  Would comparing that account on any non-DC server or PC do?

    BTW, IIS didn’t seem to like my playing with that setting.   I had to reboot the server to get back into IIS Manager after setting the ID back.   Restarting IIS didn’t work.


  9. David.Wang says:

    Ken W – I don’t know where, but the list of privileges held by "Network Service" should be documented somewhere since it is a standard Windows user account. You can do a diff between a non-DC and DC to see the changes (using secpol.msc)

    Changing Application Pool Identity should not require a reboot nor restarting IIS.

    Changing user privileges used as configurable Application Pool Identity require starting W3SVC (cached user tokens), though sometimes I have to reboot as well.


  10. Molly says:

    Hi all,

      I also have that problem, a user/password Login prompt with Integrate Authentication. I had set the IIS to integrated authentication and disabled annoymous access.

     However, the login prompt. I don’t want the user to input username and password again as they have already login to the window.

     Can you help me? and thanks a lot for your attention.


  11. The last two times that I have installed Virtual Server R2, it has been SP1 Beta 1 and then Beta 2. Each

  12. mwdiablo says:

    Just checked and this seemd to have been resolved in IE7

  13. Before I get started on this blog post, allow me to say that this is something that you should never…

  14. vijay says:

    a user enter login password  wrong three times who sent back home page doing this task i want a code  

  15. CmC says:

    I had the same problem with Exchange and Sharepoint and adding fqdn to intranet zone worked, but….only for users inside the network. If a user with a domain laptop goes home, they get page cannot be found when attempting to load the pages I’ve added to intranet zone. Ever seen this? Off-domain PC’s outside the network get login prompt and work like a charm.

    Thanks in advance.

  16. CmC says:

    One more thing to add to last posting:  When I change the zone settings to "prompt for username and password" on the domain PC off-network, the prompt shows up and they can login fine. Unfortunately, not a viable work-around for some of my challenged users.

  17. nick says:

    I had a problem with a directory on the IIS server , all  the users were prompted for a password when trying to access the directory, however their browsers would not remember the passwords when they revisited.

    I found that the problem was the security using IIS was set to Integrated Windows Authentication, , i unticked this and selected "basic authentication" and the problem was resolved,

    hope this helps

  18. David.Wang says:

    nick – Thanks for the suggestion, but that is really not a solution.

    Password prompts with Integrated Windows Authentication indicates problems with your client or domain configuration and not with IWA itself. It usually indicates a security misconfiguration that you want to correct, assuming you care about security.

    If you do not care about security, using basic authentication is one possible resolution since it removes security from the picture by making everything insecure — so use at your own risk.


  19. Johan Ingströmer says:

    Hi David

    When using integrated authentication I have problem for only one user who gets prompted for username and password when trying to access web pages on our intranet, in the intranet zone (no dots). The other users gets logged in automatically without prompt.

    When he gets prompted to login, the user is prefixed with the wrong domain (the name of the IIS server, instead of our windows domain), which makes me believe that this is why the integrated authentication fails.

    But I don’t know how to verify this, I have tried using the "Authdiag" tool, but it used gives me "The URL you entered is invalid. Please check the URL ….", although the URL works in Internet Explorer.

    If the user logs in to our network from another workstation then he doesn’t have this problem, so it seems like Internet explorer uses some information that is cached on that particular machine to try to log him in to the intranet server.

    I think it is the domain that is cached incorrectly. Or maybe the whole username

    Do you know how I can clear this cached domain / username value?

    Best regards

    Johan ingströmer

  20. David.Wang says:

    Johan – this sounds like an issue where that user has instructed IE on a computer to cache some invalid credential which now causes issues. No other users have this problem, and the user can workaround the problem by using IE on another workstation.

    I suggest asking the IE question in an appropriate forum – I really don’t know how to clear such an IE cache.


  21. wolfegang says:


    This is the answer EVERYONE is looking for.  Who knew it was a browser setting!!!!?!!!!

    Awesome, this fixed all of my issues in the lab!!!!


  22. Jon says:

    THANKS!! That was really puzzling me, i just had it in internet instead of intranet trusted sites – bah!

  23. Ravithuppal says:

    Johan Ingströmer  were you able to resolve this issue. I am also facing similar issue with only 1 user.



  24. Johan Ingströmer says:

    It was resolved by: from the users workstation in his login session, logging on to the windows server of the IIS, with his windows account and checking the remember password checkbox of the login dialog. That seems to have corrected the cache. I think I was using mstsc.exe for the remote login. It seems like the incorrect user credentials in the cache resulted from an usuccessful login attempt on the IIS windows server using mstsc, but I’m not sure.

    // Johan

  25. Yves from Belgium ;-) says:

    Thanks!!! I’ve been searching 3 days for a sloution to this problem !!!

  26. em says:


    I have been troubleshooting in the IIS and Windows Security direction.  Thanks for the explanation.  This solved my Virtual Server in IIS7 problem (added URL as save intranet site).    



  27. Avinash says:


        I have integrated authentication checked and it should not prompt for user credentials , but it does although i did add the site in local intranet all the users have same issue can some one help me with this..



  28. Johnathan says:

    It’s great!!

    Your suggestion was good enough to resolve the problem on my study.

    Thanks, David!!

  29. Mario says:

    I just installed the virtual server.  I never had any passwords set up to get into computer, but now the server is asking for password.  Is their a user and password that bypasses that for the first time?  Or do I have to "restore" to a previous date to get back into my computer?

  30. Ravi says:

    HI, i want to disable the login prompt when using window authentication but i do not want to set anything on browser like add a site to trusted zone etc..

    can i do some setting on IIS to allow only ad users to login to site without asking for login on browser? my site will  run on intranet so mainly all users will be part of a domain name and network…

  31. Othniel says:

    thank you so much, I kept getting the prompt and I could not understand,

    I had an url ( href='/../fonts.googleapis.com/css?family=Open+Sans:400,300,600&subset=cyrillic,latin'

    changed it to  fonts.googleapis.com/css

    and my windows authentication prompt was no more..

Skip to main content