ownCloud Infinite ScaleでLDAP認証を設定する方法

Infinite ScaleにおけるLDAP認証とは何ですか？

ownCloud Infinite Scale (oCIS) は、OpenID Connect (OIDC) を介してブラウザおよびクライアントセッションを認証します。LDAP は、組み込みの oCIS ID プロバイダの背後にあるディレクトリ ユーザーと認証情報を提供することも、Keycloak などの外部 OIDC プロバイダの背後に配置することもできます。適切な構成は、シンプルなログイン フローを備えた小規模なデプロイメントが必要なのか、より広範な制御機能を備えた本番環境の ID プラットフォームが必要なのかによって異なります。

その区別は、oCISがownCloud Server Classicとは異なるため重要です。Web管理ページからLDAPを設定するクラシックチュートリアルや、occ ldap:*oCISを設定しないチュートリアルでは、設定項目が異なります。oCISでは、設定はデプロイメント環境変数またはサービス構成であり、複数のサービスで同じディレクトリの一貫したビューが必要になる場合があります。

ownCloudのバージョン管理されたIDPサービスドキュメントによると、組み込みプロバイダは外部LDAPバックエンドを使用できるとのことです。セキュリティガイダンスでは、大規模な環境や本番環境では外部OIDCプロバイダの使用を推奨しています。このガイドはoCIS 8.2のドキュメントに基づいています。デフォルト値やデプロイメント例が変更される可能性があるため、変数を適用する前に、インストールされているリリースに対応するドキュメントを確認してください。

どの認証設計を選択すべきでしょうか？

既にKeycloakなどのOIDCプロバイダーを使用している場合は、ディレクトリに接続する方が通常はよりクリーンな運用環境構築方法です。小規模な導入で、組み込みプロバイダーの制限が許容範囲内であれば、IDPのLDAPバックエンドを設定し、ユーザーにアクセスを許可する前にテストを実施してください。

oCISを編集する前に、何を準備しておくべきですか？

• oCISの正確なバージョンとデプロイ方法（Docker Compose、Kubernetes、監視付きバイナリプロセスなど）。
• LDAPサーバーのDNS名、TLS証明書チェーン、およびLDAPSエンドポイント。ldaps://証明書の検証を有効にすることを推奨します。信頼性の問題を隠すために検証を無効にしないでください。
• 最小限の権限を持つバインドアカウントとその完全な識別名（DN）。このアカウントは、不要な書き込み権限を持たずに、oCISが必要とするユーザーおよびグループブランチを検索できる必要があります。
• ユーザー検索のベースDN、検索範囲、ログイン属性、オブジェクトクラス、メールアドレスと表示名属性、および安定した一意のユーザーID属性。これらを実際のディレクトリエントリと照合して確認してください。
• ユーザーのLDAPグループがoCISに表示される場合、グループベースDNとメンバーシップ属性を指定します。
• 現在のoCIS構成のバックアップと、LDAPの変更に依存しない、テスト済みの管理者サインイン。

安定したIDマッピングには特に注意が必要です。表示名やメールアドレスは変更される可能性がありますが、固有のIDは同じ人物に紐づけられたままでなければなりません。変更後にoCISが異なる識別子を検出した場合、既存の人物が本来のIDとアクセス権を継承するのではなく、新しいアカウントとして表示されてしまう可能性があります。

内蔵のIDPを外部LDAPサーバーに接続するにはどうすればよいですか？

oCISの組み込みIDPを使用する小規模なデプロイメントの場合、デプロイメントで使用する環境またはサービス構成で、IDPスコープのLDAP変数を設定してください。以下の値は例です。ホスト名、DN、証明書パス、スキーマ名は、ご使用のディレクトリの値に置き換えてください。

IDP_LDAP_URI=ldaps://ldap.example.net:636
IDP_LDAP_TLS_CACERT=/etc/ocis/certs/directory-ca.pem
IDP_LDAP_BIND_DN=uid=ocis-reader,ou=service,dc=example,dc=net
IDP_LDAP_BIND_PASSWORD=<load-from-your-secret-store>
IDP_LDAP_BASE_DN=ou=people,dc=example,dc=net
IDP_LDAP_SCOPE=sub
IDP_LDAP_LOGIN_ATTRIBUTE=uid
IDP_LDAP_EMAIL_ATTRIBUTE=mail
IDP_LDAP_NAME_ATTRIBUTE=displayName
IDP_LDAP_UUID_ATTRIBUTE=entryUUID
IDP_LDAP_UUID_ATTRIBUTE_TYPE=text
IDP_LDAP_OBJECTCLASS=inetOrgPerson

