Novell Home

LDAP: Installation and Configuration Notes

Novell Cool Solutions: Tip
By Ed Anderson

Digg This - Slashdot This

Posted: 30 Sep 1999
 

Ed has rounded up all of the post-it notes about LDAP on his desk, and stuffed them into this handy, all-be-it long, tip. Hopefully, these tips and tricks will smooth the way, so your installation of LDAP proceeds without a hiccup. It's our cheat sheet for all things LDAP, and now it's yours too.

As you know, unless you've been imprisoned in the Archipelago, LDAP v3 for NDS is part of the NDS 8 product. Don't go searching for any LDAP installation options because it's automatically installed when you install NDS 8, and NDS 8 only runs on NetWare 5 and above, so attempting to load NDS 8 and LDAP v3 on an earlier of version of NetWare won't work.

We know just how frustrating a new installation of a product can be, so we've gathered together a bunch of tidbits that we learned from all of our test installs and collected them here. This way you'll have the advantage of our experience, and be able to steer clear of all the little gotchas before you get to them. Read this document when (or before would be even better) you start the LDAP service, and eliminate potential hassles by making sure make sure you've configured the service correctly. It's bound to make your life easier, and your installation smoother.

Make sure TCP/IP is Loaded on the Server Correctly

After installing NDS 8, the server will restart, and as part of the process this will start LDAP (NLDAP.NLM). In some cases, the server reports TCP/IP problems with the following message:

NLDAP: Configure LDAP referrals with NDS failure count = 1
NLDAP: TCP/IP is not configured correctly on this host.

This error occurs if the TCP/IP configuration on the server is different from the information in the SYS:ETC/HOSTS file. You'll see this problem if the IP address for the server is changed after the initial installation. The INETCFG.NLM changes the IP address the server uses during initialization, but it doesn't change the value in the SYS:ETC/HOSTS file. If you see this problem, use the following command to manually change the IP address, so it matches the address configured in the INETCFG utility:

EDIT SYS:ETC/HOSTS

Setup ClearText Passwords for LDAP Group Object

After you've successfully installed LDAP, you'll have an LDAP Server Object and an LDAP Group Object in the same context as the NDS server object. As you might expect, these objects will be configured with default LDAP configuration information. The LDAP Group Object will contain information that can be used by multiple LDAP Server Objects, including basic LDAP configuration information.

However, there's one field on the LDAP Group Object that you'll want to take note of and modify, at least while you do your testing. It's the ClearText Passwords field. Make sure that ClearText Passwords are enabled for your initial testing of LDAP. This will ensure that connection information can flow freely for your initial testing. Of course, don't send any confidential information over this connection if the connection is publicly visible.

You can modify the ClearText Password field using either NWAdmin or ConsoleOne. In either of these management utilities, select and open the LDAP Group Object, and then click the General page to see the ClearText Password field.

Set Rights in the NDS Tree

For the most part, LDAP queries are all about searching for information in the directory. Many of the LDAP clients have some basic browsing capabilities which allow a user to interactively search through a directory to find information. The rights that a user will have to an LDAP server running against the NDS data store, depend on the username they use to authenticate. (This is NDS after all.) You're in the driver's seat, and you can set up NDS rights for these specific users to govern how much or how little information they can see in the NDS data store using LDAP.

An important thing to note with LDAP is the concept of an anonymous user. When a connection is established with no user identity (that is no user name and password) you end up with an anonymous bind which translates to an anonymous user. LDAP v3 for NDS accommodates this anonymous user by granting them rights equivalent to the public group in your NDS tree. Generally, the anonymous user will have the basic rights expected for a non-authenticated, public user; however, you may need to adjust these rights if anonymous users are unable to browse or view any objects in the tree.

LDAP Anonymous Users

LDAP v3 for NDS also makes it possible to create a user object that you can use to control the rights given to an anonymous LDAP user. You can do this by creating a new user in the NDS tree (anywhere in the tree), assigning rights to this user, and then creating a mapping between this user and an LDAP Group Object. In most cases, the NDS Public Group Object will provide adequate rights to the tree; however, you may want to adjust this and grant more rights or fewer rights for anonymous LDAP users. It's up to you. You can also determine (and limit) which parts of the NDS tree are accessible to anonymous LDAP users.

