authnd, an LDAP server for people who are somewhere else

A site’s people are already in a database, a file or another directory. The things that want to authenticate them speak LDAP. authnd is the front: it binds and searches over go-authn/directory’s sources, so what a database holds can be read by anything that knows how to ask a directory. Pure Go, CGO_ENABLED=0, one binary. These pages describe v0.11.1, whose entries follow the standard schemas and pass the schema it serves at cn=Subschema, with go-authn/ldap v0.8.0 and go-authn/directory v0.14.0 under it; what is verified and what is not is on the status page.

authnd --config /etc/authnd      # serve
authnd check /etc/authnd         # say what would be served, without listening

The smallest configuration

listen  = "127.0.0.1:3893"            # the default
base_dn = "dc=example,dc=org"         # required

reader "cn=reader,dc=example,dc=org" { password_file = "/etc/authnd/reader.pw" }

user "alice" { password_file = "/etc/authnd/passwords/alice.pw" }

group "staff" { members = ["alice"] }

People are published as uid=<name>,ou=people,<base_dn>, groups as cn=<name>,ou=groups,<base_dn>. What each entry is follows from what its source gave: a person is an account, or an inetOrgPerson when there is an sn, and a posixAccount only with uidNumber, gidNumber and homeDirectory; every person is a uidObject. A group is a posixGroup (with memberUid) when it has a gidNumber, otherwise a groupOfNames (with member DNs), or an organizationalRole when it is also empty. sshPublicKey is added when the person has keys, and sambaNTPassword when publish_nt_hash says so and a SID can be given. Every entry passes the schema served at cn=Subschema before it is published: see the entries and the schema. Up to v0.10.2 every person was a posixAccount and every group a posixGroup, whatever they had.

--config (-c) takes a file or a directory and may be repeated; a directory is every .hcl file in it, read in name order and merged into one configuration. A configuration with no base_dn, or with nobody in it, does not start.

Who may bind, and who may read

An LDAP server is asked to prove people, so its refusals are the design. These are answers from the v0.10.0 release binary to OpenLDAP’s own client:

$ ldapwhoami -x -H ldap://127.0.0.1:3893 -D uid=alice,ou=people,dc=example,dc=org -y alice.pwin
dn:uid=alice,ou=people,dc=example,dc=org

$ ldapwhoami -x -H ldap://127.0.0.1:3893 -D uid=alice,ou=people,dc=example,dc=org -y wrong.pwin
ldap_bind: Invalid credentials (49)

$ ldapwhoami -x -H ldap://127.0.0.1:3893 -D uid=alice,ou=people,dc=example,dc=org -w ''
ldap_bind: Server is unwilling to perform (53)
	additional info: an unauthenticated bind proves nothing, and this server does not accept one

$ ldapsearch -x -LLL -H ldap://127.0.0.1:3893 -D uid=alice,ou=people,dc=example,dc=org -y alice.pwin -b dc=example,dc=org '(uid=alice)'
Insufficient access (50)
Additional information: only a reader may search

A reader is a service account with a bind DN and password or password_file; a reader with neither is refused at startup (a reader that proves nothing is anonymous search with extra steps). Without any reader, nothing may search, and check says so.

The root DSE is answered to an anonymous client, as discovery needs:

$ ldapsearch -x -LLL -H ldap://127.0.0.1:3893 -s base -b '' '+' '*'
dn:
objectClass: top
objectClass: OpenLDAProotDSE
supportedLDAPVersion: 3
namingContexts: dc=example,dc=org
supportedExtension: 1.3.6.1.4.1.4203.1.11.3
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.3.6.1.1.13.1
supportedControl: 1.3.6.1.1.13.2
supportedFeatures: 1.3.6.1.4.1.4203.1.5.1
supportedFeatures: 1.3.6.1.4.1.4203.1.5.3
subschemaSubentry: cn=Subschema
vendorName: go-authn/authnd
vendorVersion: v0.11.1

1.3.6.1.4.1.4203.1.11.1 is the RFC 3062 password modify operation. subschemaSubentry names the schema, which is answered to an anonymous client as well. supportedSASLMechanisms: OAUTHBEARER appears only with an oidc block.

Where to go next