Lesson 7. Hosting OpenLDAP

Time

This lesson takes approximately 2 hours to complete.

Goals

Understand the four roles of an Open Directory server and its functionality in standalone and Master mode Identify the OpenLDAP primary configuration files Use Server Admin to configure the maximum number of results returned by an Open Directory server Configure Mac OS X Server to host an LDAP directory domain Use the slapd process tools to manipulate data stored in the LDAP database on a Mac OS X Server computer Use Open Directory’s Archive and Restore features on Mac OS X Server to back up and restore an Open Directory server Secure Open Directory connections between Mac OS X and Mac OS X Server

Using Open Directory services on Mac OS X Server enables system administrators to easily provide directory services. In previous lessons, you learned to connect Mac OS X computers as clients of a Mac OS X server, an Active Directory domain, and third-party directory services. Now you’ll find out how to configure Mac OS X Server to be that directory service by hosting a Lightweight Directory Access Protocol (LDAP) directory domain, importing and managing the directory data on the server, and tuning the server for performance and security.

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.

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.

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 services—including the distribution of users, groups, and management information—to 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.”)

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 database—the 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.

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.

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.

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 location—ensuring that the permissions are the same—and 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.

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.

Managing Directory-Service Data

Setting up an LDAP server is just the first step in providing directory data. Next you need to populate the server with data and then modify the data on an ongoing basis. This lesson will present different methods for populating the Open Directory server.

OpenLDAP Components

slapd, located in /usr/libexec, is started at boot time by launchd and implements the OpenLDAP server daemon. It must run as the root user and will listen for incoming LDAP connections on either port 389 for unencrypted connections or port 636 for SSL-enabled connections.

As the following figure shows, a number of different command-line utilities come with OpenLDAP. These tools can be separated into two types:

• Tools that begin with slap and operate directly on the LDAP databases

• Tools that begin with ldap and go through the LDAP protocol

The slap tools must be run directly on the computer hosting the LDAP database. It is also advisable to shut down the LDAP server when using the slap tools or else your database may become out of sync. Keep in mind that two processes—the LDAP server itself and the slap utility—will be writing to it at the same time.

slapcat is primarily used to generate an LDAP Interchange Format (LDIF) file from a database, which can then be added to another database by using the slapadd command. This is typically how an LDAP replica is created by hand.

Other slap commands include slapindex, which will force a reindexing of your database, and slappasswd, which can generate password hashes to be stored in the LDAP database. Since passwords are primarily stored in Password Server on Mac OS X Server, and not directly in the LDAP database, you most likely will not need slappasswd.

The ldap tools interact with the LDAP server itself and can access the server over the network. The ldap tools are the best ones for troubleshooting your LDAP server, because they replicate the interactions the LDAP server would have with a Mac OS X computer.

A common LDAP tool is ldapsearch, which can be used to query the LDAP server for a particular entry or generate an LDIF file. When you use Mac OS X to authenticate to an LDAP server, your computer will do an ldapsearch against Open Directory’s LDAP server to find out your user information. For example,

ldapsearch -H ldap://127.0.0.1 -b cn=users,dc=mainserver,dc=pretendco,dc=com

will dump all records in the users container of the server’s LDAP database to your Terminal window.

You can use ldapadd to load an LDIF file into your LDAP server. For example,

ldapadd -H ldap://mainserverserver.pretendco.com -f myusers.ldif

uploads the LDIF file myusers.ldif to the server once you have successfully authenticated as an administrator.

Apple LDAP Schema

The structure of the data stored in an LDAP database is defined not by the LDAP protocol but by a schema, a collection of files that define the types of records and attributes they might contain. The schema files used by Mac OS X Server are located in /etc/openldap/schema/.

The Open Directory LDAP server uses standard LDAP object classes whenever suitable. For example, accounts created with Workgroup Manager implement inetOrgPerson and posixAccount object classes. However, to support Apple-specific features, Apple has extended the schema to define auxiliary object classes so that user accounts can contain extra attributes that are not part of a defined LDAP standard. Similar object classes have been created for Apple-defined groups. These support features specific to Mac OS X:

• apple-user: Adds attributes that are part of an Apple user account but that are not supported by either the standard inetOrgPerson or posixAccount object classes. Examples include:

• URL of the home folder

• Home folder quotas

• Managed client settings (MCX settings)

• apple-group: Adds attributes that are part of an Apple group but that are not supported by the posixGroup object type. Examples include:

• URL of the group folder

• Managed client settings

This is just a small sample of the objects and attributes Apple added. All of the added objects and attributes are defined in the file /etc/openldap/schema/apple.schema.

