Table of Contents

Configuring LDAP

This chapter describes the Lightweight Directory Access Protocol (LDAP) that allows you to use directory services to integrate Network Registrar client and lease information. By building on your existing standard schema for objects stored in LDAP directories, you can handle information about DHCP client entries. Thus, instead of maintaining client information in the DHCP server's database, you can ask the Network Registrar DHCP server to issue queries to one or more LDAP servers for information in response to DHCP client requests.

Table 11-1<Xref_Color> lists the LDAP configuration tasks described in this chapter and the sections where you can find more information about them. For more information about LDAP and its attributes, refer to the Network Registrar Concepts Guide.

About LDAP Directory Servers

LDAP directory servers provide a way to name, manage, and access collections of attribute-value pairs. You can enter information into your LDAP server in any number of ways, because Network Registrar is not dependent on any specific LDAP object classes or schema:

When you configure the DHCP server to read from LDAP, a query dictionary tells the DHCP server which LDAP attributes to query for. The DHCP server converts the resulting data into DHCP client-data attributes.

Configuring for LDAP Client Queries

This section explains how to configure client entries in LDAP, configure DHCP client queries, and configure embedded policies within an LDAP client entry.

Configuring a Client Entry in LDAP

The following example (Table 11-2) assumes you have entered the DHCP client data into the standard LDAP organizational person object class attributes.

Configuring DHCP LDAP Client Query

To enable the DHCP server to query your LDAP server for client data, perform the following steps. Like local client-entries, LDAP client-entries are keyed by the client's MAC address. For more information about the MAC address format, see the Network Registrar CLI Reference Manual.

Step 2   Configure the credentials to use when connecting to the LDAP server. The following example sets the admin to be joe and his password to be access. Use the distinguished name for the user.

Step 3   Set the search-path. This is a point in the directory from which to start searches. The following example sets the base of the search to be the organization, Example Corp., and the country, US.

Step 4   Set the search-filter to be the attribute for which DHCP will substitute the clients' MAC addresses. In this example the attribute is the common name (cn).

Step 5   Configure a query-dictionary, which contains all the LDAP-to-DHCP mappings.

Use the setEntry command to set these mappings.

Step 6   Enable queries for the LDAP server. The following example enables queries for myserver.

Step 7   Enable client-class processing for the DHCP server.

Step 8   Enable the DHCP server to use LDAP for client-entry queries.

Step 9   Save and reload the DHCP server.

For more information about the ldap command and client-class properties, see the Network Registrar CLI Reference Manual.

Deprovisioning LDAP Client Entries

You can deprovision LDAP client entries so that the client information remains in LDAP, but the DHCP server treats the client as if that information doesn't exist. The DHCP server then supplies the client with the default behavior.

Configure the search filter set in Step 4 of the preceding section so that the LDAP server does not return a client entry containing a specified attribute with a value.

For example, if you want to deprovision the LDAP entry givenname, configure the following search filter:

Whenever the givenname attribute in the LDAP client entry is set to the deprovision string, the LDAP server does not return the client entry to the DHCP server. In other words, the DHCP server treats the client as if it has no LDAP client entry.

Configuring Embedded Policies within LDAP

To configure embedded policies within LDAP, follow these steps:

Step 2   Map the LDAP attribute that you want the DHCP server to interpret as the embedded policy to the internal embedded policy attribute. In this example, the user mapped the LDAP attribute businessCategory as the embedded policy:

Step 3   Using your LDAP server's software, put the embedded-policy string into the LDAP attribute in the LDAP directory. The string format for the embedded policy is:

((ClassName Policy) (feature/property1 value1)...(feature/propertyn valuen) (options (option1 value1)... (optionn valuen)))

where:

feature/property value indicates the names and settings of any features or properties supported by a policy. For example:

