如何讓 SASL 身份驗證與 DIGEST-MD5 一起用於 OpenLDAP？

slapd我正在Ubuntu 14.04 Trusty Tahr 上設置 OpenLDAP 。我希望某些不是使用者的實例（複製等）能夠通過SASL使用DIGEST-MD5機制登錄。

與使用者不同，他們不應該在目錄樹中具有相應的 DN（連同密碼）。相反，他們的憑據應該儲存在外部，因此SASL.

我現在正在使用saslauthd（例如，如果可以直接訪問 sasldb，這不是硬性要求）並且使用機制可以正常工作PLAIN，LOGIN而使用機制DIGEST-MD5和CRAM-MD5.

我錯過了什麼或做錯了什麼？我怎樣才能讓它工作DIGEST-MD5？

SASLOpenLDAP的 配置/etc/ldap/sasl2/slapd.conf如下：

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 日誌中似乎失敗的部分（日誌記錄已開啟any）如下所示：

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

/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" -> "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

/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顯然，它與andLOGIN與DIGEST-MD5and 的工作方式必須有所不同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" read by * 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
replication\00ldap-master\00userPassword
PasswordCensored
…

但是，在的情況下DIGEST-MD5，CRAM-MD5它似乎根本沒有聯繫saslauthd（由於我可能遺漏了什麼或做錯了什麼），因此也可能沒有諮詢數據庫。

我的方法是讓 OpenLDAP 直接檢查/etc/sasldb2。

第一步：確保/etc/sasldb2由 slapd 使用者擁有。

下一步：不必slapd在目錄樹中查找憑據，操作如下：

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

稍後，您還需要一個olcAuthzRegexp規則，但為了測試 auth 是否有效，這不是必需的。

這些設置適用於從原始碼建構的 Debian GNU/Linux Jessie OpenLDAP-2.4.40。

CRAM-MD5 和 DIGEST-MD5 方法無法使用“pwcheck_method: saslauthd”。他們需要 LDAP 目錄本身中的普通、未加密的密碼。

引用自：https://serverfault.com/questions/744050