【389 Directory Server講座 第3回】CLI管理の革命。dsidmコマンドとJSON出力による運用自動化の極意

「LDIFファイル」を書いて消耗するのは、もう終わりにしませんか?

こんにちは!「LINUX工房」管理人の「リナックス先生」です。
前回は、構成ファイルを用いた自動インストールと、Web GUI(Cockpit)の導入を行いました。
これでサーバーの「器」は完成しましたが、中身(ユーザーデータ)はまだ空っぽです。

さて、OpenLDAP経験者の皆さん。ユーザーを一人追加するとき、どうやっていましたか?
テキストエディタを開いて、呪文のようなLDIFファイルを書き、日本語が含まれていればBase64エンコードし、インデントにおびえながら ldapadd コマンドを叩く……。
そんな「苦行」は、389 Directory Serverの世界には存在しません。

コウ君

先生、僕もLDIFは大嫌いです!
dn: とか objectClass: とか、一行でも間違えるとエラーになるし。
特に「パスワード変更」とか「グループへのメンバー追加」みたいな修正作業(modify)が面倒すぎて、毎回ググってます。
389 DSなら、もっと人間らしいコマンドで管理できるって本当ですか?

リナックス先生

ええ、本当よ。
389 DSには dsidm という、Python製の素晴らしい管理コマンドが用意されているわ。
これを使えば、直感的なオプション引数だけでユーザー管理ができるし、結果を JSON形式 で出力することもできるの。
つまり、シェルスクリプトやAnsibleとの相性が抜群ってこと。
今回は、コマンドラインだけでLDAPを自在に操る「運用の自動化」テクニックを教えるわよ!

本記事では、dsidm コマンドを使ったユーザー・グループの管理方法、JSON出力を活用したスクリプト作成、そしてActive Directoryとの互換性を高める重要なプラグイン設定までを徹底解説します。

🐧 389 Directory Server 完全攻略講座 カリキュラム


第1章:OpenLDAPの呪縛からの解放。dsidmとは?

これまでのLDAP管理における最大のストレス要因、それは「LDIFフォーマット」でした。
389 DSの管理ツール dsidm (Directory Server Identity Management) は、この問題を根本から解決します。

ldapadd vs dsidm

例えば、「Taro Yamada (uid=taro)」というユーザーを作成する場合を比較してみましょう。

OpenLDAP (ldapadd) の場合:

# まずLDIFファイルを作成
cat < taro.ldif
dn: uid=taro,ou=People,dc=linuxkoubou,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
uid: taro
cn: Taro Yamada
sn: Yamada
uidNumber: 1001
gidNumber: 1001
homeDirectory: /home/taro
loginShell: /bin/bash
userPassword: {SSHA}......
EOF

# コマンド実行
ldapadd -x -D "cn=Manager,dc=linuxkoubou,dc=com" -W -f taro.ldif

非常に冗長です。objectClass の指定漏れでエラーになることも日常茶飯事です。

389 DS (dsidm) の場合:

dsidm localhost user create uid=taro,ou=People,dc=linuxkoubou,dc=com \
  --cn "Taro Yamada" \
  --displayName "Taro Yamada" \
  --uidNumber 1001 \
  --gidNumber 1001 \
  --homeDirectory /home/taro \
  --loginShell /bin/bash

たったこれだけです。
必要な objectClass はツールが自動的に補完してくれます。
localhost は第2回で作成したインスタンス名を指します。

💡 プロの視点:dsidmの権限
dsidm コマンドは、実行しているOSユーザーの権限ではなく、コマンド内部でLDAPサーバーに認証(Bind)して操作を行います。
デフォルトでは /etc/dirsrv/slapd-localhost/dse.ldif から設定を読み取り、ローカル接続を行いますが、環境変数や引数で認証情報を渡すことも可能です。


第2章:ユーザー管理の実践。作成・修正・削除

それでは、実務で頻出する操作をハンズオン形式で解説します。

1. ユーザーの作成 (Create)

先ほどの例の通りですが、パスワードの設定も同時に行いたい場合はどうすればよいでしょうか?
実は user create コマンドにはパスワード指定オプションがありません(セキュリティのため)。
作成後にリセットするか、対話モードを使います。

