authnd, ein LDAP-Server für Personen, die anderswo verwaltet werden

Die Personen eines Standorts stehen bereits in einer Datenbank, einer Datei oder einem anderen Verzeichnis. Was sie authentifizieren will, spricht LDAP. authnd ist die Fassade davor: Es führt Binds und Suchen über die Quellen von go-authn/directory aus, sodass das, was eine Datenbank enthält, von allem gelesen werden kann, das ein Verzeichnis zu fragen weiß. Reines Go, CGO_ENABLED=0, ein Binary. Diese Seiten beschreiben v0.11.1, dessen Einträge den Standardschemata folgen und das Schema bestehen, das es unter cn=Subschema bereitstellt, mit go-authn/ldap v0.8.0 und go-authn/directory v0.14.0 darunter; was geprüft ist und was nicht, steht auf der Seite Stand.

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

Die kleinste Konfiguration

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"] }

Personen werden als uid=<name>,ou=people,<base_dn> veröffentlicht, Gruppen als cn=<name>,ou=groups,<base_dn>. Was jeder Eintrag ist, ergibt sich aus dem, was seine Quelle geliefert hat: Eine Person ist ein account, oder ein inetOrgPerson, wenn es ein sn gibt, und ein posixAccount nur mit uidNumber, gidNumber und homeDirectory; jede Person ist ein uidObject. Eine Gruppe ist eine posixGroup (mit memberUid), wenn sie eine gidNumber hat, andernfalls eine groupOfNames (mit member-DNs), oder eine organizationalRole, wenn sie zudem leer ist. sshPublicKey kommt hinzu, wenn die Person Schlüssel hat, und sambaNTPassword, wenn publish_nt_hash es vorsieht und eine SID angegeben werden kann. Jeder Eintrag besteht das unter cn=Subschema bereitgestellte Schema, bevor er veröffentlicht wird: siehe die Einträge und das Schema. Bis v0.10.2 war jede Person ein posixAccount und jede Gruppe eine posixGroup, was auch immer sie hatten.

--config (-c) nimmt eine Datei oder ein Verzeichnis und darf wiederholt werden; ein Verzeichnis steht für jede .hcl-Datei darin, in Namensreihenfolge gelesen und zu einer Konfiguration zusammengeführt. Eine Konfiguration ohne base_dn oder ohne eine einzige Person startet nicht.

Wer sich binden und wer lesen darf

Ein LDAP-Server soll Personen nachweisen, also sind seine Ablehnungen das eigentliche Design. Dies sind Antworten des Release-Binarys v0.10.0 an den Client von OpenLDAP selbst:

$ 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

Ein reader ist ein Dienstkonto mit einem Bind-DN und password oder password_file; ein Reader ohne beides wird beim Start abgelehnt (ein Reader, der nichts beweist, ist eine anonyme Suche mit zusätzlichen Schritten). Ohne jeden Reader darf nichts suchen, und check sagt das.

Das Root-DSE wird einem anonymen Client beantwortet, wie es die Erkennung braucht:

$ 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 ist die Password-Modify-Operation aus RFC 3062. subschemaSubentry benennt das Schema, das ebenfalls einem anonymen Client beantwortet wird. supportedSASLMechanisms: OAUTHBEARER erscheint nur mit einem oidc-Block.

Wie es weitergeht