Nov 10 ’13

Cross-Platform Security: Considerations Before Implementing LDAP and Kerberos

by Stu Henderson in Enterprise Tech Journal

In the last three issues, after discussing the difficulties with cross-platform security and single-sign-on, we suggested Lightweight Directory Access Protocol (LDAP) and Kerberos as the most effective approaches. Here, in this concluding article, we continue by describing how to think about these protocols and the important questions and steps to address when implementing them. You will see that while they offer significant advantages, they also require significant planning, standards enforcement and organizational shifts. While this can be a major effort, each part of it will simplify overall integration of the various platforms with which you deal.

Whether or not you implement LDAP and Kerberos, the steps outlined here will have significant benefits to your organization as the computers you deal with become increasingly interconnected. In any environment where major components are starting to come together, the process is much easier if the components have been configured in advance to fit neatly.

Planning in advance for cross-platform connections will give you the opportunity to implement the needed changes gradually and with careful consideration. 

We’ve recommended LDAP and Kerberos because they’re universally supported, standard, extensible, proven, vendor-neutral and secure.

Whatever approach you select, these steps will give you a running start:

1. Define realm boundaries.
2. Design your Directory Information Tree (DIT).
3. Define userid mapping.
4. Determine what software will use LDAP and Kerberos.
5. Define your architecture for access control.
6. Plan your encryption implementation.
Define realm boundaries. Start with a list of all the platforms (computers) you want to include in your cross-platform architecture. Whether or not you use LDAP and Kerberos, you can simplify the issue by mentally organizing all the computers in your organization into realms or domains. Realm is the LDAP term; domain means the same thing with Windows Active Directory. A realm or domain is the collection of computers managed by one server or set of servers.

You will need to define where your LDAP servers and Kerberos servers will be located in each realm and which other platforms are controlled by each. Windows platforms may be a good starting point for this, since they’re already organized into realms. For all types of platform, you want the servers located on computers with good physical and logical security, since the server location is where users get authenticated.

Decide which platforms will trust which other platforms, so you can set up the trust relationship with Kerberos. This will be easier for Windows servers since each Windows domain is a realm, and Active Directory uses Kerberos handshakes to establish trust between domains. On UNIX, specify the name of the realm in the Kerberos configuration files. On IBM mainframes with z/OS, the security software uses the REALM resource class to specify realms. Decide which trust relationships will be one-way and which will be two-way.

To illustrate trust relationships, take our example of the UNIX cash registers connected in a store to an iSeries (AS/400) computer that’s connected to an IBM mainframe. Users could be defined in an LDAP server on the iSeries, which would manage the domain of the cash registers in that store. If a user on the mainframe needed to access the iSeries, the LDAP server on the iSeries might need to be able to trust the LDAP server on the mainframe. If a user defined on the iSeries server wanted to access CICS on the mainframe, then the mainframe LDAP server might need to trust the iSeries server.

Trusts involving both Windows and non-Windows platforms will almost always have to be one-way. Windows Active Directory has difficulty trusting Kerberos authentication on non-Windows platforms because Kerberos on Windows stores the userid identifiers (called SIDs and described later) in user-defined fields in the Kerberos session tickets. Since other platforms don’t understand SIDs, it’s nearly impossible for them to provide SIDs as identifiers to Windows. These other platforms then will have to trust Windows without Windows trusting them in return.
Take our example of the programmers workbench: the Windows PCs in a LAN that’s connected to a mainframe. Users would use Kerberos to log on to the LDAP server (Active Directory) that manages the LAN. The security software on the mainframe can be configured to trust the Active Directory server to have established users’ identities. If on the other hand, we wanted to have the Active Directory server trust the LDAP on the mainframe, this wouldn’t be feasible because the mainframe wouldn’t be able to provide the SIDs, which are essential in Windows to defining a user’s identity.

Design your DIT. For LDAP, you will need to define your DIT; that is, the set of Relative Distinguished Names that make up your Distinguished Names. This determines the search path when trying to obtain information about a user. 

There are two common approaches to this. The original approach was to use the upside-down tree that starts with the country at the top, organization at the next level down and organizational units below that, down to common names. Many shops prefer the second approach, which is to have all users defined in one container. This simplifies things when a user transfers to a different Organizational Unit (OU), since other users don’t need to learn a new name to reach him. 

With the second approach, the country is ignored. The top of the tree instead is taken from the organization’s DNS name. For example, if the DNS name is, the top of the tree might be dc=mycompany,dc=com. All users would be defined at the server at ou=allusers,dc=mycompany,dc=com.

Along with the names in the DIT, define other attributes for user definitions, including the user identifiers used by each platform. This is the basis for userid mapping.