# ユーザー作成
dsidm localhost user create uid=hanako,ou=People,dc=linuxkoubou,dc=com \
  --cn "Hanako Suzuki" --sn "Suzuki" --uidNumber 1002 --gidNumber 1002 --homeDirectory /home/hanako

# パスワード設定(リセット)
dsidm localhost account reset_password uid=hanako,ou=People,dc=linuxkoubou,dc=com --new-password "P@ssword123"

2. ユーザーの修正 (Modify)

OpenLDAPで最も面倒なのが「属性の変更」です。
changetype: modify … と書く必要はありません。

# シェルを /bin/zsh に変更
dsidm localhost user modify uid=hanako,ou=People,dc=linuxkoubou,dc=com add:loginShell:/bin/zsh

# 表示名を変更(上書き)
dsidm localhost user modify uid=hanako,ou=People,dc=linuxkoubou,dc=com replace:displayName:"Hanako Tanaka"

add:(追加)、replace:(置換)、delete:(削除)という直感的な構文で操作できます。

3. ユーザーの削除 (Delete)

dsidm localhost user delete uid=hanako,ou=People,dc=linuxkoubou,dc=com

確認プロンプトなしで消えるため、スクリプトに組み込む際は注意が必要です。


第3章:グループ管理とMemberOfプラグインの罠

LDAPでグループ管理を行う際、必ず直面するのが「memberOf属性がない問題」です。
Active Directoryでは、ユーザー情報を見れば「どのグループに所属しているか(memberOf)」が分かりますが、標準的なLDAPではグループ側に「誰が所属しているか(member)」があるだけで、逆引きができません。

これを解決するのが、389 DSの強力な機能「MemberOf プラグイン」です。

MemberOf プラグインの有効化

RHEL 9 / 389 DS 1.4系以降ではデフォルトで有効になっていることが多いですが、念のため確認・有効化の手順を示します。
dsconf コマンドを使用します。

# プラグインの状態確認
dsconf localhost plugin memberof status

# 有効化(無効な場合)
dsconf localhost plugin memberof enable
# 再起動して反映
systemctl restart dirsrv@localhost

重要: プラグインを有効化しても、既存のデータには反映されません。
既存データに対してmemberOf属性を生成するには、「Fixupタスク」を実行する必要があります。

# 既存データへの適用(Fixup)
dsconf localhost plugin memberof fixup -b "dc=linuxkoubou,dc=com"

グループの操作

MemberOfプラグインが有効な状態で、グループ操作を行ってみましょう。

# グループ作成
dsidm localhost group create cn=developers,ou=Groups,dc=linuxkoubou,dc=com

# メンバー追加
dsidm localhost group add_member cn=developers,ou=Groups,dc=linuxkoubou,dc=com \
  uid=taro,ou=People,dc=linuxkoubou,dc=com

この状態でユーザー taro を検索すると、自動的に memberOf: cn=developers,ou=Groups... という属性が付与されているはずです。
これにより、アプリケーション側(GitLabやJenkinsなど)での権限マッピングが劇的に楽になります。

PR

はじめてのUbuntu

新品価格
¥2,970から
(2026/5/30 09:51時点)


第4章:DevOps流。JSON出力とjqコマンドの活用

GUI(Cockpit)は便利ですが、100人のユーザーを一括登録したり、監査レポートを作ったりするにはCLIが不可欠です。
dsidm コマンドの真骨頂は、JSON形式での出力機能にあります。

ldapsearch の出力(Before)

従来のコマンド出力は、行指向のテキストで、Base64エンコードが混ざるため、スクリプトでの解析が困難でした。

dn: uid=taro,ou=People,dc=linuxkoubou,dc=com
cn: Taro Yamada
cn:: 44K... (日本語の場合Base64)

dsidm –json の出力(After)

dsidm localhost user list --json

出力例:

[
    {
        "dn": "uid=taro,ou=People,dc=linuxkoubou,dc=com",
        "attrs": {
            "uid": ["taro"],
            "cn": ["Taro Yamada"],
            "uidNumber": ["1001"]
        }
    }
]

構造化データとして出力されるため、jq コマンドと組み合わせることで、複雑な抽出が一瞬で可能になります。

【実践】全ユーザーのメールアドレスリストを作成する