You can map a user object to an LDAP Group Object by selecting and opening the LDAP Group Object in NWAdmin or ConsoleOne. On the first page of the object properties, you'll find a General field that allows you to assign an NDS user as the LDAP Proxy User. Proxy User is another name for LDAP anonymous users, or users who connect to the LDAP service by performing an anonymous bind.

Check Attribute and Class Mappings

LDAP v3 for NDS is designed to allow users to access NDS data using LDAP protocols. But as many of you know, the schema used for NDS and the schema used for LDAP have some differences. In most instances, the NDS schema is more complete, and as a result, provides more class and attribute types. To ensure that all NDS attributes are accessible via LDAP, Novell has created a class and attribute mapping facility.

When NDS 8, which includes LDAP v3, is installed several default mappings are set up. For most shops, these default mappings will satisfy your configuration requirements. However, if the NDS schema at your site has been extended, you may be a need to create some additional mappings to make sure all the data can be located.

After configuring the server and running some tests, if you are not getting the results you expect, check the mapping tables.

SSL Support For LDAP v3

SSL stands for Secure Sockets Layer. It's an encryption technology that allows a network connection over IP to be encrypted using public-private key cryptography. In order for this to work, a digital certificate must be associated with the LDAP server. This digital certificate contains the information necessary (the server's public key) to enable the encryption of the connection.

When the LDAP v3 server starts, you may see a console error message that looks like the following:

NLDAP: LDAP has not been configured with a valid SSL certificate.
SSL connections will fail until configured.
See Novell PKI Services and LDAP Services for NDS
help for more information.

This doesn't mean the LDAP server is malfunctioning, but it does mean that requests from LDAP clients requesting SSL (secure) connections to the LDAP server will be denied.

Setting Up SSL Support For LDAP

SSL support for LDAP v3 for NDS is established by associating a digital certificate with the LDAP Server Object. Another term for the digital certificate used by the server is a Key Material Object.

NDS 8 includes the ability to create the digital certificate necessary to support SSL through Novell's PKI Services.

All digital certificates are generated from a certificate authority. Generally, there will be a single certificate authority for every NDS tree although there could be more than one. Novell's PKI Services includes the ability to create this Certificate Authority Object. If one doesn't exist in your tree, create one in the Security container at the top of your tree. With the Certificate Authority Object in place, you're ready to create a Key Material Object. Here's what you do:

  1. Select the container that holds the LDAP Server Object.
  2. Choose create object.
  3. Select the object type Key Material.
  4. Use the CA Object at the top of the tree.
  5. Follow the Key Material object wizard.
  6. Select a name for the key pair.

Associate the Key Material Object with the LDAP Server Object. You do this by selecting and opening the LDAP Server Object using either the NWAdmin or ConsoleOne utilities. On the General page, you'll see a field that contains the name of the Key Material Object or the SSL certificate. Use the browse button on the SSL Certificate fields to find the newly created Key Material Object and select it.

PKI Services for NDS Notes

When you are creating Certificate Authority Objects or Key Material Objects, the PKI services will use the license number of the NetWare or NDS license string. If valid licenses haven't been installed, then the key pairs used in each of these objects won't be able to be generated. Make sure that valid licenses, using Novell's License Services (NLS) have been properly installed before beginning an SSL configuration.

Exporting the Root for Use in Netscape Communicator or Microsoft Internet Explorer

Both the Netscape Communicator and the Microsoft Internet Explorer come pre-configured with a set of "trusted roots". These root keys refer to the issuing certificate authority for which browsers explicitly accept digital certificates. When a browser initiates a secure session using SSL, the server will send its server certificate to the browser. The browser then checks this certificate against its list of "trusted roots". If the certificate was issued by one of the trusted roots, then it is accepted and considered to be "trusted". Otherwise, the user will be prompted as to whether or not the server certificate should be trusted.

Trusted roots can be added to both the Netscape and Microsoft browser. To do this, you must first export the trusted root used in the creation of the Key Material Object that the LDAP server is using. This root can be exported by selecting and opening the Key Material object, selecting the trusted root page, and then selecting Export. The trusted root will be saved in a file on the client file system. The trusted root can then be imported into either the Netscape or Microsoft browsers making it part of the standards set of trusted roots.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell