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.