Ubuntu 22.04 SSSD – LDAP ユーザーで Linux 認証する

Ubuntu 22.04 で LDAP ユーザーを Linux のログイン認証に使う場合、中心になるのは SSSD です。LDAP サーバーにユーザーを登録しただけでは、Linux 側でそのユーザーを解決したり、PAM 認証に使ったりすることはできません。

この記事では、389 Directory Server や OpenLDAP などの LDAP サーバーがすでに用意されている前提で、Ubuntu 22.04 を LDAP クライアントとして構成し、SSH ログインや id / getent で確認できる状態にします。

参考書籍

LDAP – 設定・管理・プログラミング

LDAP / OpenLDAP の設定、管理、連携を確認したい場合の参考書籍です。古い書籍のため、価格や在庫はリンク先で確認してください。

Amazon で見る

このリンクは Amazon アソシエイトリンクです。

SSSD の位置づけ

SSSD は LDAP サーバーそのものではありません。Linux 側でユーザー情報を検索する NSS と、ログイン認証を扱う PAM の間に入り、LDAP への問い合わせ、資格情報のキャッシュ、ユーザー確認をまとめて扱う仕組みです。

要素	役割
LDAP サーバー	ユーザー、グループ、DN、属性を保持するディレクトリ
NSS	`getent passwd` や `id` でユーザーとグループを解決する仕組み
PAM	SSH や sudo などのログイン認証を処理する仕組み
SSSD	NSS / PAM から LDAP を参照し、キャッシュや認証連携を行うクライアント
SSH	PAM を通じてログイン可否を確認する代表的なサービス

つまり、LDAP にユーザーが存在することと、そのユーザーで Linux にログインできることは同じではありません。LDAP の属性、SSSD の検索条件、PAM の有効化、ホームディレクトリ作成を合わせて確認する必要があります。

パッケージをインストールする

SSSD 本体、NSS 連携、PAM 連携、確認用ツールをインストールします。

sudo apt update
sudo DEBIAN_FRONTEND=noninteractive apt-get install -y sssd sssd-tools libnss-sss libpam-sss

LDAPS 用の CA 証明書を配置する

LDAP 認証を平文 LDAP のまま使うと、BIND パスワードや認証情報の扱いが弱くなります。基本的には LDAPS または StartTLS を使い、Ubuntu 側で LDAP サーバー証明書を検証できるようにします。

sudo cp example-ca.crt /usr/local/share/ca-certificates/example-ca.crt
sudo update-ca-certificates

自己署名 CA や内部 CA を使う場合でも、ldap_tls_reqcert = demand として証明書検証を無効化しない構成を基本にします。検証を無効化すると接続は楽になりますが、認証基盤としての信頼性は落ちます。

sssd.conf を作成する

ここでは、LDAP 参照用の読み取り専用 BIND ユーザーを使う例にします。ユーザー認証用のパスワード変更まで SSSD に扱わせる場合は chpass_provider = ldap を指定しますが、実際に変更できるかは LDAP 側の ACL 設計に依存します。

sudo tee /etc/sssd/sssd.conf <<'EOF'
[sssd]
services = nss, pam
domains = default

[nss]
filter_groups = root
filter_users = root

[domain/default]
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap

ldap_uri = ldaps://ldap.example.local
ldap_search_base = dc=example,dc=local
ldap_default_bind_dn = cn=ro,ou=service,dc=example,dc=local
ldap_tls_reqcert = demand
cache_credentials = true

ldap_user_search_base = ou=users,dc=example,dc=local
ldap_group_search_base = ou=groups,dc=example,dc=local
EOF

sudo chmod 0600 /etc/sssd/sssd.conf

ldap_default_bind_dn には、LDAP を検索するための BIND DN を指定します。管理者 DN や書き込み可能な BIND ユーザーを常用すると、クライアント側の秘密情報漏えい時の影響が大きくなるため、通常は読み取り専用のサービスアカウントを使います。

BIND パスワードを設定する

SSSD では sss_obfuscate を使って BIND パスワードを設定できます。これは強い暗号化というより、設定ファイルへ平文を直接書かないための難読化です。ファイル権限とシークレット管理は別途重要です。

sudo sss_obfuscate -d default

コマンドを実行すると BIND パスワードの入力を求められ、sssd.conf に ldap_default_authtok などの値が追加されます。設定ファイルの権限が 0600 になっていることも確認します。

