As more and more companies move forward with automated provisioning and automated password management and workflow an issue was found with tools like FIM that proxy the password change. I.E. You identify yourself to FIM and tell it to change the password for you, FIM uses the SET Password operation instead of the CHANGE Password operation which bypasses the password history rules.
What does that mean? In other words, say your company has a password policy that includes complex passwords that have to be changed every month and can’t be repeated for 25 passwords. Normally that means if you want to use JoeRocks1! as your password every month you would have to change it to 24 other values first and then re-change it back to JoeRocks1![1]. Well this "bug", or really, implementation flaw with using SET instead of CHANGE means that you could just tell FIM to re-use JoeRocks1! every month. FIM doesn’t perform any validation, it just depends on the OS and again… It is telling the OS to ignore the history policy via the use of SET.
To fix this, Microsoft released a patch for Active Directory which introduces a new LDAP control that helps alleviate this issue. This control is called… tada – LDAP_SERVER_POLICY_HINTS_OID and is used with password SET operations.
The KB article for the curious is http://support.microsoft.com/kb/2443871
For the folks that use AdMod, I added functionality this evening to allow AdMod to take advantage of the new control. There is a new switch called -policyhints which enables the control.
[Thu 02/09/2012 23:03:49.78]
C:\>admod -default -rb cn=testuser1,cn=testusers unicodepwd::Password2! -optenc -exterr -policyhints
AdMod V01.18.00cpp BETA Joe Richards (joe@joeware.net) February 2012
DN Count: 1
Using server: WIN8Dom-DC1.win8dom.loc:389
Directory: Windows Server 8 Developer Preview
Base DN: cn=testuser1,cn=testusers,DC=win8dom,DC=loc
Modifying specified objects…
DN: cn=testuser1,cn=testusers,DC=win8dom,DC=loc…
The command completed successfully
[Thu 02/09/2012 23:04:01.46]
C:\>admod -default -rb cn=testuser1,cn=testusers unicodepwd::Password2! -optenc -exterr -policyhints
AdMod V01.18.00cpp BETA Joe Richards (joe@joeware.net) February 2012
DN Count: 1
Using server: WIN8Dom-DC1.win8dom.loc:389
Directory: Windows Server 8 Developer Preview
Base DN: cn=testuser1,cn=testusers,DC=win8dom,DC=loc
Modifying specified objects…
DN: cn=testuser1,cn=testusers,DC=win8dom,DC=loc…: [WIN8Dom-DC1.win8dom.loc] Error 0x35 (53) – Unwilling To Perform
Extended Error: 0000052D: SvcErr: DSID-031A126A, problem 5003 (WILL_NOT_PERFORM), data 0
ERROR: Too many errors encountered, terminating…
The command did not complete successfully
[Thu 02/09/2012 23:04:04.85]
C:\>admod -default -rb cn=testuser1,cn=testusers unicodepwd::Password2! -optenc -exterr
AdMod V01.18.00cpp BETA Joe Richards (joe@joeware.net) February 2012
DN Count: 1
Using server: WIN8Dom-DC1.win8dom.loc:389
Directory: Windows Server 8 Developer Preview
Base DN: cn=testuser1,cn=testusers,DC=win8dom,DC=loc
Modifying specified objects…
DN: cn=testuser1,cn=testusers,DC=win8dom,DC=loc…
The command completed successfully
[Thu 02/09/2012 23:29:28.30]
C:\>err 52d
# for hex 0x52d / decimal 1325 :
ERROR_PASSWORD_RESTRICTION winerror.h
# Unable to update the password. The value provided for the
# new password does not meet the length, complexity, or
# history requirement of the domain.
# 1 matches found for "52d"
joe
[1] Don’t laugh, a few years ago I ran into some folks who had set up a batch file to do something exactly like this… Well they weren’t using JoeRocks1! but they used the whole idea of looping through enough passwords to be able to reuse the same password every month.