LDIF

An LDIF file allows you to easily add the contents of one LDAP server to another. Any server that uses the standard LDAP protocol should be able to import and export an LDIF file.

The file is in plaintext, and each entry is specified by its distinguished name. An example of the contents of an LDIF file entry is as follows:

dn: uid=froosevelt,cn=users,dc=mainserver,dc=pretendco,dc=com
uid: froosevelt
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: apple-user
objectClass: extensibleObject
objectClass: organizationalPerson
objectClass: top
objectClass: person
sn: 99
cn: Franklin Roosevelt
uidNumber: 1025
apple-generateduid: 247E73B0-8339-11D8-B8CA-000A9585403C
apple-mcxflags:: PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NUW
...
loginShell: /bin/bash
gidNumber: 20
authAuthority: ;ApplePasswordServer;0x406b01c33b4f78190000000a0000000a,1024 35
...
09 [email protected]:10.1.0.1
authAuthority: ;Kerberosv5;0x406b01c33b4f78190000000a0000000a;froosevelt@SERVE
...
userPassword:: KioqKioqKio=
apple-user-mailattribute:: PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4
...
apple-user-homeurl:: PGhvbWVfZGlyPjx1cmw+YWZwOi8vc2VydmVyMTcucHJldGVuZGNvLmNvb
...
homeDirectory: /Network/Servers/mainserver.pretendco.com/Users/froosevelt

LDAP Contacts Database

Many large organizations will put all their contact or address book information into an LDAP database. In fact, this was one of the original uses of an LDAP database. Most modern email clients, including the Apple Mail and Microsoft Entourage applications, have the ability to search for email and postal addresses over an LDAP connection.

The contact information can be located in a number of different locations. Which location your organization uses will depend on your LDAP configuration. Some administrators prefer to place contacts in the same container as the user accounts on the system. This method has the benefit of allowing users to search for both employee information and other contact information at the same time. However, mixing accounts and contacts in the same container may cause confusion when administering your users, and user accounts may contain sensitive information.

Another approach is to create an entirely new container especially for contacts. Common names for containers of this type are cn=People and cn=Contacts. This keeps the user information separate from the contact information but requires clients to either use the entire LDAP naming context as their search base or have two search entries.

A third approach, which is especially useful for organizations with a large amount of LDAP contact information, is to create an entirely separate LDAP database to hold contact information and to host it on the same computer. This “contacts” database would have a naming context unique from the other database and requires only another group of entries in the LDAP configuration files.

Workgroup Manager is a tool designed to manage account information for records specified by the Users search base in Directory Access. To edit attributes not exposed by Workgroup Manager, or if you wish to move your contact to a different container, you will have to find alternative tools to manage your contact information, such as the LDAP command-line tools discussed in the previous section.

Backing Up and Restoring Directory Data

With Server Admin, you can create an archive copy of the Open Directory master’s directory and authentication data. After you select a location and click the Archive button, Server Admin creates a disk image containing the following:

• LDAP database and configuration files

• Password Server database

• Kerberos database and configuration files

• Local NetInfo database

To restore the data, enter the path to the archive image and click Restore. The data from the image will be merged with the existing master’s data. If there are conflicts between the master’s data and the image, the data in the master will take precedence and the conflict is recorded in the slapconfig log file.

If you have configured Open Directory replica servers to connect to Open Directory master, you will need to reconnect the replicas after restoring a server from an archive. Replica servers are covered in Lesson 10, “Replication.”

Tuning the Open Directory Server

Part of configuring a directory server is tuning the server to provide secure yet responsive transactions.

LDAP Security Concerns

An LDAP database holds a lot of potentially sensitive account information. Mac OS X no longer requires that password hashes be stored in the directory; however, depending on your organization, you may still store contact information that should be restricted to legitimate members of your organization. For example, you probably wouldn’t want a visitor on your network to get a list of all your employees or students. As you’ve seen with ldapsearch, it’s a fairly straightforward task to query an LDAP server and dump the output to an LDIF file.

Another security concern is the vulnerability of the traffic on the network. You wouldn’t want others to see the LDAP traffic as it passed along the network.

Disallow Anonymous Binding

A standard install of Mac OS X Server allows anyone to browse the contents of your LDAP database, making it easy for client computers to connect, especially when using DHCP to configure the clients.

To secure your LDAP server, there are two ways to control binding, as shown in the following figure.

For better security, you can disable anonymous binding and limit access to authenticated users, requiring any connection to supply a valid user name and password for one of the users in the LDAP database. To disallow anonymous binding, add this line to /etc/openldap/slapd.conf:

