• IplanetLdapClassDir2037

Directory Services: Analysis and Planning

• Directory Services: Analysis and Planning: DIR-2037

• Instructor: Dan Vila <daniel.vila@sun.com>

• 24-26 October 2000

• By AdamShand

The class was about LDAP in general but the Netscape/iPlanet LDAP server in particular. Based off of my limited experience with the Netscape server I have to say that I'd recommend avoiding it and just sticking with OpenLdap unless you really feel that you need a (crappy Java) GUI interface. I've never actually deployed the Netscape server but I have deployed the OpenLdap one twice since this class so I may be somewhat biased.

See also: OpenLdap, LdapClient, Solaris8Ldap

General Notes

• there is a brand new class on how to perform day to day maintainance of the netscape directory server.
• x.500 was an osi protocol, meaning that o support it, you have to support the osi protocol stack. it used dap (directory access protocol) to talk to the back end data store. ldap is lightweight dap. originally ldap was an simply an interface to x.500 but it evolved because they discovered that they didn't really need many of the features of x.500 for most of what ldap was used for.
• ldif stands for ldap directory interface format.
• a distinguished name (or dn) is a way of pointing to a specific, and unique, point of the dit (directory information tree). for a user it's format would typically look like this (in ldif format).

  dn: uid=adam, ou=People, dc=metstream, dc=com 
  

  or in the older format:

  dn: uid=adam, ou=People, o=metstream.com 
  

• generic ldap search url (? is the field delimiter), the book has a good bit on ldap url format at intro-20 and 21.

  ldap://server:host/<base dn>?<return>?<scope>?(filter) 
  

  base dn = point to start search in the directory tree 
    return = attributes search should return
    scope = base (search just that node)
            one (search that node and one level down)
            sub (recurse down the tree from base dn)
    filter = boolean items to search for

  ldap://localhost:389/o=metstream.com?uid?sub?(&(uid=adam)(phone=907*)) 
  

• netscape's term "directory manager" is just a new term for "rootdn".
• the admin server is just a web interface to the ldap api. the console is a java gui which interacts with the admin server.
• to log in as the directory manager in the netscape console you must specify "cn=directory manager".
• slapd.at.conf contains custom attribute extensions.
• slapd.oc.conf contains custom object class extensions.

• the book has something good on page 2-2

