web-dev-qa-db-ja.com

SASL認証をOpenLDAPのDIGEST-MD5と連携させる方法

Ubuntu 14.04 Trusty TahrでOpenLDAP slapdを設定しています。ユーザーではない特定のインスタンス（レプリケーションなど）が、DIGEST-MD5メカニズムを使用してSASL経由でログインできるようにしたい。

ユーザーとは異なり、それらはないディレクトリツリーに対応するDN（およびパスワード）があるはずです。代わりに、資格情報は外部に保存されることになっているため、SASLになります。

私は現在saslauthdを使用しています（たとえば、sasldbへの直接アクセスで動作させることができる場合、これは難しい要件ではありません）。メカニズムDIGEST-MD5を使用すると失敗しますが、メカニズムPLAINおよびLOGINを使用すると正常に動作します。およびCRAM-MD5。

何が欠けているか、間違っていますか？ DIGEST-MD5を使用するにはどうすればよいですか？


OpenLDAPは、/etc/ldap/sasl2/slapd.confのSASLに対して次のように構成されています。

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と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 これらの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にまったく連絡していないようです（おそらく何か不足している、または何か間違っているため）。そのため、データベースも参照されない可能性があります。 。

ldapopenldapsaslsaslauthd
8
blubberdiblub

私のレシピはOpenLDAPが直接チェックすることです/etc/sasldb2。

最初のステップ：/etc/sasldb2はslapdユーザーが所有しています。

次のステップ：ディレクトリツリーで認証情報を検索しないようにslapdを設定します。これは次のように行われます。

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

後で、olcAuthzRegexpルールも必要になりますが、認証が機能するかどうかをテストするために、これは必要ありません。

これらの設定は、ソースからビルドされたDebian GNU/Linux Jessie OpenLDAP-2.4.40で機能しています。

4
473183469

CRAM-MD5およびDIGEST-MD5メソッドは、「pwcheck_method：saslauthd」では不可能です。 LDAPディレクトリ自体に、暗号化されていないプレーンなパスワードが必要です。

2
kupson

sasldbのさまざまな資格情報を使用して、さまざまな構成に対していくつかの広範なテストを実行しました。

結論として、ここで私が最も悩まされている問題は、どの認証方法（saslauthdとauxprop）のどちらが使用されているかによって決まります（これは、要求された認証メカニズムに依存します-_DIGEST-MD5_/_CRAM-MD5_とPLAIN/LOGINの比較）、別のdomainを探していました。私はそれを期待していなかったし、sasldbにユーザーとドメインのペアが1つしかなかったので、もう1つは見つかりませんでした。

他の人が問題を理解して回避するのに役立つことを期待して、私の結論と観察の一部をリストします。

  1. PLAINまたはLOGINメカニズムをリクエストする場合、slapdは_pwcheck_method_の_/etc/ldap/sasl2/slapd.conf_で設定された認証方法を使用します。
  2. _DIGEST-MD5_または_CRAM-MD5_メカニズムを要求した場合、_pwcheck_method_の構成に関係なく、slapdは常にauxpropメソッドを使用します。
  3. つまり、_pwcheck_method: auxprop_を設定すると、slapdで4つのメカニズムすべてに同じメソッドを使用できるようになります。または、_pwcheck_method_に対して何か他のものを構成する場合、2つの異なる方法を使用することを決定できます。
  4. いずれの場合も、_auxprop_plugin_内の_/etc/ldap/sasl2/slapd.conf_は無視されます。代わりに、slapdは、独自の構成データベースでolcSaslAuxpropsに構成されているものを使用します。これは、_DIGEST-MD5_または_CRAM-MD5_メカニズムを要求するときの暗黙のauxpropメソッドと、他の2つのメカニズムの1つを要求するときの明示的に構成された_pwcheck_method: auxprop_の両方に当てはまることに注意してください。
  5. 私の場合、saslauthdは、修飾されていないホスト名（つまり、_ldap-master_のみ）を使用して、domainコンポーネントとして認証情報を検索します。経験に基づいた推測をするなら、それはgethostname()のようなものを使用してそれを考え出すと言うので、これは何とか構成可能かもしれません。
  6. 私の場合、auxpropを何らかの方法で通過するとき、slapdはdomainコンポーネントとして完全修飾ドメイン名（つまり、_ldap-master.example.com_）を使用します。元のリクエストURLからそれを取得する可能性があります（STARTTLSを使用して、一致するドメイン名を要求するサーバー証明書を正しく検証できるようにしたい場合、リクエストを生成するための代替手段は限られています）。 olcSaslHostの構成データベースでslapdを設定して構成されます。まだ設定していないことに注意してください。