IDP リファレンスには、URI、CA 証明書、バインド DN とパスワード、ユーザーベース DN、スコープ、ログイン属性、UUID 属性、オブジェクトクラスなど、これらの設定が記載されています。この例では、ディレクトリがテキスト形式のファイルを提供していることを前提としています。Active entryUUIDDirectory やその他のスキーマでは、異なるマッピングが必要になる場合があります。ここに記載されているからといって、そのままコピーしないでくださいentryUUID。

バインドパスワードは、デプロイメントシークレットとして、またはプラットフォームで推奨されているシークレットメカニズムに保存してください。公開のComposeファイル、リポジトリ、またはチケットにコミットしないでください。CA証明書はoCISプロセスで読み取り可能な状態にし、証明書の検証を保持してください。IDPのINSECURE設定ではLDAP TLS証明書の検証が無効になり、本番環境での使用は想定されていません。

アカウント無効化の動作もディレクトリに合わせてください。IDP のドキュメントには が記載されていますIDP_USER_ENABLED_ATTRIBUTE。デフォルトでは ownCloud 固有の属性名です。ディレクトリで有効/無効フラグが異なる場合は、その実際の属性をマッピングしてください。ユーザー サービスのUSERS_LDAP_DISABLE_USER_MECHANISMも確認してください。ディレクトリによっては、ドキュメントに記載されている選択肢は属性ベースの処理、グループベースの処理、または ですnone。スキーマの不一致により無効化されたアカウントがアクティブとして扱われないように、 を意図的に選択してください。

ユーザーやグループの検索にもLDAP設定が必要ですか？

多くの場合、そうです。パスワードの検証とユーザーの検出は関連していますが、それぞれ独立した処理です。IDPはログインを認証し、oCISユーザーとGraphサービスはプラットフォームにユーザーおよびグループ情報を提供します。oCISのIDソースとして外部ディレクトリを使用する場合は、ユーザーとGraph LDAPバックエンドが同じディレクトリを読み取り、同じユーザーを一貫してマッピングするように構成してください。

ユーザーサービスについては、 、 、 、 、 、 などのサービススコープ設定を確認してください。デプロイメントで必要な場合USERS_DRIVER=ldapは、メール、表示名、スコープ、およびグループ変数を設定してください。スキーマ名は、一般的な例ではなく、ディレクトリと正確に一致させる必要があります。USERS_LDAP_URIUSERS_LDAP_CACERTUSERS_LDAP_BIND_DNUSERS_LDAP_BIND_PASSWORDUSERS_LDAP_USER_BASE_DNUSERS_LDAP_USER_SCHEMA_IDUSERS_LDAP_USER_SCHEMA_USERNAME

Graphサービスには独自のLDAP設定があります。oCISが管理せずに読み取る既存のディレクトリについては、GRAPH_LDAP_SERVER_WRITE_ENABLED=falseGraph LDAP接続とスキーマを設定および構成してください。ownCloudは、既存のLDAPサーバーに接続するための読み取り専用パターンとしてこれを文書化しています。互換性のあるLDAPスキーマを意図的に準備し、oCISにディレクトリオブジェクトを作成または変更させたい場合を除き、書き込みは無効にしてください。

サービス固有の変数プレフィックスまたはドキュメントに記載されているグローバルOCIS_LDAP_*変数は慎重に使用してください。グローバル変数は複数のサービスに同時に影響を与える可能性があります。最初の統合では、サービスごとに明示的な設定を行うことで、どのサービスが障害を起こしているかを容易に把握でき、意図しない書き込みやスキーマの想定を防ぐことができます。ユーザーサービスリファレンスとGraphサービスリファレンスには、リリース固有の名前とデフォルト値が記載されています。

設定を安全に適用するにはどうすればよいですか？

1. 現在の環境ファイル、サービスユニット、またはCompose構成のコピーを保存してください。元に戻す方法も記録しておいてください。
2. LDAP変数を実際のoCISサービス定義に追加してください。既存のCompose環境ブロックの残りの部分をこの例で置き換えないでください。設定を既に実行中のデプロイメントに統合してください。
3. oCISサービスが証明書を読み取るコンテナまたはホストの名前空間内に証明書ファイルが存在することを確認してください。ホストパスはコンテナ内では自動的に表示されません。
4. oCISを再起動する前に、バインドアカウントと検索ベースをLDAPに対して検証してください。サービス用に設定されているサーバーホスト名、ベースDN、およびログイン属性は、同じものを使用してください。
5. デプロイメントの通常の手順に従ってoCISを再起動し、サービスが新しい環境を受信できるようにします。マルチサービスまたはマルチノードのデプロイメントでは、各インスタンス上の関連サービスが意図した構成を使用していることを確認してください。
6. 許可されたLDAPアカウント1つと、ログインを許可しないアカウント1つを使用してテストしてください。新しいログインパスが検証されるまで、既存の管理者セッションを開いたままにしておいてください。

