First Steps with LDAP

 < Day Day Up > 



Now that the server is set up correctly and running, we are ready to take our first steps in the land of LDAP. LDAP organizes the information it holds in a treelike namespace called a "directory information tree" (DIT). In our case, the root of the tree is the enterprise called ldap_abc.

The command to add an entry with the command-line tool is:

 ldapmodify -a 

Exhibit 2 illustrates the command you have to use. From this command we can note other useful things.

start figure

 # ldapmodify -a -D "uid=admin, o=ldap_abc.de" -w pass1 dn: o=ldap_abc.de objectclass: top objectclass: organization o: ldap_abc.de 1: Munich adding new entry "o=ldap_abc.de" 

end figure

Exhibit 2: Adding the "organization" Entry with Idapmodify

The first line of the actual data begins with

 dn: o=ldap_abc.de 

where dn means distinguished name. The distinguished name is just a key to access this particular entry. Therefore, it must be unique across the whole directory, as explained previously.

The following lines also appear in Exhibit 2:

 objectclass: top objectclass: organization 

Note that ldap_abc.de is an object of the class "organization," and "organization" is a subclass of "top." Both top and organization are declared in the configuration files. If you look at the configuration files of your LDAP implementation, you will see that the only element that top requires is the attribute "objectClass." So the function of the object class "top" is also to ensure that all object classes will have the objectClass property.

The organization ldap_abc.de has two other properties: "o" (organization) and "1" (location), both of them defined in the schema. As noted previously, these are historical names derived from the original X.500 protocol. Reading your configuration files, you will note that some properties are required, and others are optional. A number of attributes can also be multivalued. Chapter 3 will address these issues.

The last line:

 adding new entry "o=ldap_abc.de" 

is the output the command line echoes to confirm that the command has been executed successfully. Otherwise, you will get an error message. If you get

 ldap_bind: Invalid credentials (49) 

you mistyped DN or password.

Be sure to enclose the distinguished name in quotation marks. Otherwise, the shell will interpret the command incorrectly, and the command-line utility will complain about the syntax. If you hit the "enter" key after the first line, the command-line utility waits for you to type the data in. Press "enter" only once to finish each line. If you press it twice, the utility assumes the entry you are typing is complete and parses the entry. It complains if required attributes are missing and quits. For example, if you push "enter" twice after the first line, as in:

 # ldapmodify -a -D "uid=admin, o=ldap_abc.de" -w pass1 dn: o=ldap_abc.de 

the utility answers:

 ldapmodify: no attributes to change or add (entry="o=ldap_abc.de") 

After that, the program waits for further input. You can continue to add further entries. When you are finished, you can exit from the program with Control-C.

Once we have added the root of the directory, we can proceed to add the various departments, called "organizationalUnit" in LDAP. Exhibit 3 shows how to proceed. In this case, we add an entry of the type "organizationalUnit." Obviously the dn attribute is now different. It is built up from the previous one "o = ldap_abc.de" plus an additional string "ou = Information Technologies." The additional string is called a "relative distinguished name" (RDN). The relative distinguished name has to be unique inside its scope. This means that, at the tree below o = ldap_abc.de, there can be no further "ou = IT" entry. Exhibit 4 shows the syntax for adding three additional organizational units.

start figure

 # ldapmodify -a -D "uid = admin, o=ldap_abc.de" -w pass1 dn: ou=IT, o=ldap_abc.de objectclass: top objectclass: organizationalUnit ou: IT description: Information Technologies adding new entry "ou=IT, o=ldap_abc.de" 

end figure

Exhibit 3: Adding the "organizationUnit" Entry with Idapmodify

start figure

 # ldapmodify -a -D "cn=admin, o=ldap_abc.de" -w password1 dn: ou=HR, o=ldap_abc.de objectclass: top objectclass: organizationalUnit ou: IT description: Human Resources adding new entry "ou=HR, o=ldap_abc.de" dn: ou=R&D, o=ldap_abc.de objectclass: top objectclass: organizationalUnit ou: IT description: Research and Development adding new entry "ou=R&D, o=ldap_abc.de" dn: ou=Mkt, o=ldap_abc.de objectclass: top objectclass: organizationalUnit ou: IT description: Marketing adding new entry "ou=Mkt, o=ldap_abc.de" 

end figure

Exhibit 4: Adding Three Other "organizationUnit" Entries with Idapmodify

Now that we have added so many entries, we will look in the directory to verify that the data in the directory matches what we typed in. The tool we use is called "ldapsearch." Exhibit 5 shows it in action, and the result shows that the output is exactly what we put in.

start figure

 ldapsearch -b "o=ldap_abc.de" "(objectclass=*)" # extended LDIF # # LDAPv3 # filter: (objectclass=*) # requesting: ALL # # ldap_abc.de dn: o=ldap_abc.de objectclass: top objectclass: organization o: ldap_abc.de 1: Munich # IT, ldap_abc.de dn: ou=IT, o=ldap_abc.de objectclass: top objectclass: organizationalUnit ou: IT description: Information Technologies # HR, ldap_abc.de dn: ou=HR, o=ldap_abc.de objectclass: top objectclass: organizationalUnit ou: IT description: Human Resources # R&D, ldap_abc.de dn: ou=R&D, o=ldap_abc.de objectclass: top objectclass: organizationalUnit ou: IT description: Research and Development # Mkt, ldap_abc.de dn: ou=Mkt, o=ldap_abc.de objectclass: top objectclass: organizationalUnit ou: IT description: Marketing # search result search: 2 result: 0 Success # numResponses: 6 # numEntries: 5 

