Revoking unused user IDs (INACTIVE option)

The INACTIVE operand of the SETROPTS command causes RACF® to revoke the user's right to use the system if the user ID has remained unused beyond a specified number of days. RACF revokes the user the next time the user attempts to enter the system.

The following example specifies that RACF revoke a user ID if it is unused for over 30 days: 
SETROPTS INACTIVE(30)
If you issue the SETROPTS INACTIVE(30) command and a user has not done any of the following in 31 days:
  • Logged on
  • Submitted a job
  • Changed their password or password phrase by any method
  • Used an incorrect password to attempt an unsuccessful logon to a remote system in the RRSF network
  • Received a directed command or output from RACF remote sharing
that user is considered revoked. However, the user is not actually revoked and the output of the LISTUSER command does not show that the user is revoked until the user next attempts to log on or submit a job. When you allow the user to start using the system again (using the RESUME operand on the ALTUSER command), RACF resets the effective date with which the period of inactivity starts.

When you define a new user ID, the user's last access date is set to the user ID's creation date. If the user ID is not used within the number of days specified by SETROPTS INACTIVE, the user ID will be revoked. When you issue the LISTUSER for a new user ID that has never been used, the last access date will be listed as UNKNOWN.

Note: An auditor cannot rely upon LAST-ACCESS date for the last (if ever) authentication of a user. If an authentication request (RACROUTE REQUEST=VERIFY) includes STAT=NO, there is no indication when an id was last (if ever) authenticated. This is the case with Db2®z/OS®.

If NOINACTIVE is in effect, RACF does not check the user ID against an unused user ID interval.

If NOINITSTATS is in effect, the INACTIVE, REVOKE, HISTORY, and WARNING options cannot be used.