LDAP is a user database, and it does in Unix what MS Active Directory does in Windows. From Operating System Admin perspective, LDAP would typically be used to replace NIS (or NIS+ or scattered local passwd files). If you are pondering if you should migrate to LDAP, you'll wish the answer was 'NO' :)
LDAP is much more complex than NIS, and OS support is still not rock solid as in NIS [this was written back in 2006]. Automount maps retrieval from LDAP is quite complex and not well supported. Older OS LDAP support is rather spotty, and forget about OS that have been EOL-ed by the vendor!
So, in short, unless you know you need LDAP, stay away from it :) And if you do use it, hopefully this page has some useful info for you.

LDAP Tree Conceptualization

While LDAP is a user "database" repository, do not think of it as a Relational Database. It has no resemblance to RDBMS. The only thing that bear resemblance from RDBMS is the "key" and maybe "attributes", other than that, forget everything you learned about Relational DB when working with LDAP. Definately forget about those Boyce-Codd Normal Form!!
File Cabinet Numbering
Special File System Tree

LDAP User Management

To disable/lock out a user, one can add the attribute to the user dn: nsAccountLock: true. The GUI console provide a way to click "disable" under the Accounting tab. However, OS support for this flag is spotty. For example, RHEL 3 does, but Solaris 8 does not. Thus, the admin should change the user default shell to something like /bin/false.

The Unix sys admin tradition is to also change the user's password to some random text to prevent the user from logging in. Sure, theoretically, there is a chance the password could still be guessed, but this isn't likely in practice, and may involve non-print characters. Finally, note that if POSIX account is completely disabled, it would delete the UID info, which are typically undesirable due to the need to keep UID/GID for historical reference (files ownership, etc).

LDAP Profile Management

Some OS need a profile to be stored on the LDAP server so that client side LDAP config can be updated in a single server location, rather than updating on each machine. In practice, profile may add too much complexity for too little gain.

Sun also claims profile add security, preventing user from joining a machine to LDAP w/o the LDAP admin knowledge. However, if the user have root in one client, files in /var/ldap can be copied from one machine to another. The encrypted password is copied, obliviating the need to know any password to bind to the Directory. Lastly, most site allows anonymous bind just as ypcat passwd is not secured anyway. At the end of the day, the sys admin don't have a choice whether to use profiles or not. Solaris and HPUX use profiles, and AIX and linux don't.

Some admins like to create one profile for each version of a given OS, so that vendor gratuitous changes in new version won't affect other versions. This come at a cost of maintaining more profiles. Pick your own poison :) On the other hand, if there are multiple sites, then site-specific profile would typically make sense.

If there is only one domain, storing profiles near the root would be good. eg OU=profiles,dc=unixville,dc=com. But even if there are multiple domains, it maybe best to put them in the same location anyway, using different name for profiles beloging to different domain/site. This is mostly to ensure client bind process can locate the profile easily and no guess work as to which part of the tree the profile came from.

So far, Solaris 8 thru 10 can use the same profile without any noticeable problem. It seem easiest to create the profile from a Solaris 9 client and bind using Directory Manager to seed this process.
Each version of HP-UX add a bit more "feature" into the ldapux-profile. 11.00 has a basic profile, 11.11 added something, yet 11.23 bloated it up even more. The nature of ldap client is that they ignore directives they don't understand. As such, it worked pretty well to seed the initial profile using an 11.23 client, binding as Directory Manager to upload the profile directly to the LDAP server. Once done, the client can be reconfigured to bind as proxy agent.

Lastly, I would like to mention that it is possible for LDAP-UX to use the Solaris profile, at least for HP 11.11. However, latest versions of the two OSes seem to diverge and maintaining separate profiles may reduce compatibility problems down the road.

LDAP Gotchas

Smart Referals
Probably want to stay away from them from NIS migration perspective. Linux is probably the only platform that supports it. AIX will traverse them and loop thru the many servers set by the smart referals and cause huge delays in telnet session connection, automount maps retrieval, and make machine extremely sluggish.
Solaris, it is a bit better. It still crosses the smart referal servers more often than needed, resulting in delayed performance. Even when profile is set that it should not follow the smart referals, it doesn't honor it. Performance is acceptable if smart referals is a must. But even then, I don't see automount maps referals to function correctly.
HP-UX. Don't know if it cause problem yet, but it doesn't provide the correct function of retrieving data from the smart referal automount maps.

