Re: Audit entry for PWDEXPITV

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.