Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

share|improve this question
    
It shouldn't work that way. From what I remember in years past, the password notification period is simply a client-side check for expiration. What's in the security event logs when such an attempt fails? –  TristanK Apr 20 '11 at 22:15
    
Exactly my feeling. Sec log shows nothing but successful logins. I have a request in to enable IIS logs. –  uSlackr Apr 20 '11 at 23:20
    
Enable failure auditing for account logons and logons too if they're off; that might help nut it out. Otherwise, perhaps create a simple test file (or app) with no custom code in it, and see whether that suffers the same fate. –  TristanK Apr 21 '11 at 3:12
    
Failure audits are enabled (they're the important ones), but no failed attempts are in the logs. –  uSlackr Apr 21 '11 at 19:32
    
I ran the IIS logs for 8 hours today, collected a lot of other issues, but no 403 errors in the log. Since this web service is a load-balanced set, I'll be running logs over all the servers for a couple days.. I'll post back –  uSlackr Apr 21 '11 at 22:05

2 Answers 2

up vote 1 down vote accepted

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/

share|improve this answer
    
So far we haven't see any 403.18 (or any other 403 error in the log. We're still looking though. We don't run the logs full time –  uSlackr Apr 23 '11 at 16:44
    
This looks like it. It appears to only be happening on one server in our pool. The 403.18 errors only appeared in the last log I checked. Now off to implement the fix! Thanks for the lead. –  uSlackr Apr 27 '11 at 20:28
    
One more thing. We are not using custom error pages. This appears to be an issue where one load balanced web service is calling another web service in the same load balanced pool. But the underlying issue appears to be the same. Still digging into the root of the issue. –  uSlackr Apr 28 '11 at 13:08

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.

cscript adsutil.vbs set w3svc/passwordchangeflags 6
cscript adsutil.vbs set w3svc/1/passwordchangeflags 6

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.