HashiCorp Vault で既存ディレクトリと統合する LDAP 認証の実務

既存の社内ディレクトリ（Active Directory や OpenLDAP）を活かしつつ、Vault のトークン発行に統合するのが LDAP 認証です。ローカルユーザーを増やさず、既存のグループでポリシーを割り当てられるのが最大の利点です。

本稿は HashiCorp Vault の公式動作に基づき、試験（Vault Associate）で問われやすい概念と、現場導入で外しがちなポイントをセットで解説します。

なぜ Vault を LDAP と統合するのか（概要と前提）

Vault の認証方式（auth method）の一つである LDAP は、ユーザーのパスワード検証をディレクトリに委譲し、認証成功時に Vault トークンを発行します。ディレクトリ側のグループと Vault ポリシーをマッピングすることで、権限管理の一元化が可能になります。

安定した前提：LDAP/LDAPS の接続、bind アカウントによる検索（匿名 bind を避ける）、ユーザー・グループ DN 範囲の明確化、TLS 信頼の設定。試験では「どこでポリシーが付与されるか」「どのエンドポイントで何を設定するか」が頻出です。

• 前提チェック: Vault から LDAP サーバへ 389/TCP（StartTLS）または 636/TCP（LDAPS）で到達可能
• サービスアカウント（binddn/bindpass）を用意し、ユーザー・グループ検索に十分な権限を付与
• ユーザーが所属するグループ名と、割り当てる Vault ポリシーの対応表を事前に整理
• LDAP サーバの CA 証明書を Vault に提供（certificate パラメータ）。insecure_tls は本番で使用しない

LDAP 認証の高レベルフロー

主要な設定項目と安全な既定値

URL と TLS: ldaps:// を使うか、ldap:// + starttls=true を使います。いずれにせよ certificate で信頼できる CA を渡し、insecure_tls は false のままにします。

検索のためのバインド: binddn と bindpass を指定し、ユーザー・グループを検索します。deny_null_bind=true で匿名 bind を明示的に拒否します。

ユーザー・グループの範囲: userdn（例: ou=Users,dc=example,dc=com）と groupdn を設定。userattr は OpenLDAP なら uid、AD なら sAMAccountName が一般的です。discoverdn=true を有効化すると、ユーザー名から DN を解決しやすくなります。

• 本番は LDAPS か StartTLS を必須化（証明書チェーンを Vault に提供）
• deny_null_bind=true、insecure_tls=false を維持
• userattr と groupfilter はディレクトリ実装に合わせて検証
• ポリシーは auth/ldap/groups/<name> または users/<name> で付与（原則はグループで管理）

ステップバイステップ実装（有効化・設定・マッピング・テスト）

1) 認証方式の有効化: パスを明示して有効化します（例: auth/ldap/）。

2) 接続設定: LDAP/LDAPS の URL、binddn、検索範囲、TLS の信頼を設定します。

3) ポリシーマッピング: ディレクトリのグループ名を Vault のポリシーに対応付けます（原則グループ単位）。

• 最初は検証用に限定的なポリシーを割り当て、想定外の権限付与がないか確認
• グループ名の大文字小文字差異に注意（ディレクトリ実装により挙動が異なる）
• ログイン成功後の token の policies を確認して、マッピング漏れを検出

設定とテストの CLI 例

vault auth enable -path=ldap ldap

vault write auth/ldap/config \
  url="ldaps://ldap.example.com:636" \
  binddn="cn=vault-bind,ou=svc,dc=example,dc=com" \
  bindpass="s3cr3t" \
  userdn="ou=users,dc=example,dc=com" \
  userattr="uid" \
  groupdn="ou=groups,dc=example,dc=com" \
  groupfilter="(&(objectClass=groupOfNames)(member={{.UserDN}}))" \
  starttls=false \
  insecure_tls=false \
  certificate=@/etc/ssl/certs/ldap-ca.pem \
  discoverdn=true \
  deny_null_bind=true

# グループとポリシーのマッピング
vault write auth/ldap/groups/platform-admin policies="admin,kv-ro"
vault write auth/ldap/groups/dev policies="default,kv-ro"