「全社員のメールアドレスをCSVで出して」と言われた時のワンライナーです。

dsidm localhost user list --json | jq -r '.[] | [.attrs.uid[0], .attrs.mail[0]] | @csv' > users.csv

ldapsearchawksed を駆使してスパゲッティコードを書いていた時代は終わりました。
これが現代的なLDAP運用です。


第5章:アカウントロックとパスワード管理

ヘルプデスク業務で最も多いのが「パスワードを忘れた」「アカウントがロックされた」という問い合わせです。
dsidm には、これらの対応専用のサブコマンド account があります。

アカウントのロック / ロック解除

退職者や不審なアカウントを一時的に無効化する場合。

# ロック(無効化)
dsidm localhost account lock uid=taro,ou=People,dc=linuxkoubou,dc=com

# ロック解除(有効化)
dsidm localhost account unlock uid=taro,ou=People,dc=linuxkoubou,dc=com

nsAccountLock 属性を直接いじる必要はありません。

パスワードリセットの強制

「次回ログイン時にパスワード変更を強制する」設定です。

dsidm localhost account reset_password uid=taro,ou=People,dc=linuxkoubou,dc=com --new-password "TempPass123" --must-change

💡 プロのノウハウ:パスワードポリシー
アカウントロック機能を使用するには、グローバルまたはユーザー単位でのパスワードポリシー設定が必要です。
デフォルトでは緩い設定になっていることが多いため、第6回で解説するセキュリティ設定で厳格化することをお勧めします。


第6章:組織単位(OU)と階層設計のベストプラクティス

ユーザーやグループを格納する「箱」であるOU(Organizational Unit)の作成も dsidm で行えます。

OUの作成

# People OUの作成
dsidm localhost organisationalunit create ou=People,dc=linuxkoubou,dc=com

# Groups OUの作成
dsidm localhost organisationalunit create ou=Groups,dc=linuxkoubou,dc=com

階層設計のヒント

LDAPのツリー構造(DIT: Directory Information Tree)は、一度作ると変更が大変です。
プロの現場では、以下のようなフラットな構成を推奨します。

  • ou=People: 全ユーザーをここにフラットに配置。部署ごとにOUを分けない。
  • ou=Groups: 全グループを配置。

なぜ部署でOUを分けないのか?
組織変更(部署名の変更や統廃合)があるたびに、LDAP上のDN(Distinguished Name)が変わってしまうからです。
DNが変わると、そのユーザーに紐付いていた設定や、アプリケーション側の参照設定がリンク切れを起こします。
所属部署はOUではなく、ユーザーの属性(ou属性やdepartmentNumber属性)で管理するのが鉄則です。


まとめ:運用をコード化せよ

お疲れ様でした!
第3回は、dsidm コマンドを中心としたユーザー管理と運用自動化について解説しました。

今回の重要ポイント:

  • dsidm コマンドを使えば、LDIFを書かずに直感的に管理できる。
  • MemberOfプラグインを有効化して、AD互換のグループ管理を実現する。
  • --json オプションと jq を組み合わせることで、運用スクリプトが劇的にシンプルになる。
  • LDAPツリー構造は「部署ごと」ではなく「フラット」に設計する。
ウィンドウズ先生

LDAPサーバーは「一度作ったら終わり」ではありません。
日々のユーザー追加、削除、属性変更といった運用こそが本番です。
389 DSのCLIツール群は、その「日々の運用」をエンジニアの苦痛から楽しみへと変えてくれる強力な武器ですよ。

さて、ユーザーは作れましたが、このままでは「誰でも見放題」「誰でも書き込み放題」になってしまうリスクがあります。
セキュリティの要となるのが、誰に何を許可するかという「アクセス制御」です。

次回、第4回は「アクセス制御 (ACI) の設計論。ACLとの決定的な違い」です。
OpenLDAPのACLとは全く異なる概念である「ACI」の仕組みと、実用的な設定パターン(自分自身のパスワード変更許可など)について解説します。お楽しみに!

▼ 389dsを試す ▼

389 DS環境を構築する
「おすすめVPS」

おすすめVPSを見る

DevOpsエンジニアへ
「ITエンジニア転職」

転職エージェントを見る

コメント