Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Paaword issue 2
- Thread starter aixadm
- Start date
-
1
- #2
KenCunningham
Technical User
Through smit user, Change / Show Characteristics of a User, see what the 'NUMBER OF PASSWORDS before reuse' entry for the user is set to, and if it's not 0 (zero), set it to 0 (zero). Bear in mind that whoever set up the original account might have had good reason for this restriction as some kind of security policy. HTH.
-
1
- #3
Without checking, I agree with Ken that it is the number of passwords before reuse. There is another setting that can prohibit the reuse of a password, and that is 'histexpire'
From the man page for "chuser"
histexpire Defines the period of time (in weeks) that a user cannot reuse a
password. The value is a decimal integer string. The default is 0, indicating
that no time limit is set. Only an administrative user can change this
attribute.
histsize Defines the number of previous passwords a user cannot reuse. The value is a decimal integer string. The default is 0. Only an administrative user can change this attribute.
To see the settings:
lsuser-a histexpire histsize account_name
to change the settings:
chuser histexpire=value histsize=value account_name
Again, as noted by Ken, there could be a policy for not reusing a password.
From the man page for "chuser"
histexpire Defines the period of time (in weeks) that a user cannot reuse a
password. The value is a decimal integer string. The default is 0, indicating
that no time limit is set. Only an administrative user can change this
attribute.
histsize Defines the number of previous passwords a user cannot reuse. The value is a decimal integer string. The default is 0. Only an administrative user can change this attribute.
To see the settings:
lsuser-a histexpire histsize account_name
to change the settings:
chuser histexpire=value histsize=value account_name
Again, as noted by Ken, there could be a policy for not reusing a password.
To augment my previous post, here is how we use histsize and histexpire.
This may play into your SOX or other audit compliant guidelines.
We set maxage=13, which would dictate that the password is changed at minimum four times per year.
We set histsize=8, so in theory people could not re-use their password for two years if they change their password every 13th week.
But there is nothing from keeping a person from changing their password nine times via nine "passwd" commands consecutively, and on the last execution have their original password. Which is where histexpire comes in.
We set histexpire=52. This demands that at least one year goes by before a password is re-used.
Now, histexpire could be used without histsize and essentially guarantee that passwords cannot be re-used within a 52 week period. But that doesn't satisfy the security auditors who want passwords changed on a regular bassis
Setting 'histsize' will track the last "x" number of password changes and when they changed. 'maxage' will guarantee regular password changes. 'histexpire' guarantees that passwords aren't cycled too frequently in time.
Hopefully that all makes sense.
-glenn
Now ... for those still reading ... there is a minage attribute, which dictates the minimum number of weeks before a password can be changed. For example, minage=9 and maxage=13 would dictate that the password could be changed between the 9th and 13th week since the last change.
I don't use that as I find it too restricting to the users and it is not a requirement from our security group.
If anyone users minage, can you post whether the user base gripes about it or whether it is warmly accepted?
This may play into your SOX or other audit compliant guidelines.
We set maxage=13, which would dictate that the password is changed at minimum four times per year.
We set histsize=8, so in theory people could not re-use their password for two years if they change their password every 13th week.
But there is nothing from keeping a person from changing their password nine times via nine "passwd" commands consecutively, and on the last execution have their original password. Which is where histexpire comes in.
We set histexpire=52. This demands that at least one year goes by before a password is re-used.
Now, histexpire could be used without histsize and essentially guarantee that passwords cannot be re-used within a 52 week period. But that doesn't satisfy the security auditors who want passwords changed on a regular bassis
Setting 'histsize' will track the last "x" number of password changes and when they changed. 'maxage' will guarantee regular password changes. 'histexpire' guarantees that passwords aren't cycled too frequently in time.
Hopefully that all makes sense.
-glenn
Now ... for those still reading ... there is a minage attribute, which dictates the minimum number of weeks before a password can be changed. For example, minage=9 and maxage=13 would dictate that the password could be changed between the 9th and 13th week since the last change.
I don't use that as I find it too restricting to the users and it is not a requirement from our security group.
If anyone users minage, can you post whether the user base gripes about it or whether it is warmly accepted?
- Thread starter
- #7
- Status