IBM Security Z Security

Hi 

Have a number of Ids in their thousands that are spread across many sysplexes.

1. Need an accurate method to identify which UserIds are really inactive , an Id inactive on SysplexA might be active on SysplexB or C or D, so all RACF DBs need to be referenced to ensure the ID really is inactive on all Sysplexes.
2. The type of UserIds are both Protected (usually Started Task Ids ) and Human.
3. To date I have been using the following Carla line:  s s=base c=user  last_connect_date<TODAY-100 and reporting on last_connect_date(8) ljdate(8),. Both these vars are being used as for some Ids although last_connect_date is over 100 days, LJDATE is not.

4. Given RACF uses the LJDATE to calculate the user's inactivity interval, the documentation from zSecure states "

   "When you want to report the actual date that a user logged on with a RACINIT, you can use the field LAST_CONNECT_DATE. That field is documented as follows." .....This is usually a better estimate for the last logon date than the LJDATE (which is for instance also affected by ALTUSER),"

5. The supplied examples   CKRDLGAG  Menu driven Summary and    CKRLINAC  (uses LJDATE) but the generated results are different from my own Carla Scripts. So,  grateful for any hints and tips ! Would it be better to use SMF say Type 34 for TSO logon events - but this would not address the Protected Ids.         

Is there a STIG specifically addressing Inactive Ids, apart from the check IDs must be revoked after NN days ? 

Apart from CKRLINAC mentioned above, are there any other supplied zSecure Carla Scripts ? 

Many thanks in advance 

Peter

Hi Peter,

I think the methods for determining this thing might rather be different for PROTECTED ids and for regular ids, since PROTECTED ids cannot be used to logon and cannot get revoked for issues with logging on, etc.

The overview CKRLLGAG and the detail report CKRLLGAD do report on multiple systems, but these reports show per complex which user ids are inactive, not across systems. I could see that this might be a major source of differences if your CARLa scripts are looking for a cross-complex result.

As to LAST_CONNECT_DATE, the CKRLLGAD script documents the following:

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

I hope that clarifies the pros and cons sufficiently.

From the zSecure interface perspective, these kinds of reports would naturally belong to AU.S - RACF user.
If you tag the category and "Select specific reports" on AU.S, this should bring up related reports, like:

 _  NEVER LOGGED ON- Users that never logged on                _  PENDING REVOKE - Users with pending revoke                 _  LAST LOGON SUM - Last logon overview                       _  LAST LOGON DET - Last logon details (detailed report only)

CKRLLGAD is the Print format of the Last logon details. 

PENDING REVOKE is CKR%LGRV (with % D for Display of L for Print format)
CKRLINAC is not included here; it is an old script for which I believe the functionality from an "actionable" perspective is covered by the former.

CKRLLGAG (the overview) observes: " For protected users revoke_inactive is missing!", meaning that selections on Yes or No will both exclude protected users.

A quick scan on the STIG and CIS controls, that is, SCKRCARL(C%%H*), for "inactive" turns up
CKAHR121 - RACF z/OS CIS 1.2.1: Ensure that Inactive users are revoked 
(and something for ACF2 I take it you are not looking for)

I hope this begins to help.

Regards,

Hi 

Have a number of Ids in their thousands that are spread across many sysplexes.

1. Need an accurate method to identify which UserIds are really inactive , an Id inactive on SysplexA might be active on SysplexB or C or D, so all RACF DBs need to be referenced to ensure the ID really is inactive on all Sysplexes.
2. The type of UserIds are both Protected (usually Started Task Ids ) and Human.
3. To date I have been using the following Carla line:  s s=base c=user  last_connect_date<TODAY-100 and reporting on last_connect_date(8) ljdate(8),. Both these vars are being used as for some Ids although last_connect_date is over 100 days, LJDATE is not.

4. Given RACF uses the LJDATE to calculate the user's inactivity interval, the documentation from zSecure states "

   "When you want to report the actual date that a user logged on with a RACINIT, you can use the field LAST_CONNECT_DATE. That field is documented as follows." .....This is usually a better estimate for the last logon date than the LJDATE (which is for instance also affected by ALTUSER),"

