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 www.mycompany.com, 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.