Re: Audit entry for PWDEXPITV

[CRPence <CRPbottle@xxxxxxxxx>]

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 
following logic:

   If (Current_Date-Pwd_Changed_Date)>PwdExpItv
   Then SndPgmMsg(CPF22E4|CPF366B)

  Additionally, FWiW:

  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.

Regards, Chuck