sudo ls -l /etc/sssd/sssd.conf

NSS と PAM を有効化する

ユーザー情報の解決には NSS、ログイン認証には PAM が関係します。SSSD をインストールしただけでは、期待どおりに認証経路へ入らない場合があります。

sudo pam-auth-update --enable sss
sudo pam-auth-update --enable mkhomedir
grep -E '^(passwd|group|shadow):' /etc/nsswitch.conf

mkhomedir を有効化すると、LDAP ユーザーが初回ログインしたときにホームディレクトリを自動作成できます。サーバー用途では、ホームディレクトリの作成ポリシーや権限も運用設計に含めておくと安全です。

SSSD を起動して設定を確認する

設定ファイルを作成したら、SSSD を再起動して構文とサービス状態を確認します。

sudo systemctl restart sssd
sudo systemctl status sssd --no-pager
sudo sssctl config-check

エラーが出る場合は、LDAP の DN、検索ベース、TLS 証明書、BIND パスワードのいずれかで詰まっていることが多いです。まずは LDAP ユーティリティで同じ BIND DN と LDAPS 接続が通るか確認します。

ldapwhoami -H ldaps://ldap.example.local \
  -D 'cn=ro,ou=service,dc=example,dc=local' \
  -W

LDAP ユーザーを確認する

NSS 側で LDAP ユーザーが見えるか確認します。getent と id で引けない場合、SSH ログイン以前にユーザー解決ができていません。

getent passwd myadmin
id myadmin
sssctl user-checks myadmin

SSH ログインを確認する場合は、対象ユーザーがログイン可能なシェルを持っていること、LDAP 側に POSIX 属性があること、PAM で SSSD が有効になっていることを確認します。

ssh myadmin@ubuntu-2204.example.local

キャッシュとトラブルシュート

SSSD は資格情報や LDAP 検索結果をキャッシュします。LDAP 側のユーザーやグループを変更した直後に結果が変わらない場合は、キャッシュを削除してから確認します。

sudo sss_cache -E
getent passwd myadmin
id myadmin

ログを見る場合は、まず systemd のログで十分です。詳細なデバッグログは情報量が多いため、原因が絞れない場合に段階的に有効化します。

sudo journalctl -u sssd -n 100 --no-pager

Samba 認証とは分けて考える

SSSD による Linux ログイン認証と、Samba の認証は同じ LDAP を参照していても責務が異なります。Linux ログインでは POSIX ユーザー、PAM、NSS が中心になります。一方、Samba では SID、NT パスワード、passdb、共有権限が関係します。

そのため、SSSD で id が引けることと、Samba 共有へ正しくアクセスできることは別問題です。LDAP を共通基盤にしても、Linux ログイン用の設計と Samba 用の設計は混同しない方が運用しやすくなります。

まとめ

Ubuntu 22.04 で LDAP ユーザーを Linux 認証に使う場合、SSSD は LDAP と NSS / PAM を接続する中心的な層になります。LDAP サーバーにユーザーを作るだけではなく、LDAPS、BIND ユーザー、SSSD 設定、NSS、PAM、ホームディレクトリ作成までを一連の流れとして確認することが重要です。

特に、読み取り専用 BIND ユーザー、証明書検証、キャッシュ削除、Samba 認証との責務分離を押さえておくと、LDAP 認証のトラブルを切り分けやすくなります。

Ubuntu 22.04 SSSD – LDAP ユーザーで Linux 認証する

関連する LDAP 記事

SSSD の位置づけ

パッケージをインストールする

LDAPS 用の CA 証明書を配置する

sssd.conf を作成する

BIND パスワードを設定する

NSS と PAM を有効化する

SSSD を起動して設定を確認する

LDAP ユーザーを確認する

キャッシュとトラブルシュート

Samba 認証とは分けて考える

まとめ

コメントを残すコメントをキャンセル

Ubuntu 22.04 SSSD – LDAP ユーザーで Linux 認証する

関連する LDAP 記事

SSSD の位置づけ

パッケージをインストールする

LDAPS 用の CA 証明書を配置する

sssd.conf を作成する

BIND パスワードを設定する

NSS と PAM を有効化する

SSSD を起動して設定を確認する

LDAP ユーザーを確認する

キャッシュとトラブルシュート

Samba 認証とは分けて考える

まとめ

Related posts:

コメントを残す コメントをキャンセル

コメントを残すコメントをキャンセル