This section describes four categories of tools that can be run from the command line to manage LDAP data and the directory configuration. These categories are:
The standard LDAP utilities are used to search for, and to update data in the directory. Updates can be performed by importing LDAP Data Interchange Format (LDIF) or specifying data on the command line. Besides being able to manipulate data entries, most directory configuration changes can be made by importing LDIF. You will see many examples of this later.
Solaris OE specific tools are those that interface directly with the bundled directory server or directly with naming service data. The Solaris OE ldaplist command, for example, performs a search of the directory using parameters for which the Secured LDAP Client is configured, to locate naming service data.
Sun ONE Directory Server administration tools are scripts or programs that perform routine maintenance. Some of these tools ship with the Sun ONE Directory Server software while others are available by downloading the Sun ONE Directory Server, Resource Kit (SDRK) software. Examples are scripts to start and stop the server and to backup data. The bundled Solaris 9 OE directory server provides a wrapper script called /usr/sbin/directoryserver that performs the same functions as the unbundled version of the directory server utilities without having to know where the actual utilities reside.
Standard LDAP Utilities
Standard LDAP utilities are tools that use LDAP to interact with a directory server and are available on multiple platforms. Standard LDAP utilities communicate over the LDAP v3 protocol, so the commands can be run anywhere . These tools perform the following tasks :
In general, the following information is supplied depending on what operation is being performed:
Two sets of standard LDAP utilities can exist on a Solaris OE system. One set is installed when the SUNWlldap package for Solaris 8 and 9 OE is loaded. The other is contained in the Sun ONE Directory Server software distribution and is installed when the directory server is configured.
Although the two sets of utilities look similar and perform similar functions the supported features and command syntax are significantly different. Therefore it is important to know which set of standard LDAP utilities you are running when following the examples in this book.
The examples referenced in this book assume you are using the Sun ONE Directory Server software version of the standard LDAP utilities unless otherwise specified.
Differences Between Standard LDAP Utilities
You may be asking why two sets of utilities exist that do basically the same thing. The reason for this is more historical than technical. Prior to the Sun/AOL/Netscape Alliance, Sun had produced its own directory server which included its own version of the standard LDAP utilities. These versions eventually shipped as part of the Solaris 2.6 OE. After the Alliance was formed , Sun decided to discontinue their original directory server and adopt the Netscape version because it was the market leader.
However, the Netscape version of the utilities relied on software libraries that did not ship with the Solaris OE. Therefore, the Netscape utilities could not ship as part of the Solaris OE. Legal restrictions at the time prevented Sun from shipping the libraries.
To determine which utilities you are using, it is helpful to know where the utilities are installed. The following lists show where to find the utilities.
Solaris 8 and 9 OE with SUNWlldap loaded:
Bundled Sun ONE Directory Server 5.1 software (Solaris 9 OE):
Unbundled version of Sun ONE Directory Server 5.1 software:
Sun ONE Directory Server 5.2 software, compressed tar file (default location):
Sun ONE Directory Server 5.2 software, SVR4 packages:
You can see that there are five Solaris OE commands (the first five listed above), but only three Sun ONE Directory Server commands (the rest of the list). TABLE 6-1 describes how they map to each other.
Table 6-1. Sun ONE Directory Server Software versus Solaris OE Commands
The Sun ONE Directory Server utilities are usually preferred over the Solaris OE utilities because the Sun ONE Directory Server utilities offer:
The downside to the Sun ONE Directory Server commands is they are only available on systems that have the directory server installed and configured. You also need to run the commands in the directory for which they are installed, or set your LD_LIBRARY_PATH shell variable (see ld.so.1(1) for details). For example:
# LD_LIBRARY_PATH=/var/Sun/mps/lib;export LD_LIBRARY_PATH
Even though the differences between the two sets of utilities are subtle, they are especially important when used in scripts. For example, look at the following two code boxes.
Solaris OE version:
# ldapsearch -b "(dc=example,dc=com)" cn=test2 cn=test2+ipHostNumber=10.10.25.22,ou=Hosts,dc=example,dc=com cn=test2 ipHostNumber=10.10.25.22 objectClass=ipHost objectClass=device objectClass=top # ldapsearch -L -b "(dc=example,dc=com)" cn=test2 dn: cn=test2+ipHostNumber=10.10.25.22,ou=Hosts,dc=example,dc=com cn: test2 ipHostNumber: 10.10.25.22 objectClass: ipHost objectClass: device objectClass: top
Sun Directory Server version:
# ldapsearch -b "(dc=example,dc=com)" cn=test2 version: 1 dn:cn=test2+ipHostNumber=10.10.25.22,ou=Hosts,dc=example,dc=com cn: test2 ipHostNumber: 10.10.25.22 objectClass: ipHost objectClass: device objectClass: top
While the output looks similar, the default Sun ONE Directory Server command output is in a format suitable for importing as LDIF because it includes a dn: directive and uses : as a delimiter instead of = . To get the same output with the Solaris OE version of the command, the -L switch is required. The reason this is significant is that a convenient way to create LDIF is to extract existing entries, then modify them as explained later.
Another obvious difference is how the absence of a bindDN password is handled. The Solaris OE version prompts you for a password if a bindDN is specified and no password is supplied. The Sun ONE Directory Server version defaults to an anonymous bind if the password is omitted.
See ldapsearch(1) for details on the bundled version of the tool and the Sun ONE Directory Server 5.2 software documentation for the second version.
Specific Tools for the Secured LDAP Client
In addition to the standard LDAP commands, Solaris OE provides LDAP-aware commands that can be run on a Secured LDAP Client. The advantage of these commands is that they are simple to use. This is because they make use of the same configuration data the client uses. This means you do not have to be aware of the directory server name or IP address and what base suffix is defined to hold naming service data.
These commands include:
The ldaplist command can be used to search for Solaris OE naming service information instead of ldapsearch and is discussed in the following sections. The ldapaddent , ldapclient , and idsconfig commands are discussed in Chapter 4 "Deploying Solaris OE LDAP Naming Services" in the context of Secured LDAP Client initialization. In the following sections, additional uses of these commands are discussed.
The ldaplist command can be thought as a user -friendly version of the ldapsearch command used to search for Solaris OE naming service information. Unlike ldapsearch , the ldaplist command can only be run on a Secured LDAP Client. This is because information contained in the Secured LDAP Client profile is used as defaults. Therefore you do not have to enter a directory server IP address, search base, or bind DN, because these are defined in the profile. You can specify either the LDAP container name ( ou= ) or the naming service database name.
The ldaplist command is easy to use for beginners , and can also be a useful tool for advanced users. For those who are familiar with the standard LDAP search command, it is helpful to understand the defaults that ldaplist uses.
Issuing the command without any arguments results in a list of container DNs in the default search base. This includes both the standard containers that idsconfig creates, along with any containers you may have created. For example:
# ldaplist dn: cn=Directory Administrators, dc=example,dc=com dn: ou=People, dc=example,dc=com . . .
To see an entire entry, the -l switch is specified. For example:
# ldaplist -l dn: cn=Directory Administrators, dc=example,dc=com objectClass: top objectClass: groupofuniquenames cn: Directory Administrators dn: ou=People, dc=example,dc=com objectClass: top objectClass: organizationalunit ou: People . . .
The -h switch displays the default mappings used for the databases along with the object class used to define the entry and default attribute. For example:
# ldaplist -h database default type objectclass ============= ================= ============= auto_* automountKey automount automount automountMapName automountMap publickey uidnumber niskeyobject publickey cn niskeyobject bootparams cn bootableDevice ethers cn ieee802Device group cn posixgroup hosts cn iphost ipnodes cn iphost netgroup cn nisnetgroup netmasks ipnetworknumber ipnetwork networks ipnetworknumber ipnetwork passwd uid posixaccount protocols cn ipprotocol rpc cn oncrpc services cn ipservice aliases cn mailGroup project SolarisProjectID SolarisProject printers printer-uri sunPrinter #
The database column equates to a database listed in the /etc/nsswitch.conf file. The default type column is the default attribute that is searched on. The objectclass column specifies that only entries containing those object classes are searched.
The following example illustrates how these mappings work along with other command features.
Example showing the LDAP search filter
# ldaplist -v -l hosts "test*" +++ database=hosts +++ filter=(&(objectclass=iphost)(cn=test*)) +++ template for merging SSD filter=(&(%s)(cn=test*)) dn: cn=test2+ipHostNumber=22.214.171.124, ou=Hosts, dc=example,dc=com cn: test2 ipHostNumber: 126.96.36.199 objectClass: ipHost objectClass: device objectClass: top dn: cn=test3+ipHostNumber=188.8.131.52,ou=Hosts,dc=example,dc=com cn: test3 ipHostNumber: 184.108.40.206 objectClass: ipHost objectClass: device objectClass: top #
The -v switch is specified on the command line to show the LDAP search filter, which is represented by the lines beginning with " +++ ":
+++ database=hosts +++ filter=(&(objectclass=iphost)(cn=test*)) +++ template for merging SSD filter=(&(%s)(cn=test*))
The database being searched is hosts . This could also be represented by the container ou=hosts on the command line instead. The search filter specifies entries that contain the object class iphost (the default for this database) and a cn attribute that contains the string test as the first four characters . The example uses the wild card * to shown that these types of searches are possible. Since no attribute was specified on the command line, the default cn= was assumed.
The last line specifies how to incorporate the Service Search Descriptor (SSD) filter if one is defined in the client profile for the database hosts . In this case no SSD is defined, so the template passes the specified string test without modification.
The ldapaddent command is used to load data into the LDAP server. Use of this command is described in Chapter 5 "Migrating Legacy Data to LDAP." However, it can also be used to add new entries after the directory is initialized . This can be useful if you are merging data from an NIS or NIS+ domain after your directory server is already configured and loaded with data from another domain.
If you attempt to import a file that contains entries that already exist in the directory (that is, have the same DN), the ldapaddent command will abort. If you wish to skip over duplicate entries, specify the -c switch on the command line.
The ldapaddent can be used to extract entries from the directory in files format. However, you can accomplish the same result with getent (1M). To do this with ldapaddent, specify the -d option. For example, to extract a user account from the directory with the user ID of jsmith , perform the following command:
# ldapaddent -d passwd grep jsmith jsmith:g0HKYO511jUHE:87317:40:John Smith:/home/jsmith:/bin/csh: #
Similarly, you could use the getent command, which is more efficient:,
# getent passwd grep jsmith jsmith:g0HKYO511jUHE:87317:40:John Smith:/home/jsmith:/bin/csh: #
The user password is only extracted if the LDAP client where the command is run is configured with a proxy user that has password read permission. Otherwise you would need to bind to the directory with a DN that does have password read permission, such as cn=directory manager .
The ldapclient command is primarily used to initiate a Secured LDAP Client. However, it can also be used to perform the following tasks:
All the above tasks except for creating client profiles require root privileges.
The following code boxes provide examples of performing these tasks.
Only one redo is possible. That is, you can only revert back to the previous configuration state.
The idsconfig script is primarily used to configure a new directory server to support Secured LDAP Clients. However, the script can be rerun on an already configured system without any ill effects. No data will be deleted, and if a configuration change was already made, it is simply skipped .
The idsconfig script can be run to create additional profiles or to configure the directory server to support proxy authentication.
The idsconfig script can create an output file that can be used as input for subsequent runs. This is useful when setting up a JumpStart infrastructure.
Other LDAP-Aware Commands
Commands that use the name service switch like gentent and smattrpop , can work with LDAP data. The command getent is useful because it displays all the data in your search path and the order in which data is found.
Tricks and Tips Using LDAP Commands
This section shows how LDAP commands can be used to perform useful functions.
The examples assume you are running the LDAP commands on the same system the directory server is running on. Therefore, the -h option is omitted.
Deleting Multiple Entries
As a system administrator, you might have a need to remove several entries at the same time. Removing them one at a time would be tedious , but the process can be easier using simple LDAP commands in combination. In this example, all users who belong to the group with the GID of 20 are removed.
To Delete Multiple Entries
Identifying Secondary Groups That a User Belongs To
An easy way to determine which groups a user belongs to is to search for the user's group membership ID and return the DN of the groups in which they appear.
# ldapsearch -b ou=group,dc=example,dc=com memberuid=dam dn cn=einsteins,ou=group,dc=example,dc=com cn=quasars,ou=group,dc=example,dc=com cn=rsc,ou=group,dc=example,dc=com cn=labrats,ou=group,dc=example,dc=com cn=fw-sqa,ou=group,dc=example,dc=com cn=wgweb,ou=group,dc=example,dc=com cn=rsi,ou=group,dc=example,dc=com cn=excaliburs,ou=group,dc=example,dc=com cn=wgs-sqa,ou=group,dc=example,dc=com cn=bluemoon,ou=group,dc=example,dc=com #
Sun ONE Directory Server Administration Tools
Most of the administration commands are located in the slapd- instance directory under the server-root where the directory server software was installed. For example:
The commands found here are either shell or Perl scripts that invoke other programs. The reason for this organization is that the actual commands executed have complicated syntaxes and it is easier to create a script that passes the proper parameters to the program than to remember the numerous parameters.
The scripts are generated when the directory server is configured, and are tailored to work with only a single instance of the directory. The following is a list of scripts:
Using the directoryserver Wrapper
The / usr/sbin/directory wrapper script, that is part of the Solaris 9 OE bundled directory server software, can be used to perform many useful administration commands. The wrapper script executes Sun ONE Directory Server commands and scripts for you. The advantage of using the wrapper is that you do not need to know where the instances of directory servers are installed.
When you install the Sun ONE Directory Server 5.2 software SVR4 packages, the Solaris 9 OE version of /usr/sbin/directoryserver script is overwritten with an updated version.
directoryserver Command Basics
There are many options the directoryserver command supports, so it is easy to get confused about how to use it. Examples are provided in the Chapter 7 "Performing Administrative Tasks." However, it is helpful to keep a few principles in mind. These are:
directoryserver Command Operations
Here is a list of functions that can be performed through directoryserver :