We have a number of locally installed .Net applications that communicate via web services. Authentication in IIS is handled by Windows Authentication so no additional login is required. We recently began seeing a problem where users are getting a IIS 403 forbidden eror when their password reset falls within the password exiration notification period (7 days at the moment).
As this sometimes happens in the the middle of the day (login in the morning OK, but password reaches < 7 days during the day), this comes as a surprise as they haven't been warned to change their password. Of course, I would expect they should be able to work until the password is expired.
Any idea on what could be happening here? Why would IIS reject a login if the passsword hasn't actually expired? Can we change that behaviour?
Thanks
\\Greg
You will probably see 403.18 error in your web logs. Do you have an error page configured to run from a different application pool by any chance? Have a look here: http://blogs.msdn.com/b/rakkimk/archive/2006/09/01/735684.aspx
and here (which describes a very similar problem): http://social.technet.microsoft.com/forums/en-US/exchangesvrgeneral/thread/0f96332b-5b53-42f6-8f12-7d0b79a0a636/
Given how difficult this was to resolve, I want to answer my question with the final outcome.
The issue has to do with IIS and PasswordChange notifications. On all the servers, we had removed the /IISpwdadm. This is the capability IIS builds in to allows interactive users to change their password.
Apparently when our users' password went into notification period, the web service would try to redirect them over to /iispwdadm/anot.asp. Since this is outside the path of the web service and in a different application pool, the 403 error was generated.
The solution was to use adsutil to change the changepasswordflags setting to 6 which disabled notifications and password change functionality of IIS.
One other note, our web services are in a pool behind a BigIP. All of these redirects were funneled to a single server within the pool since the source address was the pool address. This made finding the 403 events in the logs a bit tricky.
Thanks again to DmitryK for heading us down the right path.