SSL更新後にZimbra管理コンソールで発生する404 Not Foundエラーを修正する
SSL更新後に発生するZimbra管理コンソールの404エラーを修正するには、正しいURLとポート、プロキシルーティング、サービスステータス、デプロイ済みの証明書、およびログを確認してください。
Nextcloudへのサインインに組織と同じディレクトリアカウントを使用する必要がある場合は、組み込みのLDAPユーザーおよびグループバックエンドを有効にし、LDAPまたはActive Directory(AD)に接続するように構成してください。最も安全な設定は、検索専用のディレクトリアカウント、暗号化された転送、意図的に制限されたユーザー範囲、および展開前のテストログインを使用することです。
以下の手順は、2026年10月7日に確認されたNextcloud 35管理者マニュアルに基づいています。Nextcloudのリリースバージョンやホスティングパッケージによっては、コントロールのラベルや配置が異なる場合があります。インターフェース画像は、ドキュメントに記載されている設定を視覚的に説明するものであり、実際のサーバーの動作を示すものではありません。ご使用のバージョンのラベルと管理者マニュアルをご参照ください。
Nextcloudはディレクトリに対して認証済みユーザーを確認するため、ユーザーは別途ローカルのNextcloudパスワードを用意することなく、LDAPまたはADの認証情報でサインインできます。LDAPバックエンドはディレクトリグループも公開できます。Nextcloudはディレクトリ情報を読み取るだけで、ディレクトリアカウントの管理、編集、削除は行いません。これらのアカウントとグループメンバーシップは、引き続きLDAP管理者の責任となります。
これは、組織が既にアカウントを一元管理している場合に便利です。ただし、依存関係が追加されます。Nextcloudはディレクトリにアクセスし、TLS証明書を検証できる必要があります。ディレクトリの障害、ネットワークルール、または証明書の問題によってディレクトリへのサインインが中断される可能性があるため、統合の設定中は、テスト済みのNextcloud管理者アカウントとサーバーへの動作可能なパスを確保しておいてください。

ldaps://directory.example.com、 のような LDAPS ホスト名を受け入れます。ポート 636 は通常の LDAPS のデフォルトです。dc=example,dc=com。メールアドレスのドメインから推測するのではなく、ディレクトリ管理者に正しい DN を問い合わせてください。php-ldap。ターンキーインストールでは、必要なモジュールが既にバンドルされている場合があります。その場合は、パッケージのドキュメントを参照してください。ディレクトリ用に承認されているLDAPSまたはTLSで保護された別のLDAPトランスポートを使用してください。Nextcloudホストに発行証明書チェーンをインストールし、PHPのLDAPライブラリがそれを信頼していることを確認してください。本番環境で証明書の検証を無効にすることで証明書エラーを解決しないでください。
ldaps://directory.example.com。Nextcloudが自動的に検出しない場合は、正しいポート番号を入力してください。一般的なLDAPSポートは636です。組織で別のセキュアなLDAP構成を使用している場合は、ディレクトリチームの設定に従ってください。dc=example,dc=com。ユーザーまたはグループが別々のブランチに存在する場合は、基本接続が確立された後、詳細設定でベースツリーを絞り込むことができます。
Nextcloudはポート番号やベースDNなどの値を自動検出でき、セットアッププロセスでは一般的なActive Directoryの設定を認識できます。検出結果はあくまで出発点として捉え、表示されたベースDNと返されたユーザーが意図したディレクトリ範囲と一致していることを確認してください。
これらは関連していますが、それぞれ独立した設定です。[ユーザー]タブでは、Nextcloudのユーザー一覧に表示されるディレクトリユーザーを制御します。[ログイン属性]タブでは、Nextcloudがサインイン時にユーザーが入力した名前と比較するディレクトリ属性を制御します。ユーザーが検出可能になったからといって、ログイン属性が意図どおりに設定されているとは限りません。
「ユーザー」タブで、Nextcloud が検出したオブジェクトクラスとユーザーフィルターから始めます。ディレクトリグループへのアクセスを制限する場合は、グループ選択またはディレクトリがサポートする生の LDAP クエリを使用します。たとえば、AD スタイルのフィルターは次のようになります(&(objectCategory=person)(objectClass=user)(memberOf=CN=Nextcloud Users,OU=Groups,DC=example,DC=com))。グループ DN とベースを実際のディレクトリの値に置き換えてください。この例をそのまま貼り付けないでください。
ログイン属性で、組織が意図するログイン識別子を選択します。Active Directory の場合、これは通常アカウント名属性ですsAMAccountName。組織によっては、メールアドレスによるサインインも許可している場合があります。ポリシーと一致するように選択し、スタッフが使用する正確なユーザー名形式をテストしてください。グループ タブで、Nextcloud で利用可能にするディレクトリ グループを選択します。グループの検出とログインの許可は、必ずしも同じ範囲ではありません。