The protocol definition for RSH vs REXEC and other similar command: (a) rsh use the Berkeley rcmd(3) library, and requires the binary to be setuid root so that it run in priviledged ports and scan for .rhosts in remote server.
(b) rexec use the rexec(3) library. It does not scan .rhosts so no need to run as root. Instead, it provide user password in clear text to remote server to login. remsh is the same as rsh, just renamed to avoid clash with the "restricted shell"
(c) rlogin is for remote console login. It handles less control character than TELNET. Most system implements "rsh host" w/o a command as a call to rlogin for interactive login. RSH is left for executing command on remote host and streaming the output back to the source machine. RLOGIN also uses the Berkeley rcmd(3) library.
(d) rcp is remote copy akin to rsh wrapped around files directly.
(e) ssh default behaviour is to emulate rsh with command. For interactive login, it probably follows the rlogin algorithm, but hangles control characters much better, akin to telnet. Further, ssh is smart enough not to read user login/password from a std out redirect, but must ask on an interactive keyboard (expect can emulate keyboard login).

Note that
(1) RSH/RLOGIN/SSH scan user db differently than
At least in AIX, the former set seems to invariably look for local /etc/passwd user first, whilst the latter look at LDAP. nsswitch.conf on other system may have effect on this, but Solaris 8 RSH is looking at local passwd first for sure. Further note that AIX 5.3 "rsh hostname cmd" behaves more like (2). It is a bizare world of intricate details and buggy implementations a/o protocol :-/ Note that aix man page on rexec says it only look at COMPAT but in fact it look at LDAP first!

