Will rant on the evils of enforcing password policies at the directory level in another post. For now, here’s the beef:
When a password policy is being enforced on Oracle Internet Directory (OID) it is inevitable that people are going to have their accounts locked. I say “accounts” because once you start layering in things like password policy enforcement each user’s object goes from being a simple LDAP entry to … well, something a lot more complicated.
In Oracle Internet Directory accounts can be unlocked through the graphical web-based DAS (Delegated Administration Service) Console.
But how do you find out all the users who are locked out right now? Short of paging through every one of potentially thousands of accounts on your directory (by default, DAS won’t list more than 200 accounts total if you just hit enter on an empty search window — definitely too small a number for the average enterprise that can afford Oracle).
The answer lies in the OID schema.
Finding a value in the
pwdaccountlockedtime attribute is what causes OID to treat the account as locked.
So, if you do a search like
"(pwdaccountlockedtime=*)" with your favorite LDAP client, like
ldapsearch or Jarek Gawor’s LDAP Browser-Editor, you’ll find what you’re looking for.
Once you’ve found them, you can unlock the accounts desired by using the DAS Console. Or you could act like a real administrator and use
ldapmodify to do a bulk unlock with a specially crafted LDIF file.
The key to using the LDIF file method is to do a search with the filter provided above, specify only a single attribute (my favorite is “cn”, it will be in every entry). Then you need to edit the file to replace that attribute with a particular attribute/value pair:
Each entry should then look something like:
Note the instructional information that will tell
ldapmodify what it needs to do (”modify” by “adding” the attribute with the required value). See my article on using perl as a text editor for some help with that.
This will result in OID removing the
pwdaccountlockedtime attribute, as well as it’s companion
pwdfailuretime attribute, which holds the raw timestamp (in Zulu time, of course) of the original event that caused the account to be locked.