IBM Security Z Security

Expand all | Collapse all

Automatically Revoking of RACF users

  • 1.  Automatically Revoking of RACF users

    Posted Thu April 22, 2021 08:17 AM
    Does anyone have coding for running a batch Job that can produce a list of ID's that have been inactive for 120 day and then submit the ALU command to Revoke the ID?  

    Thanks

    ------------------------------
    Patrick Cravens
    ------------------------------


  • 2.  RE: Automatically Revoking of RACF users

    Posted Thu April 22, 2021 11:24 AM
    Edited by Jeroen Tiggelman Thu April 22, 2021 11:27 AM
    Hi Patrick,

    I am going to assume that you are aware of the sample batch jobs C2RJ* in the SCKRSAMP data set and are mostly asking about the CARLa commands to produce the right command output. I am also going to assume that you mean to do this simply on the basis of the information in the RACF database (as opposed to going through event logs).

    You might be aware of the "last logon details" reports in AU.S - RACF user, which gives a breakdown of users by how long ago they were last used. This is backed by the CKRDLGAD (display) and CKRLLGAD (print output) members in the SCKRCARL data set. A comment in those members is:

    * On the use of LAST_CONNECT_DATE:
    * for the RDS this is the maximum of the CGLJDATEs:
    * - this value is less susceptible to other updates (such
    * as ALTUSER) besides RACINITs than LJDATE
    * - on the other hand, if the user's most recent logon group
    * is deleted, the estimate may be set back in time
    * - RACF uses LJDATE to determine the inactivity interval, so
    * some other LG* samples must not use this field
    * for the non-RDS this is simply the LJDATE

    Let's forget about the non-restructured RACF data set format from the previous century; but the point is being made here that you can either use the LJDATE (last use date) field in the USER profile, or look at the last logon to any of the connected groups as recorded, and this might work slightly differently.

    Using LJDATE, the basic CARLa to generate the ALU commands might look like this:

    newlist type=racf nopage
    select class=user segment=base ljdate<dumpdate-120
    sortlist 'ALU' key(8) 'REVOKE'​

    And if you want to direct the output to a particular DD-name, then you might add "DD=name" on the NEWLIST statement.

    Note that I use DUMPDATE, which for an UNLOAD is the date that the file was created. You can alternatively use TODAY. For a live source that should do the same.

    (The NOPAGE keyword suppresses page headers and column headers, which you might want in a report but not for generating commands.)

    I would assume, though, that you would also want to select on users not being revoked yet, to prevent issuing spurious ALUs, that is, add a NOT(REVOKE) clause on the SELECT statement as well. So you would get something along the lines of:

    newlist type=racf dd=ckrcmd nopage
    select class=user segment=base ljdate<dumpdate-120 not(revoke)
    sortlist 'ALU' key(8) 'REVOKE'​​


    Best regards,



    ------------------------------
    Jeroen Tiggelman
    Software Development and Level 3 Support Manager IBM Security zSecure Suite
    IBM
    Delft
    ------------------------------



  • 3.  RE: Automatically Revoking of RACF users

    Posted Fri April 23, 2021 04:03 AM
    Edited by Rob van Hoboken Fri April 23, 2021 04:04 AM
    Hi Patrick
    To add to Jeroen's CARLa code, here is JCL that would automate the task.

    //JCLLIB JCLLIB ORDER=(SYS1.CKR240.CKRPARM,
    // SYS1.CKR240.SCKRPROC)
    //*
    //STEP1 EXEC C2RC
    //CKRCMD DD DISP=(,PASS),DSN=&&COMMANDS,
    // UNIT=SYSALLDA,SPACE=(TRK,(15,15))
    //SYSIN DD *
    alloc type=racf active
    alloc type=ckrcmd dd=ckrcmd

    newlist type=racf dd=ckrcmd nopage
    select class=user segment=base ljdate<dumpdate-120 not(revoke)
    sortlist ' LU' key(8) 'REVOKE'
    //*
    //STEP2 EXEC C2RCXTSO
    //SYSTSIN DD DISP=(OLD,PASS),DSN=&&COMMANDS

    Note, I changed the command to something that will fail RACF syntax check because I would not want you to lockout critical IDs.
    You may want to add some EXCLUDE commands in the CARLa too, right below the SELECT command, like  

    EXCLUDE PROTECTED
    EXCLUDE SPECIAL 
    EXCLUDE CGGRPNM=EMERTEAM

    ------------------------------
    Rob van Hoboken
    ------------------------------