Define userid mapping. To design your userid mapping, you will map the user definitions in the LDAP or other common directory to the user definitions used by each platform. For example, on UNIX, users are identified by a number called the UID or User Identifier. Groups are identified by a number called the GID or Group Identifier. If you have many UNIX platforms in your organization, and they haven’t coordinated assignment of the numbers for UIDs and GIDs, you will need to provide this coordination. Here’s why:

Suppose UNIX Server A has a user Sam Smith whose UID is 409, and UNIX Server B has a user Mary Jones whose UID is also 409. If you use LDAP and Kerberos to provide cross-platform security, these two users look the same. If Mary Jones can connect to Server A, she will be able to do everything Sam Smith can, since she will be Sam “409” Smith on that server.

Coordinating the assignment of UNIX UIDs and GIDs across UNIX platforms may seem like a lot of unpleasant work. But it’s the first of several examples of how laying the groundwork for LDAP can rationalize your whole shop in a way that makes you more flexible and ready for integration regardless of whether or not you use LDAP.

Userid mapping is necessary because each platform identifies users in a different fashion, while LDAP uses Distinguished Names. Since the access control mechanisms on each platform rely on the user identifier specific to that platform, you need to map the LDAP names to the various other types of identifier. LDAP supports this by providing attributes in the schema for the identifiers used by other platforms. For example, the attribute uidnumber is often used in the LDAP user definition to provide the numeric UID, which identifies a user to UNIX.

As we noted earlier, on Windows, users are identified by a unique number called a SID or Security Identifier. Groups are identified by a different number also called a SID. Because of the way Windows manages SIDs, it isn’t feasible to store the SIDs in non-Windows LDAP directories.

Mainframes using z/OS identify users by an eight-character name called a userid by RACF, a Logonid by ACF2 and a User ACID by TopSecret. On mainframes with z/OS, the security software uses the KERBLINK resource class to map LDAP user definitions to mainframe userids.

Determine what software will use LDAP and Kerberos. Evaluating what software will use LDAP and Kerberos has two aspects. First, ensure every piece of software that needs to verify a user’s identity can support these protocols. This is easy in Windows, since these are the standard protocols. It’s relatively easy with UNIX, too, since you can make standard modifications to the Pluggable Authentication Module (PAM) to identify users this way. By now, most UNIX programs should be capable of turning to PAM to verify users’ identities. You direct telnet, FTP and other programs to use PAM to identify users. You then direct PAM to make use of LDAP and Kerberos.

On mainframes with z/OS, some software, such as CICS and DB2, support LDAP and Kerberos. Other software is scheduled to support them, but isn’t yet available.

The second aspect of software evaluation addresses programs that can benefit from information stored in LDAP. These include email, phone directories, print programs and others. For example, if you define printers and their locations and characteristics in the LDAP directory, a print program can ask a user to specify which nearby color printer to use.

Define your architecture for access control. To define your architecture for access control, start with the basic premise that each platform is responsible for protecting its own resources. If you allow individual users (not groups) to be granted access to individual files and resources throughout your configuration, you will end up with a spaghetti-like mess of permissions that will be difficult to clean up. You will also need a userid on each platform to perform security administration for the files and resources located on the platform.

For cross-platform security, you will want to enforce Role-Based Access Control (RBAC). Define groups that represent collections of access privileges corresponding to specified roles, such as “accounts payable clerk.” Grant each of these groups the privileges it needs on the platform where the files and resources are located. Then you can simply connect users to these groups and remove them from the groups as needed. This will entail much less overhead and confusion than permitting each individual user to each individual file or resource. Using RBAC can make it possible to avoid having a userid for security administration on each platform. This is another example of management preparation for LDAP that will benefit your organization whether or not you use LDAP.

Plan your encryption implementation. Decide which links, applications and data will need to be encrypted when passing between two platforms. Get direction from your Compliance or Legal departments to do this. You can then specify that Kerberos provide encryption only for the instances where you need it. 

Finally, you will need to address a few miscellaneous tasks. Since Kerberos relies on time-of-day, you will need to synchronize the clocks across the platforms. You will also need to provide performance tuning and load balancing for servers. To avoid having a single point of failure, you will want to provide replication of both LDAP and Kerberos servers.

You will also need to conduct an overall risk assessment to ensure that connecting the various platforms doesn’t create new security exposures. Evaluate what the risk would be to other platforms if any individual platform’s security were to be broken. Ensure that passwords aren’t readable anywhere in the entire configuration.

All this work may seem daunting. However, it can be accomplished gradually. The planning, organization, standardization and security that result will benefit your organization whether or not you use LDAP and Kerberos. These benefits will be more significant as more of the computers you manage become interconnected.

Additional Resources
“Cross-Platform Security: Recommended Solutions for Common Problems,” Enterprise Tech Journal, Winter 2012/2013 available at
“Cross-Platform Security: The Role of LDAP,” Enterprise Tech Journal, May 2013 available at
“Cross-Platform Security: How Kerberos Works With LDAP,” Enterprise Tech Journal, August/September 2013 available at