Open Directory Service Configuration

Configuring Mac OS X Server to provide directory data is a straightforward task. With just a couple of clicks, the Server Admin application creates an LDAP database and enables the Open Directory service to share the data.

Open Directory Overview

Open Directory relies on LDAP to provide access to directory service data on Mac OS X Server. As you've already learned, LDAP is provided by OpenLDAP, an open-source LDAP server. Apple has made very few changes to the stock distribution of OpenLDAP, and for most functions, you should be able to treat LDAP on Mac OS X Server as a normal OpenLDAP distribution.

The following figure shows the three main components of an Open Directory server.

When working with Open Directory, the LDAP database maintains only the identification information for a user; the user's password is not kept in the LDAP database for obvious security reasons. Instead, the user will have an entry in the LDAP database that references a shadow password, an Apple Password Server password, or a Kerberos user principal. LDAP needs to work with these authentication services in order for Open Directory to truly be effective.

Roles for Open Directory Servers

An Open Directory service domain consists of a set of servers, each of which is configured to fill a specific role in the service domain. The role of each server is defined when the administrator sets it up, although the role can change if your service domain changes or you need to replace a machine that is out of service. The administrator has the option to choose a role during the initial configuration of the computer. However, the role of a system may be changed at any time after installation by using Server Admin.

The four Open Directory server roles are:

• Standalone Server: No LDAP database is running on the system. All users are local users and are located in the local NetInfo database. The Kerberos key distribution center (KDC) is not running.

• Open Directory Master: An LDAP database, a Password Server, and a KDC are on the system. Other Open Directory servers can connect to it and either share its network domain or replicate the network domain.

• Connected to a Directory System: Directory-service information for this system is received from another system. This may be over LDAP or an Active Directory connection. When connected to another system, this server will not be hosting its own LDAP database or Password Server. In addition, this server may join an existing Kerberos realm but will not be able to host its own directory.

  You will need to connect to a directory server when you are trying to configure multiple servers to share a single identification and authentication system. These scenarios will be covered in Lesson 9, "Integrating With Kerberos."

• Open Directory Replica: Directory data and services are replicated from an existing Open Directory master server. It contains a copy of the master's LDAP database, the Password Server database, and the Kerberos principal database.

The following table lists the various roles for an Open Directory server.

Let's examine two of these roles, Standalone Server and Open Directory Master, in more detail.

Standalone Server

A standalone server has the simplest configuration of all the Open Directory roles. In effect, its directory-service structure is very similar to that of Mac OS X. A standalone server has user accounts separate from those on the Mac OS X computers on the network, as shown in the following figure.

Tip

It's a good idea to configure your server in a standalone role if you know that you will be changing its IP address before the final configuration.

When configured as an Open Directory standalone server, the server does not provide LDAP or Kerberos services. It is not precluded from joining a Kerberos realm, but it does not host one. The server may also provide other services, such as Web hosting, file sharing, and DNS. All of the users will be stored in the local NetInfo database, so they will not be visible to Mac OS X computers as network users.

A typical standalone typology might involve a small workgroup that does not require sharing user account information among a large number of computers. In this case, all Mac OS X computers are set up with local users and do not use the server for authentication. On the server, a corresponding server account has been set up for each user who wants to access services on the server. However, these server accounts are in no way synchronized with those of the local users being used on the Mac OS X computers.

Tip

Standalone servers are also used to provide services that do not require advanced directory-service configuration, such as Dynamic Host Configuration Protocol (DHCP), domain name system (DNS), Network Address Translation (NAT), or Web services.

Open Directory Master

An Open Directory master adds a full LDAP server and a Kerberos KDC to a standalone server, as shown in the following figure. It can provide very robust network servicesincluding the distribution of users, groups, and management informationto bound Mac OS X computers.

All network information can be stored in the Open Directory master and provided to the bound Mac OS X computers via LDAP. Administrators can create a combination of local Mac OS X computer users and policies, and network users and policies, to best fit their situation. Additionally, the LDAP server can be used to interact with other applications, like Address Book.

An Open Directory master can fully leverage all the best-of-breed technologies of Mac OS X Server, including Kerberos and subsequently single sign-on, secure authentication with Simple Authentication and Security Layer (SASL) Password Server, and replication for redundancy and load-sharing.

