web-dev-qa-db-ja.com

ldap-2.4でTLSを有効にした後、EXTERNAL認証を使用できません

次のLDIFファイルを使用して、LDAPサーバーのTLSサポートをアクティブ化しました。

dn: cn=config
changetype: modify
add: olcTLSCipherSuite
olcTLSCipherSuite: NORMAL 
-
add: olcTLSCRLCheck
olcTLSCRLCheck: none
-
add: olcTLSVerifyClient
olcTLSVerifyClient: never
-
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/CA.crt
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/server.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/key.pem

次のLDIFを使用したクライアント接続のTLS使用を強制します。

dn: cn=config
changetype: modify
add: olcSecurity
olcSecurity: tls=1

この後、「-YEXTERNAL」を使用して構成スキーマを読み取ったり変更したりすることはできなくなります。たとえば、次のコマンドを実行すると、SASLエラーが発生します。

$ Sudo ldapsearch -Q -Y EXTERNAL -H ldapi:/// -b "" -LLL -s base -Z supportedSASLMechanisms
ldap_sasl_interactive_bind_s: Authentication method not supported (7)
    additional info: SASL(-4): no mechanism available:

サポートされているSASLメカニズムを確認すると、次のようになります。

$ Sudo ldapsearch -x -H ldapi:/// -b "" -LLL -s base -Z supportedSASLMechanisms
dn:
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: LOGIN

私は本当にリストに含まれているEXTERNALを見ることができません。ここで何が欠けていますか？

これはUbuntu-12.04とslapd-2.4.31にあります。

openldapsasl
3
user202

実行中の構成にアクセスできない場合は、slapdを停止して、構成をオフラインで編集する必要があります。

  1. 停止slapd：service slapd stop
  2. 構成データベースをテキストファイルにダンプします：slapcat -F /etc/ldap/slapd.d -b cn=config -l config.ldif
  3. 既存の構成データベースを邪魔にならない場所に移動します：mv /etc/ldap/slapd.d{,.old}

  4. 新しい空の構成データベースを作成します。

    mkdir /etc/ldap/slapd.d chown --reference=/etc/ldap/slapd.d.old /etc/ldap/slapd.d chmod --reference=/etc/ldap/slapd.d.old /etc/ldap/slapd.d

  5. ダンプされたconfig.ldifを編集してolcSecurity設定を削除します（またはolcRootDNとolcRootPWをcn=configに追加するか、その他の変更を加えます）
  6. 編集したLDIFを新しい空のデータベースにロードします：slapadd -F /etc/ldap/slapd.d -b cn=config -l config.ldif

（上記は、設定が/etc/ldap/slapd.dにあることを前提としています。これは、DebianとUbuntuのデフォルトです。）

完全なLDIFのslapaddは、常に空のデータベースで実行する必要があることに注意してください。したがって、間違えてslapaddが失敗した場合は、再試行する前にデータベースの一部をクリアしてください。

詳細については、 OpenLDAP管理者ガイド および関連するマニュアルページを参照してください。

2
rtandy

コードを調べます。サーバー側では、 servers/slapd /デーモン.c で、EXTERNALのauthidは、着信接続がaccept()の直後にuidとgidを使用して設定されます。 ed。後で、 servers/slapd/connection.c で、TLSがアクティブな場合、クライアントの証明書の名前で上書きされます。クライアント証明書を提供していないため、この時点でauthidはNULLで上書きされ、EXTERNALは使用できなくなります。

つまり、TLSがアクティブな場合、uid + gidauthidは使用されません。見方によっては、これはバグと見なされる可能性があります。理想的には、peercredIDにフォールバックします。

とはいえ、ローカルソケットはすでに完全なプライバシーを提供しているため、ldapiでのTLSは実際には必要ありません。したがって、olcSecurityを自分のデータベースだけに設定し、フロントエンドとcn=configには設定しないでおくか（たとえば、 この投稿 を参照）、ssf=tls=の代わりに、olcLocalSSFを適切に設定します。または、peercred機能に依存しないように、cn=configのマネージャーとして別のDNを使用することもできます。

2
rtandy

Rtandyに感謝します。私は本当にそれをldapiに設定したくありませんでしたが、それが影響を受けるという事実にも気づいていませんでした。

問題は、EXTERNALがcn=configを変更できる唯一の方法だったため、そのアクセス権を失い、提案されているように別のcn=config管理者を作成していないため、これを解決できる他の方法はありますか？

0
user202