Zimbraの外部LDAP認証の設定方法

Zimbraにおける外部LDAP認証の変更点とは？

外部LDAP認証を使用すると、ZimbraはZimbraの内部LDAPに保存されているパスワードではなく、別のディレクトリに対してユーザーのパスワードを検証できます。最新のZimbra Daffodil（v10）管理者ガイドによると、外部LDAP認証はドメインごとに設定され、外部方式では指定されたユーザー認証情報を使用して指定されたディレクトリへのバインドを試みます。バインドが成功した場合、パスワードは有効とみなされます。

これにより、外部LDAPディレクトリが自動的にZimbraのアカウントデータベースに変換されるわけではありません。Zimbraは、Zimbra固有のアカウントデータを独自のディレクトリに保存します。v10ガイドでは、自動プロビジョニングを別途設定しない限り、ユーザーは通常、Zimbraと外部ディレクトリの両方に存在する必要があると明記されています。

最新の製品ドキュメントについては、Zimbra Daffodil v10 管理者ガイドおよびZimbra v10 設定ガイドを参照してください。

簡単な計画チェックリスト

• 変更したい Zimbra ドメインを確認してください。例: example.com。
• 同じユーザーが既にZimbraに存在することを確認するか、自動プロビジョニングを別途計画してください。
• 外部LDAPホスト名、ポート番号、TLS方式、および証明書チェーンを把握しておくこと。
• Zimbraのログイン名がLDAPのユーザーDNにどのようにマッピングされるかを理解してください。
• ログイン名から直接DNを構築できない場合は、検索ベース、検索フィルタ、および最小権限の検索アカウントを準備してください。
• テスト中はZimbraの管理者セッションを開いたままにしておき、必要に応じてすぐにロールバックできるようにしておきましょう。

まず適切なマッピング方法を選択してください。

現在のv10設定ガイドでは、search-base、search-bind、search-filter、およびアカウントごとのexternal-DN属性が引き続き定義されています。Zimbraテクニカルセンターの古い公式資料では、これらのマッピングが実際にどのように使用されるかが説明されています。この資料はDaffodilより前のものなので、運用上の背景情報として扱い、大規模な移行を適用する前に、インストール済みのリリースと照らし合わせて詳細を確認してください。Zimbraテクニカルセンターの公式外部LDAPノートを参照してください。

ステップ1：現在のドメイン認証設定を記録する

オペレーティングシステムのユーザーとして管理者コマンドを実行しますzimbra。変更を加える前に、既存のドメイン値をキャプチャしてください。

su - zimbra

zmprov gd example.com \
  zimbraAuthMech \
  zimbraAuthLdapURL \
  zimbraAuthLdapBindDn \
  zimbraAuthLdapSearchBase \
  zimbraAuthLdapSearchFilter \
  zimbraAuthFallbackToLocal

出力を変更記録に保存します。v10 構成ガイドには、、、、および Kerberos またはカスタムメカニズムを含む、の有効な値が一覧表示されています。このzimbraAuthMechガイドでは、ターゲットメカニズムはです。zimbraldapadldap

ステップ2：Zimbraを変更する前に、ネットワークの到達可能性とTLSを確認する

基本的な接続が正常に機能することが確認できるまでは、認証マッピングのトラブルシューティングは行わないでください。Zimbraサーバーから、DNS解決とLDAPエンドポイントへの到達可能性を確認してください。LDAPSの場合は、OpenSSLを使用して証明書チェーンを検査できます。

openssl s_client -connect ldap.example.net:636 \
  -servername ldap.example.net -showcerts

標準LDAPとStartTLSを使用するディレクトリの場合、お使いのオペレーティングシステムに適したLDAPクライアントを使用して、StartTLS対応エンドポイントをテストしてください。ldapsearchインストールされている場合、検索アカウントのチェックは次のようになります。

ldapsearch -x -H ldap://ldap.example.net:389 -ZZ \
  -D "cn=zimbra-search,ou=svc,dc=example,dc=net" -W \
  -b "ou=people,dc=example,dc=net" \
  "(uid=alice)" dn

