May 31 ’13

Cross-Platform Security: The Role of LDAP

by Stu Henderson in Enterprise Tech Journal

As computers become more interconnected, administrators are often charged with administering security for other platforms across various types of network. Providing effective security across these connections is a challenge. 

This series examines common problems and approaches to cross-platform security, some basic underlying principles, and provides recommendations to make this security easy and effective. 

In the first article, which appeared in the Winter issue of Enterprise Tech Journal (available at http://esmpubs.com/u4eqv), we discussed some of the options and obstacles to implementing cross-platform information security. We provided some simplifying guidelines, and suggested Lightweight Directory Access Protocol (LDAP) and Kerberos as part of any optimum solution. Here we explain what LDAP is and how it contributes to effective cross-platform security.

LDAP is a means to store and access information about users. It consists of a program called the LDAP server, a database containing user information, and a set of rules on how the servers are to be organized and how the data is to be accessed.

The D in LDAP stands for Directory; that is, a database optimized for mostly reading. For example, a telephone directory will likely have frequent reads and infrequent updates.

Managing User Information
LDAP directories almost always store information about users. In the previous article, we examined UNIX cash registers connected to an iSeries (AS/400) midrange computer in a retail store, which connects to an IBM mainframe at a company’s headquarters. An LDAP directory on the iSeries computer could store information about cashiers who log onto the cash registers. This information might include their userids and the passwords or other information used to prove their identity.

LDAP stores and supports access to information about a user. It doesn’t verify the user’s identity; that’s a separate function. LDAP interfaces with several types of verification techniques, including Kerberos and digital certificates.

How LDAP Is Extensible
LDAP servers and directories are extensible in several ways. You can add new attributes (similar to adding a new field to a flat file record layout). For example, you could define the employeeNumber attribute as part of an LDAP directory. Then, for each user, you could store the value of this attribute. Programs and online users could then query this information.

The LDAP server maintains the LDAP directory and controls access to it. It can communicate with LDAP servers on other computers, usually via TCP/IP. For this communication to work, you must establish trust between the two servers. You accomplish this with the Kerberos security protocol, which we will describe in a future article. In our example, the LDAP server on the iSeries could be set up to trust an LDAP server on the mainframe. LDAP servers on mainframe computers can exchange information with the IBM RACF, CA ACF2 and CA Top Secret security software there.

Identity Propagation
IBM recently added a new feature to mainframes called identity propagation. This lets you tell RACF, ACF2 or Top Secret to trust an LDAP server such as Active Directory that has already verified a user’s identity. This will apply to our example configuration from the previous issue of a programmer’s workbench: a Windows computer that connects through a Local Area Network (LAN) to TSO and CICS on an IBM mainframe.

With identity propagation, a user logging on to the Windows computer, and proving his identity to Active Directory, won’t be required to re-prove his identity to the mainframe security software. Users avoid the extra effort of a double sign-on.

The LDAP Schema
You may be already familiar with many of the terms that follow if you’ve worked with Windows Active Directory. Active Directory is an LDAP server, and its database is an LDAP database.

The part of an LDAP database where you define the attributes (such as employeeNumber) is called the schema. Many of the attributes are standardized, including c= for Country, o= for Organization, ou= for Organizational Unit (such as division or department) and cn= for Common Name.

LDAP can be extended in a second way: You can organize servers into an upside down tree based on the attributes c=, o= and ou=. For example, imagine an organization named BIGCO in the U.S., which has stores named STORE01, STORE02 and so on. The LDAP server in STORE01 could be identified by its name made up of these attributes in this order: ou=STORE01, o=BIGCO, c=US.

The top of the upside down tree is the c= attribute. Below that is the o= attribute. You can add levels to branches of the tree under your control. For example, you could add an ou attribute such as division between the o=BIGCO and ou=STORE01. This would let you organize the stores into an Eastern Sales Division and a Western Sales Division. STORE01 would then have this name: ou=STORE01, ou=WestDiv, o=BIGCO, c=US. The LDAP server for o=BIGCO, c=US, would be responsible for all users whose names contain those attributes.

The LDAP server for ou=WestDiv, o=BIGCO, c=US would be responsible for all users whose names contain those attributes, but would be subordinate to the server at o=BIGCO, c=US.

Now if a cashier were temporarily assigned to a different store in a different division, he could be permitted to logon to the cash registers there. His userid and password, for example, would be sent from the different store’s LDAP server to the EastDiv server to the BIGCO server to the WestDiv server to the server for STORE01. The WestDiv server could verify the user’s identity and pass this information back to the EastDiv server and to the cash register itself. If a cashier should be permanently transferred to another store, LDAP will support an alias (a pointer from his old name to the new name). In this way, people who don’t know about his move will still be able to reach him.

Standards Applied
This scheme is easy to adopt because LDAP is supported not just on Windows, but on UNIX, mainframes, iSeries and other types of computers. All the country codes follow international standardization; organization codes follow American National Standards Institute (ANSI) standards.

Imagine an email coming from somewhere in Europe to a user named Mary Smith defined in STORE01. The email address could be to: c=US, o=BIGCO, ou=WestDiv, ou=STORE01, cn=MarySmith. The message could be routed by the country code to an ANSI server, which would route it to the BIGCO server based on the organization code. The BIGCO server would be responsible for getting the message routed properly within BIGCO.

You can see a similarity between LDAP names (cn=MarySmith, ou=STORE01, ou=WestDiv, o=BIGCO, c=US) and Domain Name System (DNS) names such as mary.smith@STORE01.WestDiv.BIGCO.com. You will want the same single set of people who manage DNS names in your organization to manage LDAP name assignment.

The individual name parts in LDAP, such as c=US and o=BIGCO, are called Relative Distinguished Names (RDNs). The entire name, all of the RDNs for an LDAP server or a person taken together, is called a Distinguished Name (DN).

Describing Resources
A third way to extend LDAP is to have directories describe things other than users (e.g., printers, computers and cash registers). LDAP can provide access control to such resources by supporting Access Control Lists (ACLs), specifying which users and groups can access which resources. ACLs are also used to control who can access which parts of the upside down tree.

When resources such as printers are described in an LDAP directory, you can make queries such as “What are all the printers to which I am permitted access, including their locations and characteristics?”

Conclusion
LDAP offers several advantages for cross-platform security:

• It provides storage and access means for information about users.
• It’s supported and proven on every major computer platform.
• It separates storage of user information from the proving of users’ identities.
• It provides a definition of each user that can be used for access control, either with its own ACLs or with the platform’s native access control.
• It interacts with (or in Window’s case is identical to) the native security mechanisms on each platform.
• It’s flexible in a controlled fashion, letting you tailor the data it maintains and the architecture of its servers.

A future article will continue our discussion of cross-platform security by describing how the Kerberos protocol works with LDAP to verify users’ identities and provide reliable encryption for cross-platform communication.