IBM Security Z Security

Expand all | Collapse all

zSECURE/ CARLA: GetUmap/getGmap vs BPX.NEXT.USER

  • 1.  zSECURE/ CARLA: GetUmap/getGmap vs BPX.NEXT.USER

    Posted Thu December 03, 2020 04:44 AM
    Edited by Nordine Mosbah Thu December 03, 2020 07:52 AM
    Hello ,

    I'm looking for an explanation about an issue I found regarding 'OMVS UID' and APPLICATION DATA of BPX.NEXT.USER eventual interaction .
    Basically , in the system BPX.NEXT.USER is here (in case of the userid does not have an OMVS segment (and other criterias) -> the user will receive a OMVS segment based on a model and the next valid UID will be given to this userid ) .

    Few month ago ,  in order to list (all the userids sorted and their assigned UID , their connected group with their GID) a built CARLA request or a generated from the zsecure menus was used . And the consequence apparently is that this resulted with the users being assigned an OMVS segment with an incremented 'defaulted' UID.

    getUmap generating an SMF type 80 record (event 88) with a new UID
    getGmap generating an SMF type 80 record (event 88) with a new GID is assigned

    Also , apparently , that the RACF USER LAST-ACCESS field is not updated .

    Could you please , inform about/explain that which kind of CARLA code/function does that ?
    How this interaction with the UIDs range values included in APPLICATION DATA of BPX.NEXT.USER ?

    How it's possible to rever back the previous UIds values ?
    And how to prevent such getUmap/getGmap done by CARLA code in the active RACF database ?

    Thank you .


    Extra info :
    ------------

    Se below an extract of this the SMF dumped when the events happened (for hundred of users)  :


    AUTOPROF SUCCESS 15:26:15 2020-06-15 XXXP NO NO NO XXXXXM BRSYS ... getUMAP USER AB$ADMNB ...OMVS(UID(2171288) HOME('/tmp/default_user_dir') PROGRAM('/bin/false'))

    AUTOPROF SUCCESS 15:26:15 2020-06-15 XXXP NO NO NO XXXXXM BRSYS ... getUMAP USER AB$BDMNF ...OMVS(UID(2171289) HOME('/tmp/default_user_dir') PROGRAM('/bin/false'))

    AUTOPROF SUCCESS 15:26:15 2020-06-15 XXXP NO NO NO XXXXXM BRSYS ... getUMAP USER AB$XDMNU ...OMVS(UID(2171290) HOME('/tmp/default_user_dir') PROGRAM('/bin/false'))

    AUTOPROF SUCCESS 15:26:15 2020-06-15 XXXP NO NO NO XXXXXM BRSYS ... getUMAP USER ACT0140 ...OMVS(UID(2171291) HOME('/tmp/default_user_dir') PROGRAM('/bin/false'))

    AUTOPROF SUCCESS 15:26:15 2020-06-15 XXXP NO NO NO XXXXXM BRSYS ... getUMAP USER ACT0190 ...OMVS(UID(2171292) HOME('/tmp/default_user_dir') PROGRAM('/bin/false'))

    AUTOPROF SUCCESS 15:26:15 2020-06-15 XXXP NO NO NO XXXXXM BRSYS ... getUMAP USER ACT0310 ...OMVS(UID(2171293) HOME('/tmp/default_user_dir') PROGRAM('/bin/false'))

    AUTOPROF SUCCESS 15:26:15 2020-06-15 XXXP NO NO NO XXXXXM BRSYS ... getUMAP USER ACT0320 ...OMVS(UID(2171294) HOME('/tmp/default_user_dir') PROGRAM('/bin/false'))

    AUTOPROF SUCCESS 15:26:15 2020-06-15 XXXP NO NO NO XXXXXM BRSYS ... getUMAP USER ACT0360 ...OMVS(UID(2171295) HOME('/tmp/default_user_dir') PROGRAM('/bin/false'))

    AUTOPROF SUCCESS 15:26:15 2020-06-15 XXXP NO NO NO XXXXXM BRSYS ... getUMAP USER ACT0370 ...OMVS(UID(2171296) HOME('/tmp/default_user_dir') PROGRAM('/bin/false'))

    AUTOPROF SUCCESS 15:26:15 2020-06-15 XXXP NO NO NO XXXXXM BRSYS ... getUMAP USER ACT0380 ...OMVS(UID(2171297) HOME('/tmp/default_user_dir') PROGRAM('/bin/false'))

    ...

    As you can see in the report the user are sorted alphabetically and Uid assigned is order incrementally : that's why I suspected such thing .

    Then , does CARLA code/or generated via zSECURE menus can do that ?





    ------------------------------
    Nordine Mosbah
    ------------------------------


  • 2.  RE: zSECURE/ CARLA: GetUmap/getGmap vs BPX.NEXT.USER

    Posted Thu December 03, 2020 07:56 AM
    Hi Nordine,

    let me start by explaining that CARLa is not involved in the automatic assignment of UID/GID values in the OMVS segment of user IDs and group IDs that do not have a OMVS segment defined yet. The feature of automatic definition of OMVS segments and assignment of UID/GID values is performed by RACF instead. According to my information, you have to define FACILITY class profile BPX.UNIQUE.USER to activate this feature.
    Next, when profile BPX.UNIQUE.USER is defined, it collaborates with FACILITY class profile BPX.NEXT.USER that keeps track (in the application data field) of what the next available UID and GID value is to be automatically assigned to the next user or group IDs that do not have an OMVS segment defined. Each time that profile BPX.UNIQUE.USER consults profile BPX.NEXT.USER, the UID/GID values (if applicable) are incremented with 1. Please be aware that, the automatically assigned UID/GID values will only increase and will not fill in the gaps when previously assigned UID/GID values are no longer defined in the RACF database. Optionally, you can code ranges of where automatic UID/GID assigned values should start and end.

    I am not quite sure what you think is the association with the CARLa programming language that you mention in your message. CARLa is not involved in the automatic of definition of OMVS segments and the assignment  of UID/GID values. CARLa can be used to report about user and group IDs with their assigned UID and GID values.

    > How it's possible to rever back the previous UIds values ?
    I do not understand what you mean with this question. If all is well, user and group IDs that already had an OMVS segment and assigned UID/GID value will not be affected by the RACF process that automatically assigns UID/GID values (based in the values extracted from BPX.NEXT.USER).

    >And how to prevent such getUmap/getGmap done by CARLA code in the active RACF database ?
    As mentioned earlier, CARLa is not responsible for automatic assignment of UID and/or GID values to user and group IDs. When you want to prevent the automatic assignment of UID/GID values, I guess that you should not define FACILITY class profile BPX.UNIQUE.USER. In that case, the definition of OMVS segments for new USS users and assignment of UID/GID values needs to be performed by your RACF security administrators.

    I may have misinterpreted your message, if that is the case, can you please elaborate on what issue you are reporting?
    I hope you find this information helpful.

    ------------------------------
    Tom Zeehandelaar
    z/OS Security Enablement Specialist - zSecure developer
    IBM
    Delft
    +31643351728
    ------------------------------



  • 3.  RE: zSECURE/ CARLA: GetUmap/getGmap vs BPX.NEXT.USER

    Posted Fri December 04, 2020 04:40 AM
    Hello Nordine,
    As we discussed via the open case yesterday, and as Tom has confirmed, zSecure does not use the RACF services that resulted in these SMF records.
    The case, as agreed, has been passed back to RACF support to assist you further in determining what caused these RACF services to be executed
    Regards, Mike

    ------------------------------
    Mike Riches
    ------------------------------