check, bevor Sie etwas neu starten, über das sich Personen anmelden

authnd check /etc/authnd
authnd check --config a.hcl --config b.hcl

check liest die Konfiguration genau so wie der Server, öffnet alles, was der Server öffnet, bevor er lauscht – die Dateien, die Datenbank, das Verzeichnis hinter diesem, das Discovery-Dokument des Identitätsanbieters, das TLS-Zertifikat und den Schlüssel, den Keytab – und gibt aus, was veröffentlicht würde und für wen, ohne zu lauschen. Es gibt aus, woher jeder Zugangsnachweis kommt, und nie, was darin steht. Es endet mit Status 0 und mit this configuration can be served oder mit Status 1 und dem einen Satz, der den Server aufhält.

Eine Konfiguration, die bereitgestellt werden kann

Zwei user-Blöcke, ein Reader und eine SQLite-Datenbank, in einem Verzeichnis mit zwei Dateien (authnd.hcl und people.hcl):

$ authnd check etc/authnd
ldap://127.0.0.1:3893, base dc=example,dc=org

USER   FROM                    CAN PROVE   PUBLISHED AS        WITH
alice  the configuration file  a password  account, uidObject  uid
bob    the configuration file  an NT hash  account, uidObject  uid
dora   a sqlite database       a password  account, uidObject  uid
eli    a sqlite database       an NT hash  account, uidObject  uid

GROUP      MEMBERS              PUBLISHED AS
engineers  dora and eli         groupOfNames
staff      alice, bob and dora  groupOfNames

alice has no uidNumber, gidNumber or homeDirectory: not a posixAccount, published as account, uidObject
bob has no uidNumber, gidNumber or homeDirectory: not a posixAccount, published as account, uidObject
dora has no uidNumber, gidNumber or homeDirectory: not a posixAccount, published as account, uidObject
eli has no uidNumber, gidNumber or homeDirectory: not a posixAccount, published as account, uidObject
group engineers has no gidNumber: not a posixGroup, published as a groupOfNames (member DNs, no memberUid)
group staff has no gidNumber: not a posixGroup, published as a groupOfNames (member DNs, no memberUid)

a bind carries a password
bob and eli cannot bind with a password: their sources hold only what an SMB server needs (an NT hash), which a bind cannot be checked against
cn=reader,dc=example,dc=org may search; every other bound client may not
sambaNTPassword is not published, so nothing here can authenticate an SMB session (NTLMv2 needs the password or its MD4, and a bind cannot answer it)

this configuration can be served

Wie man es liest

Die erste Zeile nennt Schema, Adresse und Basis: ldap://, ldaps:// oder ldap+starttls:// – siehe TLS.

Auch die Gruppentabelle hat eine Spalte PUBLISHED AS: posixGroup, groupOfNames oder organizationalRole. Bis v0.10.2 war PUBLISHED AS die Liste der Attribute, uid and cn für fast alle, und es gab keine Spalte WITH.

Die Zeilen nach den Tabellen sagen, was man wissen muss, bevor man sich auf die Konfiguration verlässt. Zuerst zu den Einträgen:

• wer kein posixAccount ist, und welche von uidNumber, gidNumber und homeDirectory fehlen;
• welche Gruppen keine gidNumber haben, und als was sie stattdessen veröffentlicht werden;
• jedes weggelassene Attribut, weil keine Klasse seines Eintrags es erlaubt, und welche Klassen es erlauben würden;
• jeder nicht veröffentlichte Eintrag, mit jedem Problem, das die Schemaprüfung gefunden hat;
• wer einen NT-Schlüssel und keine sambaSID hat, und damit kein sambaNTPassword.

Dann zu Binds und Suchen:

• was ein Bind trägt: a password oder, mit einem mfa-Block, a password with a 6-digit code after it; mit einem oidc-Block, woher Tokens kommen und worüber;
• wer sich überhaupt nicht mit einem Passwort binden kann: Personen, die nur über einen NT-Hash bekannt sind – siehe Personen;
• wer suchen darf: die Reader oder no reader is declared: nothing may search, and binds are not affected;
• ob sambaNTPassword veröffentlicht wird, und worüber – siehe publish_nt_hash;
• mit einem kerberos-Block der Realm und wem ein Ticket ausgestellt werden kann und wem nicht, mit dem Grund;
• mit einem mfa-Block, wer keinen zweiten Faktor hat und sich deshalb nicht mit einem Passwort binden kann; steht ein oidc-Block daneben, fügt die Zeile hinzu, dass ein Token, dessen amr zwei Arten nennt, es weiterhin kann;
• eine Gruppe, die jemanden nennt, den keine Quelle hat.

Diese letzte wird so veröffentlicht, wie sie ist – eine Fassade für ein System trägt berechtigterweise Namen, die einem anderen gehören –, aber es wird gesagt, weil die andere Lesart ein Tippfehler ist. In einer posixGroup ist die fremde Person ein memberUid; in einer groupOfNames ist sie ein member-DN, der keinen Eintrag hier benennt, hier member: uid=zoe,ou=people,dc=example,dc=org, den ldapdir aus go-authn/directory ab v0.14.0 auf niemanden abbildet. Hier hat die Tabelle team_members der Datenbank eine Zeile für zoe, einen Namen, den hier niemand trägt:

GROUP      MEMBERS              PUBLISHED AS
engineers  dora, eli and zoe    groupOfNames
staff      alice, bob and dora  groupOfNames
[...]
engineers names zoe, who has no entry here: the group is published as it stands, and nothing here can prove them

(Ein group-Block, der eine fremde Person nennt, wird sofort abgelehnt; siehe Personen.)

Was es ablehnt

Jeder dieser Fälle hält check und den Server gleichermaßen auf, mit Exit-Status 1. Sie stehen auf den Seiten, zu denen sie gehören; einige, wie ausgegeben:

$ authnd check cases/nobody.hcl
authnd: there is nobody here: name a user, or a users block reading a database or a directory

$ authnd check cases/nthash-clear.hcl
authnd: publish_nt_hash needs cert_file and key_file: an NT hash IS the credential, and 0.0.0.0:3893 is not loopback, so it would cross a network in the clear

$ authnd check cases/krb-mfa.hcl
authnd: kerberos and mfa together: the mfa block asks every bind for a password AND a code, and a kinit carries only the password -- this KDC has no second-factor pre-authentication, so a realm here would accept one factor where the mfa block demands two. Remove one of the blocks

$ authnd check empty
authnd: empty has no .hcl files in it

$ authnd
authnd: no configuration: give a .hcl file or a directory of them

Das Zertifikat, der Keytab und das eine, was es nicht sehen kann

Ein Zertifikat, das sich nicht laden lässt, und ein Keytab ohne krbtgt/REALM werden von check abgelehnt, mit den Worten, die der Server verwenden würde:

$ authnd check cases/badcert
authnd: the certificate: open tls/missing.pem: no such file or directory

$ authnd check cases/nokrbtgt
authnd: kdc: the keytab has no krbtgt key for this realm: matching key not found in keytab. Looking for "krbtgt/EXAMPLE.ORG" realm: EXAMPLE.ORG kvno: 0 etype: 18

Was check nicht wissen kann, ohne zu lauschen, ist, ob die Ports frei sind. Ein zweiter Server an derselben Kerberos-Adresse besteht check und wird beim Start abgelehnt:

$ authnd --config cases/realm2
authnd: kerberos udp 127.0.0.1:18388: listen udp 127.0.0.1:18388: bind: address already in use

Als Dienstkonto ausführen

sudo -u authnd authnd check /etc/authnd

damit eine Datei, die nur root lesen kann, hier scheitert und nicht beim Neustart. Führen Sie es vor einem Upgrade mit dem neuen Binary aus; siehe Installation.