PGP Corporation Tech Note

Novell NDS/eDirectory:
Setting Up and Troubleshooting of Querying and Storing PGP Keys

Copyright © 2002 by PGP Corporation. All Rights Reserved.


This Tech Note tells you how to use Novell NDS/eDirectory to set up and troubleshoot the querying and storing of PGP keys.

  1. Copy the pgpschema.ldf to a directory where you can access it from the machine on which you plan to do the import. This file is in LDIF (RFC 2849) format. LDIF stands for LDAP (RFC 2251) Data Interchange Format and is an Internet standard for a common file format for operating on LDAP compliant directory services from different vendors. The tool(s) you would use to import will depend on the version of Novell Server you are running. In this document, the tool we use is the command line version of Novell Import Convert Expert (ICE), a powerful directory management tool that ships with eDirectory 8.5 onwards to import LDIF data onto NDS. ICE was chosen over bulkload, zoneimport and ldapmodify because of its ease of use. For NDS operations, ConsoleOne 1.2d.1 and dsbrowse 84.90 (which replaces dsview of NW 4.x) are used on a Netware 5.1 (support pack 5.1.3) Server running NLDAP 3.19 on NDS v8.77. If your software versions are different from these, some of the operations may have to be done a bit differently than described here.
  2. The command line version of ice is included in the LDAP Libraries for C SDK in the Novell Developer Kit (NDK) available at http://developer.novell.com. We used ice.exe version 101100.03e from a Windows client connected to the Novell Server through Novell Client v4.81. You may choose to use ice.nlm on the server console instead, but if you are not running eDirectory but an older version of NDS, you may encounter dependency problems. You may need to update your ldif.nlm on the server. Using ice on the client is generally less problematic.
  3. Ice accesses NDS via LDAP. Hence it is necessary that the LDAP server (called LDAP Services for NDS) is running when you do the schema updates for PGP key operations. The server gets installed as a part of the NDS eDirectory installation. In ConsoleOne you should see the LDAP Server Object and the LDAP Group Object added to your tree when NLDAP is installed. If these objects are not there, you may need to install the LDAP server and/or manually start it. You can manually start the server by typing at the console prompt “load nldap.nlm” if the service is running on Netware. On Windows NT, in the DHOST screen, select NLDAP.DLM and click Start. On Linux, Solaris, or Tru64, type “/usr/sbin/nldap –l”.
  4. In the simplest of cases you need to type on the command prompt "ice –e err.ldif –l ice.log –v –DLDAP –s <yourldapserver> -d <youradmindn> -w <yourpasswd> -SLDIF -f pgpschema.ldf ".

    -e and -l stand for error and log file, respectively. -v turns the verbose mode on. -DLDAP specifies that destination of our export is LDAP server. -s specifies the DNS name or IP address of the server. -d and -w let you specify the DN of the entry used to bind to the source LDAP server and the password. This account should have sufficient rights to update the NDS schema. -S specifies that the source of export is LDIF file. -f lets you specify the LDIF file path. Note that the authentication would be clear text in this case, which may result in an error 8 (Strong authentication required) from the LDAP server. When using LDAPv3, by default only encrypted connections are allowed to the NLDAP. To turn on clear text authentication, from ConsoleOne or NWAdmin select LDAP Group Object. From the details general page select the option “Allow clear text passwords” . Alternately, you may use an encrypted session after setting up SSL. The command line parameters to ice would need to be changed accordingly. For more on command line options, type ice /?.

  5. You should see the import succeeding for all the entries. Check the error (err.ldif) and log (ice.log) files for possible error(s). In case of an error, go to the erring record number and take a close look to see if anything looks suspicious. If nothing looks wrong, remove all successful entries before the erring record and save the file. Rerun ice with identical parameters and look for errors. If you do not remove the successful entries, ice will report something like “Record: <>, ldap_modify failed: 20 (Type or value exists), dn: <>”. The deletions make the file smaller and easier to inspect while avoiding "already existing" errors when you try to import a second time.

    After a successful import you should see the new attributes and classes in dsbrowse. When you choose new object in ConsoleOne, the new classes pgpServerInfo and pgpKeyInfo should appear in the list. If they do not, then you may need to click the refresh toolbar button or choose View --> Refresh to get the new pgp classes to appear in the new object popup.

  6. PGP clients use the LDAP operational attribute namingContexts on root DSE (DSA Specific Entry) of LDAP Server to do automatic key space discovery. The automatic discovery works as follows. The PGP client tries to find <namingContexts>,CN=PGPServerInfo for each DN returned in the attribute value. This object is expected to be of class pgpServerInfo, which stores the DN of the PGP key store in its pgpBaseKeySpaceDN attribute. If your server returns non-blank value(s) in the attribute, you would need to create a pgpServerInfo object under any one of the naming contexts returned and the CN of this object must be “PGPServerInfo” and the mandatory attribute pgpBaseKeySpaceDN should be set to a valid DN that will be used as the key store. But when the server root DSE does not return this attribute or returns blank (meaning that it is a gateway or the server believes it contains the entire directory), you will need to specify the DN of your key space directly in your server definition in PGP client.

    You may create the pgpServerInfo object at the appropriate folder via ConsoleOne. ConsoleOne may report “There is not a snap-in to create this type of object. If you proceed and use the generic object creator, the resulting object may not be usable. Continue with object creation ?”. Choose Yes. Enter the CN as “PGPServerInfo” and set the pgpBaseKeySpaceDN attribute to the DN of the folder in which you want the key store to reside. NLDAP in our case returned blank value for the namingContexts attribute, which made automatic discovery impossible. We specified the DN of the key store in the client(s) directly. (Note that this means each PGP client has to be configured to point to the right DN.) For more on LDAP operational attributes, refer to section 5.2 of RFC 2252.

  7. If you did not create the pgpServerInfo object, you have to take care of access permissions on the key store DN folder in NDS. If you did create the object, you would have to additionally make sure that the permissions on the folder where you created the pgpServerInfo object are good enough to be accessed by the PGP client. PGP currently talks LDAPv2 with simple authentication. This is treated as “anonymous binding” by NLDAP and the special pseudo-object [Public] will govern access to the tree.

    By default, this pseudo object can browse the entire hierarchy and read a limited number of attributes on entries. These rights will not be sufficient to do the key operations, especially sending keys to the server for storage. Hence it is necessary to create an LDAP proxy user and assign the proxy user the exact right(s) required. This is more secure than assigning additional rights to [Public], since the types of objects and attributes that anonymous users can access can be restricted by setting the appropriate access controls on the proxy user object. The proxy user must have a blank password (which is not the same as no password) and should not have restrictions such as password expiry and such. Create such a user and enter the DN of the new user in the Proxy Username field of the General tab page of LDAP Group Object Properties property sheet in ConsoleOne. Add this user to the trustee list of the folders that involve PGP operations. The access permissions should include read and write for the key space folder since users will be sending keys to the server and searching keys. The pgpServerInfo object folder should allow reading of all attributes to the proxy user. Trustee rights can be assigned via ConsoleOne --> Properties --> NDS Rights --> Add Trustee. For more on LDAP proxy user, refer to TID’s 10062428 and 2920151.

  8. Now try uploading and searching keys.

    If the access permissions are insufficient, PGP will report this, in which case you need to revisit step 7 and make sure rights are sufficient. Once the upload succeeds, you may want to make sure more rights than required are not being granted accidentally to the proxy trustee. This is very important. Restrict the proxy user to only pgpKeyInfo objects in the folder if other objects that you do not wish to give access are in the same location.

  9. Your NDS/eDirectory is now integrated with PGP.