Warning Livedoc is no longer being updated and will be deprecated shortly. Please refer to https://documentation.tjhsst.edu.

Difference between revisions of "NSS LDAP"

From Livedoc - The Documentation Repository
Jump to: navigation, search
m (Administration/Management)
m (See Also: categorize)
 
(18 intermediate revisions by 4 users not shown)
Line 1: Line 1:
LDAP is used to store NSS (Name Service Switch) information for the UNIX passwd and group databases.  All information about network users, such as UNIX uid/gid, home directory, shell, and other group membership is handled through NSS.
+
LDAP is the system currently used to store NSS (Name Service Switch) information for the UNIX passwd and group databases.  It serves as a centralized supplement/replacement for the information stored in /etc/passwd and /etc/group including usernames, uids, homedirectory locations, group memberships, and login shells.
  
=History=
+
==History==
 
Previously, the CSL used [[NIS]] to store network user information.  However, when the decision was made to integrate CSL accounts and authentication with Windows Active Directory (previously all CSL accounts were managed separately and required an application form to receive), LDAP was chosen to replace NIS as the backend for the NSS database.
 
Previously, the CSL used [[NIS]] to store network user information.  However, when the decision was made to integrate CSL accounts and authentication with Windows Active Directory (previously all CSL accounts were managed separately and required an application form to receive), LDAP was chosen to replace NIS as the backend for the NSS database.
  
Line 8: Line 8:
 
During the winter of 2007-08, NSS was switched back to LDAP following various discussions.  ''(Need more information.)''  LDAP was configured on [[chuku]] and [[mihr]], running Sun Directory Server 6.
 
During the winter of 2007-08, NSS was switched back to LDAP following various discussions.  ''(Need more information.)''  LDAP was configured on [[chuku]] and [[mihr]], running Sun Directory Server 6.
  
