authnd, un serveur LDAP pour des personnes qui sont ailleurs

Les personnes d’un site sont déjà dans une base de données, un fichier ou un autre annuaire. Ce qui veut les authentifier parle LDAP. authnd est la façade : il se lie et cherche sur les sources de go-authn/directory, si bien que ce que contient une base de données peut être lu par tout ce qui sait interroger un annuaire. Pur Go, CGO_ENABLED=0, un seul binaire. Ces pages décrivent la v0.11.1, dont les entrées suivent les schémas standard et respectent le schéma qu’elle sert à cn=Subschema, avec go-authn/ldap v0.8.0 et go-authn/directory v0.14.0 en dessous ; ce qui est vérifié et ce qui ne l’est pas figure sur la page état.

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

La plus petite 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"] }

Les personnes sont publiées sous uid=<name>,ou=people,<base_dn>, les groupes sous cn=<name>,ou=groups,<base_dn>. Ce que est chaque entrée découle de ce que sa source a donné : une personne est un account, ou un inetOrgPerson quand il y a un sn, et un posixAccount seulement avec uidNumber, gidNumber et homeDirectory ; chaque personne est un uidObject. Un groupe est un posixGroup (avec memberUid) quand il a un gidNumber, sinon un groupOfNames (avec des DN member), ou un organizationalRole quand il est de plus vide. sshPublicKey est ajouté quand la personne a des clés, et sambaNTPassword quand publish_nt_hash le dit et qu’un SID peut être donné. Chaque entrée respecte le schéma servi à cn=Subschema avant d’être publiée : voir les entrées et le schéma. Jusqu’à la v0.10.2, chaque personne était un posixAccount et chaque groupe un posixGroup, quoi qu’ils aient.

--config (-c) prend un fichier ou un répertoire et peut être répété ; un répertoire vaut tous les fichiers .hcl qu’il contient, lus dans l’ordre des noms et fusionnés en une seule configuration. Une configuration sans base_dn, ou sans personne dedans, ne démarre pas.

Qui peut se lier, et qui peut lire

On demande à un serveur LDAP de prouver des personnes : ses refus sont donc la conception même. Voici les réponses du binaire de la version v0.10.0 au client propre d’OpenLDAP :

$ 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

Un reader est un compte de service avec un DN de liaison et password ou password_file ; un reader qui n’a ni l’un ni l’autre est refusé au démarrage (un reader qui ne prouve rien, c’est une recherche anonyme avec des étapes en plus). Sans aucun reader, rien ne peut chercher, et check le dit.

Le DSE racine est servi à un client anonyme, comme la découverte l’exige :

$ 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 est l’opération de modification de mot de passe de la RFC 3062. subschemaSubentry nomme le schéma, qui est servi aussi à un client anonyme. supportedSASLMechanisms: OAUTHBEARER n’apparaît qu’avec un bloc oidc.

Pour aller plus loin