したがって、実際の構成を考え出すには、いくつかのオプションがあります。

  1. STARTTLSでPLAINとLOGINのメカニズムだけで問題ない場合は、必要に応じて_pwcheck_method_で_/etc/ldap/sasl2/slapd.conf_を構成します。 auxpropにする場合は、olcSaslAuxpropsの構成データベースでslapdも構成します（たとえば、資格情報ストアとして_/etc/sasldb2_を使用する場合は、sasldbに設定します）。
  2. _DIGEST-MD5_だけで問題ない場合（セキュリティが低いため、通常は_CRAM-MD5_が推奨されないので避けてください）、olcSaslAuxpropsの構成データベースでslapdメソッドを使用するため、auxpropを設定します、_pwcheck_method_の構成に関係なく。
  3. セット_DIGEST-MD5_、_CRAM-MD5_（ただし、_CRAM-MD5_）とセットPLAIN、LOGINの両方のメカニズムを使用できるようにしたい場合は、 STARTTLS-oneなどの暗号化された接続を介して使用され、それらすべてに対して同じ認証方法を使用し、同じ資格情報のセットに対してチェックすることを好む場合、auxpropに制限されます。 _pwcheck_method: auxprop_で_/etc/ldap/sasl2/slapd.conf_を構成し、必要に応じてolcSaslAuxpropsの構成データベースでslapdを設定します。

  4. 異なる認証方法を使用しながら両方のセットのメカニズムを使用できるようにしたい場合（管理の悪夢のように聞こえますが、これで終わりです）PLAINに応じて_pwcheck_method_に_/etc/ldap/sasl2/slapd.conf_を構成します。 LOGINおよびauxpropを_DIGEST-MD5_（および主張する場合は_CRAM-MD5_）に強制的に使用し、必要に応じてolcSaslAuxpropsの構成データベースでslapdを設定する必要があることを覚えておいてください。

    • ハッシュされていないメカニズムに対してsaslauthdを構成し、saslauthdがslapdを介してauxpropを介してアクセスするデータベースとは異なるデータベースにアクセスするか、sasldb以外の何かをolcSaslAuxpropsに使用する場合、それらはうまく分離されており、心配する必要はありません。

    • ハッシュされていないメカニズムに対してsaslauthdを構成し、ハッシュされたメカニズムに対してsasldbに対してauxpropを構成して、それらに同じ資格情報データベースにアクセスさせる場合、優先順位の高い3つのオプションがあります。

      1. どういうわけか、saslauthdと、slapdを介して直接sasldbにアクセスするauxpropの両方が、同じdomainを使用して資格情報をクエリすることを確認します（olcSaslHostを設定するか、saslauthdを強制して、エンティティごとに1つのエンティティのみに資格情報を指定します。認証する。
      2. ハッシュ化されていないメカニズムとハッシュ化されたメカニズムに異なる資格情報を使用することを意図的に決定します。 useridのハッシュ化されていないメカニズムにはhostname-saslauthdペアを使用し、useridを介してハッシュされたメカニズムにはauxprop-_hostname.domain.name_ペアを使用します。
      3. 認証するエンティティごとに2つの認証情報エントリを保持します-1つは「hostname」を使用し、もう1つは「hostname.domain.name」を使用します-両方のパスワードを同期します（ugh）。
0
blubberdiblub