Why does the Password Reset System keep failing for user X
(Last updated on August 2, 2018)
I was recently working with a customer that had successfully implemented the password reset solution, but had one particular user that was unable to enroll in the system. The user received an error message once he entered his new password.
Like typical admins we checked all the obvious things:
- the user was in the correct OU
- the password reset account had the correct permissions
- it failed on multiple machines and not just one machine
We could see that it was reaching the Specops server – the background and message is part of our design. Gpresult showed that the GPO being applied was the same one that worked for everyone else. The password reset service account had exactly the same permissions that it had on other accounts. Finally, the problem followed the user from one machine to another, so it wasn’t a local machine problem. It was either something in AD or something to do with his profile.
We switched on debugging on the server logs, but no clues there either. The web session just stopped.
We then did what a lot of admins forget to do: check the Windows Eventlogs! Sure enough we got a great hint!
There’s a ton of text in that eventlog message, but if we look at the first line of the exception information, we can see the critical piece of information.
Exception Message: A potentially dangerous Request.Form value was detected from the client (ct100$ContentPlaceholder1$ResetWizard$txtPassword=”<Summer2016!”).
This shows the users password, but why does it think this word is “dangerous”? What’s the problem with it, and why does IIS throw this ASP.NET exception?
The problem is that IIS does not like the < in the password. By default, it blocks any attempt by an end user to place that character into a form since certain statements bound in <> can be used to hack websites and change their behaviour.
Sure enough once we reset the password to something that did not begin with <, the user was able to enroll.
There are tweaks you can make to the web.config file to switch off this behaviour in IIS, but generally speaking we do not recommend their usage as they will lessen the security of the webserver in general.
As a final note this is a great example of how the Windows Eventlog can explain what’s happening when things go wrong. It’s often overlooked, but I always recommend it as the first port of call if systems start to misbehave.