LDAP

This page desperately needs to be filled out or brought up to date. If you're familiar with the operations of this part of the site, please help!

FIXME: There's almost no server info here

FIXME: What about client startup when servers are flaky?

Hosts should be to use LDAP for users and some other stuff.

Things are moving to NIS... very, very slowly...

setup LDAP client on new machine

• run /home/wikipedia/bin/setup-ldap
• copy zwinger:/etc/ldap.conf to the new machine

LDAP server is on srv1 (master) and srv2 (slave). failover should be automatic. to add new users, add them on srv1, then run ldapsync. srv2 will update automatically.

Overload

If the local caching daemon nscd dies on clients, the server can get badly overloaded and logins can fail.

If necessary restart it sitewide. :P

Server logging

slapd's logging stuff goes to a channel on syslog that's not logged by default. On a new server, you may have to manually edit syslog.conf and add something for local4.*

Then set an appropriate loglevel in /etc/openldap/slapd.conf

LDAP take 2

Installing/Configuring the server manually

Install required packages

apt-get install openjdk-6-jre openjdk-6-jdk ldap-utils opends-wmf

Create a Basic Directory Information Tree (DIT)

Top level structure

Our aim is for a DIT that is as flat as possible. Adding hierarchy adds complexity, and isn't as flexible as one would first imagine. Using attributes to imply hierarchy is more effective. Below is a basic OU and automount hierarchy:

dn: ou=people,<basedn>
changetype: add
objectClass: top
objectClass: organizationalUnit
ou: people
 
dn: ou=group,<basedn>
changetype: add
objectClass: top
objectClass: organizationalUnit
ou: group
 
dn: ou=netgroup,<basedn>
changetype: add
objectClass: top
objectClass: organizationalUnit
ou: netgroup
 
dn: ou=sudoers,<basedn>
changetype: add
objectClass: top
objectClass: organizationalUnit
ou: sudoers
 
dn: ou=hosts,<basedn>
changetype: add
objectClass: top
objectClass: organizationalUnit
ou: hosts
 
dn: ou=profile,<basedn>
changetype: add
objectClass: top
objectClass: organizationalUnit
ou: profile
 
dn: nisMapName=auto.master,<basedn>
changetype: add
objectClass: top
objectClass: nisMap
nisMapName: auto.master
 
dn: nisMapName=auto.home,<basedn>
changetype: add
objectClass: top
objectClass: nisMap
nisMapName: auto.home
 
dn: nisMapName=home,nisMapName=auto.master,<basedn>
changetype: delete
 
dn: nisMapName=/home,nisMapName=auto.master,<basedn>
changetype: add
objectClass: top
objectClass: nisObject
cn: /home
nisMapEntry: ldap:nisMapName=auto.home,<basedn>
nisMapName: auto.master
 
dn: cn=*,nisMapName=auto.home,<basedn>
changetype: add
nisMapEntry: <homedirserver>:/home/&
objectClass: nisObject
objectClass: top
nisMapName: auto.home
cn: *

Object classes and attributes for objects

Users

Objectclasses:

• top
• person
• inetorgperson
• posixaccount
• shadowaccount

Attributes:

• Required:
  • sn
  • cn
  • uid
  • uidnumber
  • gidnumber
  • homedirectory
• Optional:
  • userpassword
  • loginshell
  • description

In practice, loginshell should always be defined; also, userpassword should always be set if any system will be using pam_ldap in the auth stack.

Groups

Objectclasses:

• top
• posixgroup

Attributes:

• Required:
  • cn
  • gidnumber
• Optional:
  • memberuid
  • description

We may want to use the groupofuniquenames objectclass to define the members here, while using posixgroup to define the gidnumber. Doing so would allow us to use full DNs for the group members, which would give us referential integrity.

Netgroups

Objectclasses:

• top
• nisnetgroup

Attributes:

• Required:
  • cn
• Optional:
  • membernisnetgroup
  • nisnetgrouptriple
  • description

