We have a single-domain network with Windows 2008 servers and about 100 workstations mixed between XP, Vista and 7. The domain functional level is Windows Server 2008. There is a web-based app that runs on IIS 7 on one of the member servers. On 90% of the workstations, the app works fine. To the best of my knowledge, all of the security settings are the same on every workstation in the domain. GPOs are used to ensure everyone is using the same security settings. However there is a small handful of workstations that are not authenticating properly. It does not seem to be OS-specific; the issue has occurred on XP, Vista and Windows 7. On the 3 or 4 problem computers, what happens is, when launching the web-based app, a window pops up that says "Windows Security" on the title bar, and "Connecting to server1.domain.local" in the description. If a user correctly types in Domain\username" into the User Name field, and their Windows network password into the Password field, it will authenticate them and the app will work fine. If you click Cancel, it gives an HTTP error 401.2. It seems like Windows Authentication is failing somewhere on these 3 or 4 computers. Since it works fine on all the other 90-plus computers, it would seem that there's something amiss on these 4 workstations, but I do not know what to check. If anyone could point me in the right direction I would be extremely grateful. Much thanks, Fluxblocker

On Wed, 22 Feb 2012 17:55:17 +0000, fluxblocker wrote: We have a single-domain network with Windows 2008 servers and about 100 workstations mixed between XP, Vista and 7. If you're saying that on the "working" computers the users are not being prompted for credentials then I'd check to make sure that the "non-working" computers have the web site in the same security zone, and if so, then check the security settings for the zone in question to make sure they are the same. I'm thinking specifically of the User Authetication/Logon setting for the zone. Paul Adare MVP - Forefront Identity Manager http://www.identit.ca The world is coming to an end... SAVE YOUR BUFFERS!!

I found the problem but I do not know why it behaves this way. If we use the NetBIOS name in the link, it works correctly, but if we use the FQDN or the IP address, it behaves erratically (unwanted login prompt). I had a user log on to another where the app was working correctly; call this computer B. This user had experienced the erratic behavior on her computer; call it Computer A. The app worked correctly on Computer B with the user from Computer A logged on, so long story short, it was not a user issue. I changed the links to http://server/APP instead of http://server.domain.local/APP and that did the trick. Thanks for your reply. Sam S. P.S. Stocking up on buffers!

On Tue, 6 Mar 2012 14:44:33 +0000, fluxblocker wrote: I found the problem but I do not know why it behaves this way.?If we?use the NetBIOS name in the link, it works correctly, but if we use the FQDN or the IP address, it behaves erratically (unwanted login prompt). I had a user log on to another where the app was working correctly; call this computer B. This user had experienced the erratic behavior on her computer; call it Computer A. The app worked correctly on Computer B with the user from Computer A logged on, so long story short, it was not a user issue. I changed the links to http://server/APP instead ofhttp://server.domain.local/APP?and that did the trick. Thanks for your reply. You'll find, if you check the status bar in Internet Explorer, that using the NetBIOS name versus the FQDN name puts the web site into different security zones. Paul Adare MVP - Forefront Identity Manager http://www.identit.ca Code: Virus lasting about three to five days, accompanied by sore throat, runny nose and fever.