eDirectory and LDAP

 <  Day Day Up  >  

Test Objectives Covered:

4. Describe how eDirectory works.

5. Perform eDirectory administration tasks .

The version of eDirectory that is installed with NNLS includes a very powerful LDAP server. LDAP is a set of standards that provides controlled access to the information stored in a directory such as eDirectory.

Before we go any further, we need to make some clarifications about the nature of LDAP. The concept of LDAP tends to confuse a lot of people, even those who have a lot of experience with directory services.

LDAP, as stated earlier, is a protocol that allows programmers to write applications that can read and write information to a directory service that complies with the X.500 directory standard (hence the name Lightweight Directory Access Protocol).

LDAP is not, as many think, a directory service in and of itself. The confusion comes because we use the term LDAP server frequently in the industry. A more correct term would be LDAP service . The LDAP server doesn't contain any information, such as containers or objects. It simply allows you to access information in an LDAP-compliant directory service, such an eDirectory. This is shown in Figure 5.35.

Figure 5.35. LDAP and the directory.

graphics/05fig35.jpg


The goal behind the LDAP protocol is to provide a common way to access directory information. As shown in Figure 5.35, programmers can access system information in a directory with either the native directory access protocols established by the vendor with LDAP calls.

Without LDAP, programmers would have to learn a whole new API set for each directory service they needed to write applications for. With LDAP, they can learn a single set of protocols and use it with many different directory services.

Equating eDirectory and LDAP Terms

Another point of confusion for eDirectory administrators is the difference in terminology and naming conventions between eDirectory and LDAP. Let's review some of the most common:

  • In LDAP terms, an object is referred to as an entry or as a record .

  • Object properties are referred to as attributes .

  • eDirectory contexts are referred to as naming contexts .

  • eDirectory client connections are referred to as LDAP binds .

You also need to be aware of the differences in naming standards. Recall that eDirectory object names can be typeful or typeless, relative or distinguished. Using LDAP syntax, objects in the tree are always referenced using typeful distinguished names .

Another difference is the delimiter . With eDirectory standards, a period ( . ) is used to separate objects. When using LDAP syntax, you use a comma ( , ) instead.

For example, if you have an eDirectory object named CGrayson located in the IF.CLE container, it is referred to (typefully) as .CN=CGrayson.OU=IF.O=CLE . When referring to the same object using LDAP syntax, you would use cn=CGrayson,ou=IF,o=CLE .

LDAP syntax is not case-sensitive. Common usage, however, is to actually use all lowercase letters .

With these points in mind, let's look at how LDAP is integrated with eDirectory.

eDirectory LDAP Integration

The LDAP service installed on your server during the NNLS implementation is tightly integrated with eDirectory. The LDAP service binary (nldap) is located in /usr/sbin . Within the eDirectory tree, you will see two objects that are used to configure and manage the LDAP service:

  • LDAP Server object ” The LDAP Server object is automatically created in the same context as your server object. It is named LDAP Server “ your_server_name , as shown in Figure 5.36. This object stores the configuration information for your LDAP service. When the service starts, it reads this object to retrieve its configuration parameters.

    Figure 5.36. eDirectory LDAP objects.

    graphics/05fig36.jpg


  • LDAP Group object ” The LDAP Group object also stores LDAP configuration parameters. It is also automatically created during installation and is placed in the same context as the server object, as shown in Figure 5.36. It is named LDAP Group “ your_server_name . A single LDAP Group object can be associated with multiple LDAP servers in the tree, allowing them to share a common configuration. This can be very beneficial if your network and tree are very large.

LDAP Binds to eDirectory

When a client binds to eDirectory through the LDAP service, eDirectory rules and rights, discussed earlier, apply just as if the client had accessed the directory using native eDirectory calls.

If an LDAP client accesses the directory without supplying a username or password (anonymously), it is authenticated as [Public] and is granted browse rights (unless you've changed [Public]'s default rights assignment) to the root of the tree.

Using the LDAP Group object, you can change the default anonymous user. You can create a user in the tree, assign the rights you need anonymous LDAP users to have, and associate the new user with the LDAP Group. Modifying the properties of the LDAP Group object, as shown in Figure 5.37, does this. Remember that the proxy user can't have a password or any password restrictions.

Figure 5.37. Configuring the LDAP proxy user.

graphics/05fig37.jpg


Unless you have an outstanding reason for doing this, you should stick with the default [Public] level of access. The rights you give this proxy are automatically granted to unauthenticated LDAP clients . You should err on the side of caution.

If an LDAP client accesses the directory and supplies a valid username and password, it is authenticated using those credentials. The effective rights associated with the authenticated user object are granted to the LDAP client.

With that, let's briefly discuss how to import objects into your tree using LDAP and a text file.

LDAP Data Interchange Format (LDIF)

One very useful feature of LDAP is the LDAP Data Interchange Format (LDIF) specification. This allows you to define directory objects in a simple text file (using standardized formatting) and import the file into the directory tree.

You can complete add, delete, and modify operations in the file. You can complete multiple operations within the same file. A detailed discussion of the full LDIF specification is beyond the scope of this book. We will, however, explore a couple sample entries in an LDIF-compliant text file:

Note

If you want to learn more about creating LDIF files, visit http://developer.netscape.com/docs/manuals/directory/admin30/ldif.htm .

 

 version: 1 dn: cn=mhuffman,ou=IF,o=CLE changetype: add objectclass: inetorgperson sn: Huffmann title: Manager dn: cn=jcorry,ou=SLC,o=CLE changetype: delete dn: cn=cgrayson,ou=IF,o=CLE changetype: modify replace: title title: Vice President 

 


If saved in a text file, this information can be imported into your eDirectory tree. This file creates a new user object named mhuffman in the IF.CLE container.

The second operation in this file deletes a user named jcorry from the SLC.CLE container ( assuming this user already existed there). The last operation modifies the cgrayson object in IF.CLE and changes the value of its title attribute.

eDirectory includes a utility named Import Convert Export utility ( ice ) that can be used to import LDIF files into the tree as well as export objects from the tree into an LDIF file. iManager includes a graphical interface that can be used to configure ice jobs and run the ice engine to import the file.

Let's practice importing an LDIF file in Lab Exercise 5.6.

 <  Day Day Up  >  


Novell Certified Linux Engineer (CLE) Study Guide
Novell Certified Linux Engineer (Novell CLE) Study Guide (Novell Press)
ISBN: 0789732033
EAN: 2147483647
Year: 2004
Pages: 128
Authors: Robb H. Tracy

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