=Current=
+
Upon reception of the [[Sun Academic Excellence Grant (AEG)| Sun Academic Excellence Grant]], LDAP was moved into the [[LDOM]]s ldap1 and ldap2 running on [[Ohare]] and [[Logan]].
NSS LDAP is currently used by nearly all *NIX systems managed by the CSL.  It is running in [[LDOM]]s [[ldap1]] and [[ldap2]].
 
  
=Configuring LDAP on clients=
+
==Current==
==Linux==
+
NSS LDAP is currently used by nearly all *NIX systems managed by the CSL (noteable exceptions are the mailservers [[Casey]] and [[Smith]]It is run using OpenLDAP from the VMs [[openldap1]] and [[openldap2]].
*libnss-ldap (or similar) needs to be installed.
 
*Edit /etc/libnss-ldap.conf:
 
**Setup LDAP servers 198.38.16.59:388, 198.38.16.12:388, and 198.38.16.13:388.
 
**Use search base: dc=csl,dc=tjhsst,dc=edu.
 
**Set bind_timelimit to 2
 
**Set bind_policy to soft
 
**Set nss_base_passwd to <code>ou=people,</code>
 
**Set nss_base_group to <code>ou=group,</code>
 
*Edit /etc/nsswitch.conf to use "files ldap" for the passwd and group databases.  The two lines should look like this:
 
<nowiki>
 
passwd:    files ldap
 
group:      files ldap</nowiki>
 
*You may need to restart nscd.
 
==Solaris==
 
'''WARNING:''' There was at least one point in the history of Sun Directory Server where setting up the LDAP client on the LDAP server was not supported because the client was started before the server was, causing a halt in system boot because of a failure to initialize the client.  I'm not sure if this is still the case, but if it is, you will need an init script to disable the client in SMF until the server starts, and then restart the client after the server starts.  In the CSL, this is easily done by installing the STJinitd-sunds package.
 
*Run the following command:
 
<nowiki>
 
/usr/sbin/ldapclient manual -a credentialLevel=anonymous \
 
-a defaultSearchBase="dc=csl,dc=tjhsst,dc=edu" \
 
-a defaultSearchScope=sub \
 
-a defaultServerList="198.38.16.12:388 198.38.16.13:388" \
 
-a followReferrals="TRUE" \
 
-a preferredServerList="198.38.16.59:388" \
 
-a serviceSearchDescriptor=passwd:ou=people,dc=csl,dc=tjhsst,dc=edu \
 
-a serviceSearchDescriptor=group:ou=group,dc=csl,dc=tjhsst,dc=edu</nowiki>
 
*On most CSL systems: You are done.
 
*On stock Solaris systems (and possibly some CSL systems):
 
**The ldapclient command has installed an nsswitch.conf that assumes you use LDAP for everything.  And I mean EVERYTHING.  But that's rarely the case anywhere.  So <code>cp /etc/nsswitch.dns /etc/nsswitch.conf</code>.  Then edit /etc/nsswitch.conf to use "files ldap" for passwd and groupSee Linux section above for sample of what this will look like.
 
**<code>pkill nscd</code> to restart it (Solaris 10), or restart it some other way.
 
==Admin-only access==
 
Follow the above directions, but wherever you see an <code>ou=people</code>, replace it with an <code>ou=sysadmins</code>.  Only sysadmins with LDAP entries in ou=sysadmins will be able to access that system.  Note that additional access control can, and is often, managed by using hostname groups (i.e. the LDAP POSIX group named after the hostname of the system).  This is currently not done on Solaris systems, but is done on most Linux systems.
 
  
=LDAP Server Software=
+
==LDAP Server Software==
Both of the below applications are part of [[Sun Java System Directory Server]] Enterprise Edition 6.
+
OpenLDAP's slapd is currently run in one-way replication on openldap1 (master) and openldap2.  It can integrate with nsswitch to provide all NSS databases although we currently only use it for the passwd and group databases.  For detailed installation and configuration notes, see [[OpenLDAP]].
  
NOTE: If the database needs to be rebuilt from scratch and data reloaded from LDIF dumps, you may need to get Identity Synchronization to "prepare" Directory Server as it needs to modify the schema with new object classes and attribute types.
+
===Service IP Caveats===
==Sun Java System Directory Server==
+
The service IP for NSS LDAP is 198.38.16.59 (ldap-sun.tjhsst.edu is the hostname; it remains what it is for historical reasons). Note that neither openldap1 nor openldap2 will automatically grab this IP at boot.  This IP must be manually added.  This is so that the IP can be moved during maintenance; for example, if openldap1 is down for maintenance, the IP is moved to openldap2 so correctly configured clients will query openldap2 instead. If openldap1 is rebooted as part of maintenance, it will not also snag the IP as it comes up and cause a network service conflict.
*Sun's implementation of an LDAP server.
 
*Can fully integrate with nsswitch for all NSS databases (currently only using passwd and group).
 
*Currently running in one-way replication on [[ldap1]] (master) and [[ldap2]].
 
*For installation and configuration notes, see [[Sun Java System Directory Server]].
 
  
==Sun Java System Identity Synchronization for Windows==
+
In the event that there is a complete power outage and both systems are rebooted, obviously the IP will not be assigned to either of them at bootCorrectly configured clients will not be impacted as they will rapidly timeout 198.38.16.59 and fall back on openldap1 and openldap2 IP addresses.
*Connects and synchronizes users from Active Directory to Sun Directory Server and maps specified attributes (currently only one-way from AD to Sun).
 
*User creation, attribute modification, and account lockout is synchronized.  User deletions are not enabled since we want to preserve users' NSS entries for all time.
 
*Note that this software is pretty old and sometimes gets finicky, needing a reinstall or other strange fixesWhen running the installer, use the GUI installer and not the text-mode as there are some things that aren't fully implemented in the text-mode installer that will later cause many headaches.
 
===Attribute Mappings===
 
{| border=1 cellpadding=4 cellspacing=0 style="margin: 0 0 1em 1em; background: #f9f9f9; border: 1px #aaaaaa solid; border-collapse: collapse; font-size: 95%; text-align:left;"
 
|-
 
! width="100px" | Description || Active Directory || Sun LDAP
 
|-
 
! Username || samAccountName || uid
 
|-
 
! Password (hashed) || unicodepwd || userpassword
 
|-
 
! First name || givenname || givenname
 
|-
 
! Surname || sn || sn
 
|-
 
! Full Name || cn || cn
 
|-
 
! Display Name || displayName || displayName
 
|-
 
! Description (grad year for current students) || description || description
 
|}
 
  
=Directory Structure=
+
==Directory Structure==
 
*Everything below is relative to a root dn of dc=csl,dc=tjhsst,dc=edu.
 
*Everything below is relative to a root dn of dc=csl,dc=tjhsst,dc=edu.
*The subtree ou=Services and entry uid=PSWConnector are used by Identity Synchronization.  Please do not touch those entries.
 
 
*Groups are referenced by cn (i.e. cn=allaccess,ou=group,dc=csl,dc=tjhsst,dc=edu).  Users are referenced by uid (i.e. uid=wyang,ou=2008,ou=students,ou=people,dc=csl,dc=tjhsst,dc=edu).
 
*Groups are referenced by cn (i.e. cn=allaccess,ou=group,dc=csl,dc=tjhsst,dc=edu).  Users are referenced by uid (i.e. uid=wyang,ou=2008,ou=students,ou=people,dc=csl,dc=tjhsst,dc=edu).
==ou=group==
+
===ou=group===
 
This subtree contains POSIX groups.  Currently we have 3 major classes of groups:
 
This subtree contains POSIX groups.  Currently we have 3 major classes of groups:
 
*'''Primary''': Each LDAP user's default group is one of these.  There are a few subclasses:
 
*'''Primary''': Each LDAP user's default group is one of these.  There are a few subclasses:
Line 89: Line 30:
 
**''"Adult" users'': Staff members are assigned to group "faculty" with gidnumber 1984.  Separating parents/external users into a separate group would be advisable, but they presently share the "faculty" group.  
 
**''"Adult" users'': Staff members are assigned to group "faculty" with gidnumber 1984.  Separating parents/external users into a separate group would be advisable, but they presently share the "faculty" group.  
 
**''"users"'': This is presently used for all LDAP user entries in the ou=sysadmins subtree (see below).
 
**''"users"'': This is presently used for all LDAP user entries in the ou=sysadmins subtree (see below).
*'''Host/VM access control''': Each of these groups (gid starting at 1000) has the hostname of the system that it is designed to control access for.  The group has a list of users that should be granted login access to that system; however, some of the systems listed may not necessarily have group control implemented, rendering the LDAP group's membership moot.  The group is not used to grant root access on a system; that is controlled independent of LDAP at this time.  The members of the "allaccess"  group (gid 1337) are grant login access on all systems that have the LDAP group access control scheme configured.
+
*'''Host/VM access control''': Each of these groups (gid starting at 1000) has the hostname of the system that it is designed to control access for.  The group has a list of users that should be granted login access to that system; however, some of the systems listed may not necessarily have group control implemented, rendering the LDAP group's membership moot.  The group is not used to grant root access on a system; that is controlled independent of LDAP at this time.  The members of the "allaccess"  group (gid 1337) are granted login access on all systems that have the LDAP group access control scheme configured.
 
*'''System/service groups''': These are primarily used by the Solaris systems, but can also be used by others.  It is sometimes easier to ensure that any particular group used by a system service will have the same ID across multiple systems by adding it to LDAP, hence the existence of this class of groups.  These have gids starting at 5000.
 
*'''System/service groups''': These are primarily used by the Solaris systems, but can also be used by others.  It is sometimes easier to ensure that any particular group used by a system service will have the same ID across multiple systems by adding it to LDAP, hence the existence of this class of groups.  These have gids starting at 5000.
There are some miscellaneous groups scattered in there.  For instance, "commons_mm" (gid 8000) is the primary group for all music card users.
+
There are some miscellaneous groups scattered in there.  For instance, "commons_mm" (gid 8000) is the primary group for all music cart users.
  
==ou=people==
+
===ou=people===
 
This is the subtree used for the NSS passwd database on all general use systems.  It is itself made up of several more sub-ous.  The major ones are listed below.  Others may be created as needed (for example, the josti2008 ou contains temporary users that were created for a JOSTI 2008 interactive user experience in one particular presentation; although the users are still in LDAP, they cannot login because their Kerberos credentials are expired).
 
This is the subtree used for the NSS passwd database on all general use systems.  It is itself made up of several more sub-ous.  The major ones are listed below.  Others may be created as needed (for example, the josti2008 ou contains temporary users that were created for a JOSTI 2008 interactive user experience in one particular presentation; although the users are still in LDAP, they cannot login because their Kerberos credentials are expired).
===ou=legacy===
+
====ou=legacy====
 
Most NIS users were loaded into this ou so legacy accounts could still have their uids looked up, and previous admins that retained their Kerberos accounts can still log in.  Some NIS users were not imported because their username already existed in one of the other ous.
 
Most NIS users were loaded into this ou so legacy accounts could still have their uids looked up, and previous admins that retained their Kerberos accounts can still log in.  Some NIS users were not imported because their username already existed in one of the other ous.
===ou=parents===
+
====ou=parents====
 
Parents that have login access for website editing or for whatever other purpose go here.  Some parents may actually be in ou=legacy if they were created during the NIS era.
 
Parents that have login access for website editing or for whatever other purpose go here.  Some parents may actually be in ou=legacy if they were created during the NIS era.
===ou=special===
+
====ou=special====
This contains things that don't belong in any other category.  Some system service users go here (see "System/service groups" in the ou=group section above for why we do this).  Music card users also go here, although they could also have their own ou since there seem to be enough of them nowadays.
+
This contains things that don't belong in any other category.  Some system service users go here (see "System/service groups" in the ou=group section above for why we do this).  Music cart users also go here, although they could also have their own ou since there seem to be enough of them nowadays.
 
*'''IMPORTANT:''' Most users that are added here should also be added to the ou=special in ou=sysadmins (see below).
 
*'''IMPORTANT:''' Most users that are added here should also be added to the ou=special in ou=sysadmins (see below).
===ou=staff===
+
 
 +
====ou=staff====
 
Well yes...faculty and staff have their own ou.  Naturally.
 
Well yes...faculty and staff have their own ou.  Naturally.
===ou=students===
+
====ou=students====
No student users go directly in here; they go into another subou under this ou by graduation year first.  At time of writing, ous exist for 2006 through 2050 (most of these latter ones are empty).
+
No student users go directly in here; they go into another subou under this ou by graduation year first.  At time of writing, ous exist for 2006 through 2017.
  
==ou=sysadmins==
+
===ou=sysadmins===
 
This contains...well...sysadmins.  The distinction from ou=people is primarily for access control on non-general-use servers.
 
This contains...well...sysadmins.  The distinction from ou=people is primarily for access control on non-general-use servers.
===ou=special===
+
====ou=special====
 
This is basically a copy of ou=special from above.  The difference is that non-general-use servers are configured to see this ou=special, while general-use systems see the one in ou=people.  For example, it is important to have the music card users here and above since music card users are logged in to on a general use system, but the NFS server, which is non-general use, also needs to be able to look up the username and uid.
 
This is basically a copy of ou=special from above.  The difference is that non-general-use servers are configured to see this ou=special, while general-use systems see the one in ou=people.  For example, it is important to have the music card users here and above since music card users are logged in to on a general use system, but the NFS server, which is non-general use, also needs to be able to look up the username and uid.
  
=Administration/Management=
+
==Configuring LDAP on clients==
See [[Sun Java System Directory Server]] for general ways to administer Sun Directory Server.
+
===Gentoo===
==Scripts==
+
*emerge nss_ldap. If you want to be able to manage LDAP from this system, make sure that the kerberos and sasl USE flags are enabled on both nss-ldap and openldap.
Currently there are a few bash scripts to help with administration. They are currently located on the Sun administrative volume in the "ds" directory.
+
*Edit /etc/ldap.conf:
 +
**Setup LDAP servers 198.38.16.59, 198.38.16.70, and 198.38.16.71.
 +
**Use search base: dc=csl,dc=tjhsst,dc=edu.
 +
**Set bind_timelimit to 2
 +
**Set bind_policy to soft
 +
**Set nss_base_passwd to <code>ou=people,</code>
 +
**Set nss_base_group to <code>ou=group,</code>
 +
*Edit /etc/nsswitch.conf to use "compat ldap" for the passwd and group databases.  The two lines should look like this:
 +
<nowiki>
 +
passwd:    compat ldap
 +
group:      compat ldap</nowiki>
 +
*You may need to restart nscd if it is installed.
  
===update_nssldap.sh===
+
===Centos 7===
This is the big oneWhile Identity Synchronization will create the new LDAP entries when new AD user objects are created, it doesn't know how to fill in all the POSIX values, such as uid and home directory.  So we have a script that can fill them in.  This script iterates on all accounts that do not have the posixAccount objectClass set yet.
+
*Install nss-pam-ldapd.
 +
*Add/Edit the following lines in /etc/nslcd.conf
 +
<code>
 +
uri ldap://openldap1.tjhsst.edu/
 +
uri ldap://openldap2.tjhsst.edu/
 +
base dc=csl,dc=tjhsst,dc=edu
 +
base  group ou=group,dc=csl,dc=tjhsst,dc=edu
 +
base  passwd ou=people,dc=csl,dc=tjhsst,dc=edu
 +
</code>
 +
*Execute the following command to reload the nslcd configuration:
 +
<code>
 +
systemctl enable nslcd
 +
systemctl restart nslcd
 +
</code>
 +
*Edit /etc/nsswitch.conf to use "compat ldap" for the passwd and group databases as described in the Gentoo section above.
  
This script must be run by someone with AFS admin.  It must be run on a system that has the AFS client and tools installed as it handles the AFS side of user-creation as wellIt currently must also be run on a system with both the Sun LDAP tools in /usr/bin and the OpenLDAP tools in /usr/local/binPerhaps someone should try and rewrite the script to only need one set of toolsCurrently it is recommended to run this script on [[arcturus]]The NSS LDAP Manager password will also be needed to gain admin-level access to LDAP.  (Again, maybe someone wants to implement GSSAPI or other binding mechanism that allows users to be admins without knowing the Manager password.)
+
===Solaris===
 +
'''WARNING:''' There was at least one point in the history of Sun Directory Server where setting up the LDAP client on the LDAP server was not supported because the client was started before the server was, causing a halt in system boot because of a failure to initialize the client.  I'm not sure if this is still the case, but if it is, you will need an init script to disable the client in SMF until the server starts, and then restart the client after the server starts.  In the CSL, this is easily done by installing the STJinitd-sunds package.
 +
*Run the following command:
 +
  <nowiki>
 +
/usr/sbin/ldapclient manual -a credentialLevel=anonymous \
 +
-a defaultSearchBase="dc=csl,dc=tjhsst,dc=edu" \
 +
-a defaultSearchScope=sub \
 +
-a defaultServerList="198.38.16.70 198.38.16.71" \
 +
-a followReferrals="TRUE" \
 +
-a preferredServerList="198.38.16.59" \
 +
-a serviceSearchDescriptor=passwd:ou=people,dc=csl,dc=tjhsst,dc=edu \
 +
-a serviceSearchDescriptor=group:ou=group,dc=csl,dc=tjhsst,dc=edu</nowiki>
 +
*On most CSL systems: You are done.
 +
*On stock Solaris systems (and possibly some CSL systems):
 +
**The ldapclient command has installed an nsswitch.conf that assumes you use LDAP for everything.  And I mean EVERYTHING.  But that's rarely the case anywhere.  So <code>cp /etc/nsswitch.dns /etc/nsswitch.conf</code>Then edit /etc/nsswitch.conf to use "files ldap" for passwd and groupSee Linux section above for sample of what this will look like.   
 +
**<code>pkill nscd</code> to restart it (Solaris 10), or restart it some other way.
 +
*NOTE: Solaris defaults tolibnss- using files instead of compat to reference the local password and group databases.  For more information on the differences between files and compat, you can run <code>info libc “Name Service Switch”</code> on a system with GNU info configured.
  
Should the active NSS LDAP database become lost or corrupted and no backups workable, requiring a rebuild from scratch, historical NSS data will be lostHowever, the update_nssldap.sh script knows how to retrieve user information from AFS using pts, so users and home directories will not be duplicated if they already exist in AFS.  This feature depends on usernames being unique for all time, which they should be by now.
+
===Admin-only access===
 +
Follow the above directions, but wherever you see an <code>ou=people</code>, replace it with an <code>ou=sysadmins</code>.  Only sysadmins with LDAP entries in ou=sysadmins will be able to access that systemNote that additional access control can, and is often, managed by using hostname groups (i.e. the LDAP POSIX group named after the hostname of the system).  This is currently not done on Solaris systems, but is done on most Linux systems.
  
Home directories are created from a skeleton found at /afs/csl.tjhsst.edu/service/skel. Adjust the afs_server and afs_vicep variables to control what server and partition new homedir volumes are created on. Some other variables may also be of interest, such as quota and host.
+
Note that if you are doing this, you will probably want to enable the pam_mkhomedir module to automatically create home directories the first time an admin logs in. This can be done by adding the following line to /etc/pam.d/system-auth on linux systems:
 +
<code>
 +
  session    optional      pam_mkhomedir.so
 +
</code>
 +
On Centos, this can also be done using authconfig:
 +
<code>
 +
authconfig --enablemkhomedir --update
 +
</code>
  
If the directory structure of AFS or LDAP ever changes for either students or staff, this script will need to be reviewed and updated, otherwise things will fail and/or get created in the wrong places!
+
==Administration/Management==
 +
Administration and management of NSS data is primarily accomplished through the LDAP command line utilities. In order to gain administrative access to NSS LDAP, four things are necessary:
  
===backup.sh===
+
*You must have an ou=sysadmins user entry (eg: uid=ahamilto,ou=sysadmins,dc=csl,dc=tjhsst,dc=edu)
The name says it all.  The database is dumped out in a dumps subdirectory.  Each backup operation creates 2 LDIFs, one for the data and another for ACIs.  Files are created with the format hostname.dumpYYYYMMDDHHmmss, with an ending of acis.ldif or .ldif, depending on the contents.
+
*You must have a Kerberos /admin principal (eg: ahamilto/admin)
 +
*The dn of your ou=sysadmins entry must be added as a member of cn=ldapadmins,dc=csl,dc=tjhsst,dc=edu
 +
*The ldap utilities on the system you are using must support SASL GSSAPI binding
  
This script may be run from any Solaris system that has the Sun LDAP client tools in /usr/bin.  Again, Manager access will be needed.  Dumps will be sent to the dumps directory in whatever your current working directory is; traditionally dumps have been kept in ds/dumps on the Sun admin volume.
+
Once you have the above four items, you can kinit to your /admin principal and use the standard LDAP command line utilities to make changes. For examples of various changes see [[NSS LDAP Templates]].
  
If the LDAP server changes, this script will need to be updated.
+
=See Also=
 +
*[[NSS LDAP Templates]] - Template LDIFs and commands for various NSS LDAP changes
 +
*[[OpenLDAP]] - Installation and configuration of the OpenLDAP Daemon (slapd)
 +
*[[Integrated Authentication]] - Information on the Integration Authentication between the LOCAL and CSL systems.
  
===group_manage.sh===
 
This script makes it easy to add users to groups.  It can be cumbersome to use for a lot of users, so you might find it easier to read the code and generate your own LDIF to import to the LDAP server if handling many users.  It does NOT create or delete groups, nor does it remove users from groups.  To perform those operations, the script will need to be written to do more, or you will need to use one of the two below methods.
 
  
This script may be run from any Solaris system that has the Sun LDAP client tools in /usr/bin.  Again, Manager access will be needed.  See update_nssldap.sh section for comment on using GSSAPI or other binding for other users to make changes to LDAP.  If that's implemented, group administration should be delegatable so, for instance, shodan's administrator can add users to the shodan group without being able to add users to the fiordland group.
+
[[Category:Production Service]]
 
+
[[Category:Current]]
If the LDAP server or directory structure changes, this script will need to be updated.
 
 
 
=See Also=
 
*[[LDAP]]
 
*[[Integrated Authentication]]
 
*[[Sun Java System Directory Server]]
 
*[[Sun Identity Synchronization for Windows]]
 

Latest revision as of 00:41, 27 February 2016

LDAP is the system currently used to store NSS (Name Service Switch) information for the UNIX passwd and group databases. It serves as a centralized supplement/replacement for the information stored in /etc/passwd and /etc/group including usernames, uids, homedirectory locations, group memberships, and login shells.

History

Previously, the CSL used NIS to store network user information. However, when the decision was made to integrate CSL accounts and authentication with Windows Active Directory (previously all CSL accounts were managed separately and required an application form to receive), LDAP was chosen to replace NIS as the backend for the NSS database.

Integrated authentication using LDAP and Kerberos was initially deployed in lab 231 during the spring of 2006. Sun Directory Server 5.2 was used at the time, replicated from sol across what are now known as chuku and ekhi. During the summer following, LDAP was moved into a VMWare virtual machine known as daystar in order to run LDAP on a faster system. However, for reasons not completely understood, the VM subsequently developed problems during the fall of 2006 and resulted in NSS becoming painfully slow on both rockhopper (at that time used for all of lab 231 and 16 LTSP nodes in the CSL) and the rest of the CSL workstations. In order to remedy the situation, /etc/passwd was rapidly deployed as a flatfile across all affected systems. Hesiod was subsequently set up as the NSS database for the remainder of the school year and the beginning of the next.

During the winter of 2007-08, NSS was switched back to LDAP following various discussions. (Need more information.) LDAP was configured on chuku and mihr, running Sun Directory Server 6.

Upon reception of the Sun Academic Excellence Grant, LDAP was moved into the LDOMs ldap1 and ldap2 running on Ohare and Logan.

Current

NSS LDAP is currently used by nearly all *NIX systems managed by the CSL (noteable exceptions are the mailservers Casey and Smith. It is run using OpenLDAP from the VMs openldap1 and openldap2.

LDAP Server Software

OpenLDAP's slapd is currently run in one-way replication on openldap1 (master) and openldap2. It can integrate with nsswitch to provide all NSS databases although we currently only use it for the passwd and group databases. For detailed installation and configuration notes, see OpenLDAP.

Service IP Caveats

The service IP for NSS LDAP is 198.38.16.59 (ldap-sun.tjhsst.edu is the hostname; it remains what it is for historical reasons). Note that neither openldap1 nor openldap2 will automatically grab this IP at boot. This IP must be manually added. This is so that the IP can be moved during maintenance; for example, if openldap1 is down for maintenance, the IP is moved to openldap2 so correctly configured clients will query openldap2 instead. If openldap1 is rebooted as part of maintenance, it will not also snag the IP as it comes up and cause a network service conflict.

In the event that there is a complete power outage and both systems are rebooted, obviously the IP will not be assigned to either of them at boot. Correctly configured clients will not be impacted as they will rapidly timeout 198.38.16.59 and fall back on openldap1 and openldap2 IP addresses.

Directory Structure

  • Everything below is relative to a root dn of dc=csl,dc=tjhsst,dc=edu.
  • Groups are referenced by cn (i.e. cn=allaccess,ou=group,dc=csl,dc=tjhsst,dc=edu). Users are referenced by uid (i.e. uid=wyang,ou=2008,ou=students,ou=people,dc=csl,dc=tjhsst,dc=edu).

ou=group

This subtree contains POSIX groups. Currently we have 3 major classes of groups:

  • Primary: Each LDAP user's default group is one of these. There are a few subclasses:
    • Students/graduation year: The name of each group is TJ and then a two digit year, except in the case of 2000, which has name TJ2K. The gidnumber is the four digit graduation year.
    • "Adult" users: Staff members are assigned to group "faculty" with gidnumber 1984. Separating parents/external users into a separate group would be advisable, but they presently share the "faculty" group.
    • "users": This is presently used for all LDAP user entries in the ou=sysadmins subtree (see below).
  • Host/VM access control: Each of these groups (gid starting at 1000) has the hostname of the system that it is designed to control access for. The group has a list of users that should be granted login access to that system; however, some of the systems listed may not necessarily have group control implemented, rendering the LDAP group's membership moot. The group is not used to grant root access on a system; that is controlled independent of LDAP at this time. The members of the "allaccess" group (gid 1337) are granted login access on all systems that have the LDAP group access control scheme configured.
  • System/service groups: These are primarily used by the Solaris systems, but can also be used by others. It is sometimes easier to ensure that any particular group used by a system service will have the same ID across multiple systems by adding it to LDAP, hence the existence of this class of groups. These have gids starting at 5000.

There are some miscellaneous groups scattered in there. For instance, "commons_mm" (gid 8000) is the primary group for all music cart users.

ou=people

This is the subtree used for the NSS passwd database on all general use systems. It is itself made up of several more sub-ous. The major ones are listed below. Others may be created as needed (for example, the josti2008 ou contains temporary users that were created for a JOSTI 2008 interactive user experience in one particular presentation; although the users are still in LDAP, they cannot login because their Kerberos credentials are expired).

ou=legacy

Most NIS users were loaded into this ou so legacy accounts could still have their uids looked up, and previous admins that retained their Kerberos accounts can still log in. Some NIS users were not imported because their username already existed in one of the other ous.

ou=parents

Parents that have login access for website editing or for whatever other purpose go here. Some parents may actually be in ou=legacy if they were created during the NIS era.

ou=special

This contains things that don't belong in any other category. Some system service users go here (see "System/service groups" in the ou=group section above for why we do this). Music cart users also go here, although they could also have their own ou since there seem to be enough of them nowadays.

  • IMPORTANT: Most users that are added here should also be added to the ou=special in ou=sysadmins (see below).

ou=staff

Well yes...faculty and staff have their own ou. Naturally.

ou=students

No student users go directly in here; they go into another subou under this ou by graduation year first. At time of writing, ous exist for 2006 through 2017.

ou=sysadmins

This contains...well...sysadmins. The distinction from ou=people is primarily for access control on non-general-use servers.

ou=special

This is basically a copy of ou=special from above. The difference is that non-general-use servers are configured to see this ou=special, while general-use systems see the one in ou=people. For example, it is important to have the music card users here and above since music card users are logged in to on a general use system, but the NFS server, which is non-general use, also needs to be able to look up the username and uid.

Configuring LDAP on clients

Gentoo

  • emerge nss_ldap. If you want to be able to manage LDAP from this system, make sure that the kerberos and sasl USE flags are enabled on both nss-ldap and openldap.
  • Edit /etc/ldap.conf:
    • Setup LDAP servers 198.38.16.59, 198.38.16.70, and 198.38.16.71.
    • Use search base: dc=csl,dc=tjhsst,dc=edu.
    • Set bind_timelimit to 2
    • Set bind_policy to soft
    • Set nss_base_passwd to ou=people,
    • Set nss_base_group to ou=group,
  • Edit /etc/nsswitch.conf to use "compat ldap" for the passwd and group databases. The two lines should look like this:
passwd:     compat ldap
group:      compat ldap
  • You may need to restart nscd if it is installed.

Centos 7

  • Install nss-pam-ldapd.
  • Add/Edit the following lines in /etc/nslcd.conf

uri ldap://openldap1.tjhsst.edu/
uri ldap://openldap2.tjhsst.edu/
base dc=csl,dc=tjhsst,dc=edu
base   group  ou=group,dc=csl,dc=tjhsst,dc=edu
base   passwd ou=people,dc=csl,dc=tjhsst,dc=edu

  • Execute the following command to reload the nslcd configuration:

systemctl enable nslcd
systemctl restart nslcd

  • Edit /etc/nsswitch.conf to use "compat ldap" for the passwd and group databases as described in the Gentoo section above.

Solaris

WARNING: There was at least one point in the history of Sun Directory Server where setting up the LDAP client on the LDAP server was not supported because the client was started before the server was, causing a halt in system boot because of a failure to initialize the client. I'm not sure if this is still the case, but if it is, you will need an init script to disable the client in SMF until the server starts, and then restart the client after the server starts. In the CSL, this is easily done by installing the STJinitd-sunds package.

  • Run the following command:
/usr/sbin/ldapclient manual -a credentialLevel=anonymous \
 -a defaultSearchBase="dc=csl,dc=tjhsst,dc=edu" \
 -a defaultSearchScope=sub \
 -a defaultServerList="198.38.16.70 198.38.16.71" \
 -a followReferrals="TRUE" \
 -a preferredServerList="198.38.16.59" \
 -a serviceSearchDescriptor=passwd:ou=people,dc=csl,dc=tjhsst,dc=edu \
 -a serviceSearchDescriptor=group:ou=group,dc=csl,dc=tjhsst,dc=edu
  • On most CSL systems: You are done.
  • On stock Solaris systems (and possibly some CSL systems):
    • The ldapclient command has installed an nsswitch.conf that assumes you use LDAP for everything. And I mean EVERYTHING. But that's rarely the case anywhere. So cp /etc/nsswitch.dns /etc/nsswitch.conf. Then edit /etc/nsswitch.conf to use "files ldap" for passwd and group. See Linux section above for sample of what this will look like.
    • pkill nscd to restart it (Solaris 10), or restart it some other way.
  • NOTE: Solaris defaults tolibnss- using files instead of compat to reference the local password and group databases. For more information on the differences between files and compat, you can run info libc “Name Service Switch” on a system with GNU info configured.

Admin-only access

Follow the above directions, but wherever you see an ou=people, replace it with an ou=sysadmins. Only sysadmins with LDAP entries in ou=sysadmins will be able to access that system. Note that additional access control can, and is often, managed by using hostname groups (i.e. the LDAP POSIX group named after the hostname of the system). This is currently not done on Solaris systems, but is done on most Linux systems.

Note that if you are doing this, you will probably want to enable the pam_mkhomedir module to automatically create home directories the first time an admin logs in. This can be done by adding the following line to /etc/pam.d/system-auth on linux systems:

session     optional      pam_mkhomedir.so

On Centos, this can also be done using authconfig:

authconfig --enablemkhomedir --update

Administration/Management

Administration and management of NSS data is primarily accomplished through the LDAP command line utilities. In order to gain administrative access to NSS LDAP, four things are necessary:

  • You must have an ou=sysadmins user entry (eg: uid=ahamilto,ou=sysadmins,dc=csl,dc=tjhsst,dc=edu)
  • You must have a Kerberos /admin principal (eg: ahamilto/admin)
  • The dn of your ou=sysadmins entry must be added as a member of cn=ldapadmins,dc=csl,dc=tjhsst,dc=edu
  • The ldap utilities on the system you are using must support SASL GSSAPI binding

Once you have the above four items, you can kinit to your /admin principal and use the standard LDAP command line utilities to make changes. For examples of various changes see NSS LDAP Templates.

See Also

  • NSS LDAP Templates - Template LDIFs and commands for various NSS LDAP changes
  • OpenLDAP - Installation and configuration of the OpenLDAP Daemon (slapd)
  • Integrated Authentication - Information on the Integration Authentication between the LOCAL and CSL systems.