すぐ動かす — 5分でLDAPサーバーを起動する
まず動かして、理論は後で。以下のコマンドを順番に実行すれば、5分でLDAPサーバーが接続を受け付ける状態になります：
# 389 Directory Serverのインストール
sudo dnf install 389-ds-base -y
# インスタンス設定ファイルの作成
cat > /tmp/ds-setup.inf << 'EOF'
[general]
config_version = 2
full_machine_name = ldap.company.com
[slapd]
instance_name = company
root_dn = cn=Directory Manager
root_password = StrongP@ssword123!
port = 389
secure_port = 636
[backend-userRoot]
suffix = dc=company,dc=com
sample_entries = yes
EOF
sudo dscreate from-file /tmp/ds-setup.inf# サービスの有効化と起動
sudo systemctl enable --now dirsrv@company
# 接続確認
ldapsearch -x -H ldap://localhost \
-b "dc=company,dc=com" \
-D "cn=Directory Manager" -W \
"(objectClass=*)" dn最後のコマンドがDNのリストを返しましたか？よし — LDAPサーバーは動いています。次は各部分を説明して、今やったことを理解してもらいます。
389 Directory Server — なぜこれを選ぶのか？
私はDebian上のOpenLDAP、RHEL 7上のFreeIPA、SSSD経由でLinuxと連携したADの3つすべてを運用してきました。RHEL/CentOS環境で純粋なLDAPが必要なとき、389 DSが一番よく戻ってくる選択肢です — 慣れているからではなく、Red Hatエコシステムに本当に合っているからです。
2021年にCentOS 8がEOLを迎えたとき、私は1週間で5台のサーバーをRocky Linuxへ急いで移行しました。結果：389 DSを動かしていたサーバーはほぼzero-configで移行完了 — パッケージは完全互換、dataディレクトリはそのまま、再インストールして正しいパスを指定するだけで終わりました。OpenLDAPを使っていたサーバーは？スキーマの再構築に1台あたり半日かかりました。
簡単な比較：
- vs OpenLDAP：389 DSにはWebコンソール（cockpit-389-ds）があり、組み込みレプリケーションの設定が簡単で、ログも詳細
- vs FreeIPA：389 DSははるかに軽量で、Kerberos/DNS/CAを引き連れません — RAMが限られているサーバーやLDAPのみが必要な場合に最適
- vs Active Directory：Windowsライセンス不要、Linuxエコシステムとネイティブ統合
インストール前の環境準備
ホスト名とファイアウォールの設定
389 DSはホスト名が解決できる必要があります — このステップが最もよく見落とされ、欠けていると dscreate がかなり分かりにくいTLSエラーで失敗します：
# FQDNでホスト名を設定
sudo hostnamectl set-hostname ldap.company.com
# 内部DNSがない場合は/etc/hostsに追加
echo "192.168.1.10 ldap.company.com ldap" | sudo tee -a /etc/hosts
# LDAPとLDAPSポートを開放
sudo firewall-cmd --permanent --add-service=ldap
sudo firewall-cmd --permanent --add-service=ldaps
sudo firewall-cmd --reload
# ホスト名が解決できるか確認
python3 -c "import socket; print(socket.getfqdn())"ユーザーとグループの管理
OU構造の作成
インスタンスの準備ができました。まずユーザーとグループを分類するOUを作成します — これが最もよく使われる最小構造です：
cat > /tmp/add-ou.ldif << 'EOF'
dn: ou=users,dc=company,dc=com
objectClass: organizationalUnit
ou: users
dn: ou=groups,dc=company,dc=com
objectClass: organizationalUnit
ou: groups
EOF
ldapadd -x -H ldap://localhost \
-D "cn=Directory Manager" -W \
-f /tmp/add-ou.ldif新しいユーザーの追加
# 先にパスワードハッシュを作成
pwdhash -s SSHA "UserPassword123!"
# 出力例: {SSHA}abc123...== — その文字列をコピーして下のuserPasswordフィールドに貼り付ける
# ユーザーエントリの作成
cat > /tmp/add-user.ldif << 'EOF'
dn: uid=john,ou=users,dc=company,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: john
cn: John Doe
sn: Doe
mail: [email protected]
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/john
loginShell: /bin/bash
userPassword: {SSHA}REPLACE_WITH_PWDHASH_OUTPUT
EOF
ldapadd -x -H ldap://localhost \
-D "cn=Directory Manager" -W \
-f /tmp/add-user.ldif検索と確認
# 作成したユーザーを検索
ldapsearch -x -H ldap://localhost \
-D "cn=Directory Manager" -W \
-b "ou=users,dc=company,dc=com" \
"(uid=john)" uid cn mail uidNumber
# そのアカウントでログインテスト
ldapwhoami -x -H ldap://localhost \
-D "uid=john,ou=users,dc=company,dc=com" \
-W応用編 — TLSの有効化とLinuxクライアント統合
LDAPSの有効化（本番環境では必須）
本番環境でTLSなしのLDAPを使うということは、認証情報がネットワーク上をプレーンテキストで流れることを意味します — やめましょう。389 DSには証明書を管理する dsconf ツールがあります：
# Let's Encryptまたは内部CAを使う場合
sudo dsconf company security certificate add \
--file /etc/pki/tls/certs/ldap.crt \
--name "server-cert"
sudo dsconf company security rsa enable
# またはdsctlでself-signed証明書を作成
sudo dsctl company tls generate-server-cert-csr \
--subject "CN=ldap.company.com,O=Company,C=VN"
sudo systemctl restart dirsrv@company
# LDAPSのテスト
ldapsearch -x -H ldaps://ldap.company.com \
-D "cn=Directory Manager" -W \
-b "dc=company,dc=com" "(uid=john)"sssdを使ったLinuxクライアント統合
他のサーバーをこのLDAPで認証させたいですか？各クライアントに sssd をインストールし、セットアップしたLDAPサーバーを指定します：
# クライアントマシンで
sudo dnf install sssd sssd-ldap authselect -y
sudo authselect select sssd with-mkhomedir --force
sudo tee /etc/sssd/sssd.conf << 'EOF'
[sssd]
services = nss, pam
config_file_version = 2
domains = company.com
[domain/company.com]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://ldap.company.com
ldap_search_base = dc=company,dc=com
ldap_default_bind_dn = cn=Directory Manager
ldap_default_authtok_type = password
ldap_default_authtok = StrongP@ssword123!
ldap_tls_cacert = /etc/pki/ca-trust/source/anchors/company-ca.crt
ldap_id_use_start_tls = True
cache_credentials = True
EOF
sudo chmod 600 /etc/sssd/sssd.conf
sudo systemctl enable --now sssd
# LDAPユーザーが見えるか確認
id johnパスワードポリシーの設定
# 389 DSの組み込みパスワードポリシーを有効化
sudo dsconf company pwpolicy set \
--pwdminage 0 \
--pwdmaxage 90 \
--pwdminlength 8 \
--pwdlockout on \
--pwdmaxfailure 5運用経験からの実践的なTips
- 毎日の自動バックアップ：
sudo dsctl company db2bak /backup/ldap-$(date +%Y%m%d)を実行するcronjobを追加 — スキーマとデータ両方を保存。7日分保持して古いものはfind /backup -name 'ldap-*' -mtime +7 -deleteで削除しています。 - Webコンソール：
cockpit-389-dsをインストールしてhttps://ldap.company.com:9090を開く — スキーマを確認したりレプリケーションのステータスをデバッグするときによく使います。手動でldapsearchを打つより断然速い。 - SELinuxは無効化不要：389 DSはCentOS Stream 9でSELinux enforcingのまま正常に動作します。
setenforce 0が必要と書いてある2015年頃のガイドは信じないでください — もう不要です。 - ログローテーション：500人以上のアクティブユーザーがいるシステムは毎月数GBのアクセスログを生成する可能性があります。サイズ制限：
sudo dsconf company config replace nsslapd-accesslog-maxlogsize=100 - 接続のモニタリング：
sudo dsconf company monitor server | grep -i connectionで現在の接続数を確認 — 通常は同時接続10〜50程度。突然数百になったらクライアントの設定が誤って再接続ループを起こしているサインです。
クイックトラブルシューティング
接続エラー
# リッスン中のポートを確認
sudo ss -tlnp | grep -E ':389|:636'
# エラーログをリアルタイムで確認
sudo journalctl -u dirsrv@company -f
# または詳細なアクセスログを確認
sudo tail -f /var/log/dirsrv/slapd-company/access認証エラー
# 手動でバインドをテスト
ldapwhoami -x -H ldap://localhost \
-D "uid=john,ou=users,dc=company,dc=com" \
-W
# パスワードハッシュのフォーマットが正しいか確認
ldapsearch -x -H ldap://localhost \
-D "cn=Directory Manager" -W \
-b "uid=john,ou=users,dc=company,dc=com" \
userPasswordこれでLinuxインフラの集中LDAPサーバーを動かすのに十分な内容です。Windowsも不要、ライセンス料も不要、将来RHEL 10にアップグレードしてもパッケージは完全互換です。高可用性が必要ですか？次のステップはマルチマスターレプリケーション — 389 DSは2〜4台のマスターノード構成をサポートしており、数年前と比べてはるかに簡単に設定できます。