# 必要に応じてユーザー単位で上書き（最小限に限定）
# vault write auth/ldap/users/alice policies="breakglass"

# ログインテスト
echo "<password>" | vault login -method=ldap -format=json username=alice

# 認証方式のチューニング（例：トークン種別）
vault auth tune -token-type=default-service ldap/

AD と OpenLDAP の違いとフィルター実例（比較表あり）

ディレクトリのスキーマや属性名が異なるため、userattr や groupfilter の最適解は AD と OpenLDAP で変わります。AD では sAMAccountName や UPN、group の member 属性、さらにはネストグループを解決するためのマッチングルール（1.2.840.113556.1.4.1941）がよく使われます。OpenLDAP では uid と groupOfNames/posixGroup のどちらを採用しているかでフィルターが変わります。

Vault 側は groupfilter でグループ検索を行い、得られたグループ名と auth/ldap/groups/<name> のマッピングによりポリシーを付与します。groupfilter のテンプレート変数 {{.UserDN}} と {{.Username}} のどちらを使うかは、ディレクトリの group エントリが何を持っているか（DN か name か）に合わせます。

• AD: userattr=sAMAccountName、member:...=UserDN を使うのが堅い。ネストは in-chain ルールを検討
• OpenLDAP: uid + groupOfNames(member=UserDN) か posixGroup(memberUid=Username) のどちらか
• groupfilter は少しずつ変えて ldapsearch で検証し、想定通りのグループが返ることを確認

フィルター例（用途別）

# AD: 直接所属グループ
(&(objectClass=group)(member={{.UserDN}}))

# AD: ネスト含む所属グループ（in-chain）
(&(objectClass=group)(member:1.2.840.113556.1.4.1941:={{.UserDN}}))

# OpenLDAP: groupOfNames
(&(objectClass=groupOfNames)(member={{.UserDN}}))

# OpenLDAP: posixGroup（ユーザー名で照合）
(&(objectClass=posixGroup)(memberUid={{.Username}}))

運用・セキュリティ考慮（回転・証明書・監査・障害時）

資格情報の回転: bindpass は定期的にローテーションし、設定反映後はログインテストを自動化して失敗を早期検知します。CI/CD から vault write を安全に実行できる仕組みを用意します。

証明書運用: LDAP サーバの CA 変更時は、certificate パラメータを更新してから切替えると中断を避けやすいです。insecure_tls を一時的に true にしてしのぐ運用は避けます。

監査: Vault の audit デバイス（file/syslog 等）を有効化し、auth/ldap/login への書き込みイベントを記録します。失敗が続く場合は LDAP サーバ側ログと突き合わせます。

• 定期的な bind アカウント有効性チェック（期限切れ・ロックアウト検知）
• audit ログで group マッピング結果（policies）を確認
• 変更はステージング環境で ldapsearch によるフィルター検証を事前実施
• メンテナンスタイミングで certificate を段階ロールアウト

運用時の代表コマンド

# bind パスワードローテーション
vault write auth/ldap/config \
  binddn="cn=vault-bind,ou=svc,dc=example,dc=com" \
  bindpass="<new-password>"

# LDAP 認証の詳細リスト
vault auth list -detailed

# audit（例: ファイル出力）
vault audit enable file file_path=/var/log/vault_audit.log

試験対策の観点と落とし穴（Associate 向け）

ポリシー付与の場所を言えるか: auth/ldap/groups/<groupname> または users/<username> に policies を書く。groupfilter 自体は検索条件であり、ポリシー付与は別物。

ログインパス: ユーザーは vault login -method=ldap username=<name>（または auth/ldap/login/<name>）でログインする。ユーザーのパスワードは Vault に保存されない（LDAP で検証）。

TLS の基本: 本番で insecure_tls を使わない、certificate で信頼を与える。ldap:// を使う場合は starttls=true。

• 落とし穴: groupfilter を変えても、auth/ldap/groups にマッピングが無いとポリシーは付与されない
• 落とし穴: StartTLS は 389/TCP、LDAPS は 636/TCP。ファイアウォール例外の確認を忘れない
• 落とし穴: 証明書チェーン不一致で TLS 失敗。中間 CA まで含めて certificate を渡す

問題で確認

よくある質問