Password hardening using pam

Hi

We have a requirement to vary the minimum password criteria by the group to which a user belongs.

For example a standard user should have a password with a minimum length of 12 and containing a mix of characters whereas an administrator should have a password with a minimum length of 14 etc.

It would seem that the pam_cracklib.so line is the one to use but the exact method seems to be unclear.

We actually have three requirements normal user, admin, service user.

I think the below lines show the area of pam that requires changing. If anyone has tried this any information or help would be gratefully received.

A google search does show up some hints but none for RHEL6 which is what we are using.

Greg

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so
 

A while back we had a god at this. We got as far as this before other business pressures took over. I'm not sure if it actually works, but it might provide a pointer:-

The plan then was to move people into the group privgrp if they had elevated privileges which mainly was considered as people with sudo rules for anything except where tied into the application, so those who could reset passwords, those who could become the superuser account etc. The limits are set for minimum of 8 for normal users and 12 for privileged, but I'm sure you can adjust that. We also require passwords to contain a mixture of upper & lower case, numerics and punctuation. We've had a few issues on some servers with characters # , and @ so bear that in mind when publishing guidelines. Worst affected for us on HP-UX, but it's a known limitation.

I hope that this gives you a pointer. I don't think it was actually fully implemented so I can't be sure it actually has any effect. Please test it thoroughly before committing to it. It would be worth having multiple sessions as a superuser before saving the files so you have a chance to undo them if they cause a problem.

I hope that this is useful, or prompts someone else to chip in, perhaps proving me wrong. I'm always happy to learn. :slight_smile:

Regards,
Robin