disallow bind_anon

Then restart the LDAP process, slapd, or reboot the server.

Using Trusted Binding

Using Server Admin, you can configure an Open Directory master to allow or require trusted binding between the LDAP directory and the computers that access it. Replicas of the Open Directory master automatically inherit its binding policy.

Trusted LDAP binding is mutually authenticated. The computer proves its identity by using an LDAP directory administrator’s name and password to authenticate to the LDAP directory by means of an authenticated computer record created in the directory when you set up trusted binding.

Where authenticated binding proves the identity of the client computer, trusted binding proves the identity of both the client computer and the LDAP directory. Trusted binding is configured from the client computer using Directory Access

Controlling Access to the Database

Access control lists (ACLs) are another way to secure your LDAP server. ACLs are specified in the AccessControls container in the LDAP directory. Each ACL specifies what a user can do to a specified container or object class in the LDAP database. Here’s an example of a directory-service ACL:

1000:access to attr=userPassword by self write by sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write
by group/posixGroup/memberUid="cn=admin,cn=groups,dc=mainserver,dc=pretendco,dc=com"
write by * read

Write access to the userPassword attribute is limited to either the specific owner of the attribute or any user in the admin group. The last line allows any user to read the value. (Remember, in this case this is not the password but the password attribute.)

Alternatively, you can use Workgroup Manager to assign directory domain administrator privileges for an account stored in the LDAP directory of an Open Directory master or a NetInfo domain. A user with administrator privileges for a directory domain can make changes to user accounts, group accounts, and computer list accounts stored in that domain using Workgroup Manager. After enabling the domain administration option for the user account, you can specify the editing capabilities for each account type.

Preventing Eavesdropping With SSL

In Server Admin, you can enable SSL to provide encrypted communications between the Open Directory server and the client computers. SSL uses a digital certificate to provide a certified identity for the server. You can use a self-signed certificate or one obtained from a certificate authority, such as VeriSign or Thawte.

Once you have the certificate, you can store it anywhere you want, but it’s best to put it somewhere accessible only by the root user. Also, remove any passphrase associated with the certificate, since OpenLDAP does not support passphrases.

Enable SSL through Server Admin by choosing Enable Secure Sockets Layer (SSL) in the Protocols pane. After it has been enabled, choose the SSL certificate from the Certificate pop-up menu. To use a certificate not listed, choose Custom Configuration from the pop-up menu and supply the full path to the server’s certificate and private key. If you created your own certificate, supply the one from the certificate authority.

To configure the LDAP server to listen only for SSL connections, you edit the launch arguments for slapd. The launch arguments are specified in /System/Library/ LaunchDaemons/org.openldap.slapd.xml. Delete the ldap:/// entry under ProgramArguments, but leave the ldaps:/// entry.

Once the server has been secured with SSL, you’ll need to enable SSL on the client. In Directory Access on the client, choose SSL next to the LDAP entry for your server.

LDAP Indexing and Caching

Indexing increases the speed of queries by creating an indexed lookup table of attribute values, but it also increases the size of the LDAP database files on the server as well as the time of write operations.

The slapd_macosxserver.conf file specifies what attributes are cached by the server. By default, only a few attributes, such as user name and user ID, are indexed. However, if you have the space and need better responsiveness, you can index other attributes by editing the configuration file. The more attributes you index on, the slower the performance during writes, since the index needs to be updated for the added attributes.

Changing the Default BerkeleyDB Cache Size

In Mac OS X Server v10.4, the BerkeleyDB cache size depends on the amount of RAM installed on your computer when the LDAP master is created.

If your computer has 256 MB of RAM, the default BerkeleyDB cache size will be 16 MB. If your computer has more than 256 MB of RAM up to 512 MB, the cache size will be 32 MB. If your computer has more than 512 MB of RAM, the default cache size will be 64 MB.

If you’ve added more RAM to the server, you can manually increase the BerkeleyDB cache size, using the RAM to cache ratios described above as your guideline. This helps improve overall LDAP performance.

To change the BerkeleyDB cache size, edit the file /var/db/openldap/openldap-data/DB_ CONFIG and change the set_cachesize entry to one of the following:

• For 4 MB: set_cachesize 0 4194304 1

• For 16 MB: set_cachesize 0 16777216 1

• For 32 MB: set_cachesize 0 33554432 1

• For 64 MB: set_cachesize 0 67108864 1

Save the file and restart the server to apply your change.

Troubleshooting LDAP Connections

