Since its development in the 1990s, Kerberos has become a widely-used choice for exchanging security information. From CICS TS Version 5.2, CICS supports the use of Kerberos security tokens for authentication.

There are lots of good reasons for wanting to use Kerberos to allow clients to access services on both distributed systems and on z/OS. It joins up the authentication processes between the systems so that you can use single sign-on and gets you away from flowing passwords between the distributed and mainframe systems. But the configuration can be complex. We’ve written a paper to show you how to do it, step-by-step.

Blog Summary

    This blog aims to answer the following questions:

  • How do I set up Kerberos to authenticate client access to services on both distributed systems and on CICS TS for z/OS?
  • How do I deal with problems in the Kerberos configuration?

Kerberos is often used in a client/server environment. Clients need access to services in a range of servers and Kerberos is used to authenticate that access. That’s a familiar pattern for distributed systems. But what if one of the services that they need is on CICS, on z/OS?

Without Kerberos on the CICS side, your clients need a whole different authentication method to get to the service in CICS. They have to connect directly with a password which might not be ideal from two points of view: many systems are trying to get away from flowing passwords and it prevents single sign-on.

Using CICS support for Kerberos, clients can authenticate to the service in CICS in the same way as they do to the services on distributed systems. The CICS service is, to them, just another service. No passwords are flowed and single sign-on is possible. The Kerberos support in CICS (and RACF) maps Kerberos identities to z/OS userIDs so that you get all the benefits of CICS security, combined with the single sign on.

But …

In theory, that’s great. In practice, it can be a daunting prospect. You have to link the distributed security manager, such as Microsoft Active Directory, with the mainframe security manager, such as RACF. Typically, this involves multi-disciplinary teams who have to bridge between the terminology and concepts of their respective worlds. Like a jigsaw puzzle, every piece of the configuration needs to go into exactly the right place. And if things go wrong, it can be tough to pinpoint the cause and unravel the configuration to the right point.

Download our step-by-step guide

Our CICS paper walks you through configuring Kerberos for CICS with both RACF and Microsoft Active Directory. Sample code of a simple Java application that you can use to test the configuration is provided in GitHub.

The paper shows you how to set up RACF and CICS in a simple Kerberos configuration, and how to test this before you go any further. Then, it covers a simple configuration of Microsoft Active Directory – the sort of configuration that you could use in a test environment – and connects this second Kerberos server to the RACF system on z/OS. Finally, it shows you how to test trust between these two servers. Troubleshooting Kerberos issues can sometimes be challenging so there is advice on getting out of some potential pitfalls.

Get the paper here.

1 comment on"Configuring Kerberos for CICS with RACF and Microsoft Active Directory"

  1. I have been asked by my management to look at Single Sign-On solutions for the mainframe. I was given this article as a reference. I see how this can be set up for CICS. Will CL-Supersession work using this model? Additionally I would like to know do the subsystems running on the mainframe, TN3270, Netview, etc. include code to take advantage of the Kerberos,Active Directory, RACF, CA-Top Secret ability to use certificates?

Join The Discussion

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.