By Paul Murphy, author of The Unix Guide to Defenestration
Users have a tendency to pick poor passwords; add sloppy systems administration and you have a disaster waiting to happen.
For example, I once walked into an organization that had about 900 employees but maintained 1400+ user id and password combinations on its servers because no one had bothered to clear them out when people left. Worse, many of those passwords were the same as the user id and one, belonging to a person in Finance who had once worked in Systems, gave root permissions to an account identified by his first name with his last name as the password.
In Solaris releases later than 2.5.1 its easy to impose controls on what users can pick as passwords, force periodic change, and automatically freeze unused user ids into limbo after some pre-set period but not every Unix supports these facilities and not every major Solaris installation follows good procedure on this.
What I like to do, as a solution, is to check the entire user list by first determining which
ids haven't been used for three months
( use find /usrs +atime 90; or just ls -lc | grep 'drw' >foo)
and then by trying to crack all the passwords.
To do the latter I use a copy of Crack! for which I picked up source in about 1992 but you'll want something more recent - just be careful to review the source, or have someone you trust review the source, before compiling and running it to be absolutely sure it doesn't contain something nasty.
Crack! dates from SunOS and so needs a classic /etc/password file; creating one from /etc/shadow is trivial (make sure you do this somewhere safe; and neither as root nor in /etc!; I generally run it on my home machine) and the thing then goes through and finds all of the people using their dog's birthday as their password.
Once I know which accounts are dormant and which users have weak passwords, I can see what action is needed in each case - usually a mass lockout of the dormant accounts and a quiet talk with those who have weak passwords.
This approach works on nearly all Unix variants and creates a base from which you can then move forward to implementing whatever password management scheme users are willing to put up with, and management is willing to pay for.