• an entry object, in ldif, looks like this (in genenal terms), the dn will *always* be first, the rest can be in any order. the rdn part of the dn *must* appear as one of the attributes.
  1. dn
  2. objectclasses
  3. attributes
  4. operational attributes (aci's, replication stuff)
• the admin server port can be whatever (and in fact changes from install to install).
• dynamic groups rock. you can define groups with an ldap url.
• a "container" is the word for a node on the dit which has assocated attributes inside it.
• the slapd.ldbm.conf file contains all the suffix info
• the netscape directory server has a "referencial integrity checker". this means that when you delete or modify the user anything that might have included that user (eg. groups, dynamic or not) is automatically take care of.
• uid uniqueness is another custom netscape plugin. it forces the server to check that the attribute 'uid' is unique before adding a new user. it can be applied to any attribute. for other attributes to be forced into uniqueness you must manually edit the config file.
• stupid url encoding stuff like %3D is just hex encoded ascii. man ascii is the easiest way to get a listing of them all.
• the program db2ldiff will export the database into ldiff format. ldiff2db will import an ldiff file into the database (either as an addition or to overwrite current contents).
• start and stop scripts (need to be linked/moved into /etc/init.d/) are inthe below directories and need to be started in the below order. also note that the admin server runs as root and should only be run when needed.

    <server-root>/slapd-<hostname>/start-slapd 
      <server-root>/start-admin
      <server-root>/startconsole
  

• you can tweak performance by indexing on different attributes to speed searches. be careful though since all indexes need to be rebuilt everytime a change is made.
• the standard port for ldap over ssl is 636.
• ldap v3 doesn't require a bind for anonymous access, ldap v2 requires a NULL bind.
• when you do a compare function 0 = "compare" and -1 = "not compare".
• netscape's aci's (acl's really) are not rfc, they are a custom solution implemented by netscape (at least according to netscape).
• there are several ldap url keywords used in writing aci's:

  ldap:///             - this host, standard port (you'd think it would be "ldap:" like http but hell ... guess they wanted to be different).
  ldap:///anyone   - anonymous bind
  ldap:///self       - whoever logged in as
  

• aci order processing, the instructor was a little vague about this and i haven't done testing yet but this is what i understood from him:
  • there is a default implicit deny
  • now a series of explicit allows
  • now explicit denies
  be careful because any matched explicit deny takes precedence. basically in the above system it looks like it's top down rule processing but the instructor said it wasn't... he said the most specific rule takes precedence.
• remember you must allow anonymous search for the uid. this is so customers can log in as "scarter" and their client can do an anonymous search to figure out that their dn is actually "uid=scarter, ou=People, dc=metstream, dc=com". without this search capability (or a client that will qualify the uid to the dn for the user) clients would have to log in with their dn as their username.
• adding users to the group "Directory Administrator" will give them full admin permissions (ie. full control except over the o=Netscape Root tree).
• page 7-24 has good stuff on it.
• when the server starts up it says "default 600 second cache". this is the amount of time the the server keeps looked up entries in the cache for faster future look ups. this is a system wide setting and can not be tuned on a per index basis.

• the file <server-root>/slapd-<hostname>/db/id2entry.db2 is the actual database. it's a modified berkeley db file. it contains entries in this basic form:

  1: entry
  2: entry
  

  and then the indexes (also in the db sub-directory) index their vaule pointing directly to the entry number so the uid index would have something like:

  adam: 28
  scarter: 32
  

• the default indexes that come with the server are good. you should think pretty hard, or have specific requirements before you change them (according to instructor).
• if you're installing the directory in a lab environment where dns doesn't work make sure you specify the hostname as an ip or you will have problems using the console.
• page 8-12 through 8-13 is good.

Questions I Asked

all info is specific to the netscape directory server, much isn't specifically described by standards, eg. replication, aci's etc.

is there a read only mode for maintainance (so you can leave the server up for authentication and not worry about changes being made as you modify the schema etc)?

yes, can be found in the gui/console

will nscd cache ldap queries make in solaris 8 (assuming internal nsswitch stuff is used)?

instructor thought probably yes.

is having a customized default object class a good idea (eg. metstreamPerson) to pave way for future extensibility?

not really needed though doesn't hurt. all object classes can but updated later with a single ldapmodify command.

what are bottle necks likely to occur on a server dedicated to running a directory server?

instructor thought this was a dumb question. basically it seems that ram is good (to keep indexes in ram), after that i/o and cpu (duh!). netscape has a good case study where they list what hardware they used in their second deployment of ldap (1998) available on their developer site.

can the server handle multiple roots (eg. metstream.com and metstream.net).

yes, built in.

why store "o=Netscape Root" on a seperate server?

for availability of services (because other servers require the "o=Netscape Root" to boot. not entire sure i buy that this is a good idea but you can store it on a master server and replicate it out to the individual servers to remove the network dependency.

what exacty is the rdn (relative distinguished name)?

it is the left most part of the dn, typically "uid=blah"

can you make a change to a replica and have it propagate back to the master?

short answer no, all changes must be made directly to the master. however attempts to change data on the replicaa will result in an automatic referal to the master, so it appears that you can.

how standard is ldif, can i export from netscape's server and import into openldap?

ldap is a standard, this should work fine (beware prepriatory atributes though).

what is the significance of dn other then as a naming device to descibe a node on the directory tree?

as far as i could get the instructor to admin, nothing but he was insistant that it *was* important, just couldn't give me a good reason why.

Useful Links

netscape developer information

http://developer.netscape.com/ go to documentation (top left), case studies, directory and ldap studies

iplanet developer information

http://developer.iplanet.com/

iplanet documentation

http://docs.iplanet.com/

netscape schema guide

http://docs.iplanet.com/docs/manuals/directory/schema/contents.html

open ldap schema guide

http://www.hklc.com/ldapschema/

win32 ldap browser

http://www.ldapbrowser.com/

CategoryPublished