IIS 5 & IIS 6
Errors ONLY after changing domain password
Last post Dec 12, 2007 07:34 AM by rvspinx
Dec 10, 2007 09:51 AM|rvspinx|LINK
I am at my wits end. I have a DMZ'd domain that has integrated authentication turned on for all web servers, and the first time a user connects they are prompted for the username and password. If they enter
email@example.com it is getting cached in the "Stored Users and Passwords" applet in the Control Panel, if they use domain\username it is not. We prefer to use
firstname.lastname@example.org to keep it simple for the users. When the password changes however they are not prompted with the credentials dialog box, they are given a Page Cannot be found error 500. However the IIS logs shows
a 401 error, and with friendly errors off the error presented to the user is "The Local Security Authority cannot be contacted"
I have the enviornment replicated in a test area and I AM getting prompted for user credentials when the password changes.
This is an IIS6 enviornment, sitting on a completely seperate and isolated domain. There are multiple web sites affected. The firewall between the local lan and DMZ blocks all but ports 443 for web traffic. Test enviornment is the same.
*edit* - There is one difference. The production sites are considered Trusted/Intranet sites, the test sites are not.
If I use basic authentication it works fine, however the managers don't want users to be presented the dialog box unless the password has changed.
Any help is appreciated, thanks.
Dec 10, 2007 10:26 AMemail@example.com|LINK
There's an IE setting for whether or not to store passwords. I think this is what triggers the sending of the old password. Until it's cleared in IE, IE sends the stored version.
Dec 10, 2007 10:34 AM|rvspinx|LINK
We actually want the credentials to be cached, but for the user to be prompted when the password is incorrect. I believe I have narrowed the problem down to the trusted sites vs non-trusted internet site difference. This appears to be a problem for our
local intranet users only, and also happens for users accessing cross-domain file shares (login to domain A, access domain B) when their domain B password changes they get immediate access denied errors until the local user and passwords cache is updated.
I have a sinking feeling I am doomed unless I can get our root policies changed to remove the site from the trusted zone (not likely), or get the managers to accept multiple logon boxes (less likely), or move the app onto the intranet (screw external users!).
Someone please kill me.
Dec 11, 2007 06:36 PM|Enterhost_Nathan|LINK
While this is a client side suggestion, you might want to go into IE's Internet Options and down to the Custom Level settings for your zones. When here, scroll to the bottom for the section on "User Authentication" and "Logon"; you should have the following
Automatic logon only in Intranet zone
Automatic logon with current user name and password
Prompt for user name and password
Anonymous should always attempt to access a resource using the anon user within IIS for that site.
Automatic will attempt to use the current Window's login credentials into the authentication window. To be honest, this isn't something you really want to do outside the Intranet and only to trusted sites. I'd recommend making sure you don't say "Automatic
logon with current user name and password" to sites in the Internet zone.
Promping for a user name a password should always do exactly that. If you do not mind the dialog box always appearing, you may just want to set your login method to here. If you have the feature in IE that saves your names and passwords turned on, technically
this would auto-fill the next time you browse to the page. When the password is changed and no longer valid, you should still always have the prompt and easy access to change it on the spot.
Dec 12, 2007 07:34 AM|rvspinx|LINK
Right, this is what I want to change but am unable to due to our corporate policies. Unfortunatly I think we are going to have to change the login model for our users back to a domain\userid method, which confused them quite a bit, but at least it prompted
when the password was different.