Ubuntu 22.04 389 Directory Server #5 – グループとユーザーの登録

389 Directory Server でユーザーやグループを扱うときは、suffix の直下に無秩序にエントリを追加するのではなく、ou=People と ou=Groups のような入れ物を決めてから登録します。LDAP を SSSD、Samba、Postfix などから参照する場合、この配置と属性の選び方が後続の認証連携に影響します。

この記事は、Ubuntu 22.04 の既存環境で 389 Directory Server のユーザー・グループ登録を見直すための記事です。新規構築では Ubuntu 26.04 側の記事を優先しつつ、22.04 環境の設定確認や古い構築記録の読み替えに使ってください。

ユーザーとグループの配置

ここでは、ユーザーを ou=People,dc=example,dc=local、グループを ou=Groups,dc=example,dc=local に置く前提にします。SSSD から Linux ログインに使う場合は、uidNumber、gidNumber、homeDirectory、loginShell を一貫して管理します。

OU を確認する

先に、ユーザーとグループの入れ物が存在するか確認します。なければ base entry の記事で追加した OU を作成します。

ldapsearch -x \
  -H ldaps://ldap.example.local \
  -D 'cn=ro,ou=service,dc=example,dc=local' \
  -W \
  -b dc=example,dc=local \
  '(objectClass=organizationalUnit)' \
  dn

ou=People と ou=Groups が見えない場合は、先にツリーの基礎を作ります。ユーザーやグループ登録だけを急ぐと、後で検索 base やアクセス制御がぶれやすくなります。

POSIX グループを登録する

Linux 認証で使うグループは、posixGroup と gidNumber を持たせます。gidNumber は既存のローカルユーザーや他の LDAP グループと重複しないように管理します。

cat <<'EOF' > /tmp/linux-groups.ldif
dn: cn=linux-users,ou=Groups,dc=example,dc=local
objectClass: top
objectClass: posixGroup
cn: linux-users
gidNumber: 10000

dn: cn=linux-admins,ou=Groups,dc=example,dc=local
objectClass: top
objectClass: posixGroup
cn: linux-admins
gidNumber: 10001
EOF
ldapadd -x \
  -H ldaps://ldap.example.local \
  -D 'cn=Directory Manager' \
  -W \
  -f /tmp/linux-groups.ldif

グループ名は用途で分けます。ログイン可能な一般ユーザー、管理作業を許可するユーザー、アプリケーション専用ユーザーを同じグループに混ぜない方が確認しやすくなります。

POSIX ユーザーを登録する

ユーザーには inetOrgPerson と posixAccount を持たせます。uidNumber と gidNumber は、OS 側の UID / GID として扱われるため、採番範囲を決めてから登録します。

cat <<'EOF' > /tmp/linux-users.ldif
dn: uid=user01,ou=People,dc=example,dc=local
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
uid: user01
cn: User 01
sn: 01
uidNumber: 11001
gidNumber: 10000
homeDirectory: /home/user01
loginShell: /bin/bash
mail: user01@example.local
userPassword: change-me-user01
EOF
ldapadd -x \
  -H ldaps://ldap.example.local \
  -D 'cn=Directory Manager' \
  -W \
  -f /tmp/linux-users.ldif

パスワードは例の値をそのまま使いません。既存環境を見直す場合は、平文の LDIF が残っていないか、登録後の一時ファイルをどう扱うかも確認します。

グループメンバーを追加する

posixGroup のメンバーは memberUid で指定します。SSSD 側の設定やスキーマの使い方によっては groupOfNames などを併用する場合もありますが、ここでは POSIX グループとして確認します。

ldapmodify -x \
  -H ldaps://ldap.example.local \
  -D 'cn=Directory Manager' \
  -W <<'EOF'
dn: cn=linux-admins,ou=Groups,dc=example,dc=local
changetype: modify
add: memberUid
memberUid: user01
EOF

既存グループに同じ memberUid を重複追加しようとすると失敗します。登録済みの値を確認してから変更します。

登録内容を確認する

読み取り用 BIND ユーザーで、ユーザーとグループが検索できることを確認します。ここで見えない場合は、base DN、ACI、BIND DN、検索フィルタを分けて確認します。

ldapsearch -x \
  -H ldaps://ldap.example.local \
  -D 'cn=ro,ou=service,dc=example,dc=local' \
  -W \
  -b ou=People,dc=example,dc=local \
  '(uid=user01)' \
  uid uidNumber gidNumber homeDirectory loginShell
ldapsearch -x \
  -H ldaps://ldap.example.local \
  -D 'cn=ro,ou=service,dc=example,dc=local' \
  -W \
  -b ou=Groups,dc=example,dc=local \
  '(cn=linux-admins)' \
  cn gidNumber memberUid

SSSD で参照する前に、LDAP 側だけで検索結果を確認しておくと切り分けが楽になります。LDAP 検索で見えないものは、OS 側の id や getent でも解決できません。

連携前に見る点

SSSD や Samba とつなぐ前に、UID / GID の採番、ホームディレクトリの作成方針、ログインシェル、無効化したユーザーの扱いを決めます。LDAP にユーザーがあるだけでは、Linux で安全にログインできる状態とは限りません。

既存の Ubuntu 22.04 環境では、古い検証用ユーザーや使われなくなったグループが残っていないかも確認します。特に管理者向けグループは、メンバーが現在も必要な人だけになっているかを見ます。

まとめ

389 Directory Server でユーザーとグループを登録するときは、OU、UID / GID、属性、参照権限を一緒に確認します。LDAP 側の配置が曖昧なまま SSSD や Samba を設定すると、認証側の問題に見えて実際はディレクトリ設計の問題だった、という切り分けになりがちです。

22.04 の既存環境を見直すときは、登録済みエントリを棚卸しし、不要なユーザー、重複した ID、過剰な管理者グループ所属がないかを確認します。

関連記事

Ubuntu 22.04 389 Directory Server #1 – インスタンス作成と suffix 設計 Ubuntu 22.04 389 Directory Server #2 – TLS 有効化と LDAPS 設定 Ubuntu 22.04 389 Directory Server #3 – ベースエントリーの登録 Ubuntu 22.04 389 Directory Server #4 – BIND ユーザーとアクセス制御 Ubuntu 26.04 LDAP サーバーの基本設定 – 389 Directory Server でディレクトリ基盤を作る Ubuntu 22.04 デスクトップ環境 – Server に ubuntu-desktop を追加する Ubuntu 22.04 isc-dhcp-server – PXE ブートを見据えた DHCP サーバー構築 Ubuntu 22.04 netplan apply の ovsdb-server.service 警告 – Open vSwitch を使わない環境での考え方