businesscategory:((ClassName Policy) (options ((routers 1.2.3.4, 5.6.7.8)))

For more information, see the policy command in Chapter 2 of the Network Registrar CLI Reference Guide.

option value indicates the names and settings of any DHCP option that can be used with the policy command. For more information, see the DHCP options listed in Appendix D of the Network Registrar CLI Reference Guide.

Specifying Multi-Value DHCP Options

If you want to specify multi-value options, separate the values with a comma.

The following example configures two specialized domain name servers for a particular client (1.2.3.4 and 6.7.8.9) and sets the dhc-lease-time option for 3600.

Configuring the DHCP LDAP Update and Create Service

You can configure the DHCP LDAP service to copy lease-state data to existing attributes in the LDAP server. The service converts the lease-state data to string form, and uses an update dictionary to map the LDAP attributes to the DHCP data values.

Each time the state of a lease changes, the DHCP server makes a copy of the data and then transfers it to the LDAP server that you have configured to store lease-state data.

Lease-State Attributes

You can store any of the following attributes about the lease's state information in your LDAP server:

Note Although the MAC addresses in LDAP have to be formatted exactly the way they are formatted by Network Registrar when it creates local client-entries, they are separate instances and thus unique to lease data.

Not every lease has all of these attributes. The client-mac-addr and client-id are not present if a lease has been released by its client, or forced available through Network Registrar. In addition, the lease-renewal-time may not be present if the save-lease-renewal-time property is disabled through DHCP. Similarly, the vendor-class-identifier property may not be present if the save-vendor-class-id property is disabled through DHCP, using the CLI.

Configuring LDAP for Lease-State Updates

There are three steps to configuring lease-state updates:

Step 2   Add entries to the directory or modify existing entries to store the lease state information. You may need to extend entries through the addition of attributes or custom object classes.

Step 3   Configure Network Registrar to perform the updates.

Given the flexibility of directories, there are many different ways in which you could choose to store a copy of lease-state attributes in a directory. For example, you could choose to store the lease-state data as part of an existing entry, or you could store the lease-state data independently.

Storing Lease State Data As Part of an Existing Entry

You can store lease-state data as part of an existing entry, like a person. It is even possible to store the client-entry information, the lease-state information, and employee data in the same entry. As part of the setup for this method, you must decide how you want to store the lease data attributes. You may store data attributes using the following methods:

The advantage to this method is that lease data is stored directly with other associated client information. The disadvantage is that there are scenarios, albeit unlikely, related to client-class and reservations that could result in stale data being in the directory for a short period of time when a client is moved off a lease by the server.

Also, this method requires two LDAP interactions to write the lease information. When updating lease-state information, the DHCP LDAP service contacts the directory twice because when updating an entry it is not enough just to know how to find the entry. You must specifically know the entry's distinguished name.

The DHCP LDAP service first finds the appropriate entry in the directory by using one the lease-state attributes that you chose (preferably the MAC address) as the search criteria. This is necessary to do since none of the lease-state attributes is part of the distinguished name of the entry. When the DHCP LDAP service locates the entry, the distinguished name is returned. Then the DHCP LDAP service updates that same entry with the appropriate information. For an example of using this method, see the "Configuring LDAP State Updates" section.

Storing L ease-State Data Independently

You can store lease-state data by IP address in its own entries. This method results in a copy of the server lease-data database in a directory, and is the most straightforward way to configure the database. As part of the setup for this method, create new entries for each IP address that the server can serve. The advantage to this method is that there are no scenarios in which the lease-state data in the directory will be stale. The disadvantage is that lease data is not stored directly with other associated client information.

To update the lease-state information, the DHCP LDAP service contacts the directory service once. When performing the update, DHCP LDAP service uses the IP address to construct the distinguished name.

Using LDAP Updates

There are two ways you can use the LDAP update feature:

Network Registrar Considerations

When using Network Registrar, you should be aware of the following:

Configuring LDAP State Updates

There are two options available for performing a lease state update to an LDAP server.

Option 1: Using Update-search-path

The following example illustrates the first option, update-search-path. It shows what to do when the LDAP object's dn cannot be constructed from data that is available in the lease state. The DHCP server creates an LDAP query based on the update-search-xxx information, locates the LDAP object, and uses its distinguished name to issue an LDAP update.

The example shown in Table 11-3 assumes you are using the standard LDAP organizational person object class attributes to hold lease update data.

You must supply the server's host name. The following example creates the LDAP server object myserver with a host name of myserver.example.com.

Step 2   Configure the credentials to use when connecting to the LDAP server.

The following example sets the admin to be joe and his password to be access. Use the distinguished name for the user.

Step 3   Configure the update-search-path, which is the starting point in the directory for the objects that the DHCP server will update.

The following example sets the search path to begin at the organizational unit (ou) IT, the organization Example Corporation, and country US.

Step 4   Set the ID of the attribute you want to use to search for the LDAP object that will be updated.

The following example sets the search attribute to be the client's MAC address.

Step 5   Configure a filter expression into which the update-search-attribute should be formatted.

This expression must contain a %s, which indicates where the search-attribute's data should be substituted.

Step 6   Configure an update-dictionary, which allows you to identify the LDAP attributes that you want set with the values of the corresponding lease-state attributes.

The following example specifies the LDAP uid should be updated to contain the IP address, and the attribute carlicense should be updated to contain the DHCP lease-state information.

Step 7   Enable updates for the new LDAP server.

Step 8   Save and reload the DHCP server.

Option 2: Using Dn-format

The following example illustrates using the second option, dn-format:

Step 2   Configure the credentials to use when connecting to the LDAP server.

The following example sets the admin to be joe and his password to be access. Use the distinguished name for the user.

Step 3   Use the dn-format string to specify where in the LDAP server database hierarchy you want to begin searching for the update.

Step 4   Set the dn-attribute you want the dn-format string to refer to.

The following example sets the dn-attribute to be the client's MAC address.

Step 5   Specify the entries to be updated.

Step 6   Enable the can-update feature.

Step 7   Reload the server.

Configuring LDAP Entry Creation

This section explains how to create LDAP entries. LDAP entry creation provides the ability to locate entries and update them with current lease information. Entries are created only if a state update operation fails because it cannot locate an entry.

After performing the steps in the previous example, follow these steps to configure LDAP entry creation.

Step 2   Create the distinguished name of the entry to be created when combined with the existing dn-attribute property.

Note Network Registrar's client-mac-addr field uses this form: 1,6:xx:xx:xx:xx:xx:xx . Since the comma character is a special separator in LDAP, you must use the \" characters to quote distinguished names.

Step 3   Using the create-dictionary property, establish mappings between LDAP attributes and lease-state attributes by entering a series of name=value pairs.

The LDAP attributes indicate the entry attributes set to the value of their corresponding lease-state attributes.

Step 4   Using the create-object-classes property, specify the object classes to be used when creating the entry. Use a comma-delimited list format.

Step 5   Enable entry creation for the LDAP server myserver.

Note Make sure you enable the can-update feature before enabling the can-create feature. For an example, see the previous section.

Step 6   Save and reload the DHCP server.