Using the LDAPv3 Plug-in
Due to LDAP’s broad adoption by most directory-service vendors, the Mac OS X DirectoryService LDAP plug-in allows Mac OS X to integrate with most directory-service environments. Mac OS X supports connecting to an LDAP server using version 2 or 3 of the LDAP protocol; however, the LDAPv3 plug-in supports only full read/write access to an LDAPv3 directory. The figure below illustrates that the directoryservice process uses the LDAPv3 plug-in to access an LDAP data store via the LDAP protocol.
Directory Access is the primary tool for configuring the LDAPv3 plug-in. Within Directory Access, there are two ways to configure the LDAPv3 plug-in to access an LDAP server running on Mac OS X Server.
The first method is to use a DHCP-supplied LDAP server. To use this option, the LDAP configuration must be included with the information that your DHCP server provides. If an LDAP server’s address and search base are provided by the DHCP server and pushed down over the appropriate option, Mac OS X will automatically bind to the server, and applications will have access to the directory’s data through Open Directory without any additional configuration.
However, the server is not automatically added to the authentication or contacts search path by default. To be able to log in using user accounts on an LDAP server provided by DHCP, you must enable the checkbox for the “Add DHCP-supplied LDAP server to automatic search policies” option or manually add the server in the Authentication and Contacts panes, both of which can be accessed by editing the LDAPv3 plug-in using the Directory Access application.
You can also create a configuration for the LDAPv3 plug-in and manually set the connection, search and mapping, and security parameters. If you’re connecting to an LDAP server running on a Mac OS X server, you only need to provide the server address in the Connection pane and click one button to have Mac OS X automatically bind to the LDAP server.
If a more customized schema is used, you can choose to map record types and attributes to LDAP object classes and attributes. In the Search & Mappings pane, the “any” and “all” choices in the “Map to. . .items in list” pop-up menu (under the Edit menu of the LDAPv3 plug-in when selecting a configured LDAP server to which you are going to bind) define which object classes or attributes are necessary when returning a result. The default is “all,” which means a search will return only those entries that contain all of the values listed on the right. If you choose “any,” the search will return entries that have any of the values.
Whereas LDAP supports limiting the scope of a search to the base object (base) and one level down (one) or to all subtrees (sub), Directory Access does not offer all of these options. Directory Access will limit the scope of the search to all subtrees (sub) or to first level only (one), as shown in the figure below.
In the list of LDAP configurations, you can use Secure Sockets Layer (SSL) for the connection between your computer and the LDAP server by selecting the SSL option next to the LDAP configuration in the LDAPv3 plug-in. Other security options for an LDAP configuration can be selected by choosing the LDAP configuration you want to modify, and clicking the Edit button. Click the Security tab (as shown in the figure below) to see additional security options. The options that are available depend on the configuration and capabilities of the LDAP server.
If you select the “Use authentication when connecting” option, the LDAPv3 connection authenticates with the directory when it connects by providing a dn and password. The security options are explained further in Lesson 7, “Hosting OpenLDAP.”
Troubleshooting the LDAP Connection
The components of a successful remote connection to an LDAP database include:
- An active connection to the server where the LDAP database is located
- A successful binding to the LDAP database
- An appropriate LDAP plug-in configuration
If you are experiencing problems with your LDAP connection, you should isolate it to one of these three areas.
First establish that you have an active connection to the server. Check your network connection, and make sure that you have configured the LDAP plug-in with the correct server address information. If you’re using DHCP to receive this information from the server, use ipconfig to verify the configuration.
If you’re not using DHCP to receive this information, use Directory Access to configure the LDAPv3 plug-in with the server address and search base. Verify that “Access this LDAPv3 server using Open Directory Server” is selected, and don’t remap any of the record types and attributes.
If your connection to the server is working but you’re still having problems, you should verify that the information you need is actually in the database. You can use:
- ldapsearch to make a request directly from the LDAP directory
- dscl to check if the attributes and associated values are correct
- Third-party tools, such as LDapper (http://www3.baylor.edu:80/~Carl_Bell/stuff.html) or LDAPManager (http://sourceforge.net/projects/ldapmanager)
- Directory Access to make sure Mac OS X will bind to the correct directory service.
Use these tools to search the directory for entries with objectClass=mount. This search will list the volumes that should be automounted. If the search returns the results you expect, then you have verified that the directory contains the correct information and that your client is receiving it correctly.
If the directory does not return correct information for mounts, verify that the file servers are functioning properly and that your user account has authorization to use the server (as well as enough user licenses).
If the requests are returning incorrect information or no information, tell your directory administrator to modify the directory using Workgroup Manager.
Mapping Open Directory Records to LDAP Entries
Open Directory contains predefined record types that are automatically mapped to LDAP entries on Mac OS X Server. When Open Directory receives requests for information, such as users or mounts, using the LDAPv3 plug-in builds the search at that time for that information based on the mappings. This is because Open Directory record types are also mapped to LDAP search bases and object classes. When the LDAP plug-in requests a particular piece of information, it knows where in the LDAP directory to find it based on the search base and one or more object classes. The plug-in also parses the results based on those same mappings. This presents a unified request for data from requestors to Open Directory, and thus the LDAP mappings are transparent to the requestor (or application) that originated the request.
Mapping Open Directory Records to LDAP Attributes
Although the search base tells Open Directory how to query an LDAP server for a given type of entry, Open Directory must be told how to use the information found in the entry. For this reason, Open Directory attributes are mapped to LDAP attributes. The mapping tells Open Directory which LDAP attributes hold the specific data Open Directory is looking for.
Workgroup Manager defines all attributes as either Standard or Native attributes. Standard attributes are Open Directory attributes, and Native attributes are OpenLDAP attributes. You can choose to see either or both sets of attributes by clicking the Options button within the Inspector tab of Workgroup Manager. Each set of attributes can also be preceded by their respective prefixes; however, viewing the prefixes is not absolutely necessary to obtain a better understanding of the automatic mapping of attributes.