Wie funktioniert die SASL-Authentifizierung mit DIGEST-MD5 für OpenLDAP?

Ich richte OpenLDAP slapdunter Ubuntu 14.04 Trusty Tahr ein. Ich möchte bestimmte Fälle (Replikation usw.) , die Benutzer nicht über zu Login der Lage sein , SASLmit DIGEST-MD5Mechanismus.

Im Gegensatz zu Benutzern sollten sie keinen entsprechenden DN (zusammen mit dem Kennwort) in der Verzeichnisstruktur haben. Stattdessen sollen ihre Anmeldeinformationen daher extern gespeichert werden SASL.

Ich verwende saslauthdgerade (dies ist keine schwierige Voraussetzung, wenn es zum Beispiel mit direktem Zugriff auf die sasldb funktionieren soll) und es funktioniert gut mit Mechanismen PLAINund LOGINwährend es mit Mechanismen DIGEST-MD5und nicht funktioniert CRAM-MD5.

Was vermisse ich oder mache ich falsch? Wie kann ich damit arbeiten DIGEST-MD5?

OpenLDAP für konfiguriert SASLin /etc/ldap/sasl2/slapd.confetwa so aus :

mech_list: EXTERNAL DIGEST-MD5 CRAM-MD5 PLAIN LOGIN
pwcheck_method: saslauthd
saslauthd_path: /var/run/saslauthd/mux

Die interessanten (geänderten) Optionen in /etc/default/saslauthdsind:

START=yes
MECHANISMS="sasldb"

Sie führen dazu, saslauthddass wie folgt begonnen wird:

/usr/sbin/saslauthd -a sasldb -c -m /var/run/saslauthd -n 5

Ich reproduziere den fehlgeschlagenen Fall folgendermaßen DIGEST-MD5:

# ldapsearch -U replication -ZZ -Y DIGEST-MD5 -H ldap://ldap-master.example.com/ -b "dc=example,dc=com" "(objectClass=*)"
SASL/DIGEST-MD5 authentication started
Please enter your password: 
ldap_sasl_interactive_bind_s: Invalid credentials (49)
    additional info: SASL(-13): user not found: no secret in database

Der Teil im slapd-Protokoll, in dem es anscheinend fehlschlägt (Protokollierung ist aktiviert any), sieht folgendermaßen aus:

slapd[23330]: [rw] authid: "uid=replication,cn=digest-md5,cn=auth" -> "uid=replication,cn=digest-md5,cn=auth"
slapd[23330]: slap_parseURI: parsing uid=replication,cn=digest-md5,cn=auth
slapd[23330]: >>> dnNormalize: <uid=replication,cn=digest-md5,cn=auth>
slapd[23330]: <<< dnNormalize: <uid=replication,cn=digest-md5,cn=auth>
slapd[23330]: <==slap_sasl2dn: Converted SASL name to uid=replication,cn=digest-md5,cn=auth
slapd[23330]: slap_sasl_getdn: dn:id converted to uid=replication,cn=digest-md5,cn=auth
slapd[23330]: SASL Canonicalize [conn=1002]: slapAuthcDN="uid=replication,cn=digest-md5,cn=auth"
slapd[23330]: SASL [conn=1002] Failure: no secret in database
slapd[23330]: SASL [conn=1002] Debug: DIGEST-MD5 common mech dispose
slapd[23330]: send_ldap_result: conn=1002 op=2 p=3
slapd[23330]: send_ldap_result: err=49 matched="" text="SASL(-13): user not found: no secret in database"
slapd[23330]: send_ldap_response: msgid=3 tag=97 err=49

Es gibt weder in /var/log/auth.lognoch in der Debug-Ausgabe, saslauthdwenn ich es manuell ausführe, was wahrscheinlich darauf hinweist, dass slapdes nicht einmal so weit gekommen ist, die Authentifizierung zu übergeben saslauthd(im Gegensatz zum Arbeitsfall, siehe unten).

Ich reproduziere den Arbeitsfall mit PLAINoder LOGINwie folgt:

# ldapsearch -U replication -ZZ -Y PLAIN -H ldap://ldap-master.example.com/ -b "dc=example,dc=com" "(objectClass=*)"
SASL/PLAIN authentication started
Please enter your password: 
SASL username: replication
SASL SSF: 0
# extended LDIF
…

Der entsprechende Teil im slapdProtokoll, der einen Fehler für den obigen Fall anzeigt, sieht nun folgendermaßen aus:

slapd[23330]: [rw] authid: "uid=replication,cn=plain,cn=auth" -> "uid=replication,cn=plain,cn=auth"
slapd[23330]: slap_parseURI: parsing uid=replication,cn=plain,cn=auth
slapd[23330]: >>> dnNormalize: <uid=replication,cn=plain,cn=auth>
slapd[23330]: <<< dnNormalize: <uid=replication,cn=plain,cn=auth>
slapd[23330]: <==slap_sasl2dn: Converted SASL name to uid=replication,cn=plain,cn=auth
slapd[23330]: slap_sasl_getdn: dn:id converted to uid=replication,cn=plain,cn=auth
slapd[23330]: SASL Canonicalize [conn=1006]: slapAuthcDN="uid=replication,cn=plain,cn=auth"
slapd[23330]: daemon: activity on 1 descriptor
slapd[23330]: daemon: activity on:
slapd[23330]: 
slapd[23330]: daemon: epoll: listen=8 active_threads=0 tvp=zero
slapd[23330]: daemon: epoll: listen=9 active_threads=0 tvp=zero
slapd[23330]: daemon: epoll: listen=10 active_threads=0 tvp=zero
slapd[23330]: SASL proxy authorize [conn=1006]: authcid="replication" authzid="replication"
slapd[23330]: conn=1006 op=1 BIND authcid="replication" authzid="replication"
slapd[23330]: SASL Authorize [conn=1006]:  proxy authorization allowed authzDN=""
slapd[23330]: send_ldap_sasl: err=0 len=-1
slapd[23330]: conn=1006 op=1 BIND dn="uid=replication,cn=plain,cn=auth" mech=PLAIN sasl_ssf=0 ssf=128
slapd[23330]: do_bind: SASL/PLAIN bind: dn="uid=replication,cn=plain,cn=auth" sasl_ssf=0
slapd[23330]: send_ldap_response: msgid=2 tag=97 err=0

Beide /var/log/auth.logund die Debug-Ausgabe von saslauthdjetzt enthalten Folgendes:

saslauthd[23354]: rel_accept_lock : released accept lock
saslauthd[23358]: get_accept_lock : acquired accept lock
saslauthd[23354]: cache_get_rlock : attempting a read lock on slot: 458
saslauthd[23354]: cache_lookup    : [login=replication] [service=] [realm=ldap]: not found, update pending
saslauthd[23354]: cache_un_lock   : attempting to release lock on slot: 458
saslauthd[23354]: cache_get_wlock : attempting a write lock on slot: 458
saslauthd[23354]: cache_commit    : lookup committed
saslauthd[23354]: cache_un_lock   : attempting to release lock on slot: 458
saslauthd[23354]: do_auth         : auth success: [user=replication] [service=ldap] [realm=] [mech=sasldb]
saslauthd[23354]: do_request      : response: OK

Anscheinend muss es einen Unterschied geben, wie es mit PLAINund LOGINvs. DIGEST-MD5und funktioniert CRAM-MD5.

Aktualisierung und Klarstellung:

Die DNs für die Genehmigung Zugang zum Baum verwendet werden , uid=replication,cn=digest-md5,cn=authund uid=replication,cn=plain,cn=authjeweils und gemäß Abschnitt 15.2.5 von http://www.openldap.org/doc/admin24/sasl.html diese DNs nicht tatsächlich benötigen existiert im Baum ( das muss zumindest für zutreffen PLAINund LOGINda es dort gut funktioniert).
Zu Testzwecken verwende ich derzeit, olcAccess: to * by dn.regex="replication" read by * breakum sicherzustellen, dass die Replikationsanmeldung mindestens Lesezugriff auf alles (ja, ich weiß, dass dies nicht sicher ist und ich werde ihm die richtigen Berechtigungen für die Produktion erteilen) im Master-LDAP-Baum erhält.

Die Anmeldeinformationen sind vorhanden /etc/sasldb2und werden bei Verwendung von PLAINoder erfolgreich überprüft LOGIN(siehe oben). Als Referenz sieht es so aus:

# sasldblistusers2
replication@ldap-master: userPassword
…

# db_dump -p /etc/sasldb2 
VERSION=3
format=print
type=hash
h_nelem=4
db_pagesize=4096
HEADER=END
 replication\00ldap-master\00userPassword
 PasswordCensored
…

