This Tech Note tells you how to use Novell NDS/eDirectory to set up and troubleshoot
the querying and storing of PGP keys.
- 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.
- 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.
- 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”.
- 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 /?.
- 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.
- 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.
- 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.
- 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.
- Your NDS/eDirectory is now integrated with PGP.