1/17/2006
Eric Low

LDAP is used internally by Netware for iFolder, SSH authentication, and probably some other things. :) Here is an excellent article about configuring LDAP on Netware.

We also wanted to use it for our Linux workstations' roaming profile logins (replacing our Linux LDAP server, so that it would be more integrated with the users' Netware accounts). LDAP was installed along with the initial Netware installation, so I left it at that.

First off, LDAP Services can be loaded and unloaded by loading or unloading NLDAP.NLM.

In eDirectory, there are two objects used to confgure LDAP:

ConsoleOne should have the correct plugin(s) to configure the LDAP objects, but it can also be done nicely from iManager, by clicking on LDAP -> LDAP Overview in the lefthand menu.

The first thing I did was go into the properties of the LDAP Server Object (with ConsoleOne) and, from the SSL/TLS Configuration tab, check the Require TLS for All Operations checkbox. Anything else would be a huge security risk. Under Screen Options, I checked Connection Information and Messages from LDAP Extended Operations.

Under the properties for the LDAP Group Object, I ensured that Require TLS for Simple Binds with Password. This requires the user to use encryption when sending their password, but could also result in a clear text password being sent across the network (because the client would send the password before the server ever returns the error code) if the Require TLS for All Operations option was not turned on in the LDAP Server Object properties.

Just to be sure, I checked the Disable TCP Port option under the LDAP Server object's General tab. After I clicked Apply, I could no longer even connect to port 389 (unencrypted LDAP) on the server.

I did not enter a Proxy Username, so any anonymous requests use the [Public] credentials. This kind of worried me, but if I created a proxy user, it would realistically require at least as many rights as [Public] has anyhow. Besides, it appeared that even if a Proxy Username was used, it would be granted the same rights as [Public] in addition to what is specifically assigned to that user. Same as in NDS!

LDAP attributes are mapped to eDirectory attributes on the Attribute Mappings tab. Set what you need!

*** Supposedly, you can set ACLs under the LDAP Group object (or at least you could in NW5) to restrict what attributes people can see. I could not see this in ConsoleOne, and don't seem to have the NWAdmin LDAP plugin installed.

*** Apparently, eDirectory 8.7 and later extends the LDAP schema and introduces an attribute called "ldapBindRestrictions." Using this attribute, you can disable anonymous binds completely Please note that some applications that rely on anonymous binds may break. I could not find this attribute, or perhaps it just needs to be added.

Fairly straightforward, I know. Enjoy LDAP! :P