end figure

Exhibit 5: Searching the Directory

Let us take a closer look at the ldapsearch command.

 ldapsearch -b "o=ldap_abc.de" "(objectclass=*)" 

The switch "-b" specifies the base from which we want to see all entries, here the root of the directory. The term "(objectclass = *)" specifies that we are interested in seeing all object classes in the directory, not just a particular one. Again, leave the quotation marks where there are. The parentheses in this case are optional, but for more complicated queries, it is a good practice to use parentheses.

If you are not working on the same machine the directory server is running on, you should specify the switch "-h servername" to indicate the machine where the directory server is running. For example, if your server was installed on www.directoryserver.de, your search would look like this:

 ldapsearch -h www.directoryserver.de -b o=ldap_abc.de "objectclass = *" 

Later in this chapter we will examine the search operation in greater detail.

Now let us finally add an entry for a person. Exhibit 6 shows the command line. This time there are more object-class attributes. The object we want to insert is an inetOrgPerson. It should contain a user ID (uid), a password (userPassword), and an e-mail address (mail).

start figure

 # ldapmodify -a -D "uid=admin, o=ldap_abc.de" -w pass1 dn: uid=RVoglmaier, ou=IT, o=ldap_abc.de objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson cn: Reinhard E. Voglmaier cn: Reinhard Erich Voglmaier cn: Reinhard Voglmaier sn: Voglmaier givenName: Reinhard Erich ou: IT uid: RVoglmaier mail: Reinhard.Voglmaier@ldap_abc.de adding new entry "uid=RVoglmaier, ou=IT, o=ldap_abc.de" 

end figure

Exhibit 6: Adding the "inetOrgPerson" Entry with ldapmodify

At this point, if you get an error message complaining about "object class violation" specifying an "unrecognized objectclass: 'inetOrgPerson'," you may have forgotten to include the schema file containing the definition of the object class inetOrgPerson into your configuration file. Put the schema in, stop the server, and restart it again. If the server does not start, complaining instead of a missing attribute type, then you forgot to include another schema file the server needs. In this case, it is the file containing the definition of the attribute type "audio," provided by the file cosine.schema. At startup the directory server loads the schema files and checks to see if all attributes mentioned in the object classes have been defined.

Now that we have provided definitions for all object classes and attribute types, you will get a message confirming that the person has been successfully added. (See last line in Exhibit 6.)

The object class in LDAP offering these entries is inetOrgPerson. We notice that inetOrgPerson derives from organizationalPerson, which in turn derives from person. As stated before, person finally derives from the top, which enforces the presence of the object-class attributes.

If you look at the point where the object classes are defined, you will see that "person" defines a number of attributes, such as "sn," the surname, and "cn," the common name, with the full name being composed of surname + given name. Optionally, the "person" entry can contain a userPassword, a telephoneNumber, a seeAlso reference, and a description. Look at the definition of organizationalPerson. Because this object class inherits from person, the above-listed attributes are not listed anymore. Instead, only the new attributes extending the person class are listed.

Let us do another search, but this time we are interested in the object classes of type "organizationalUnit." Exhibit 7 shows the syntax.

start figure

 ldapsearch -b "ldap_abc.de" "(objectclass=organizationalUnit)" # extended LDIF # # LDAPv3 # filter: (objectclass=organizationalUnit) # requesting: ALL # # IT, ldap_abc.de dn: ou=IT, o=ldap_abc.de objectClass: top objectClass: organizationalUnit ou: IT description: Information Technologies # HR, ldap_abc.de dn: ou=HR, o=ldap_abc.de objectClass: top objectClass: organizationalUnit ou: HR description: Human Resources # R&D, ldap_abc.de dn: ou=R&D, o=ldap_abc.de objectClass: top objectClass: organizationalUnit ou: R&D description: Research and Development # Mkt, ldap_abc.de dn: ou=HR, o=ldap_abc.de objectClass: top objectClass: organizationalUnit ou: Mkt description: Marketing # search result search: 2 result: 0 Success # numResponses: 5 # numEntries: 4 

end figure

Exhibit 7: Searching for All Classes of Type "organizationalUnit"

If we want to see the entries for all persons, we must make a query like that shown in Exhibit 8.

start figure

 ldapsearch -b "ldap_abc.de" "(objectclass=person)" # extended LDIF # # LDAPv3 # filter: objectclass=person # requesting: ALL # # RVoglmaier, IT, ldap_abc.de dn: uid=RVoglmaier, ou=IT, o=ldap_abc.de objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: Reinhard E. Voglmaier cn: Reinhard Erich Voglmaier cn: Reinhard Voglmaier givenname: Reinhard Erich sn: Voglmaier ou: IT uid: RVoglmaier mail: RVoglmaier@ldap_abc.de mobile: +49 170 36273 3747 3747 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 

end figure

Exhibit 8: Searching for All Classes of Type "person"

At this point, you know enough to start playing around with the software. Add some entries, try to find different object classes, and see what happens. You could also add an "inetOrgPerson" object and an "organizationalPerson" object. Then try to search for "organizationalPerson" or "inetOrgPerson" and see the different results. The more you play, the more you will learn.



 < Day Day Up > 



The ABCs of LDAP. How to Install, Run, and Administer LDAP Services
The ABCs of LDAP: How to Install, Run, and Administer LDAP Services
ISBN: 0849313465
EAN: 2147483647
Year: 2003
Pages: 149

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net