Im Fall von DIGEST-MD5und CRAM-MD5scheint es jedoch überhaupt keinen Kontakt saslauthdzu geben (weil ich möglicherweise etwas vermisse oder etwas falsch mache), sodass die Datenbank wahrscheinlich auch nicht konsultiert wird.

Mein Rezept ist, dass OpenLDAP direkt überprüft /etc/sasldb2.

Erster Schritt: /etc/sasldb2Stellen Sie sicher, dass der Benutzer dem Benutzer slapd gehört.

Nächster Schritt: Sie müssen slapdnicht nach Anmeldeinformationen in der Verzeichnisstruktur suchen. Dies geschieht wie folgt:

dn: cn=config
changetype: modify
replace: olcSaslAuxprops
olcSaslAuxprops: sasldb

Später benötigen Sie auch eine olcAuthzRegexpRegel, aber um zu testen, ob die Authentifizierung funktioniert, ist dies nicht erforderlich.

Diese Einstellungen funktionieren unter Debian GNU / Linux Jessie OpenLDAP-2.4.40, das aus dem Quellcode erstellt wurde.

Die Methoden CRAM-MD5 und DIGEST-MD5 sind mit "pwcheck_method: saslauthd" nicht möglich. Sie benötigen einfache, unverschlüsselte Kennwörter in einem LDAP-Verzeichnis.

Ich habe einige umfangreiche Tests mit verschiedenen Konfigurationen mit unterschiedlichen Anmeldeinformationen durchgeführt sasldb.

Zusammenfassend stellt sich heraus, dass das Problem, das mich hier am meisten verfolgt hat, darin bestand, dass nach der verwendeten Authentifizierungsmethode ( saslauthdvs. auxprop) (die wiederum vom angeforderten Authentifizierungsmechanismus abhängt - DIGEST-MD5/ CRAM-MD5vs. PLAIN/ LOGIN) nach einer anderen gesucht wurde domain. Ich hatte das nicht erwartet und da ich nur ein Benutzer-Domain-Paar im hatte sasldb, fand es das andere nicht.

Ich werde einige meiner Schlussfolgerungen und Beobachtungen auflisten, in der Hoffnung, dass dies anderen hilft, das Problem zu verstehen und es zu umgehen:

1. Falls Sie eine Anfrage PLAINoder einen LOGINMechanismus anfordern , slapdverwenden Sie die unter pwcheck_methodin konfigurierte Authentifizierungsmethode /etc/ldap/sasl2/slapd.conf.
2. Falls Sie eine Anfrage DIGEST-MD5oder einen CRAM-MD5Mechanismus anfordern , slapdwird die auxpropMethode immer verwendet , unabhängig davon, wofür sie konfiguriert ist pwcheck_method.
3. Tatsächlich bedeutet dies slapd, dass Sie bei der Konfiguration für alle vier Mechanismen dieselbe Methode verwenden können pwcheck_method: auxprop. Oder Sie können zwei verschiedene Methoden verwenden, wenn Sie etwas anderes für konfigurieren pwcheck_method.
4. In jedem Fall wird auxprop_pluginin /etc/ldap/sasl2/slapd.confignoriert. slapdVerwendet stattdessen das, wofür olcSaslAuxpropsin der eigenen Konfigurationsdatenbank konfiguriert ist. Beachten Sie, dass dies sowohl für die implizite auxpropMethode beim Anfordern DIGEST-MD5oder für CRAM-MD5Mechanismen als auch für die explizit konfigurierte Methode pwcheck_method: auxpropbeim Anfordern eines der beiden anderen Mechanismen gilt.
5. In meinem Fall saslauthdwerden die Anmeldeinformationen mit dem schmucklosen Hostnamen (dh nur ldap-master) als domainKomponente nachgeschlagen. Wenn ich eine fundierte Vermutung anstellen würde, würde ich sagen, dass es so etwas wie gethostname()eine Idee gibt, also könnte dies irgendwie konfigurierbar sein.
6. In meinem Fall wird beim Durchlaufen der auxpropeinen oder anderen Methode slapdder vollständig qualifizierte Domänenname (dh ldap-master.example.com) als domainKomponente verwendet. Dies wird wahrscheinlich von der ursprünglichen Anforderungs-URL abgerufen (meine Alternativen zum Generieren der Anforderung sind begrenzt, wenn ich STARTTLS verwenden und das Serverzertifikat, das nach einem passenden Domänennamen fragt, korrekt überprüfen möchte), aber es kann wahrscheinlich sein konfiguriert durch Einstellen olcSaslHostin slapdder Konfigurationsdatenbank. Beachten Sie, dass ich nicht versucht habe, es zu konfigurieren.

