IGA & RACF – How Effectively Can You Manage the Risk of Mainframe Users?

This article was originally posted on LinkedIn on 29 August, 2019 (https://www.linkedin.com/pulse/iga-racf-how-effectively-can-you-manage-risk-users-david/).

Way back in the late 80’s I was a trainee programmer learning all things green-screen, like ISPF, JCL, CICS and Cobol. Colleagues laughed, asking me why I was bothering given the mainframe would be gone in five years. Here we are thirty years later, and the mainframe is still going strong powering many of the mission-critical workload of many enterprises. 

Given that we’re unlikely to see the demise of the mainframe in another five years, and the reason they’re still in use is because of the mission-critical workloads, it makes sense to look at how we can govern users, particularly high-risk users on the mainframe. Specifically, z/OS mainframes running the Resource Access Control Facility (RACF), as this represents the majority of systems.

This article will look at the RACF access model to highlight the myriad ways it manages access for users. Then it will look at the standard approaches IGA solutions use to get into RACF and extract data for identity governance use cases. Finally, it looks at some of the access objects that should be the focus of identity governance and how well IGA solutions can access this data.

The RACF Access Model

At a cursory level, RACF seems to fit the standard users (accounts), groups, resources and permissions model used by many systems.

Users (accounts) are defined in User Profiles. Users can be collected into groups (Group Profiles) via a connect command. Users and/or groups can be permitted to access dataset or general (other) resources with an access level (defined in an Access List). For example, John may be granted read access on a file directly, or he may be in a group that gives him read access to the file.

Whilst this represents a lot of the access control on many z/OS systems secured by RACF, it is just one of many ways that access may be granted or restricted. The following figure shows many of the access-related settings that may be found on the different profiles.

(My z/OS and RACF colleagues will probably cringe at my over-simplification of the complexities here.)

For a RACF user, in addition to connections to groups and/or permissions on resources there may also be:

  • Attributes providing system-wide overrides for access. For example, “SPECIAL” (often called system-SPECIAL) makes the user the z/OS equivalent of a super user.
  • The users default group and the authority associated with that group (i.e. permissions on that group and the resources associated with the group).
  • Universal access (UACC) is like a default access if no other access rules apply
  • Installation-specific access control can be implemented through security classification (security levels, categories and security labels). For example, there may be labels, like “Top Secret”, “Secret”, “Confidential” applied to resources with a user needing the appropriate level to access resources.
  • Segment-specific attributes – the user profile may contain user attributes for different components running on the mainframe and this may include access-relevant settings

For connections to groups there may be group-attributes (like group-auditor, group-special or group-operations) that give the user overriding access to resources controlled by the group. There may also be group authorities or universal access applied in a connection to a group. Group profiles may also have some restrictions applied.

Resources (datasets and general) will have access lists defining who (user/group) can access a resource and how (none, read, update etc.) they can access the resource. There may also be conditions built into the access list.

There can also be a universal access on a resource. For example, it may make sense to set a UACC of Read access for all users for general access resources and use access lists to defined higher access for others. There is also the security classification mentioned above.

Another feature of RACF is the ability to have generic resource definitions. By using wildcards, sets of resources can have their access managed together. RACF can review all resource definitions and identify the best fit one for the resource a user is trying to access. You can’t rely on a casual look at a set of resource profiles to determine what access a user would have – you would need to use some system utilities to explore the catalog (for datasets) and determine which resource profile applies. 

Thus, knowing what users, groups, and resource profiles, and their relationships is only part of the RACF access model and won’t give a true picture of the access all users have.

How do IGA Systems Access RACF Data

Now that we have an inkling of the complexity of the RACF access model, let’s look at how IGA systems access the objects. There three basic patterns; via LDAP, via a scriptable 3270 client, or via an agent running on the mainframe. We will look at each.

The first pattern is accessing RACF via LDAP. This involves configuring the z/OS Directory Server (aka IBM Tivoli Directory Server for z/OS) with the RACF database as one of its backend data stores.

This means LDAP commands can be used to access RACF data; Users, Connects, Groups and General Resources. It cannot access Dataset profiles. From an identity governance perspective this means you can access all of the user-, connect-, group- and general resource-access definitions, but not dataset access definitions.

This pattern is used by many IGA vendors but does require the z/OS Directory Server to be configured and LDAP (or preferably LDAPS) access be allowed into the z/OS system.

The second pattern is accessing RACF via a scriptable 3270 client running near the IGA solution. Some 3270 clients allow scripting to pass commands via the client to the mainframe. This mechanism allows any command to be run against RACF (and other components on z/OS) so any RACF object could be extracted into the IGA solution for governance. 

With this pattern, there may be performance implications of pulling the entire RACF DB across the network for analysis in an IGA tool. Also, there would need to be a lot of work to define the scripting to access every RACF object in this way.

This pattern is sometimes used with Microsoft Identity Management implementations. There are two interesting articles by Darren Robinson of Kloud; Automating RACF Administration with PowerShell (https://blog.kloud.com.au/2019/06/25/automating-racf-administration-with-powershell/) and A Rudimentary RACF Management Agent for Microsoft Identity Manager (https://blog.kloud.com.au/2019/06/26/a-rudimentary-racf-management-agent-for-microsoft-identity-manager/).

The third pattern is to build and deploy an IGA agent onto the z/OS system to interact with RACF there.

This pattern relies on the agent being written to interface with RACF and having the logic to be able to access the different RACF objects. Theoretically the agent could access all RACF objects. As it is running on the z/OS system, it could do local analysis and only send the necessary data across the network to the IGA system.

IBM and MicroFocus NetIQ use this pattern for their IGA implementations.

An extension of this pattern is to use a RACF audit/administration tool, like the IBM zSecure suite, to perform all of the detailed RACF extraction/reporting/analysis and leave the agent to perform the networking interface duties. This pattern is used by IBM Security Identity Governance and Intelligence for its fine-grained RACF integration.

Each of these patterns have their benefits and challenges. The LDAP pattern is simplest to setup and uses the LDAP standard for accessing RACF data but cannot expose all RACF objects (specifically the dataset profiles). The other two patterns will allow access to all RACF data but at a cost of having to code to do so. The “agentless” patterns (3270 & LDAP) may also involve large amounts of RACF data being shipped over the network, vs. the agent-based pattern where analysis can be performed on z/OS.

What Does All This Mean for Identity Governance?

The previous sections have talked about what RACF objects are available and how to access them. We can look at some of the identity governance implications; i.e. identifying the risk that users pose through their access. As we have seen, RACF is a complex beast and each implementation will be different, so security consulting is recommended to come up with the required identity governance plan for an environment. The following are some suggested guidelines and limitations.

First, we can look at the user profile. There is a lot of access information on the user that may indicate risk and the need for governance tools (like recertification):

  • Which users are carrying risky attributes, such as SPECIAL, OPERATIONS and AUDITOR? Any users found with these should be flagged as risky and managed/governed appropriately.
  • Do users have high-risk default groups and a risky level of authority (CREATE, CONNECT or JOIN)? This will require an analysis of the group profiles to determine  what’s considered “risky” and may involve system-managing groups and groups granting access to business application resources.
  • Do any users have higher-level UACC, such as UPDATE, CONTROL or ALTER? They should be flagged as risky and managed/governed appropriately
  • Is there some form of security classification implemented (security levels, categories and/or security labels) and if so, which users have risky classifications? Again, this requires an understanding of what is considered risky.
  • Do any users have any risky segment-based settings? Are there CICS settings that give privileged access? Are there z/OS UNX (OMVS/USS) settings (like having a UID=0, i.e. root) that give privileged access? Much of this information is installation-specific and requires analysis.

All of this information is held on the user profile, so any of the integration patterns would allow an IGA system to access it, although the agent-based or 3270-based patterns may require work to access all of the information as many implementations won’t look at all the settings or segments.

From a connect and group profile perspective, you should look at:

  • What is the risk associated with each group? This would require analysis but may be based on the resources if manages (common-use files vs. system or critical business application files) and the system it is on (testing, QA, production, DR).
  • What users have group-SPECIAL, group-OPERATIONS or group-AUDITOR for the group and how high is the risk on the group? If a group is low risk then this may not be a concern, but if the group is high risk then these users should be flagged as risky and managed appropriately.
  • What group authorities are assigned to the group for a user via a connect? Are they higher risk (CREATE, CONNECT or JOIN) against higher-risk groups?
  • Are there higher-level universal access settings, such as UPDATE, CONTROL or ALTER? If they are for higher-risk groups, the users should be flagged.
  • Are there any risky segment-based settings? Whilst the segments available for groups is a lot less than for users, they should be reviewed.

All of this information is held in the connect and group profiles, so any of the integration patterns would allow an IGA system to access it, although the agent-based or 3270-based patterns may require work to access all of the information as many implementations won’t look at all the settings or segments.

The last, and most complex, access definitions to consider are the resource profiles (dataset and general). There should be an analysis of what resources are being secured and what the risks associated with those resources are. Does a profile protect system datasets (like SYS1.**) or mission critical application resources (like CICS transactions or DB2 access)? The Access Lists on each resource will identify users or groups and their access level. Any user or group with an access level higher than READ (i.e. UPDATE, CONTROL, ALTER) on a resource that is considered risky should be flagged.

However, there are complexities associated with this. The major one is the use of generic profiles, i.e. profiles defined through wildcards accessing many resources. Looking at resource profiles won’t tell you exactly what dataset or other resource the user/group can actually access. There are z/OS utilities that will go through the catalog and determine what datasets are covered by a generic dataset profile. But this doesn’t cover everything (e.g. CICS transactions). The other complexity is that some access lists may have conditions (conditional access list) that define how a user/group can access a resource (such as via a certain program or terminal). So, whilst a user/group may appear to have a high level of access based on the access list, the risk of this may be mitigated by controlling how that access is used.

This resource-based access is the hardest for IGA products, irrespective of the integration pattern used. The LDAP-based pattern won’t expose the dataset resources. Both the 3270-based and agent-based patterns require significant customization to extract and analyze all of the resource-related data.

If you need more fine-grained visibility into access that current IGA products do not provide, what other options do you have? You could certainly develop your own reporting and analysis capability for z/OS RACF or use a product like IBM zSecure Audit that has a rich scripting language designed for just that purpose. Results could be pulled into an IGA system.

Another approach is to identify the privileged users (accounts) and manage them in a Privileged Access Management (PAM) system. This could be combined with audit capture for high risk users combined with reporting with SMF and a SIEM like IBM Security QRadar. Combined they may mitigate the risk of identities on z/OS.


In this article we have looked at Identity Governance and Administration (IGA) and z/OS RACF. We’ve looked at the RACF access model and how complex it can be. We’ve also looked at the standard patterns for integration between an IGA solution and RACF and the limitations that may impose. Finally, we’ve looked at the types of access applied to the different RACF objects and how that can be used with IGA to manage user-related risk.

RACF is a complex system and no current IGA solutions can provide effective governance of RACF identities. Consulting is required to determine what your identity governance needs would be for a RACF-secured z/OS system. Perhaps you don’t need visibility into everything and the current set of IGA products would be enough. Perhaps you need to look for additional capabilities, like complex reporting on z/OS, use of PAM and/or SIEM solutions to mitigate risk.

Some additional reading:

Leave a Reply