Re: Audit entry for PWDEXPITV

[CRPence <CRPbottle@xxxxxxxxx>]

  FWiW I saw that v7r1 [IBM i 7.1] has a new feature, as attributes on 
the *USRPRF, apparently to automatically disable user profiles according 
to new profile "expiration date" or profile [versus password] 
"expiration interval" parameters.  Though with further review, seems to 
me that the disabling still is achieved only by a separate scheduled 
procedure, as I alluded effects disabling due to password expiration for 
having met\exceeded the PwdExp interval.  The docs suggest QSECEXP1 job 
defined in the job scheduler.  From the T-CP documentation:

    CP (User Profile Changes) journal entries

    This table provides the format of the
    CP (User Profile Changes) journal entries.
    Table 1. CP (User Profile Changes) journal entries.
    QASYCPJE/J4/J5 Field Description File

    Offset 994 in J5 is "User expiration date" as Char(7)
    which "Specifies the date when the user profile expires.
    The user profile is automatically disabled or deleted on
    this date."

  So the CL commands CHGUSRPRF and CRTUSRPRF add parameters User 
expiration date (USREXPDATE) and User expiration interval (USREXPITV). 
These are apparently like with disabling for PwdExpItv where there are 
the "Display Expiration Schedule (DSPEXPSCD) command to display a list 
of all user profiles set to expire" and the "Change Expiration Schedule 
Entry (CHGEXPSCDE) command allows you to expire a user profile on a 
certain date.  The expired user profile can either be disabled or deleted."

  Seems these new xxxUSRPRF parameters effect the same as what would be 
done by CHGEXPSCDE [adding the user profile and expiration date or 
interval] but without having to add the details with that command.? 
However seems to me then, that the reference to "deleted" in the T-CP 
docs seems a bit indirect, since there is no new ACTION parameter; i.e. 
seems to me that CHGEXPSCDE would be required to change from a defaulted 
ACTION(*DISABLE) to the ACTION(*DELETE) [along with the desired 
OWNOBJOPT() and PGPOPT()].

Regards, Chuck

On 09-May-2011 10:31 , CRPence wrote:
> 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.