Zimbra v10 管理者ガイドには、ldaps:エンドポイントが LDAP サーバー証明書を Zimbra から信頼されている必要があると記載されています。テストに合格させるためだけに証明書の検証を省略しないでください。ご使用の Zimbra ビルドに合わせて、適切な CA または証明書チェーンをトラストストアの手順に従ってインストールしてください。

ステップ3：ユーザーDNが予測可能な場合は、直接バインドDNテンプレートを構成する

これは最もシンプルなパターンです。外部ディレクトリにユーザーがとして保存され、uid=alice,ou=people,dc=example,dc=netZimbraのログインがであるとしますalice@example.com。ドメインを次のように設定します。

zmprov md example.com zimbraAuthMech ldap

zmprov md example.com \
  zimbraAuthLdapURL "ldaps://ldap.example.net:636"

zmprov md example.com \
  zimbraAuthLdapBindDn "uid=%u,ou=people,dc=example,dc=net"

管理者ガイドzimbraAuthLdapBindDnでは、外部バインドに使用されるDNを決定するために使用されるフォーマット文字列として説明されています。Zimbraテクニカルセンターの公式ドキュメントでは、%uログイン名のローカル部分や%n完全なログイン名など、一般的な置換値について説明しています。

DNテンプレートは、正しいディレクトリオブジェクトを確実に識別できる場合にのみ使用してください。ユーザーが異なる組織単位に属している場合、またはDNがログイン名から派生していない場合は、代わりに検索フィルタパターンを使用してください。

ステップ4：DNを直接構築できない場合は、検索フィルタマッピングを使用する

検索フィルタマッピングにより、Zimbraはまずユーザーエントリを特定し、次に返されたDNに対して認証を行います。v10設定ガイドでは、検索関連の必須ドメイン属性を定義しています。

一般的なOpenLDAPスタイルの設定は以下のとおりです。

zmprov md example.com \
  zimbraAuthLdapSearchBase "ou=people,dc=example,dc=net"

zmprov md example.com \
  zimbraAuthLdapSearchFilter "(uid=%u)"

zmprov md example.com \
  zimbraAuthLdapSearchBindDn \
  "cn=zimbra-search,ou=svc,dc=example,dc=net"

ディレクトリのパスワードをシェル履歴に直接書き込まないようにするには、まず一時的なシェル変数に読み込んでください。

read -s LDAP_BIND_PASSWORD
zmprov md example.com \
  zimbraAuthLdapSearchBindPassword "$LDAP_BIND_PASSWORD"
unset LDAP_BIND_PASSWORD

検索アカウントには、設定されたデータベース内のユーザーを検索するために必要な読み取りアクセス権限のみが必要です。広範なディレクトリ管理権限は必要ありません。

Active Directory の場合、ログイン規則に応じて、フィルタはsAMAccountNameまたは を使用する場合がありますuserPrincipalName。Zimbra は外部 Active Directory 認証メカニズムも提供しているため、汎用 LDAP 設定ですべての AD 環境を強制するのではなく、展開環境に最適な AD 固有のメカニズムを使用してください。

ステップ5：Zimbraが実際に保存した内容を確認する

変更後にドメイン属性を読み戻してください。

zmprov gd example.com \
  zimbraAuthMech \
  zimbraAuthLdapURL \
  zimbraAuthLdapBindDn \
  zimbraAuthLdapSearchBase \
  zimbraAuthLdapSearchFilter \
  zimbraAuthLdapSearchBindDn \
  zimbraAuthFallbackToLocal

引用符の誤り、ベースDNの誤り、予期しないホスト名、または以前の試行で残された古いマッピングがないか確認してください。検索バインドのパスワードをドキュメント、スクリーンショット、チケット、またはシェルのトランスクリプトに印刷しないでください。

ステップ6：広範囲展開の前に、管理対象ユーザー1名でテストを実施する。

Zimbraと外部ディレクトリの両方に存在する、管理者権限を持たないテストアカウントを選択してください。以下のケースを意図的にテストしてください。