AIX has a variable AUTHSTATE that get set to:
  • compat when login using rsh
  • LDAP when login using telnet
  • files can be set manually to force UID to username resolution thru files first (still go thru other method if it fails to find it in files).
    It seems safe to set this variable in /etc/profiles and /etc/csh.cshrc to "compat" and all seems to work well, sourcing local files first.

    RSH issues
    RSH is likely to work in LDAP environment. However, getting RSH to allow user to login without prompting for password (use of the insecure .rhosts, etc) is likely to be more problematic. Solaris may need patches and config on pam.conf. HP-UX will need update on pam.conf, and perhaps a myriad of other config depending on security model. Refer to HP PAM doc.

    SSH issues
  • If you compiled OpenSSH from source, you will need to include PAM support.
  • If you got openssh package from SunFreeware.com, the older version won't work with LDAP.
  • If you are using vendor provided SSH, and vendor supplied LDAP libraries, then all should be good. If on the other hand third party LDAP libraries are added, eg from PADL.com, then things may break.
    Automount issues
    The typical sys admin would put lot of automount maps on NIS, and just about every unix OS automount can retrieve these maps from NIS. However, such assumption would be very wrong when migrating to LDAP. While the LDAP server can store anything one throws at it, the data may not always be retrievable :( There is an rfc defining how to store automount maps in LDAP, and when configured correctly, will work. But it need substantial client-side support. Autofs on just about every OS client need to be updated. Solaris 9 and older need patches. AIX 5.2 and older don't have upgrades available. HP-UX 11i can use the Enhanced-AutoFS package, but it need lot of OS patches and kernel recompilation to support it. Newer Linux can run up2date to patch the autofs rpm. See the client section below for more details. In general, treat each version of each OS as an independent entry in the configuration matrix, and test everything to ensure your config works!

    LDAP command


    Query ldap directory server info, output in LDIF format.
    Sample ldap search commands...
    solaris 10 argument structure:
    ldapsearch -b SearchBase [options] FILTER [attributes]
    	-h ldaphost	# ldap server to connect to, default to localhost
    	-D bindDN	# user used to connect to LDAP, default to anonymous
    	-d n		# debug level, bits flags. 
    	-e 		# minimizes base-64 encoding (like tab!)
    	-T		# don't fold/wrap lines.  ldiff treat lines starting with space as
    			# continuation of previous line, def width is 80 chars.
    	-p 1234		# use port 1234 (default ldap use 389, TLS is 636)
    	-L		# ...
    	select the addributes to list.  Default to all, but can limit to display only a certain ones, eg:
    	dn 		# list only the dn entry
    	dn cn		# list both dn and cn entries, nothing else.
    <!-- -->
    ldapsearch -b "dc=unixville,dc=com" -h ldapsvr        uidNumber=5001
    ldapsearch -b "dc=unixville,dc=com" -h ldapsvr -p 389 gidNumber=5001
    	# find entry with a given uid or gid number.
    ldapsearch -b "dc=unixville,dc=com" -h ldapsvr memberUid=tin dn
    	# find all gruops whereby tin is a member of (unix secondary group membership)
    	# display only the dn (name of group and "domain" group is defined in)
    ldapsearch -b "l=sf,l=us,dc=unixville,dc=com" -h ldapsvr uid=* dn
    	# list all user in a the "domain" l=sf,l=us
    ldapsearch -b ou=Groups,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com -h ldap007 cn=* dn
    	# list all group names of a given domain.
    ldapsearch -b "dc=unixville,dc=com" -h ldapsvr "uid=tin*" dn cn uidNumber
    	# find all username starting with tin, display only the fields dn, cn, uidNumber.
    ldapsearch -b "ou=us,dc=unixville,dc=com" -h ldapsvr "givenName=*tin*" dn givenName uidNumber
    	# find all user real name containing tin anywhere, case insensitive
    ldapsearch -b "ou=us,dc=unixville,dc=com" -h ldapsvr -D "cn=Directory Manager" "givenName=tin" userPassword
    	# -D = perform search using specific user credentials
    	# Certain attributes such as shadow password can only be retrieved by
    	# priviledged user.
    	# Finally, some info is only available on the Directory Server (eg via
    	# export) but not as ldapsearch at all.  eg attributes for Person entry: 
    	# creatorsName, modifiersName, modifyTimestamp, nsUniqueId
    ldapsearch -b "cn=config" -h ldapsvr -D "cn=Directory Manager" "objectClass=*"
    	# retrieve config info, objectClass=* serve as wildcart for "all"
    ldapsearch -b "cn=config" -h ldapsvr -D "cn=Directory Manager" "objectClass=*" | grep  passwordStorageScheme
    	# grep for the password encryption scheme (crypt, ssha, etc).  
    	# aix 5.3 only supports crypt
    	# solaris and linux support both crypt, ssha.
    ldapsearch  -b "cn=schema" -h ldapsvr -D "cn=Directory Manager" "objectClass=*" 
    	# retrieve all info on the schema of the directory tree
    ldapsearch -h ldapsvr  -b "o=NetscapeRoot" -D "cn=directory manager" "objectClass=*" 
    	# retrieve fedora directory server internal config info
    	# NetscapeRoot cuz fedora/redhat ds is based off the old netscape directory server 
    ldapsearch -h ldapsvr -L -b automountMapName=auto_master,l=sf,l=ca,c=us,dc=element50,dc=com objectclass=*
    	# something similar to "ypcat auto.master"
    ldapsearch -h ldapsvr -T -b automountMapName=auto_home,ou=us,dc=unixville,dc=com  objectClass=*  dn                   | grep -v ^$ 
    ldapsearch -h ldapsvr -T -b "ou=us,dc=unixville,dc=com"                          automountkey=*  automountInformation | grep home
    	# list automount maps entries for auto_home, similar to "ypcat auto.home"
    ldapsearch -h ldapsvr -T -b automountMapName=auto_home,ou=us,dc=unixville,dc=com  automountKey=tin
    	# retrieve automount info about /home/tin
    ldapsearch -h ldapsvr -T -b dc=unixville,dc=com  automountkey=/home
    	# find out where /home is refered and how it is defined (auto.master, auto_master, which domain/ou)
    ldapsearch -h ldapsvr -b dc=unixville,dc=com nisnetgrouptriple=*lungfish* | less
    	# find out which netgroup a machine called lungfish belongs to, long output!

    ldapsearch is located in /usr/ldap/bin. Parameters are similar to Solaris.
    Linux native
    Parameters used by /usr/bin/ldapsearch from the opendap-client rpm, most of them are similar to the Solaris ldapsearch:
    ldapsearch [options] FILTER [attributes]
    	-x 		# no SASL (option not in Solaris)
    	-LL		# suppress comments in output
     	-b SearchBase	# specify the starting point where search will begin.  Typically root.
    	-h ldaphost	# ldap server to connect to, scan /etc/ldap.conf if configured.
    	-D bindDN	# user used to connect to LDAP, default to anonymous
    	-d n		# debug level, bits flags. 
               [------------- options -------------]   [-- FILTER (req) --] [attr]
    ldapsearch -b dc=hybridauto,dc=com -h ldap007 -x   nsds5ReplConflict=*    dn    | grep -v ^$
    	# find all entries with replication conflict problem, 
    	# where dn is has nsuniqueid appended to it.  eg:
    	# nsuniqueid=f0b6791e-1dd111b2-80dba88a-997d0000+uid=duptest,ou=people,dc=hybridauto,dc=com

    Parameters used by /opt/fedora-ds/shared/bin/ldapsearch installed by the RedHat/Fedora DS:
    Some strange Linux machines default ldapsearch
    Probaly old school linux machines...

    ldapsearch -x -ZZ -s "dc=unixville,dc=com" -b ""
    	-x 	= no SASL
    	-ZZ	= use TLS
    	-s 	= search base


    ldapadd will add info to the directory server, erroring out if the entry already exist (as defined by the dn). Must be done when the Directory Server is running, live. (ldif2db will overwrite, see below).
    ldapadd -x -W -c -D "cn=Directory Manager" -h ldapsvr -f data.ldif
    	ldapadd is really "ldapmodify -a", so it share the same options, see below
    Sample data.ldif file used to add a user, a group and simple automountmap entry for the home directory.
    # add a user 
    dn: uid=tin,ou=People,l=sf,c=us,dc=unixville,dc=com
    uid: tin
    cn: Tin Ho
    givenName: Tin
    sn: Ho
    mail: tho01@yahoo.com
    objectClass: person
    objectClass: organizationalPerson
    objectClass: inetOrgPerson
    objectClass: posixAccount
    objectClass: top
    userPassword: {crypt}solarisShadowOk
    loginShell: /bin/bash
    uidNumber: 168
    gidNumber: 168
    homeDirectory: /nfshome/tin
    gecos: optional NIS gecos field 
    # eg for adding a group
    dn: cn=sn-group,ou=Groups,l=sf,c=us,dc=unixville,dc=com
    objectClass: posixGroup
    objectClass: top
    cn: sn-group
    gidNumber: 168
    memberUid: moazam
    memberUid: rlee
    memberUid: lys
    # eg for automount entry (automount object need to be already defined prior to this add)
    # this form is acceptable by Solaris and new Linux autofs (ditto for Aix and Hpox, 
    # but the old linux autofs will not understand it, so get rpm 4.1.3-174 or newer)
    dn: automountKey=tin,automountMapName=auto_nfshome,l=sf,c=us,dc=unixville,dc=com
    objectClass: automount
    automountKey: tin
    cn: tin
    automountInformation: -rw casper:/export/home/&
    When first setting up LDAP repository, initial maps for auto.master, auto.nfshome, etc need to be defined. It maybe easier to do this using the GUI, see below. The LDIF files defined here can be used for addition or verification in subsequent ldapsearch. Pay special attention to dot(.) vs underscore(_) below.
    # auto.master direct map (Linux) 
    dn: automountMapName=auto.master,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    objectClass: top
    objectClass: automountMap
    automountMapName: auto.master
    dn: automountKey=/nfshome,automountMapName=auto.master,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    objectClass: automount
    automountKey: /nfshome
    cn: /nfshome
    automountInformation: ldap:automountMapName=auto_nfshome,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    dn: automountKey=/net,automountMapName=auto.master,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    objectClass: automount
    automountKey: /net
    cn: /net
    automountInformation: -hosts
    # auto_master direct map (Solaris?)
    dn: automountMapName=auto_master,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    objectClass: top
    objectClass: automountMap
    dn: automountKey=/nfshome,automountMapName=auto_master,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    objectClass: automount
    automountKey: /nfshome
    automountInformation: auto_nfshome -rw,hard,intr,vers=3,rsize=32786,wsize=32786
    dn: automountKey=/net,automountMapName=auto_master,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    objectClass: automount
    automountKey: /net
    automountInformation: -hosts
    # auto_nfshome
    dn: automountMapName=auto_nfshome,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    objectClass: top
    objectClass: automountMap


    Change existing data already stored in the Directory Server
    ldapmodify -D uid=tinh,ou=people,dc=geneusa,dc=com -h ldapsvr -p 1389 -f ./data.ldif
    ldapmodify -x -W -c -D "cn=Directory Manager" -h ldapsvr -f data.ldif
    	-h specify the server to connect to to perform the add
    	-f FILENAME, if using path with filename, must use /full/path/to/file
    	   If no filename is defined, ldapmodify expect all commands to come from std in, one line at a time;
    	   empty line by itself to indicate end of record.
    	-x = simple auth instead of SASL
    	-W = prompt for password on the CLI
    	-c = continuos operation, instead of exiting when errors happens
    	-D USER = the user to perform the change as
    	-v = verbose
    	-n = dry run, don't acutally do anything
    # modify user account try adding the objectClass=shadowAccount
    # so that user can login to Solaris 8 and related machines
    # Note that some ldapmodify binary may crook on comments!!
    # (Solaris and many Linux can't parse #)
    # Blank lines are potential problems, so avoid them :)
    dn: uid=tin,ou=People,l=sf,c=us,dc=unixville,dc=com
    changetype: modify
    add: objectClass
    objectClass: shadowAccount
    # Add a password field to user whose account have empty password
    # ie, no userPassword clause definated at all
    dn: uid=mlee,ou=People,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    changetype: modify
    add: userPassword
    userPassword: {crypt}*notSet*
    # Change user password field to indicate that it is in locked state.
    dn: uid=tho,ou=People,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    changetype: modify
    replace: userPassword
    userPassword: {crypt}*AccountLocked-2006-07-26*
    # Change account to lock state, not all OS honor this.
    dn: uid=tho,ou=People,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com
    changetype: modify
    add: nsAccountLock
    nsAccountLock: true
    # Change a group definition: add a user to its membership list
    dn: cn=sysadmin,ou=Groups,ou=sc,ou=ca,ou=na,dc=hypbridauto,dc=com
    changetype: modify
    add: memberUid
    memberUid: tho
    memberUid: mlee



    /opt/redhat-ds/slapd-ldapsvr/db2ldif -s dc=unixville,dc=com -a export.ldif
    Export all site data for the domain uxville.com, place it in LDIF format. This file can then be edited, eg sed 's/\t/ /g' to remove all tabs, and then reimported.
    For the -a option, output file may need to have full path specified, and output location may need to be writable by user "nobody". If option -a is not used, the output will be stored automatically in a location where "nobody" can write to, typically /opt/redhat-ds/slapd-ldapsvr/ldif.

    /opt/redhat-ds/slapd-ldapsvr/db2ldif -n userRoot
    Brief test, output info related to "default master db" that stores root-level data, such as profiles, etc. It does not output data in sub-suffix databases related db that stores user data. so it is usually small.


    /opt/redhat-ds/slapd-ldapsvr/ldif2db -s "ou=us,dc=unixville,dc=com" -i /full/path/to/import.ldif
    Import data in ldiff format. Typically req to be importing a specific section of the domain. It will overwrite data that already exist under the subtree of the import. The import has to be done when the directory server is turned off. If using replication with multiple servers, the other machines need to be re-init from this master server that did the import.


    LDIF is the standard data exchange format. It is a simple ASCII file with special text formatting. Each entry has a dn. Different entries are separated by blank lines. line that begin with a space is considered to be continuation of previous line, which are typically wrapped at 80 chars. Anything not presentable in standard ASCII will be uuencoded in base64.
    Besides LDIF, there is also format based on the XML standard called ____. It seems to be seldom used.
    < !--
    Additional example of ldif file for various objects can be found at: http://docs.sun.com/app/docs/doc/816-4556/6maort2ro?a=view


    Fedora Directory Server is the open source version of RedHat Directory Server.
    The RH DS came from the Netscape Directory Server (6.1). The Netscape DS was also developed by Sun and branded as iPlanet DS and later Sun ONE DS. HP also repackage the Netscape/Red Hat DSwith their LDAP-UX. Thus, these products are largely the same.

    GUI Console

    Fedora DS has a Graphical Console. There is two piece to it, an app/web server that typically configured to listen on port 5555, which can be started as:
    cd /opt/fedora-ds
    And a client part. A web browser can point to http://ldapsvr:5555/ and get lightweight ldap server queries, or use the full featured java client which get started as: cd /opt/fedora-ds
    The GUI console can be used to perform admin task on the Directory Server configuration or for modifying data in the LDAP data tree. Below are several examples of adding objects in the "database" tab.

    Add Unix User

    Right click on the People OU, click new, user. For Unix user, check on the Posix Account entry. Furthermore, go to advance attributes and add the "shadowAccount" attribute.

    Add Unix Group

    Right click on the Groups OU, click new, other object, posix group.

    Add Automount Map

    automount map is for defining an entirely new set of automount entries, such as /import, /products, etc.
    Here is an example for defining automount maps in LDAP for the first time, adding a auto.master, auto_master and finally a sample indirect map for /nfshome . Pay special attention to dot(.) vs underscore(_) below.

      Defining auto.master (master map used by Linux, AIX and HP-UX?)
    1. Right click on the desired OU where the automount map should be added (eg, ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com)
    2. Click new, other object, automountMap
    3. Enter "auto.master" in the automountMapName field.
    4. Then, inside this newly created auto.master object, right click, new, other object, automount
    5. In the automountInformation field, enter info like "ldap:automountMapName=auto_nfshome,ou=sc,ou=ca,ou=na,dc=hybridauto,dc=com"
    6. In the automountkey field, enter "/nfshome"

      Defining auto_master (master map used by Solaris?)
    7. Right click on the desired OU, as in step 1 above
    8. Click new, other object, automountMap
    9. Enter "auto_master" in the automountMapName field.
    10. Then, inside this newly created auto_master object, right click, new, other object, automount
    11. In the automountInformation field, enter info like "auto_nfshome"
    12. In the automountkey field, enter "/nfshome"

      Defining auto_nfshome (indirect map used by all systems)
    13. Right click on the desired OU, as in step 1 above
    14. Click new, other object, automountMap
    15. Enter "auto_nfshome" in the automountMapName field.
    16. Entries in auto_nfshome will be added in the section below "Add Automount Entry".
    The info can be verified by using ldapsearch and compare it against the ldif used in the ldapadd section above.

    Add Automount Entry

    Sample automount entries would be the various user's home dir that are defined under /home. Thus, /nfshome/tin with content of nfssvr:/export/home/tin would be one automount entry.
    For user home directory that need atuomount entry to define which server to use for the actual mount, To add a new entry:
    1. right click on the desired automount map (eg auto_nfshome)
    2. click new, other object, automount.
    3. Enter the mount key into the automountKey field
    4. Enter mount path info and mount option into the automountInformation field

    Change Default Posix (Unix) Password Encryption

    When creating unix user account using the GUI console, the password strings need to be encrypted in the same method that client OS expectes them to. While newer OS can support MD5 or SSHA, CRYPT is still the universal standard. Thus, it is best to set the console to encrypt user password using CRYPT by default. Solaris NIS use CRYPT by default.

    Method 1 - What Red Hat consultant told me and I know it works:
    1. Go to the Directory tab
    2. Click on the config node in the tree, right click, select advance properties (in a nutshell, we are editing the properties for the node cn=config.
    3. Scroll to the bottom where the attribute "passwordStorageScheme" is listed. By default, it says SSHA. Change it to say "CRYPT"
    Method 2 - What is described by the Admin Guide:
    1. Go to Config tab,
    2. Data node in the LDAP tree.
    3. On right side, go to Password tab. Toward the bottom, it has option to choose password encryption policy. The default is SSHA, change it to CRYPT.

    To verify that default password is created using CRYPT, perform a password change on a test user, then perform ldapsearch on this user using the cn=Directory Manager credentials. Encryption method is prefixed as {CRYPT} or {SSHA}.

    Backing up DB

    /opt/fedora-ds/slapd-SVR/db2bak		# run the backup
    /opt/fedora-ds/slapd-SVR/bak/DATE/	# dir where the files are stored (mostly Berkeley DB files)


    Some fields are not indexed by default, and when used as a NIS replacement, having these indexes would greatly improve performance.
    To create indexes,
    1. Go to config tab
    2. Click on "data" on the ldap tree
    3. Expand to the desired database container config, indexes tab should appear on right
    4. Click on attribute, and select the attribute that should be added to the index.
    5. Typically, equality is the box that need to be checked for indexing to be performed on.
    The above steps need to be done on each LDAP server, on each database repository (eg when different domains/OU use different database backend).

    Replication Conflicts

    Records from replications with conflicts are marked by nsds5ReplConflict. If the conflicts are specific to a single domain (and espcially in a dedicated consumer), the easiest way to remove them is to "Initialize the Consumer" from the Replication Config.

    Otherwise, refers to http://www.redhat.com/docs/manuals/dir-server/ag/7.1/replicat.html#1106141

    Replication Agreement

    Example of setting up a new server for a new domain, and adding replication.
    Step# Central Master Server (eg ldap1) Local Replica (new server, eg ldap3)
    I. Setup Directory Server Admin metadata
    0   Run ./setup to configure the directory server.
    Enable "Change Log", db dir = /opt/redhat-ds/slapd-ldap*/changelogdb/ (owned by nobody:nobody, chmod 755)
    restart slapd
    1   Create user "uid=replication manager" under "cn=config" (in Directory tab)
    2   Remove unecessary data from the directory tree (eg: People, Group, Special users)
    3   For replication, userRoot, ensure to
  • check "Enable Replica"
  • uid=replication manager,cn=config
  • dedicated consumer
  • 4

    Replicate "userRoot" data to the new server

    This will setup the root dc=hybridauto,dc=com to the new remote server.

    II. Replicate existing domain/database to new server
    5   In config tab, create databases matching all desired subsuffices for the data/domain that wish to be made available in this new server
    6   Check to ensure all subsuffix for db defined above exist, they should have been replicated from Part I.
    7   Enable replication (on Local Replica, this would typically be dedicated consumer, so read-only).
    8 Add replication agreement for each database/domain defined in step 5.  
    III. Setting up new domain, getting data to new server
    9 In config tab, create new subsuffix with db for it. eg, create ou=seattle,ou=on,ou=na,dc=hybridauto,dc=com  
    10 In database tab, create a matching subsuffix  
    11 Enable replication. (On Central Master Server and Backup Master Server, this would need to be a "multi-master" replicatoin)  
    12   In config tab, create subsuffix matching that created in step 9, create the db with it to store the data locally
    13   In database tab, create ou matching above (may not really need to create this manually)
    14   Assign a unique replication id to this machine to use (if servers are numbered sequentially, this is a good number to use).
    15   Enable replication (It maybe desirable to setup the Local Replica to act as Local Master for this domain that host local user, as such, the replication would be a "multi-master", and not dedicated consumer.
    IV. Setup Replication agreement
    16 In config tab, replicatin branch in the tree:
  • centralServer-seattle, new agreement: SE-central2se
  • consumer is ldap3:389
  • simple auth, uid=replication manager, cn=config (created in step 1, enabled for writing in step 3)
  • Do NOT initialize consumer (at this time).
    17   In config tab, replication branch of the tree, create a "back-fill" replication from the local master back to central master, db name: localMaster-seattle:
  • right click and add a new replication agreement.
  • call it SE-SE2central
  • consumer: ldap1:389 (central master server)
  • Do NOT initialize conumer
  • 18

    Tail the error log (slapd-ldap1/logs/error).
    Initialize consumer.

    V. Replication with Backup Master - repleat stage IV, adjust as:
    19 (step 16): name replication agreement as SE-backup2se, multi-master replication  
    20   (step 17) name for replication:
  • localMaster-SE
  • SE-SE2backup

  • When defining the replication agreements, for database that need multi-master, it maybe best to select such type of replication from the beginning. This is because the GUI console is rather buggy, and it has a tendency to put in a random number if the replication is first setup as dedicated consumer. If error happens, it is probaby best to blow away the replication agreement and redo it. For those really brave, the slapd server can be shut down and edit the dse.ldif file manually :) It was actually possible to define the replication agreement as ldif file that one just paste into the dse.ldif, but I don't konw the details.

    Other things to remember when setting up additional server:
  • Copy custom schemas into the schema directory and restart the DS. /opt/redhat-ds/slapd-*/config/schema, typically starts with number 61 thru 98.
  • Uniqueness plugin, either thru ldif import or set them up manually on the GUI console.
  • Tail the error logs when doing replicaiton test. Sometime console reports status as good but when in fact error log shows replication problems.
  • Ensure each server is assigned a uniq replicaiton id. Last octet(s) of the server IP address may work. Naming the servers with numerical sequence and using that number may also be a good idea.
  • Perform any server-specific changes to each machine, eg change password encryption from default SSHA to the more compatible CRYPT.

    Server Transfer

    If there is ever a need to migrate the RedHat Directory Server from one physical server to another, here is one possible method. This method assumes that you have at least one other server that can pick up all the workload, or downtime is acceptable.
    1. Stop slapd
    2. Create a tar of the whole /opt/fedora-ds
    3. Transfer this tar to the new server
    4. Untar into /opt/fedora-ds (rename the existing dir if the fedora rpm has already been added)
    5. Shutdown or otherwise network disconnect the old ldap server
    6. Configure the new LDAP server to have hostname (and optionally IP) of the old server
    7. Start slapd on the new server

    LDAP Client Config and Troubleshooting


    Config files:
  • /etc/pam.conf
  • /etc/nsswitch.conf
    /etc/init.d/ldap.client stop		# restart ldap client bind process
    /etc/init.d/ldap.client start
    svcadm enable network/ldap/client	# solaris 10
    /usr/lib/ldap/ldap_cachemgr -g 		# generate a new cache, display status
    /etc/init.d/nscd stop			# restart name service daemon
    /etc/init.d/nscd start


    Solaris support the ldaplist command that does the equivalent of ypcat in the NIS world. It is easier than ldapsearch in the sense that it will use the BASEDN and ldapserver that is already configured for a given ldap client machine. If ldaplist work, then the client is correctly configured to talk to the ldap server (whereas ldapsearch just means the ldap server is reachable). It is probably tuned to work with the Sun One Directory Server, but many specific queries will work with RedHat/Fedora DS also.
    Also, command works better when ldapclient init is used, rather than hacking the machine to work by copying files to /var/ldap.
    ldaplist    passwd "*"		# list all user, equiv of ypcat passwd
    ldaplist -l passwd tin		# display detailed info about user tin
    ldaplist -l group  \*		# list all groups and their members
    ldaplist    auto_master  \*	# list master automount info, like ypcat -k auto.master
    ldaplist -l auto_nfshome tin	# give specific details for /nfshome/tin
    ldaplist -l aliases root	# find out email alias definition for user root


    AIX as LDAP client

    Config and Test Commands
    mksecldap -c -h ldap03.hybridauto.com -a "cn=Directory Manager" -p bigsecret -d "dc=hybridauto,dc=com" -u NONE
    ## Bind as Directory Manager, kinda bad.  
    ## Some older sys password is in clear text in teh ldap.cfg file!!
    mksecldap -c -h ldap03.hybridauto.com -a "cn=proxyagent,ou=profile,dc=hybridauto,dc=com" -p secret -A ldap_auth -d "dc=hybridauto,dc=com" -u NONE
    ## Works for AIX 5.3 with ML 3 patches, bind for authorization only, using
    ## proxyagent  (which is just a normal People OU in the profile OU).
    ## One can edit the ldap.cfg file and remove the user and password for
    ## anonymous bind.
    lsuser -R LDAP tin	# see if user "tin" is defined in LDAP
    			# AIX command, in /usr/sbin
    ls-secldapclntd		# check status of ldap connectivity, in /usr/sbin
    Config Files
  • /etc/security/user
  • /etc/security/ldap/ldap.cfg
  • /etc/irs.conf
    1. Update needed if using PADL nss_ldap module.
    2. No changes needed in AIX 5.3, and there should be no clause for automount if it is to query LDAP for the maps (stating that it should query from LDAP makes it fail!)
  • /usr/lib/security/methods.cfg. LDAP clause need to be present, added by ldap.client.rte
  • /etc/pam.conf (no changes are typically required)
  • /etc/inittab has extra clause for ldap:
    ldapclntd:2:once: /usr/sbin/secldapclntd > /dev/console 2>&1
    Any service that depends on ldap user auth need to be placed below this line (eg Clear Case, custom rc script that start services using LDAP user credentials)
  • /etc/profile, /etc/csh.cshrc:
    $AUTHSTATE (env variable: LDAP, compat, files. It define default, first method for UID resolution)

  • /etc/security/user config details
    the "default" clause should say something like:
    	SYSTEM = "LDAP or compat or DCE"
    This would allow local user account to be checked. If the order is "compat or LDAP", ldap user who telnet in will see a small error message about "invalid login name or password" and then move on to LDAP and log the user right in (assuming currect pam.conf). If the order is "LDAP or compat", then somehow local user can still login even if there is matching USERNAME on LDAP with /bin/false for shell. IBM doc says DCE is used for X windows login, but seems to work w/o it anyway.
    Lastly, if somehow local user still doesn't work, then a specific clause for the user need to be added, one that looks similar to the entry for the root user. Either run commands like:
    chuser SYSTEM=compat db2inst8
    chuser SYSTEM=compat registry=files db2inst8
    (registry deal with where the password is stored. For LDAP, it would be "registry=LDAP"). Alternatively, one can edit the file manually. Final config should look like:
    	SYSTEM = "compat"

    IBM claims that the extension, RFC2307AIX, provides additional support for AIX 5.2 onward. It was supopsed to be a transparent addition that does not affect other clients that do not use such feature. The ldif file for schema update is provided on AIX machines at /etc/security/ldap/nisSchema.ldif . This extra support is not required, but provides AIX with additional user tracking support.


    anonymous bind works if server allows it, proxyagent bind wilL need to put password 
    in a separate file 600 root and contain password in clear text.
    /etc/sysconfig/autofs, define BASEDN so that it will locate the correct auto*master 
    autofs rpm version at least 4.1.3-174 need to be available to support maps retrieval thru LDAP.


    Config files:
    /etc/opt/ldapux/ldapclientd.conf	# LDAP-UX daemon config file
    /etc/pam.conf 		# can use pam.ldap as template
    Config commands:
    swlist -l product | grep -i ldapux
    # Ensure that ldapux package is installed.  
    # Need at least version B.03.30...
    cd /opt/ldapux/config
    # this is the main config for the ldap-ux module
    # to configure HP-UX to use ldap for user authentication
    # it is an interactive program
    # will ask ldap server name, port, and 
    # the hpux/ldapux profile dn path/location
    cd /opt/ldapux/config
    ./ldap_proxy_config -i
    # configure ldapux to use a proxyagent
    # the two lines after the command are entered after the command is issued
    # there is no prompt, just enter "username" and password, 
    # one line at a time, and then the command prompt will return
    ./ldap_proxy_config -p
    # print out the config setup above
    ./ldap_proxy_config -v
    # verify proxy agent config, should return "verified - valid"
    swlist -l product | grep -i auto
    # Ensure Enhanced Autofs is installed
    # Need at least version ...


    These are commands available in most OS, unless otherwise specified.
    id -a tin		# see id of user (all platform, but diff flags)
    getent  		# get entries from administrative database as def by nsswitch.conf
    	  		# avalable on solaris, linux, hp-ux.
            		# But there is NO service that look up automount maps :(
    getent passwd		# equiv of cat /etc/passwd, but retrieving the content from whatver nsswitch has configured .
    			# multiple source will be queried and result combined 
    getent shadow		# typically return blank.  encrypted pw not provided.
    getent passwd tin    	# see if user tin is recognized
    			# similar to ypcat passwd | grep tin
    			# but would work against LDAP source.
    getent group
    getent group wheel	#  
    getent hosts		# get list of hosts , but don't retrieve from DNS.  think cat /etc/hosts
    perl -e "print crypt('clear-text-password','salt');"
    			# generate the CRYPT encrypted version of the string
    			# clear-text-password usnig the first two letter as
    			# the salt to seed the encryption.
    			# CRYPT is the default password encrypting scheme
    			# for solaris /etc/shadow and many other unices.
    			# {CRYPT}encrypted entry can be used in ldif file
    			# for password import into LDAP POSIX User account.



    Red Hat



    [Doc URL]
    (cc) Tin Ho. See main page for copyright info.