Creating an Open Directory Master

When you use Server Admin to promote a standalone server to an Open Directory master, you will be asked to provide a name and password for a new account to act as an LDAP directory administrator. (You will learn more about the Open Directory Master creation process is detailed in Lesson 8, "Providing Single Sign-on Authentication.")

Tip

It's a good idea to use a name and password that differ from those of your initial administrator, because anyone who has the user name and password for the initial administrator account would then have access to manipulate the LDAP database, KDC, and Password Server as well.

You will also be asked for a Kerberos realm name. This field is preset to the server's fully qualified domain name, except it appears in capital letters, the standard convention for Kerberos realm names. You can enter a different name if your site has a different convention.

The search base field specifies the naming context of the LDAP databasethe name that refers to the database itself. The search base in the figure above is dc=mainserver,dc=pretendco,dc=com, specifying that this database handles data under the dc=mainserver,dc=pretendco,dc=com container.

Much like the Kerberos realm name, the search base tends to be based on the server's DNS name. If you have a valid reverse DNS record for the server, you should see a default entry here. Again, if your organization has established different conventions for LDAP, you may enter a different search base here. If Mac OS X Server is the first LDAP server and the first Kerberos KDC on your network, the default values will serve you well.

Once you enter the information and click OK, the following actions take place, courtesy of slapconfig:

1. The file /etc/openldap/slapd_macosxserver.conf is created.

2. The LDAP database is created.

3. The directory administrator user is created in the LDAP database and added to the Password Server database as a Password Server administrator.

   Note

   In versions of Mac OS X Server prior to 10.4, the initial administrator account was copied from the local NetInfo database to the LDAP database. With version 10.4, the LDAP database's initial administrator account is created with the user name and password provided for the Open Directory master server. You can have two different users with two different passwords, making it more difficult for attackers to gain access to both databases.

   
   

