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-responze 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.
2. Don't serve /etc/shadow with ldap, use libnss-ldap for user/group/shadow (with empty shadow data?), use libpam-ldap for auth.