コンテンツにスキップ

TLS・ACL・運用上の注意

LDAP では、通信の保護、Bind 情報の扱い、ACL、キャッシュ、バックアップを分けて考える。


Simple Bind は DN とパスワードで認証するため、通信経路の保護が重要である。

避けるべき構成は、暗号化されていない ldap:// で Simple Bind のパスワードを送ることである。

安全に使うには、次のどちらかを使う。

方法 説明
StartTLS ldap:// で接続したあと TLS へ昇格する
ldaps:// 最初から TLS で接続する

OpenLDAP クライアントコマンドでは、StartTLS を要求する場合に -ZZ を使う。

Terminal window
ldapsearch \
-x \
-ZZ \
-H ldap://ldap.example.com \
-D "uid=ldapuser,ou=people,dc=example,dc=com" \
-W \
-b "dc=example,dc=com"

ACL は Access Control List の略で、どの認証 ID がどのエントリ・属性を読めるか、変更できるかを決める。

OpenLDAP の ACL は、主に olcAccess として cn=config に設定する。

ACL で考える対象は、エントリ単位だけではない。属性単位でも制御できる。

たとえば、一般ユーザーに userPassword を読ませない、本人だけ自分のパスワードを変更できる、管理者だけユーザーを追加できる、というような制御を行う。


通常データベースの rootDN は、そのデータベースに対する特権 DN である。

olcRootDN: cn=admin,dc=example,dc=com

ただし、これは Linux root と同じではない。また、 cn=config の管理権限とも別である。

cn=admin,dc=example,dc=com が通常データを管理できても、 cn=config を変更できるとは限らない。 cn=config の ACL が別に判断する。


LDAP サーバーは、設定次第で匿名検索を許可できる。

学習環境では便利だが、運用では公開する属性を慎重に選ぶ必要がある。

特に注意する属性は次のとおり。

  • userPassword
  • メールアドレス
  • 電話番号
  • 所属情報
  • 管理者 DN

匿名アクセスを許可する場合でも、検索ベースや属性を絞る。


LDAP のデータを変更しても、Linux 側の結果がすぐ変わらないことがある。

原因として、次のキャッシュがある。

キャッシュ 例
nscd NSS の passwd / group / hosts など
SSSD NSS / PAM 用の ID 情報や認証情報
アプリケーション 独自のユーザー情報キャッシュ

検証時は、どの層を見ているかを分ける。

Terminal window
ldapsearch ...
getent passwd ldapuser
id ldapuser

ldapsearch は新しい値を返すのに getent が古い場合、LDAP サーバーではなく NSS / SSSD / nscd のキャッシュを疑う。


LDAP は設定とデータを分けてバックアップする。

対象 例
設定 cn=config、 slapd.d
データ dc=example,dc=com のデータベース
証明書・鍵 TLS 用の証明書、秘密鍵、CA 証明書
クライアント設定 nslcd.conf、 sssd.conf、 nsswitch.conf、PAM 設定

データベースの LDIF バックアップには slapcat を使うことが多い。復旧には slapadd を使うが、通常は slapd を停止してから行う。


OpenLDAP を運用する前に、少なくとも次を決める。

  • base DN
  • ユーザー・グループを置くツリー構造
  • UID / GID の採番ルール
  • NSS / PAM クライアントとして nslcd を使うか SSSD を使うか
  • Bind 用管理者と読み取り専用アカウント
  • TLS の方式
  • 匿名アクセスの可否
  • ACL の方針
  • バックアップと復旧手順