4. The local host is added to the search path in Directory Access (ldap://127.0.0.1).

5. OpenLDAP is configured to launch at system startup by editing /etc/hostconfig to contain the directive LDAPSERVER=YES.

6. The Launch Daemon for slapd is activated to automatically restart the slapd process, in case it abruptly quits.

For a freshly created LDAP database, the new administrator user will be the only user account. You must authenticate as this user to make any changes to that LDAP database, since all other users will be in the local NetInfo database. Once the database is populated with users, you can designate other users to be administrators of the network directory domain with the same rights and privileges as the initial LDAP administrator. This process can be handled manually, should you wish to do so. However, it is best to rely on slapconfig.

The process of creating an Open Directory master is by no means over, as the Kerberos KDC has not yet been created. You will learn the rest of this process in Lesson 8.

Tip

To learn exactly what takes place during the process of creating an Open Directory master, open the Terminal and type tail f /Library/Logs/slapconfig.log to tail the slapconfig log file. This log file is an excellent resource.

OpenLDAP Configuration Files

The primary configuration files for the OpenLDAP system are kept in /etc/openldap/. There, you will find slapd.conf, the main configuration file for slapd, and some basic configuration information. Most of the configuration for Open Directory is kept in slapd_macosxserver.conf. An include statement in slapd.conf includes slapd_macosxserver.conf.

Note

Include statements are often used to let processes read more than one configuration file. At the end of the initial file, a line points to the location of the additional file(s). The process then reads that information as well.

The directives listed in these files can be modified from the GUI, so you should avoid adding custom configurations to these files unless you decide not to use the GUI administration tools. If you do use your own configuration file, add an include directive for it in the slapd.conf file.

When the slapd_macosxserver.conf file is created, it contains an entry for the root user of the LDAP database, the directive rootdn. This is not the same as the root user in the local NetInfo database; it's a user who has total control over all data inside the LDAP database, since access controls do not apply to the root user. An example value for rootdn is uid=root,cn=users,dc=mainserver,dc=pretendco,dc=com.

The entry for the root user in the slapd_macosxserver.conf file, by default, refers to the root user created in the LDAP database when you promote your server to an Open Directory master. Right below this entry is the rootpw directive containing an MD5-encrypted hash of the root user's password, which can be used to manage the LDAP server even when Password Server is not running.

Any user name and password can be used for the root LDAP user. In fact, this user doesn't even have to exist in the LDAP database itself, just here in the configuration file. An administrative user on the system can edit the slapd_macosxserver.conf file to add a new password hash, or plaintext password, into the file. Then that administrator user would be able to once again administer the LDAP database.

slapd will assume that a user who can authenticate to this name and password is the root user for the LDAP database and is not bound by any access controls to the database. That's useful when your LDAP database has reached a point where the user records are no longer readable. Without the LDAP root user, you wouldn't be able to edit the LDAP database. This technique can also be used when all passwords for users in the LDAP database have been lost or forgotten.

LDAP Protocol Settings

Some of the options from the Server Admin Protocols pane are written to slapd_macosxserver.conf. They are:

• Search base: An uneditable view of your LDAP server's current search base.

• Database: The location of the LDAP database files on your local disk. The default location of the LDAP database is /var/db/openldap. If you'd like to change the location of the database, shut down the LDAP server, copy over the database to the new locationensuring that the permissions are the sameand then restart the LDAP server. This will not move an existing database to the new location; you need to do that by hand. Moving your LDAP database makes sense when you need to move to a larger capacity or more robust volume, such as a RAID array.

• Searching: Two other protocol settings change OpenLDAP configuration entries in slapd.conf:

  • Maximum search results: The maximum results field limits the total records returned from an LDAP search. On publicly accessible LDAP servers, this is commonly done to prevent someone from "harvesting" the entire database. On Mac OS X Server, you might want to do this to increase response times for all LDAP servers.

  • Search timeout: Represents the length of time before a search times out. You should need to worry about this only on very large databases. On a normal database of a few thousands users, all searches should return within a few seconds.

• SSL Certificates: Two options control security for your LDAP database:

  • Enable Secure Sockets Layer (SSL): This enables SSL for encrypted communications between the Open Directory server's LDAP directory domain and the computers that access it.

  • Certificate: This selects which certificates are used. You can use a self-assigned certificate or one obtained from a certificate authority.

NetInfo Settings

Server Admin also provides an interface to modify NetInfo settings. NetInfo is being retired as a network directory, but Mac OS X Server still provides NetInfo access as backward compatibility for older clients.

The NetInfo service allows the data stored in the LDAP network domain to be accessed by NetInfo clients. This feature is enabled when you migrate a Mac OS X Server v10.2 NetInfo parent to a Mac OS X Server v10.4 Open Directory master. During the migration period, all Mac OS X v10.4 computers that were connecting over NetInfo will automatically be redirected to connect over LDAP. All other Mac OS X computers will need to be manually configured to use an LDAP connection to the server. Once the transition is complete, you can use the NetInfo Migration settings in Server Admin to permanently stop NetInfo.

Providing LDAP Connection Settings via DHCP

DHCP provides a standardized way to provide LDAP connection information through DHCP. As discussed in Lesson 6, "Kerberos Fundamentals," DHCP uses Option 95 to provide clients with connection information for the LDAP database, but not a description of the schema. Mac OS X supports a standard way to distribute the schema to all clients by keeping the schema mappings inside the directory itself. This is an incredibly efficient way of allowing clients access to the schema.

The following figure shows a DHCP server configured to send LDAP information along with the standard DHCP information.

Providing Schema Mappings

All Open Directory servers have a schema mapping configuration entry located in the LDAP database at cn=macosxodconfig,cn=Config. When a client connects to the LDAP database, the schema mappings are transferred to the client. If the client obtains LDAP server information via DHCP, the entire LDAP configuration process can be fully automated on the client.

While this record is generated on an Open Directory server automatically, it can be saved to any LDAP server, as long as the configuration information is in the same place. If you have write access to your third-party LDAP server, you may be able to use the Write to Server button in Directory Access to generate the appropriate record on the server.

Tip

Setting up a client to automatically trust a directory service that is provided through DHCP is potentially risky. While your client computers may be relatively secure on your LAN, using that computer on an untrusted network (for example, one at a hotel) may allow a nefarious system administrator to push out his or her own directory service over DHCP. Your client computer will trust this for authentication and thus allow other users to connect, unbeknownst to you.

You can also manually configure clients to use a particular schema:

• Use the generic Open Directory configuration in Directory Access on the client to map attributes to their common place on an Open Directory server.

• Specify on the client what mappings should occur. This method is commonly used when connecting a client computer to a third-party LDAP server.