View source for LDAP

Clients on the network use LDAP to authenticate user logins.  We are running an LDAP server on Einstein. This server serves up the user information (passwd and shadow) and also lists of servers and workstations which tie into various permission schemes.
== Organization ==
LDAP runs on einstein. For passwords and such it is protected with TSL encryption. (See [[Certificates]].) The certificate is valid for einstein.unh.edu and einstein.farm.physics.unh.edu.  The service program ''slapd'' handles requests from clients.
== Configuration ==
For clients, configuration for LDAP is in '''two locations''': ''/etc/ldap.conf'' and ''/etc/openldap/ldap.conf''. Here you set the host(s) that is serving the information.  Specifically, einstein.unh.edu or einstein.farm.physics.unh.  Also, ldap must be referenced in ''/etc/nsswitch.conf'' like so:
<pre>passwd:     files ldap
shadow:     files ldap
group:      files ldap</pre>
Those '''may not''' be the only entries requiring a reference to ldap, but the GUI tool ''system-config-authentication'' is good at taking care of things.  If a machine doesn't have that program, it's safe to look at another machine's files.

Once a user is authenticated, the client mounts the user's home directory.  See [[Automount]].

== Troubleshooting ==
The best way to check whether LDAP is working is <code>getent passwd</code>, which should show user passwords. If it does not work, then <code>env HOME=/root ldapsearch -ZZ '(uid=someusername)'</code> may give more diagnostics. Try <code>ldapsearch -x '(uid=someusername)'</code> to test LDAP without using the encryption layer.

If your node has a bad system time, the certificate may look like it is from the future and will not be accepted. So check system time if users cannot log in.

Another thing to check is if the client is able to connect to the LDAP server, and that the server is referenced in the appropriate configuration files.

If LDAP isn't configured properly, or the machine cannot reach the LDAP server, then the machine may experience a very long boot time (usually hanging during "Starting system message bus...").

== Administration ==
Administrators can use the programs ''/usr/sbin/luseradd'', ''/usr/sbin/luserdel'', and ''/usr/sbin/lusermod'' to add, delete, and modify users from the directory. There is also a more-friendly(??) program for adding users: ''/usr/local/bin/adduser-npg'', however it requires that the above programs and more be accessible via the PATH environmental variable (root has the appropriate path set up, but ''sudo'' won't use it). When running any of these programs, it is important that the HOME environment variable is set to "/root". Best way to use them is: "env HOME=/root /usr/local/bin/adduser-npg". 

There appears to be a problem with the libuser stuff in that a new user is added with objectClass of "posixUser" and "account", and you cannot (as far as I (Maurik) could figure out) change "account" to "person". The "account" has a mandatory field for "userid" which is redundant with "uid" and actually gets translated to "uid" when you add something there (in JXplorer). The result is that you cannot modify anything in the account, since you must have something for "userid" which must be different from "uid". See below for the difficult way of changing user info, which works.

[http://tools.ietf.org/html/rfc4519 Standard defining things like dn, cn, ou, and object classes]

== What is needed for a succesful login? ==

* Entry in ldap tables or /etc/password and /etc/shadow
* Be in the correct group. Which group is correct is controlled by [[PAM]] in /etc/security/access.conf

== External Information ==
* <strike>[http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/ref-guide/s1-ldap-pam.html  Setup information]</strike>
* [http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Deployment_Guide-en-US/ch-ldap.html Documentation for RHEL 5]
* [http://www.openldap.org/doc/admin23/ OpenLDAP Software 2.3 Administrator's Guide] 
* [http://www.openldap.org/faq/data/cache/1.html  OpenLDAP Faq-O-Matic]

== Some Useful LDAP Hints ==

* Add a user account: Use '''env HOME=/root  /user/local/bin/adduser-npg'''
* You can look at and manipulate the tables with JXplorer (installed on improv). Login as root with the standard password for ldap.
* <font color="red" size=+1>'''Be careful: slapcat, slapadd etc commands can only be run when slapd is NOT running''' </font> Can be used to dump and restore the entire ldap database.
* Modify user items (i.e. shell, home, uid, gid) '''env HOME=/root /usr/sbin/lusermod --shell /bin/false minuti'''
* Add a user to a group:  '''env HOME=/root /usr/sbin/lgroupmod --member-add uid group'''

We've got to do something about needing the "env HOME=/root" stuff to get those scripts to work properly.  The representation of the programs used in a script shouldn't be dependent on a certain user's PATH variable.  It's already annoying enough when we've got a bunch of scripts that are dependent on a bunch of non-default programs, and the only ways to find out what they are is to pour over the entire source code, or try to run the script over and over, seeing what program it fails to find each time, hoping that what did run didn't mess the system up.