5. The supplied examples   CKRDLGAG  Menu driven Summary and    CKRLINAC  (uses LJDATE) but the generated results are different from my own Carla Scripts. So,  grateful for any hints and tips ! Would it be better to use SMF say Type 34 for TSO logon events - but this would not address the Protected Ids.         

Is there a STIG specifically addressing Inactive Ids, apart from the check IDs must be revoked after NN days ? 

Apart from CKRLINAC mentioned above, are there any other supplied zSecure Carla Scripts ? 

Many thanks in advance 

Peter

Thanks Jerome! 

I will look into all of the above, as for the protected attribute I guess turning on / off as appropriate will help sort Human vs Protected.

I have worked with ACF2 and seem to remember it was less hazardous to find Inactive Ids , but we are where we are. Thank you ! 

Hi Peter,

I think the methods for determining this thing might rather be different for PROTECTED ids and for regular ids, since PROTECTED ids cannot be used to logon and cannot get revoked for issues with logging on, etc.

The overview CKRLLGAG and the detail report CKRLLGAD do report on multiple systems, but these reports show per complex which user ids are inactive, not across systems. I could see that this might be a major source of differences if your CARLa scripts are looking for a cross-complex result.

As to LAST_CONNECT_DATE, the CKRLLGAD script documents the following:

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

I hope that clarifies the pros and cons sufficiently.

From the zSecure interface perspective, these kinds of reports would naturally belong to AU.S - RACF user.
If you tag the category and "Select specific reports" on AU.S, this should bring up related reports, like:

 _  NEVER LOGGED ON- Users that never logged on                _  PENDING REVOKE - Users with pending revoke                 _  LAST LOGON SUM - Last logon overview                       _  LAST LOGON DET - Last logon details (detailed report only)

CKRLLGAD is the Print format of the Last logon details. 

PENDING REVOKE is CKR%LGRV (with % D for Display of L for Print format)
CKRLINAC is not included here; it is an old script for which I believe the functionality from an "actionable" perspective is covered by the former.

CKRLLGAG (the overview) observes: " For protected users revoke_inactive is missing!", meaning that selections on Yes or No will both exclude protected users.

A quick scan on the STIG and CIS controls, that is, SCKRCARL(C%%H*), for "inactive" turns up
CKAHR121 - RACF z/OS CIS 1.2.1: Ensure that Inactive users are revoked 
(and something for ACF2 I take it you are not looking for)

I hope this begins to help.

Regards,

Hi 

Have a number of Ids in their thousands that are spread across many sysplexes.

1. Need an accurate method to identify which UserIds are really inactive , an Id inactive on SysplexA might be active on SysplexB or C or D, so all RACF DBs need to be referenced to ensure the ID really is inactive on all Sysplexes.
2. The type of UserIds are both Protected (usually Started Task Ids ) and Human.
3. To date I have been using the following Carla line:  s s=base c=user  last_connect_date<TODAY-100 and reporting on last_connect_date(8) ljdate(8),. Both these vars are being used as for some Ids although last_connect_date is over 100 days, LJDATE is not.

4. Given RACF uses the LJDATE to calculate the user's inactivity interval, the documentation from zSecure states "

   "When you want to report the actual date that a user logged on with a RACINIT, you can use the field LAST_CONNECT_DATE. That field is documented as follows." .....This is usually a better estimate for the last logon date than the LJDATE (which is for instance also affected by ALTUSER),"

5. The supplied examples   CKRDLGAG  Menu driven Summary and    CKRLINAC  (uses LJDATE) but the generated results are different from my own Carla Scripts. So,  grateful for any hints and tips ! Would it be better to use SMF say Type 34 for TSO logon events - but this would not address the Protected Ids.         

Is there a STIG specifically addressing Inactive Ids, apart from the check IDs must be revoked after NN days ? 

Apart from CKRLINAC mentioned above, are there any other supplied zSecure Carla Scripts ? 

Many thanks in advance 

Peter

Hi 

Have a number of Ids in their thousands that are spread across many sysplexes.