As with most Mac OS X Server troubleshooting, you should start troubleshooting LDAP connections by reading the log files, specifically /var/log/system.log and the DirectoryServer logs in /Library/Logs/DirectoryServices.

Next run the LDAP server process, slapd, in debug mode. First stop the LDAP server by killing the slapd process. Then start it from the command line:

sudo /usr/libexec/slapd -d 99

This will now run the LDAP server and display all transactions and errors to the Terminal window. If you would like even more information, increase the value after -d.

You can also enable LDAP logging with

sudo slapconfig -enableslapdlog

which will allow slapd to log to /var/log/slapd.log.

You can also add logging options to the slapd.conf configuration file using the loglevel directive. Adding the numbers will add the output to the log file for that item.

loglevel <integer>

Another troubleshooting technique is to use an LDAP browser utility to view the contents of your LDAP database. If you do this from a client computer, you will be able to test all aspects of the client/server LDAP connection.

Also, keep in mind that the Inspector function of Workgroup Manager will also allow you to browse the LDAP database on the server and make changes as appropriate.

With Mac OS X Server, LDAP provides the advantages of industry standards, compatibility, and industry know-how. Apple has not merely taken OpenLDAP and added it to its list of features, but has gone the next step, integrating it into the entire Open Directory architecture. Additional tools, schema definitions, and configuration files have been added to make the management of an LDAP architecture as painless as possible. Mac OS X Server is a prominent player in the LDAP server arena.

What You’ve Learned

• Apple’s implementation of LDAP is OpenLDAP.

• An Open Directory master consists of an LDAP database, a Password Server, and a KDC.

• Some basic LDAP configuration information is kept in slapd.conf; however, most of the configuration for Open Directory is kept in slapd_macosxserver.conf.

• OpenLDAP does not support passphrases in SSL certificates.

• slapcat is primarily used to generate an LDIF file from an LDAP database.

• The schema files used by Mac OS X Server are located in /etc/openldap/schema/.

References

Administration Guides

“Mac OS X Server Open Directory Administration”: http://images.apple.com/server/pdfs/Open_Directory_v10.4.pdf

“Mac OS X Server Command-Line Administration”: http://images.apple.com/server/pdfs/Command_Line_v10.4.pdf

Apple Knowledge Base Documents

The following Knowledge Base documents (located at www.apple.com/support) provide further information about the BerkeleyDB database and LDAP databases.

Document 301264, “Mac OS X Server: How to change the default BerkeleyDB cache size”

Document 301490, “Mac OS X Server 10.4: Open Directory LDAP databases must be migrated using Setup Assistant”

Books

Carter, Gerald. LDAP System Administration (O’Reilly, 2003).

URLs

Open Directory: www.apple.com/support/macosxserver/opendirectory

OpenLDAP: www.openldap.org

Lesson Review

1. What are the advantages of using a Mac OS X Server centralized directory store in a heterogeneous network?

2. What configuration file is used by the LDAP server process? Where is it located?

3. How do Mac OS X computers acquire the mappings when binding to an Open Directory server?

4. What is the schema and where is it stored?

5. In order for a client to work properly with Open Directory, what directory-service data items must be correctly mapped and populated?

6. What does adding disallow bind_anon to slapd.conf do?

7. What is the benefit of enabling SSL on the LDAP server?

8. When is the BerkeleyDB cache size set by Mac OS X Server, and how is its value determined?

Answers

1. a) There is only one directory store for ease of administration.

b) Users can use the same account from disparate clients.

c) The administrator has more control over the connection methods.

d) As connection methods are secured, all clients take advantage of the increased security.

2. The LDAP server uses the /etc/openldap/slapd.conf file as its configuration file. The slapd.conf file includes a directive to include /etc/openldap/slapd_macosxserver.conf file, which is managed by Server Admin.

3. The mappings are provided as part of the configuration entry located in the LDAP database at cn=macosxodconfig,cn=Config.

4. The schema defines the types and format of records stored in the local LDAP database. The schema files are at /etc/openldap/schema.

5. In order for a client to work properly, the following data items must be correctly mapped and populated: RecordName, RealName, Password, UniqueID, PrimaryGroupID, NFSHomeDirectory, and HomeDirectory.

6. It configures the LDAP server to not respond to data requests without authentication.

7. When SSL is enabled on both the client and server computers, the LDAP data sent between the two computers is encrypted. This prevents attackers from eavesdropping on critical directory data.

8. Mac OS X Server sets the BerkeleyDB cache size when the server is promoted to be an Open Directory master. The size of the cache is based upon the amount of RAM installed on the server when it was promoted. The value can later be overridden to enhance performance.