Understanding the DIT

One of the most important decisions to make when transitioning to an LDAP name service is determining how your directory information tree (DIT) should be organized. This is important because it is difficult, and potentially disruptive, to redesign your DIT after it is implemented. Questions to ask are:

• Is the directory suffix name meaningful?

• Are there particular security policies you need to implement?

• Will the DIT be shared with other applications?

Other considerations indirectly affecting the DIT are:

• What will your user entries look like?

• Do you plan to create custom attributes and object classes?

• How large will the directory need to scale to?

• Will the deployment be departmental or enterprise-wide?

The following sections discuss these considerations, explain what the defaults are, and offer advice for alternatives:

• "Understanding the Directory Suffix" on page 184

• "Creating Containers" on page 186

• "Using ACIs to Support Security Policies" on page 189

• "Co-Existence with Other LDAP-Aware Applications" on page 190

Understanding the Directory Suffix

The directory suffix is the top node of your DIT and last component of an entry's distinguished name (DN). In some respects it resembles the root ( / ) directory in a UNIX file system. Unlike the root directory, there is no single predefined name for the top of the tree. Instead, there may be several suffixes defined for a DIT. However, in virtually all cases, user data is only contained under one of the suffixes. Other suffixes are used to store items such as configuration data.

To determine what suffixes a DIT contains, you can perform a base-level search of the directory server entry (DSE) of the directory service instance you are interested in. The supported suffixes are returned as namingContexts attribute values. To find out what data is contained beneath a suffix, you can perform subsequent searches on each suffix.

There are no hard and fast rules for choosing a suffix name. However, because the suffix is specified as part of the search base that is used to locate entries, it makes sense to choose a suffix name that is meaningful and easy to remember. For example, many companies choose a suffix that resembles their registered DNS name. Besides making the name easy to remember, this technique provides you with a unique name, which could be important if you plan to share directory data with a business partner. Unlike DNS, there are no registration authorities for issuing directory suffix names .

Choosing a Suffix Name

Suffix names can be constructed by specifying one of three naming conventions:

1. organization ( o= )

2. country code (C=)

3. domain component ( dc= )

The first two naming conventions come from the X.500 and X.509 specifications that predated the wide use of the Internet. At the time there was no global DNS infrastructure that included nearly all companies like the one that exists today. To establish unique names, X.500 specified elements like the country of origin and name of a corporation. The country attribute represented the country where the enterprise is based and the organization attribute represented the name of the corporation. The country naming attribute is not recommended because it is not suited for international corporations.

The second naming convention takes advantage of the fact that practically every corporation has a registered DNS address. This name is generally recognizable by everyone within the enterprise, which make it a practical choice.

The organization Attribute

The organization attribute can contain a DNS domain name like: o=sun.com , or simply the name of your enterprise like o=sun . The organization attribute is sometimes used to identify components that are not related to the name of an enterprise, for example, o=internet . Using the o= attribute in this manner might be alright to support internal applications, but should be avoided if possible.

The dc Attribute

The domain component ( dc ) attribute is typically specified more than once to form a DNS address. For example:

 dc=example, dc=com 

If you choose, you can specify additional subdomains. For example:

 dc=uk, dc=example, dc=com 

Either the dc= or o= convention work just fine. By default, Sun ONE Directory Server 5.2 software uses the dc= notation set to your DNS domain as the main suffix. For example, if you are in the uk.example.com domain, the default main suffix is dc=uk , dc=example , dc=com .

Creating a Suffix

Directory suffixes can be created either during the initial directory server installation and setup, or after the directory server is configured. As described in "Configuring Sun ONE Directory Servers and Clients " on page 214, you are prompted for a main suffix. The default that is displayed is the domain of the system you are installing it on, expressed using the dc= format.

Accepting the default is perfectly reasonable, although you might not want to map the directory suffix to the full DNS domain name of the system you are installing the directory server on. This is because the directory service scales much better than DNS, so you might choose to place all your naming data under the same suffix. For example, even though your DNS domains are split up into east.example.com , central.example.com , west.example.com , and so forth, you might choose to only use the two trailing components. For example, example.com . If you do not split your DNS domains internal to your company, this is not an issue.

Creating Containers

Below the suffix, containers are created where your naming service data will be placed. Containers are usually denoted by specifying the organizational unit ( ou ) object class. By default, the directory server installation creates the following three containers:

• ou=People

• ou=Groups

• ou=Special Users

The following additional containers are needed to support the Secured LDAP Client:

• ou= group

• ou=services

• ou=protocols

• ou=rpc

• ou= hosts

• ou=networks

• ou= netgroup

• ou=printers

• ou=profiles