通常は変更する必要はありません。まず、基本的な接続とディレクトリの範囲を確認してください。「詳細設定」タブには、接続、ディレクトリ、特殊属性、プロファイルに関するオプションが含まれています。ご使用の環境に必要な設定のみを変更してください。
IDマッピングには特に注意してください。Nextcloudは、各LDAPユーザーに安定した内部ユーザー名を割り当てます。これは通常、ディレクトリのUUIDから派生したもので、そのIDをディレクトリのエントリにマッピングします。内部ユーザー名は、ホームフォルダ名やサービスURLに使用できます。アカウントのマッピング後にUUIDまたは内部ユーザー名のルールを変更すると、Nextcloudがユーザーを異なるユーザーとして扱い、既存のファイルへのアクセスが複雑になる可能性があります。これらの値は本番環境に移行する前に決定し、稼働中のサーバーでLDAPマッピングをクリアしないでください。
初回展開時には、LDAPパスワード変更操作のためにディレクトリ権限と暗号化されたトランスポートを明示的に設定していない限り、LDAPパスワード変更を有効にしないでください。Nextcloudのドキュメントには、書き込み権限やTLSなど、パスワード変更に関する追加要件が記載されています。通常のLDAP認証では、検索アカウントにユーザーパスワードを変更する権限を与える必要はありません。

| 症状 | チェックすべき事項 |
|---|---|
| 接続タイムアウトまたはサーバーに接続できません | NextcloudホストのDNS、ルーティングとファイアウォールルール、ホスト名、およびLDAPポートを確認してください。選択したセキュアエンドポイントでディレクトリがリッスンしていることを確認してください。 |
| 証明書またはTLSエラー | サーバーのPHP LDAPスタックが信頼できるディレクトリ証明書チェーンをインストールしてください。システムのLDAP CA構成を確認し、LDAPSの場合はポートがエンドポイントと一致していることを確認してください。証明書の検証は有効にしておいてください。 |
| バインドまたは無効な認証情報 | 検索アカウントの完全なDN、パスワード、および設定されたサブツリーを検索する権限を確認してください。ログイン失敗をユーザーパスワードの誤りとして扱う前に、設定が有効であることを確認してください。 |
| 接続は成功しましたが、ユーザーページは空です。 | ベースDN、ユーザーオブジェクトクラス、ユーザーフィルタ、およびグループ制限を確認してください。フィルタは構文的に有効であっても、意図したアカウントに一致しない場合があります。 |
| ユーザーが表示されるが、ログインできない | ログイン属性と、ユーザーが入力した正確なログイン識別子を確認してください。また、アカウントがログインフィルタの範囲内にあること、およびLDAP構成が有効になっていることも確認してください。 |
| ネストされた AD グループはアクセスを許可しません | Nextcloudのドキュメントによると、ネストされたグループを有効にするだけでは、ユーザー一覧表示とログインには不十分な場合があります。ユーザーおよびログインフィルタには、Active Directoryのマッチングルールをチェーンに含める必要がある場合もあります。正確なフィルタ設定については、ディレクトリ管理者と調整してください。 |
コマンドライン診断のために、Nextcloud は LDAP バックエンドアプリが有効になっている場合に LDAP コマンドを提供します。occ ldap:show-configコマンドを実行して構成 ID を見つけ、次に を実行してテストします。 をサーバーに表示されている ID にocc ldap:test-config s01置き換えてくださいs01。一般的な Linux インストールでは、コマンドは次のようになります。
sudo -E -u www-data php /var/www/nextcloud/occ ldap:test-config s01
インストール環境に合わせて、Webサーバーのユーザー名とNextcloudのパスを調整してください。診断出力は機密情報として扱ってください。設定の詳細からディレクトリ構造が特定される可能性があります。
これらのチェックにより、テスト対象のディレクトリパスとアカウントで統合が正しく機能することが確認できます。フィルタ、証明書、グループ構造、またはLDAPサーバーアドレスを変更した後は、再度チェックしてください。リリース固有の正確なラベルについては、NextcloudのLDAP認証マニュアル、PHPモジュールのガイダンス、およびLDAP occコマンドのリファレンスを参照してください。
SSL更新後に発生するZimbra管理コンソールの404エラーを修正するには、正しいURLとポート、プロキシルーティング、サービスステータス、デプロイ済みの証明書、およびログを確認してください。
アクティブなPHP SAPI、サイズ制限、コメント、および再検証設定を確認することで、NextcloudのPHP OPcache構成警告を診断および修正する方法を学びましょう。
MySQLまたはMariaDBのアップグレード後にKopanoデータベースの移行が失敗した場合は、バックアップ、サーバーバージョン、SQLモード、文字セット、スキーマ状態、およびログを確認してトラブルシューティングを行います。
セキュアなトランスポート、ユーザーおよびグループフィルタ、ログイン属性、そしてテスト済みの展開機能を使用して、NextcloudをLDAPまたはActive Directoryに接続します。
UnifiedPush、Androidの権限設定、バッテリー設定、および信頼性の高い検証テストを設定することで、Googleサービスを削除した端末におけるElement Android通知の問題を修正します。
Nextcloudのデータベースインデックス不足警告を、公式のoccコマンドでクリアします。まずバックアップを作成し、変更内容をプレビューしてから修復を実行し、結果を確認してください。
Element Web 用の Keycloak SSO を設定するには、OIDC を Synapse に接続し、正確なコールバック URL を設定し、ユーザー クレームをマッピングし、ログアウトをテストします。
応答しないLDAPサーバーが原因で発生するZimbraの起動失敗を診断および修正する方法を学びましょう。これには、サービスチェック、DNS、ポート、証明書、LDAP URL、および復旧検証が含まれます。
ownCloud Infinite Scale向けに、s3ngドライバ、POSIXメタデータ、バケットポリシー、検証、および安全な本番環境チェックを使用して、S3互換のオブジェクトストレージを設定します。
Zimbra Postfixのバックログを検査する方法、延期されたメールと保留されたメールを識別する方法、安全なキューフラッシュを実行する方法、メッセージを削除せずに進捗状況を確認する方法を学びましょう。