• 正しい外部LDAPパスワードがあれば、Zimbraにログインできます。
• 誤った外部LDAPパスワードが拒否されました。
• 無効化またはロックされたディレクトリアカウントは、ディレクトリポリシーに従って動作します。
• 自動プロビジョニングが設定されていない限り、存在しないZimbraアカウントにはログインできません。
• LDAPサーバーまたはネットワークの障害が発生すると、想定どおりの障害動作が発生します。

最後のテストが重要なのは、zimbraAuthFallbackToLocalそれが別のドメインオプションだからです。v10 のドキュメントによると、そのデフォルトは ですFALSE。フォールバックを有効にすると、慎重に設計された移行には役立つかもしれませんが、古いローカル Zimbra パスワードが有効なままの場合、外部ディレクトリのパスワードを無効化または変更してもすぐにアクセスがブロックされるという期待が裏切られる可能性もあります。フォールバックは、一般的なトラブルシューティングスイッチではなく、セキュリティ ポリシーの決定事項として扱ってください。

ステップ7：自動プロビジョニングも必要かどうかを決定する

外部認証とアカウントプロビジョニングは異なる機能です。新しいディレクトリユーザーにZimbraアカウントを自動的に付与する場合は、Zimbraの自動プロビジョニングを別途設定してください。最新のv10管理者ガイドには、EAGER、LAZY、MANUALモードとそのzimbraAutoProv*属性について記載されています。

自動プロビジョニングに認証設定を安易に再利用しないでください。自動プロビジョニングには、URL、バインド、検索ベース、フィルタ、アカウント名マッピング、属性マッピングなど、個別のオプションがあります。まず、既存ユーザーに対する外部認証を確実に機能させ、その後、プロビジョニングを2番目の変更点として設計してください。

よくある故障パターンとチェックすべき点

ロールバック計画

外部ディレクトリ構成によって通常のユーザー認証が妨げられる場合は、既に開いている管理者セッションを使用して、ドメインを内部Zimbra認証に戻してください。

zmprov md example.com zimbraAuthMech zimbra

次に、その値を確認します。

zmprov gd example.com zimbraAuthMech

緊急ロールバック時には、特別な理由がない限り、外部LDAP属性を削除しないでください。属性を保持しておくことで、何が失敗したのかを容易に確認し、マッピングやTLSの問題を修正した後に再試行することができます。

実用的な参考資料の概要

• zimbraAuthMech: ドメインの認証メカニズムを選択します。
• zimbraAuthLdapURL: 外部LDAPエンドポイント。SSLldaps:経由のLDAPに使用します。
• zimbraAuthLdapBindDn: 直接バインディング用のユーザーDNを構築するために使用されるフォーマット。
• zimbraAuthLdapSearchBase: Zimbraが外部ユーザーを検索するサブツリー。
• zimbraAuthLdapSearchFilter: ユーザーを特定するために使用されるLDAPフィルタ。
• zimbraAuthLdapSearchBindDnまたzimbraAuthLdapSearchBindPassword、匿名検索が適切でない場合に検索に使用される認証情報。
• zimbraAuthLdapExternalDn: 単一の Zimbra アカウントに対する明示的な外部 DN マッピング。
• zimbraAuthFallbackToLocal: 外部認証が失敗した場合に、Zimbra がローカル認証にフォールバックするかどうかを制御します。

最終検証チェックリスト

• 外部LDAPエンドポイントは、Zimbraメールボックスサーバーからアクセス可能です。
• TLS証明書の検証は、安全でない回避策を用いることなく成功します。
• 選択されたbind-DNテンプレートまたは検索フィルタは、1つのログインを1つのディレクトリエントリに正確にマッピングします。
• テストユーザーはZimbraに存在するか、または自動プロビジョニングが意図的に設定されている。
• 正しいパスワードと間違ったパスワードのテストは、期待どおりに動作します。
• フォールバック動作は、お客様のセキュリティポリシーに準拠します。
• 元のドメイン設定とロールバックコマンドについては、ドキュメントに記載されています。

本番環境への変更については、テストドメイン1つまたは小規模なユーザーグループを用いた段階的なロールアウトを推奨します。IDマッピングが予測可能な場合、外部LDAP認証は容易です。最も厄介な障害は、DNマッピング、証明書の信頼性、または認証とアカウントプロビジョニングの混同から発生します。