OpenLDAP Password Policy on Ubuntu 12.04 - Part Two

Last time we started implementing a password policy. The server side is more or less ready. Now let us do some testing.

I strongly reommend the download and use of Apache Directory Studio to make the testing more confortable. No need to install - extract and run. I like it beacuse it shows me a lot of hidden attributes - if I ask nicely (watch teh mouse pointer):

Option to switch on in Apache Directory Studio

These hidden attributes hold almost everything the ppolicy overlay makes notes about.

Now for the testing:

• Password length and last three passwords: These parts are supposed to function out of the box. Log on to a client with LDAP auth and try to change the password using the command passwd. If you try to use a password that is too short or in the history of the last three passwords then no password change is made. The latter you can cheat if you delete the pwdHistory attribuutes of the user. If you only could. OK, we'll get back to it when talking about the modification of the password setting's timestamp. (If your setup is like mine (read: you use smbkrb5pwd to propagate password changes to Samba and Kerberos) things are more difficult. We'll get back to it too.)
• Account locking: this has to function right away too. Enter the wrong password three times. Keep an eye on the pwdFailureTime attributes appearing at the user. After the third wrong password for the specified time (in my case it is 300 second) LDAP will lie to the client that the password is incorrect - even if it is correct. (tail -f /var/log/auth.log). In the LDAP the pwdAccountLockedTime attribute appears. If you do not want to wait for the time to pass, you can delete this attribute. If you did not specify this time window this is the only way to disable locking. You can set up things to have the server tell the truth about locked accounts instead of lying about incorrect passwords. This raises security concerns - google is your friend. If the admin gives a new password for the user drunig the lockout period the locking will be disabled.
• Expiration warning: it's a bit more tricky. There are two parts to be concerned about: first is to have the message get to the client, second is to have the client act on it. Let us begin generating the test case. We have set up things in a way that passwords are valid for 5 weeks warning messages coming 3 weeks before expiration. Now we need a password set 4 weeks ago. But we cannot alter the pwdChangedTime attribute. Or can we? Let us set the password of the user:

  ldappasswd -D cn=admin,dc=itthon,dc=cucc -w secret -s newpassword uid=suser1,ou=People,dc=itthon,dc=cucc
  

  Let us create a file called pwdchangedtime.ldif:

  dn: uid=suser1,ou=People,dc=itthon,dc=cucc
  changetype: modify
  replace: pwdChangedTime
  pwdChangedTime: 20120427192853Z

  Use a timestamp indicating the date a month before. Now for the point (the real point is in bold):

  ldapmodify -D cn=admin,dc=itthon,dc=cucc -w secret -e relax -f pwdchangedtime.ldif
  

  So we have a password one month old:) Now issue the command:

  ldapwhoami -e ppolicy -x -D uid=suser1,ou=People,dc=itthon,dc=cucc -w newpassword
  

  You will see a message like "Password expires in 256244 seconds". So far so good. Open the syslog:

  tail -f /var/log/syslog|grep ppolicy_bind
  

  and you'll see: ppolicy_bind: Setting warning for password expiry for uid= and that is good. If you logon to a client the message in syslog is there, but the user is not warned. We'll get back to it next time.
• Forcing password change: sometimes it is good to make the user change her password after we have given a new one to her. You force this to place a new user attribute called pwdReset with the value of TRUE . Directory Studio will complain but we couldn't care less. Issuing the ldapwhoami you have used before you will see "Password must be changed". The client of course does not show it. We leave this for later.