IBM Security Z Security

Security for Z

Join this online user group to communicate across Z Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  Re: "zSecure Scheduled actions"

    Posted yesterday

    Sorry for opening a new thread, but I have tried to answer the other thread for some days now, and cannot get the "Post" button to work on my reply...
    ====

    Hi Danielle,
    Terminology-wise I would prefer to speak of "queued commands" and "revoke/resume schedules" and "scheduled events".
    Queued commands can be timed and temporary, there you would actually schedule a particular command for a particular date etc.
    Here we are talking about revoke/resume schedules, with events on the schedule(s), and potentially a command or action resulting from the combination of all the schedules.

    It appears you have a schedule called CANCEL. 
    This might be the only schedule you have on this user, so it might determine the overall revoke/resume setting.

    I think the Audit Trail here is from zSecure Command Verifier (while the schedules are from the CKGRACF component of zSecure Admin).
    This reflects actual commands that were issued.
    Issuing commands on the basis of revoke/resume schedules would be done by a daily CKGRACF job, I think.
    https://www.ibm.com/docs/en/szs/3.2.0?topic=production-requirements-rationale-running-daily-ckgracf-job
    This is on the basis of this TYPE=RACF CARLa field:
    CKGREFRESH, CNGREFRESH
    This field is derived from the USR field and contains the date after which a CKGRACF REFRESH command is required; undefined if the profile does not contain scheduled revoke/resume actions or queued commands.

    So I guess my first question is if the daily job is in fact running.

    > to essentially "hard revoke" user IDs so only we can reinstate them

    The way this works is that there can be multiple schedules, and only some people are authorized to set events on a particular schedule.
    So insofar CKGRACF controls who is resumed and revoked, this means it won't resume users that are 'hard revoked'.
    Note this does not mean that someone else cannot be authorized to do a direct RESUME in RACF. 
    But you'd expect another REVOKE to occur if the user is still hard-revoked at the next refresh.
    I hope this begins to help.
    Regards,
    Jeroen


    ------------------------------
    Jeroen Tiggelman
    IBM - Software Development Manager IBM zSecure
    Delft
    ------------------------------


  • 2.  RE: Re: "zSecure Scheduled actions"

    Posted 5 hours ago
    Edited by Rob van Hoboken 5 hours ago

    As Jeroen pointed out, scheduled commands exist by virtue of a (daily) job that verifies if all profiles fit the status laid down in the schedules.  If this job, C2RJXRFR, somehow, does not run, the schedules are ignored.

    There are two points in time when the scheduled action changes the profile: 

    1. when the administrator defined or modified the schedule for a profile, the schedules in the profile are evaluated and (in the case of a USER ENABLE/DISABLE) an ALTUSER RESUME or REVOKE is issued, as you can see in the Command Verifier log entries from 2023.
    2. when the daily job runs, a CKGRACF REFRESH class profile is issued (only) for profiles where the scheduled state does not fit the profile status, which results in a RACF command.

    So I am guessing that the daily job ran last week, for the first time ever(!), it found a user with a pending DISABLE for schedule CANCEL, so it applied the scheduled status of REVOKE.  Furthermore, I also guess that the RESUME that Command Verifier logged at 15:39 was actually an ALTUSER RESUME issued from the panels (or as a TSO command) and not an ENABLE CANCEL NOW.

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



Related Content