CentOS 8 389 Directory Server 構築 #3 – BIND ユーザーとアクセス制御

CentOS 8 は既に通常の CentOS Linux としてはサポートが終了しています。このページは新規構築を推奨するものではなく、過去環境の保守、移行前調査、設定の読み解きに使うためのレガシー Linux 手順です。新規構築では、現在サポートされているディストリビューションを利用してください。

CentOS 8 サーバー管理ガイドへ戻る

CentOS 8 の 389 Directory Server で、アプリケーション用の BIND ユーザーとアクセス制御を整理する手順です。LDAP を使うアプリケーションは、Directory Manager ではなく、参照用途に限定した BIND DN で接続させるのが基本です。

ここでは、読み取り専用のサービスアカウントを作成し、どの範囲を読ませるかを明確にします。LDAP 連携では、認証できることよりも、不要な属性や不要な DN を読ませないことが重要です。

BIND ユーザー用 OU を用意する

dn: ou=Services,dc=example,dc=local
objectClass: organizationalUnit
ou: Services

BIND ユーザーを登録する

dn: uid=ldap-reader,ou=Services,dc=example,dc=local
objectClass: inetOrgPerson
objectClass: simpleSecurityObject
uid: ldap-reader
cn: LDAP Reader
sn: Reader
userPassword: change_this_password

ldapadd -x -D "cn=Directory Manager" -W -f ldap-reader.ldif

BIND できるか確認する

ldapwhoami -x -D "uid=ldap-reader,ou=Services,dc=example,dc=local" -W

検索できる範囲を確認する

ldapsearch -x -D "uid=ldap-reader,ou=Services,dc=example,dc=local" -W -b dc=example,dc=local "(uid=user01)"

アクセス制御の考え方

389 Directory Server のアクセス制御は、運用上かなり重要です。アプリケーション連携用 BIND ユーザーには、必要な subtree と属性だけを読ませ、管理操作やパスワード属性の扱いは慎重に分けます。

確認するポイント

• アプリケーションが Directory Manager で接続していないか。
• BIND ユーザーのパスワード管理が明確か。
• 読ませる subtree と属性が過剰でないか。
• SSSD、Samba、Postfix など用途ごとに BIND DN を分ける必要があるか。

まとめ

LDAP 連携では、接続できることより、どの DN で接続し、どの範囲を読めるかが重要です。CentOS 8 の 389 Directory Server では、Directory Manager、BIND ユーザー、一般ユーザーの責務を分けることで、後続の認証連携やアプリケーション連携を安全に整理できます。

関連する記事

参考書籍

関連記事

CentOS 8 389 Directory Server 構築 #1 – 導入と TLS 証明書の登録 CentOS 8 389 Directory Server 構築 #2 – 初期データ登録 CentOS 8 389 Directory Server IPv4 が Listen しないように見える場合 CentOS 8 389 Directory Server legacy setup-ds.pl – 旧導入方式の位置づけ CentOS 8 389 Directory Server – 特定インスタンスを削除する CentOS 8 389 Directory Server と Samba – LDAP スキーマ連携の基本 CentOS 8 389 Directory Server と Postfix – メールエイリアス LDAP 連携 CentOS 8 BIND 内部 DNS サーバー構築 – forwarder と内部ゾーン