In practice, every entry should either have membernisnetgroup or nisnetgrouptriple.

nisnetgrouptriple attributes are defined as:

(host,user,domainname)

In practice, it is preferred to have netgroups that only define user or host, never both. domainname is never defined. User netgroups are used for controlling access to sudo, ssh login, console login, etc. Host netgroups are used for controlling network access to nfs shares, ssh, etc.

NisMap entries (automount)

Objectclasses:

• top
• nismap

Attributes:

• Required:
  • nismapname
• Optional:
  • description

From the perspective of automount, nismaps are like auto.master, and the other files that define mounts. If you have an auto.master file that looks like this:

/home           /etc/auto.home
/data           /etc/auto.data
/scratch        /etc/auto.scratch
+auto.master

You would have nismaps that look like this:

dn: nisMapName=auto.master,<basedn>
changetype: add
objectClass: top
objectClass: nisMap
nisMapName: auto.master
 
dn: nisMapName=auto.home,<basedn>
changetype: add
objectClass: top
objectClass: nisMap
nisMapName: auto.home
 
dn: nisMapName=auto.data,<basedn>
changetype: add
objectClass: top
objectClass: nisMap
nisMapName: auto.data
 
dn: nisMapName=auto.scratch,<basedn>
changetype: add
objectClass: top
objectClass: nisMap
nisMapName: auto.scratch

NisObject entries (automount)

• Required:
  • cn
  • nismapentry
  • nismapname
• Optional:
  • description

Sudo entries

Objectclasses:

• top
• sudorole

Attributes:

• Required:
  • cn
• Optional:
  • sudouser
  • sudohost
  • sudocommand
  • sudorunas
  • sudorunasuser
  • sudorunasgroup
  • sudooption
  • description

In practice, most entries will define sudouser, sudohost, and sudocommand. cn=defaults,ou=sudoers should be added with sudooption attributes that should apply globally (like mailto address, etc.).

Security groups

Objectclasses:

• top
• groupofnames

Attributes:

• Required:
  • cn
  • member
• optional
  • description

Host entries

Objectclasses:

• top
• iphost

Attributes:

• Required:
  • cn
  • iphostnumber
• Optional:
  • description

In practice, we should avoid using host entries. DNS is much more suited for this. The only real consideration for using host entries is naming backend systems that aren't in DNS.

Add a proxy agent

Since we are requiring authentication by default, the clients need a user to do authenticated lookups. We create a proxyagent user for this:

dn: cn=proxyagent,ou=profile,<basedn>
changetype: add
objectclass: top
objectclass: inetorgperson
objectclass: person
sn: agent
givenName: proxy
userpassword: <aPasswordGoesHere>
cn: proxyagent

Add the sudoers schema

cp /usr/share/doc/sudo-ldap/schema.iPlanet /usr/local/OpenDS/config/schema/98sudo.ldif

• Note: This should be a function of our opends package; the package should have a dependency on the sudo-ldap package

Installing/Configuring the client manually

Install required packages

apt-get install ldap-utils sudo-ldap libpam-ldap libnss-ldap nss-updatedb libnss-db autofs5 autofs5-ldap nscd

Install the server certificate's CA

1. Install to /etc/ssl/certs/ldapca.crt
2. Run:

pushd /etc/ssl/certs
ln -s ldapca.crt $(openssl x509 -hash -noout -in ldapca.crt).0
popd

Configure openldap's ldap.conf

Add the following options to /etc/ldap/ldap.conf:

BASE            <basedn>
URI             ldap://<servername>:389
TLS_CRLCHECK    require
TLS_CACERTDIR   /etc/ssl/certs
TLS_CACERT      /etc/ssl/certs/ldapca.crt

• Note: TLS_CACERTDIR is likely ignored, since gnutls doesn't support the directive, but for future compatibility, it should be defined.
• Note: Though we define the URI as ldap/389, we should always use encryption, so all clients should use StartTLS