【OpenLDAP基本講座 補足2】Active Directory連携。パスワード一元化と「シャドウディレクトリ」構築の極意

「WindowsとLinux、パスワードが別々」問題を解決せよ。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
全8回の基本講座でOpenLDAPの構築は完璧になりましたが、実際の企業ネットワークには、もう一つの巨人が存在します。
そう、Active Directory (AD) です。

「Windowsのログインパスワードを変えたら、Linuxのパスワードも変わってほしい」。
ユーザーにとっては当たり前のこの要望も、インフラエンジニアにとっては頭の痛い問題です。
ADにLinuxを直接参加（Join）させれば解決する話ではありますが、「ADの管理権限がない」「ADにLinux用の属性（ログインシェルなど）を追加したくない」という事情がある場合、OpenLDAPを「中継役（Proxy）」として使う構成が輝きます。

本記事では、saslauthd を用いたパススルー認証の構築、ADユーザーをOpenLDAPに取り込む設計思想、そしてUID/GIDの整合性問題を解決するIDマッピングの技術までを徹底解説します。

---

第1章：連携パターンとアーキテクチャ。「シャドウディレクトリ」とは？

まず、なぜOpenLDAPを経由させるのか、その意義を整理しましょう。

パターンA：Linuxを直接ADに参加させる (SSSD + Realmd)

最も簡単な方法です。realm join ad.example.com 一発で終わります。
メリット： 簡単。
デメリット： Linux固有の属性（loginShell, homeDirectory）をADスキーマ拡張で持たせる必要があり、AD管理者の許可が必要です。また、LinuxサーバーごとにUIDがバラバラになるリスク（IDマッピング問題）があります。

パターンB：OpenLDAPを「シャドウディレクトリ」にする（推奨）

ADのユーザー情報をOpenLDAPにコピー（同期）し、Linux特有の属性はOpenLDAP側で管理します。
認証（パスワード確認）の瞬間だけ、OpenLDAPからADへ問い合わせを行います。

メリット：

• ADを汚さない： ADのスキーマ変更不要。
• 柔軟な属性管理： Linux独自のグループや属性を自由に設定可能。
• DMZ対応： ADを直接インターネット側のセグメントに晒さず、OpenLDAPをクッションにできる。

今回は、このパターンBを構築します。

---

第2章：OpenLDAP側の準備。SASLとKerberosクライアント設定

OpenLDAPサーバー（RHEL/AlmaLinux）が、ADと会話できるように準備します。

1. パッケージのインストール

KerberosクライアントとSASL認証デーモンを入れます。

dnf install krb5-workstation cyrus-sasl cyrus-sasl-gssapi cyrus-sasl-ldap

2. Kerberosの設定 (/etc/krb5.conf)

ADのドメインコントローラー（KDC）を指定します。
ADドメイン名が AD.LINUXKOUBOU.COM だとします（大文字必須！）。

[libdefaults]
    default_realm = AD.LINUXKOUBOU.COM
    dns_lookup_realm = false
    dns_lookup_kdc = true

[realms]
    AD.LINUXKOUBOU.COM = {
        kdc = ad01.ad.linuxkoubou.com
        admin_server = ad01.ad.linuxkoubou.com
    }

[domain_realm]
    .ad.linuxkoubou.com = AD.LINUXKOUBOU.COM
    ad.linuxkoubou.com = AD.LINUXKOUBOU.COM

3. Kerberos認証テスト

ADのユーザー（例：administrator）でチケットが取れるかテストします。

kinit administrator@AD.LINUXKOUBOU.COM
# パスワードを入力し、エラーが出なければOK
klist

チケットが表示されれば、OpenLDAPサーバーからADへの認証経路は開通しています。

---

第3章：パススルー認証の実装。saslauthdの設定

OpenLDAP (slapd) は、パスワード検証を自分で行わず、saslauthd というデーモンに委託します。
saslauthd は受け取ったパスワードを使ってAD (Kerberos) にログインを試み、成功すれば「OK」を返します。

1. saslauthdの設定 (/etc/sysconfig/saslauthd)

認証メカニズムを kerberos5 に設定します。

# MECH=pam
MECH=kerberos5

2. saslauthdの起動

systemctl enable --now saslauthd

3. 認証テスト (testsaslauthd)

この段階で、ADのユーザーIDとパスワードで認証が通るか確認します。

