如何使用SASL身份验证与DIGEST-MD5 for OpenLDAP一起使用？

我正在Ubuntu 14.04 Trusty Tahr上设置OpenLDAP slapd.我希望某些非用户的实例(复制等)能够使用DIGEST-MD5机制通过SASL登录.

与用户不同,它们不应该在目录树中具有相应的DN(以及密码).相反,他们的凭证应该存储在外部,因此SASL.

我现在正在使用saslauthd(例如,如果能够直接访问sasldb,这不是一个很难的要求)并且使用机制PLAIN和LOGIN可以正常工作,而它使用机制DIGEST-MD5和CRAM失败-MD5.

我错过了什么或做错了什么？如何让它与DIGEST-MD5一起使用？

在/etc/ldap/sasl2/slapd.conf中为SASL配置了OpenLDAP,如下所示：

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

/ etc / default / saslauthd中有趣的(已更改的)选项是：

START=yes
MECHANISMS="sasldb"

他们导致saslauthd像这样开始：

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

我使用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

slapd日志中似乎失败的部分(日志记录在其中)看起来像这样：

slapd[23330]: [rw] authid: "uid=replication,cn=digest-md5,cn=auth" -> "uid=replication,cn=auth"
slapd[23330]: slap_parseURI: parsing uid=replication,cn=auth
slapd[23330]: >>> dnNormalize: <uid=replication,cn=auth>
slapd[23330]: <<< dnNormalize: <uid=replication,cn=auth>
slapd[23330]: <==slap_sasl2dn: Converted SASL name to uid=replication,cn=auth
slapd[23330]: slap_sasl_getdn: dn:id converted to uid=replication,cn=auth
slapd[23330]: SASL Canonicalize [conn=1002]: slapAuthcDN="uid=replication,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

当我手动运行时,在/var/log/auth.log和saslauthd的调试输出中都没有任何内容,这可能表明slapd甚至没有将身份验证转交给saslauthd(与工作案例相比),见下文).

我使用PLAIN或LOGIN重现工作案例,如下所示：

# 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
…

slapd日志中指示上述情况失败的相应部分现在如下所示：

slapd[23330]: [rw] authid: "uid=replication,cn=plain,cn=auth
slapd[23330]: SASL Canonicalize [conn=1006]: slapAuthcDN="uid=replication,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=auth" mech=PLAIN sasl_ssf=0 ssf=128
slapd[23330]: do_bind: SASL/PLAIN bind: dn="uid=replication,cn=auth" sasl_ssf=0
slapd[23330]: send_ldap_response: msgid=2 tag=97 err=0

/var/log/auth.log和saslauthd的调试输出现在都包含：

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

显然,PLAIN和LOGIN与DIGEST-MD5和CRAM-MD5的工作原理必然存在差异.

更新和澄清：

用于授权访问树的DN分别是uid = replication,cn = digest-md5,cn = auth和uid = replication,cn = plain,cn = auth,根据http://www.openldap.org/doc/admin24/sasl.html的第15.2.5节,这些DN没有需要实际存在于树中(至少对于PLAIN和LOGIN必须是真的,因为它在那里工作正常).
出于测试目的,我目前正在使用olcAccess：to * by dn.regex =“replication”读取* break以确保复制登录至少获得对所有内容的读取权限(是的,我知道这不安全,我会给它正确的主LDAP树中的生产权限.

凭据位于/ etc / sasldb2中,使用PLAIN或LOGIN时会成功检查凭据(参见上文).作为参考,它看起来像这样：

# sasldblistusers2
replication@ldap-master: userPassword
…

# db_dump -p /etc/sasldb2 
VERSION=3
format=print
type=hash
h_nelem=4
db_pagesize=4096
HEADER=END
 replication0ldap-master0userPassword
 PasswordCensored
…

但是,在DIGEST-MD5和CRAM-MD5的情况下,它似乎根本没有联系saslauthd(由于我遗漏了某些东西或者做错了,可能),所以也可能没有咨询数据库.

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