ディレクトリを直接チェックする場合、ldapsearchコマンドラインにパスワードを入力せずにバインドとユーザーフィルタをテストできます。

ldapsearch -H ldaps://ldap.example.net:636 \
  -D 'uid=ocis-reader,ou=service,dc=example,dc=net' -W \
  -b 'ou=people,dc=example,dc=net' '(uid=alice)' dn uid entryUUID mail

設定するログイン属性とベースDNを使用してください。クエリが成功した場合、そのクエリに対するネットワーク、TLS、バインド、および検索の動作が確認されますが、すべてのoCISサービスが同じマッピングを使用していることを証明するものではありません。

設定が正しく機能していることをどのように確認しますか？

ログインページが表示されるかどうかだけでなく、結果も考慮して判断してください。テストディレクトリユーザーを使用して通常のoCIS Webフローでサインインし、ファイルを開いて、期待どおりのユーザー名とプロファイルの詳細を確認します。グループが共有やスペースへのアクセスを管理している場合は、既知のグループメンバーシップも1つ確認します。次に、間違ったパスワードと、無効化されているか許可されたユーザー検索の範囲外にあるLDAPアカウントをテストします。これらのアカウントはアクセスできないはずです。

oCIS サービスログを確認し、LDAP 接続、TLS、バインド、およびユーザー検索のエラーがないか確認してください。LDAP バインドが成功した後に oCIS ログインが失敗した場合は、検索フィルタ、ベース DN、ユーザー識別子、または OIDC とユーザーのマッピングの不一致が原因であることが多いです。本番環境でのパイロット運用では、より大規模なグループを移行する前に、既存ユーザーのファイル、共有、およびグループベースのアクセス権限を確認してください。認証チェックが成功しただけでは、既存のアカウント ID と認証が保持されていることを検証することはできません。

ログインがそれでも失敗する場合は、何を変更すればよいですか？

• TLSエラーまたは接続エラーが発生した場合： oCISホストが解決され、LDAPサーバーに到達していること、ポートとスキームが一致していること、およびCAファイルに発行証明書チェーンが含まれていることを確認してください。検証は有効にしておいてください。
• バインドは成功しましたが、ユーザーが見つかりません。正確なユーザーベースDN、スコープ、オブジェクトクラス、ログイン属性、およびフィルタをテストしてください。正しいバインドDNを使用しても、検索が正しいブランチを参照しているとは限りません。
• LDAPはパスワードを受け入れますが、oCISがアカウントを解決できません。IDPログイン識別子とユーザーサービスユーザー名または安定したIDマッピングを比較してください。安定した識別子を維持し、ユーザー名からメールアドレスへの安易な変更は避けてください。
• ログインは正常に機能しますが、グループベースのアクセスが正しくありません。ユーザーとGraphグループのベースDN、グループオブジェクトクラス、メンバー属性、およびGraphバックエンドが意図どおりに読み取り専用または書き込み可能で構成されているかどうかを確認してください。
• MFA、集中型セッション、またはより広範なID制御が必要な場合は、 LDAP認証を外部のOIDCプロバイダーに移行し、oCISがその発行者を信頼するように構成してください。組み込みのIDPは意図的に機能が制限されています。ownCloudは、大規模なインストールには外部プロバイダーの使用を推奨しており、組み込みプロバイダーは外部IDサービスのすべての機能を提供するわけではないことを明記しています。

本番環境のブラウザログインのショートカットとして有効にしないでくださいPROXY_ENABLE_BASIC_AUTH。プロキシのドキュメントには、Basic Auth がサポートされているリクエスト スキームとして記載されていますが、開発環境でのみ使用し、本番環境では使用しないようにと記載されています。標準の oCIS サインインでは、組み込みの OIDC プロバイダの制限が許容範囲内である場合に限り使用するか、LDAP をバックエンドとする外部の OIDC ID プロバイダを接続してください。

この設定の外にあるものは何ですか？

LDAP認証では、oCISでLDAP管理機能がすべて自動的に利用可能になるわけではありません。ユーザーおよびグループのプロビジョニング、グループ同期、書き込みアクセス、パスワード変更、無効化アカウントルール、既存ユーザーのマッピングには、それぞれ互換性のあるサービス設定とLDAPスキーマが必要です。外部OIDC自動プロビジョニングの場合、ownCloudでは、選択したフローでアカウントを作成する際に、安定したユーザークレームと書き込み可能なGraphバックエンドも必要となります。この動作を有効にする前に、プロキシのドキュメントを確認してください。

変更は一度に1つずつ行い、少数のアカウントでテストし、広範囲に展開する前に認証とIDマッピングの両方を確認してください。oCISのリリース、LDAPスキーマ、またはIDプロバイダーが例の前提条件と異なる場合は、サンプルをそのまま再利用するのではなく、そのリリース固有の構成リファレンスに従ってください。