testsaslauthd -u administrator -p 'SecretPassword123' -r AD.LINUXKOUBOU.COM

0: OK "Success." と表示されれば、saslauthdは正常にADと連携できています。

4. OpenLDAP (slapd) の設定

OpenLDAPが saslauthd を利用できるように設定します。

/etc/sasl2/slapd.conf (新規作成)

pwcheck_method: saslauthd
mech_list: PLAIN LOGIN GSSAPI

そして、OpenLDAPユーザー (ldap) が saslauthd のソケットにアクセスできるように権限を調整します。

usermod -aG saslauth ldap
systemctl restart slapd

5. ユーザーエントリの設定 (userPassword)

ここが最大のポイントです。
OpenLDAP上のユーザーエントリの userPassword 属性に、ハッシュ値ではなく、「SASLを使って認証せよ」という指示を書き込みます。

dn: uid=taro,ou=People,dc=linuxkoubou,dc=com
changetype: modify
replace: userPassword
userPassword: {SASL}taro@AD.LINUXKOUBOU.COM

これで、ユーザー taro がOpenLDAPにバインド（ログイン）しようとすると、OpenLDAPは {SASL} タグを見て処理を saslauthd に投げ、saslauthd がADで認証し、結果が返ってくる……という「パススルー」が完成します。

---

第4章：ユーザーデータの同期戦略。ADからOpenLDAPへ

認証の仕組みはできましたが、肝心のユーザーエントリ（uid=taro...）がOpenLDAP側に存在しないとログインできません。
AD上の数千人のユーザーを、どうやってOpenLDAPにコピーするか？

手動同期は地獄の入り口

CSVを作って手動で ldapadd ……は、入社・退職のたびに運用コストが発生し、すぐにデータが陳腐化します。

同期スクリプト (Python/LDAP3) の活用

ADを検索し、OpenLDAPにないユーザーがいれば作成、いなくなったユーザーがいれば削除（または無効化）するスクリプトをCronで回すのが一般的です。

同期ロジックの例：

1. ADにLDAP接続し、(&(objectClass=user)(objectCategory=person)) で全ユーザーを取得。
2. sAMAccountName (ADのID) をOpenLDAPの uid にマッピング。
3. OpenLDAPを検索し、存在しなければ inetOrgPerson + posixAccount として追加。
4. 重要： userPassword は自動的に {SASL}sAMAccountName@REALM に設定する。
5. uidNumber (UID) は、OpenLDAP側で採番管理するか、ADの属性（もしあれば）をコピーする。

ツール：LSC (Ldap Synchronization Connector)

Java製の同期ツール LSC を使うと、スクリプトを書かずにXML設定だけで「AD → OpenLDAP」の同期が可能になります。
大規模環境ではLSCの導入を強くお勧めします。

---

第5章：事例研究。「UIDの奪い合い」とIDマッピング問題

実際にAD連携を行うと、必ず直面する問題があります。
それが「UID/GIDの不整合問題」です。

現象

ADには本来、LinuxのUID（数値）という概念がありません。
SSSDで直接ADに参加した場合、SSSDはADのSID（Security Identifier）を元に、ハッシュ計算でUIDを生成します。
しかし、OpenLDAPで静的に管理しているUIDと、SSSDが自動生成するUIDが衝突したり、サーバーによって計算結果が違ったりすると、ファイル権限がおかしくなります。

解決策：OpenLDAPを「UIDのマスター」にする

これが「シャドウディレクトリ」構成の最大のメリットです。
UID/GIDはOpenLDAPの posixAccount スキーマで静的に定義し、全Linuxサーバーはそれを参照します。

• AD: 認証（パスワード）のマスター
• OpenLDAP: 認可属性（UID, GID, HomeDir, Shell）のマスター

この役割分担を明確にすることで、どのサーバーにログインしても同じUID 1001 が保証され、NFSなどでファイルを共有しても権限エラーが起きなくなります。

---

まとめ：ID統合は「政治」と「技術」の融合

お疲れ様でした！
補足編第2回では、OpenLDAPとActive Directoryの連携について解説しました。

今回の重要ポイント：

• パスワード管理をADに一元化するには、saslauthd によるパススルー認証を使う。
• OpenLDAPを「シャドウディレクトリ」として使い、Linux属性（UIDなど）のマスターとする。
• ユーザー同期はスクリプトやツール（LSC）で自動化し、userPassword を {SASL}... に書き換える。