1. Need an accurate method to identify which UserIds are really inactive , an Id inactive on SysplexA might be active on SysplexB or C or D, so all RACF DBs need to be referenced to ensure the ID really is inactive on all Sysplexes.
2. The type of UserIds are both Protected (usually Started Task Ids ) and Human.
3. To date I have been using the following Carla line:  s s=base c=user  last_connect_date<TODAY-100 and reporting on last_connect_date(8) ljdate(8),. Both these vars are being used as for some Ids although last_connect_date is over 100 days, LJDATE is not.

4. Given RACF uses the LJDATE to calculate the user's inactivity interval, the documentation from zSecure states "

   "When you want to report the actual date that a user logged on with a RACINIT, you can use the field LAST_CONNECT_DATE. That field is documented as follows." .....This is usually a better estimate for the last logon date than the LJDATE (which is for instance also affected by ALTUSER),"

5. The supplied examples   CKRDLGAG  Menu driven Summary and    CKRLINAC  (uses LJDATE) but the generated results are different from my own Carla Scripts. So,  grateful for any hints and tips ! Would it be better to use SMF say Type 34 for TSO logon events - but this would not address the Protected Ids.         

Is there a STIG specifically addressing Inactive Ids, apart from the check IDs must be revoked after NN days ? 

Apart from CKRLINAC mentioned above, are there any other supplied zSecure Carla Scripts ? 

Many thanks in advance 

Peter

Note that the LAST-ACCESS (LJDATE) field is updated when the user completes a logon, or similar, but also when a RACF admin issues an ALTUSER RESUME for the ID.  It is quite normal to see IDs with recent LAST ACCESS date even when the user no longer works on your system: over-active RACF admins.

The LAST_CONNNECT_DATE is the most recent value from the list of LAST-CONNECT dates.  This will be updated after a successful RACROUTE REQ=VERIFY.

I assume the RACF databases are synchronized using RRSF, using command direction and password autodirect?  You can read here how RRSF synchronizes fields in the USER profile during logon (RACROUTE REQ=VERIFY).  LAST-ACCESS (LJDATE) and the LAST-CONNECT date are not included.  That means, you have to process a RACF database for each sysplex and combine the last use dates.

So allocate the RACF data base for each sysplex, or an UNLOAD of the databases, using the S line command in SE.1.  Each database must have a different COMPLEX value.  If you have CKNSERVE running on all systems, you can remotely access the (active) database of the remote systems.

Next, run a CARLa query like this

newlist type=racf
  define last_update max(ljdate)
  define last_connect max(last_connect_date)
  select class=user not(protected)
  summary profile(8) last_update last_connect count(nd)

This should give you the most recent logon info across all the selected databases.

SUMMARY has a concept of thresholds (see here) but I do not believe this supports a "today-100" symbolic reference.

Hi 

Have a number of Ids in their thousands that are spread across many sysplexes.

1. Need an accurate method to identify which UserIds are really inactive , an Id inactive on SysplexA might be active on SysplexB or C or D, so all RACF DBs need to be referenced to ensure the ID really is inactive on all Sysplexes.
2. The type of UserIds are both Protected (usually Started Task Ids ) and Human.
3. To date I have been using the following Carla line:  s s=base c=user  last_connect_date<TODAY-100 and reporting on last_connect_date(8) ljdate(8),. Both these vars are being used as for some Ids although last_connect_date is over 100 days, LJDATE is not.

4. Given RACF uses the LJDATE to calculate the user's inactivity interval, the documentation from zSecure states "

   "When you want to report the actual date that a user logged on with a RACINIT, you can use the field LAST_CONNECT_DATE. That field is documented as follows." .....This is usually a better estimate for the last logon date than the LJDATE (which is for instance also affected by ALTUSER),"

5. The supplied examples   CKRDLGAG  Menu driven Summary and    CKRLINAC  (uses LJDATE) but the generated results are different from my own Carla Scripts. So,  grateful for any hints and tips ! Would it be better to use SMF say Type 34 for TSO logon events - but this would not address the Protected Ids.         

Is there a STIG specifically addressing Inactive Ids, apart from the check IDs must be revoked after NN days ? 

Apart from CKRLINAC mentioned above, are there any other supplied zSecure Carla Scripts ? 

Many thanks in advance 

Peter