• ou=projects

• ou=solarisauthattr

• ou=solarisprofattr

• automountMapName=auto_*

The names of the containers can be changed from the default names, but this is not recommended because you would have to explicitly supply the names of the containers to your clients. One exception might be the ou=People container where user entries are stored. If you choose to split up your users into different categories, you might wish to create additional containers such as ou=SalesPeople .

Notice that there is an ou=group container present. Do not confuse this with the ou=Groups container. The former is applicable only to POSIX-defined groups, while the latter is used for directory user groups.

The containers where automap entries are stored are not designated as organizational units (ou) like the other containers. Instead, the autoMapName attribute that is contained in an automountmap entry is used. These are shown in bold in FIGURE 4-1.

Figure 4-1. Naming Service DIT Example

When the idsconfig script (discussed on page 225) is run to configure your directory server, a DIT similar to the one shown in the following diagram is created.

Additional containers are created when the directory is populated with the ldapaddent(1M) or smattrpop(1M) commands. Use of these commands and procedures for creating additional containers is described in Chapter 5 "Migrating Legacy Data to LDAP."

Using ACIs to Support Security Policies

Access Control Instructions (ACIs) are the mechanism used by the directory server to control access to directory data. To implement LDAP as a Solaris OE name service, some default ACIs need to be overwritten. The nicknames of three ACIs that are often created, or modified, are:

• LDAP_Naming_Services_deny_write_access

• VLV Request Control

• LDAP_Naming_Services_proxy_password_read

The first ACI overwrites the default behavior of the directory server. The default allows the owner of an entry to modify the values in that entry. Because a user entry stores information contained in the passwd and shadow databases, there are some passwd and shadow attributes that users should not be able to modify. For example, you do not want users to be able to change their uidnumber (UNIX UID), which could effectively give them root privileges. However, you might want them to be able to change other attributes such as gecos and description . This ACI usually appears at the top node of your DIT. The ACI that is created when the idsconfig command is run, looks like this:

 (targetattr = "cnuiduidNumbergidNumberhomeDirectoryshadowLastChange shadowMinshadowMaxshadowWarningshadowInactiveshadowExpi reshadowFlagmemberUid")(version 3.0; acl LDAP_Naming_Services_deny_write_access; deny (write) userdn = "ldap:///self";) 

The second ACI is a modification of the default for virtual list view (VLV) access. This type of access is used by the Secured LDAP Client for some requests for performance reasons. The default allows access to all , which means all users have entries (credentials) in the directory. This presents a dilemma because the client does not have credentials to bind to the directory until the client is initialized. To become initialized , an anonymous bind is performed to retrieve a client profile. To permit anonymous binds that use the VLV control mechanism, permission must be granted to anyone , which sounds similar to all, but does not require the existence of an account. The ACI is located at dn:oid=2.16.840.1.113730.3.4.9 , cn= features , cn=config and looks like this:

 (targetattr != "aci") (version 3.0; acl "VLV Request Control"; allow(read, search, compare) userdn = "ldap:///  anyone  ";) 

The third ACI is optional and is only required if pam_unix style authentication is being deployed. This is because pam_unix authentication takes place on the client which must be able to retrieve the password of the user who is logging in. The directory server default only allows the RootDN ( cn=directory manager ) the ability to read passwords, so this access control must be overwritten to grant that access to the proxyagent account that the Secured LDAP Client uses to bind to the directory. The ACI is usually located at the top node of your DIT and looks like this:

 (target="ldap:///dc=example, dc=com")(targetattr= "userPassword")(version 3.0; acl LDAP_Naming_Services_proxy_password_read; allow (compare, read, search) userdn = "ldap:///cn=proxyagent, ou= profile, dc=example, dc=com";) 

Note

This ACI is inherently insecure and should be avoided if possible. Support of pam_unix style authentication should only be used for transition purposes and removed once all your clients can use pam_ldap .

Details on how to add and modify existing ACIs are described in Chapter 6 "Management Tools and Toolkits."

Co-Existence with Other LDAP-Aware Applications

Another consideration when designing a DIT is whether the DIT will be shared with other applications and whether those applications require a particular DIT structure. There is such a wide range of applications that use LDAP for data storage and user authentication it is impossible to provide details on how to develop a corresponding DIT.

The NIS+ Gateway application is covered in this book. Refer to Chapter 5 "Migrating Legacy Data to LDAP" if you are planning to deploy NIS+ along with the Secured LDAP Client. In general, the idsconfig script creates an appropriate DIT for using LDAP as a naming service. However, password read access and storage schemes are important considerations because the NIS+ Gateway requires password storage to be in crypt format and readable by the application.