Um eine funktionierende Konfiguration zu erstellen, haben Sie mehrere Möglichkeiten:

1. Wenn Sie mit Just PLAINund LOGINMechanismen über STARTTLS einverstanden sind, konfigurieren Sie sie pwcheck_methodnach /etc/ldap/sasl2/slapd.confBedarf. Wenn dies der Fall sein soll auxprop, konfigurieren Sie es auch olcSaslAuxpropsin slapdder Konfigurationsdatenbank (setzen Sie es sasldbbeispielsweise auf, wenn Sie es /etc/sasldb2als Anmeldeinformationsspeicher verwenden möchten ).
2. Wenn Sie mit nur in Ordnung sind DIGEST-MD5(ich sehe es normalerweise CRAM-MD5aufgrund schlechterer Sicherheit empfohlen, vermeiden Sie es also), legen Sie es olcSaslAuxpropsin slapdder Konfigurationsdatenbank fest, da die auxpropMethode verwendet wird, unabhängig davon, wofür Sie sie konfigurieren pwcheck_method.
3. Wenn Sie Mechanismen in der Lage sein wollen , sowohl die Menge von verwenden DIGEST-MD5, CRAM-MD5(aber versuchen zu vermeiden CRAM-MD5) sowie der Satz PLAIN, LOGIN(stellen Sie sicher , diejenigen , die nur über eine verschlüsselte Verbindung verwendet werden, wie ein STARTTLS-on) und es vorziehen , die verwenden Sie sind auf dieselbe Authentifizierungsmethode für alle beschränkt und prüfen anhand derselben Anmeldeinformationen, auf die Sie beschränkt sind auxprop. Konfigurieren Sie pwcheck_method: auxpropin /etc/ldap/sasl2/slapd.confund Satz olcSaslAuxpropsin slapd‚s - Konfigurationsdatenbank nach Bedarf.

4. Wenn Sie möchten , Mechanismen können Sätze von beiden verwenden , während verschiedene Authentifizierungsmethoden für sie verwenden (klingt wie eine Verwaltung Alptraum für mich, aber es Sie gehen), configure pwcheck_methodin /etc/ldap/sasl2/slapd.confentsprechend für PLAINund LOGINund denken Sie daran , dass Sie Gebrauch gezwungen sind , auxpropfür DIGEST-MD5( und CRAM-MD5wenn Sie darauf bestehen) und stellen olcSaslAuxpropsin slapd‚s - Konfigurationsdatenbank nach Bedarf.

   • Wenn Sie zufällig saslauthdfür nicht beschädigte Mechanismen konfigurieren und sicherstellen, dass saslauthd auf eine andere Datenbank slapdzugreift als die, über die zugegriffen wird, auxpropoder etwas anderes als sasldbfür verwendet olcSaslAuxprops, haben Sie diese gut getrennt und brauchen sich keine Sorgen zu machen.

   • Wenn Sie zufällig saslauthdfür nicht gehashte Mechanismen und sasldbfür auxpropdie gehashten Mechanismen konfigurieren und diese auf dieselbe Datenbank mit Anmeldeinformationen zugreifen lassen, haben Sie drei Optionen in der Reihenfolge ihrer Präferenz:

     1. Stellen Sie irgendwie sicher, dass sowohl saslauthdals auch slapdder direkte Zugriff auf die sasldb durch auxpropAbfragen der Anmeldeinformationen mit denselben domain(versuchen olcSaslHostSie saslauthd, einen vollqualifizierten Domänennamen festzulegen oder zu erzwingen ) erforderlich sind , sodass Sie sich nur um einen Eintrag für Anmeldeinformationen pro Entität kümmern müssen, um sich zu authentifizieren.
     2. Treffen Sie absichtlich die Entscheidung, unterschiedliche Anmeldeinformationen für die nicht gehashten und die gehashten Mechanismen zu verwenden. Verwenden Sie ein userid- hostnamePaar für die ungehashte Mechanismen über saslauthdund verwenden Sie ein userid- hostname.domain.namePaar für die Hash - Mechanismen über auxprop.
     3. Behalten Sie zwei Einträge für die Authentifizierung pro Entität bei, um sich zu authentifizieren - einen mit 'Hostname' und einen mit 'Hostname.Domain.Name' - und halten Sie die Kennwörter beider synchron (ugh).