Have you ever thought what would happen if your External Security Manager (RACF, ACF2, or TSS) becomes unavailable? How will you be able to access your mainframe system?
Well, SYS1.UADS is the answer to this question. This dataset contains the list of users that can access the mainframe system should your External Security Manager (ESM) decides to go ‘belly up’.
There are however a few considerations you should be aware of before you start populating SYS1.UADS with all your team mates, or all the hot girls in the company (yes, I’m sure they would love to go out with you once you told them that they will be able to access the mainframe when disaster occurs and RACF ‘dies’).
The first thing you should know is how the system checks if a user can access the system:
- TSO first checks RACF before SYS1.UADS
- If the userid is defined to RACF with a TSO Segment then:
- Retrieves userid’s logon characteristics from the segment
- Validates password with RACF
- Verifies if userid is authorised to use TSO resources via RACF profiles
- If the userid is defined to RACF without a TSO Segment it then:
- Retrieves userid’s logon characteristics from SYS1.UADS
- If userid is not defined to SYS1.UADS then the system issues message:
- IKJ56420I Userid userid not authorized to use TSO
- Validates password with RACF
- If the userid is not defined to RACF, but is defined to SYS1.UADS it then:
- Retrieves userid’s logon characteristics from SYS1.UADS
- Validates password with SYS1.UADS
The second thing you should know is that passwords are stored in SYS1.UADS as clear text. This means that if you have READ access to SYS1.UADS, you can see which passwords are associated to the userids. Note that although recommended, users in SYS1.UADS do not require to have a password defined.
You should also be aware that every user in SYS1.UADS ends with a numeric character that starts in zero (e.g. IBMUSER0). Ever wondered why TSO users can only have 7 characters in length?
The most important thing you must always remember is that only a limited number of users should be defined in SYS1.UADS (yes, I’m afraid all those hot girls will be very disappointed). IBMUSER and system programmers are good candidates for SYS1.UADS. However, as a security best practice try to define a bear minimum of users to SYS1.UADS.
To manage users to SYS1.UADS you rely on the following TSO commands ACCOUNT and EDIT.
Finally, make sure that SYS1.UADS is well protected in RACF (or whatever ESM flavour you are using). When setting security controls remember that READ access allows someone to see which users (and passwords) are defined to SYS1.UADS. As a note, Eric Rosenfeld (IBM) reminds me, that in most cases, those users should be defined in RACF without TSO segments and revoked. This way they can only access the system when RACF is not available.
Dave, using UADS should always be a decision taken by the mainframe security team along perhaps with the system programmers. Trying to recover the problem with your ESM should always be the your main option. We could imagine a million different disaster scenarios, and in some of them UADS could be the easiest and fastest way to solve the problem. However, we must always bear in mind that by using UADS, we create another point that we need to control. Access to UADS should be restricted (even READ as mentioned in the article), there should only exist a very limited number of users in UADS, and these users should be reviewed ever so often.
Rui, I suppose the question here is, would you really want the option to logon using UADS if your ESM wasn’t working?
Obviously there are a lot of factors involved and it depends on the ESM and the issue itself, but if we take RACF as an example, then you may be in FAILSOFT. Not a good place to be if your system is accessing a large number of Datasets (General Resource access will be managed by the Resource Manager). I would suggest that you would probably look to fix/recover from another active system and then re-ipl.