On Mon 05-May-2011 09:41 , fbocch2595@xxxxxxx wrote:
if the PWDEXPITV of a password is set to 30 days on day 31...
does a CP audit entry get generated? I'm trying to find out
when a usrprf was disabled b4 it expired. I changed the usrprf
last week but didn't check to see when it had expired.
As I recall the "expiration" for the PWDEXPITV [password expiration
interval] is merely a calculated result versus an attribute, distinct
from whatever is the PWDEXP() [set password to expired] setting. As
such I expect that nothing is "set" when that expiration interval is
reached, thus that no T-CP would result. That instead, upon initiation
of some password verification [e.g. signon or CHKPWD], the effect is the
That could be confirmed as the behavior given a user showing "Set
password to expired: *NO" on DSPUSRPRF, but the password is diagnosed
as expired [due to the interval] upon signon or CHKPWD. Irrespective of
those, the "Status" of the user may be in play, per "usrprf was disabled".
The T-CP audit entry should exist for any explicit request to either
CHGUSRPRF PWDEXP(*YES) or CHGUSRPRF STATUS(*DISABLED). Some software [I
think GO SECURITY even has some] will change the status of a user
profile from *ENABLED to *DISABLED when the expiration interval is
exceeded, thus preventing the user from even getting the opportunity to
signon to change the password. There may even be a security menu option
which enables that feature, added on the job scheduler as a *DAILY
activity. Those would be explicit requests to change, and thus logged.