Overview

With dnsmasq there is a very small, simple, powerful, and reliable combined dns server, dns cache, dhcp server, and tftp server. It's got everything you need to serve a small home/classroom/school sized network that can include thin clients. It's very easy to configure (dns just serves up the /etc/hosts file with auto-dns support for dhcp clients), and its dhcp server can easily be configured to serve anything like auto-proxy config or different boot options for different thin clients. It's small enough to run on a OpenWRT? router or QNAP NAS.

One of the things a small network like this really needs is an LDAP server for managing users. It needs to be small and efficient, with enough grunt to support at least 100 clients and 1000 users when running on something like a router or NAS. It must be powerful enough to support most commonly used functionality, but familiar and simple to configure. It absolutely must be reliable and secure enough for the home/classroom/school environment. I believe that they should be written in C (widely used and fast) using an event-loop design (threads suck).

Objectives

Primary objectives are;

1. Support enough LDAP functionality for pam-ldap and nss-ldap to work for clients.
2. Serve familiar /etc passwd group shadow files directly with no special file formats.
3. Easily support ~100 clients and 1000 users on router level hardware.
4. Keep the code small and simple, using existing libraries as much as possible.

Secondary objectives are;

1. Support TLS and SASL for security in a slightly untrustworthy network.
2. Support additional nss files like hosts networks netgroup etc.
3. Support writes enough so that pam-ldap updates using passwd chfn chsh work.
4. Support samba domain authentication and schemas.
5. Support arbitrary schemas served from passwd like files.
6. Support ACLs?.

Alternatives

Security Options

So that anyone can see users/groups, /etc/passwd and /etc/group are world readable. Historically these used to contain crypt passwords, relying on the crypt security to protect users passwords. This makes dictionary attacks too easy, so /etc/shadow and /etc/gshadow were created readable only by root to contain the crypted passwords. This way only root has access to the crypted passwords for doing auth.

LDAP can export data with or without TLS encryption. Originally TLS was done by serving ldaps:// through a secure tunnel on another port, but now LDAP supports a StartTLS? command to turn on encryption in the middle of an LDAP session.

When authenticating with an LDAP server there are several alternatives. The original simple BIND sends the password in plaintext to the LDAP server. This is a security hole without TLS on an untrusted network, so SASL was added, which supports several auth methods including challenge-response auth that doesn't send the plaintext passwd over the wire. The problem with challenge-response protocols is they require the server to know the plaintext passwd. See the following;

http://www.ldapguru.info/ldap/authentication-best-practices.html

We want to use /etc/shadow passwords which are crypted, so we can't use SASL challenge-response auths like DIGEST-MD5. Note that things like smtp auth uses SASL PLAIN over TLS, which is the same level of security as simple BIND over TLS.

This means SASL adds nothing over simple BIND for our purposes. The only reason to add SASL support would be for clients that insist on using SASL BIND, and then we can only support SASL PLAIN. Note that entente already supports simple BIND using pam.

Client machines can use ldap for users/groups 2 different ways;

1. Serve /etc/shadow with ldap readable only by root, have client machines use libnss-ldap for user/group/shadow, and use normal pam-unix for auth. This means the ldap server needs read access to /etc/shadow, which means either running as root or as a member of group shadow. The client machines will have full access to /etc/shadow, so need to be trusted. The contents of /etc/shadow are sent over the network, so you need a trusted network, or TLS encryption.
2. Don't serve /etc/shadow with ldap, use libnss-ldap for user/group (with empty shadow?), and use libpam-ldap for auth. This means that the ldap server doesn't need read access to /etc/shadow. The contents of /etc/shadow are never sent to clients so they don't need to be trusted. However, clients will send passwords to the ldap server for bind, so you still need a trusted network, or TLS encryption.

Note that to bind to the ldap port, the ldap server needs to start as root, but can drop privileges after that if it doesn't need /etc/shadow read access.

Implementation

See http://github.com/dbaarda/LightLdapd for the latest sources.

This was forked and renamed from http://github.com/urbanserj/entente after submitting several improvements and cleanups. The fork was done with the approval blessing of the entente author so that entente could remain a good example of a bare minimum LDAP server.