Google Cloud Directory Sync (GCDS)の設定中に問題が発生した場合の解決方法を説明します。
セットアップと設定 | シミュレーションと同期 | エラー | ユーザーとグループ | コンタクトとカレンダー | ルール
Log Analyzer を試す
このツールを使うと、ほとんどの問題を送信から数分以内に特定できます。
- Google 管理者ツールボックスの Log Analyzer に、トレースログ（非圧縮ファイルまたは ZIP ファイル）を送信します。
- 高度なログ分析を行うには、非圧縮ファイルを Log Analyzer 2 に送信します。
トレースレベルのログを有効にする方法をご確認ください。
セットアップと設定
設定マネージャーを使用したトラブルシューティング同期が正しく実行されない問題が発生した場合は、設定マネージャーで設定情報が正しいことを確認し、どのテストで失敗するかを確認します。
- 設定マネージャーで、同期の設定に使用している XML ファイルを開きます。
- [LDAP Connections] ページで [Test Connections] をクリックし、LDAP サーバーに接続できることを確認します。
- [Notifications] ページで [Test Notification] をクリックし、テスト通知を送信できることを確認します。
- [Sync] ページで [Simulate Sync] をクリックし、必須の欄すべてに情報を入力したことを確認してから、同期が実行されることを確認します。
まれに、サポートが、GCDS でのトレースレベルのロギングの有効化に加え、完全な HTTP のロギングの有効化を依頼する場合があります。完全な HTTP のロギングは、GCDS によって行われた正確な API リクエストと、Google API からの応答を確認するために使用されます。
重要: 完全な HTTP ログには、非常に機密性の高い情報が含まれる場合があります。ログをサポートに送信する前に、機密情報（現在の refresh_token や access_token など）を削除してください。
完全な HTTP ロギングを有効にするには:
- sync-cmd または設定マネージャーを使用して、GCDS が実行されていないことを確認します。
- GCDS のインストール フォルダに移動します。
-
jre/lib/logging.properties ファイルを編集します。
- 次の行をファイルの末尾に追加します。
java.util.logging.FileHandler.pattern = %h/gcdshttp%u.%g.log
java.util.logging.FileHandler.limit = 5000000
java.util.logging.FileHandler.count = 100
java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter
handlers = java.util.logging.FileHandler
com.google.api.client.http.level = CONFIG
com.google.gdata.client.http.HttpGDataRequest.level = ALL
sun.net.www.protocol.http.HttpURLConnection.level = ALL - ファイルを保存します。
- 別の GCDS 同期を実行します（ロギングを [Trace] に設定）。
gcdshttp*.log というログファイルが、homedir フォルダ（Linux の場合）または profile フォルダ（Microsoft Windows の場合）に作成されます。これらのファイルはサイズが非常に大きくなる場合があるため、ファイルをまとめてアーカイブします。
- 今後大きいログファイルが作成されないようにするため、手順 4 で追加した行を削除します。
- 次のファイルをサポートに提供します。
- XML ファイル
- 最新の同期のトレースレベルのログと gcdshttp*.log ファイル
リクエストとレスポンスのログのボディのサイズ制限は、それぞれ 16 KB です。この制限を超過したログエントリは完全な状態ではないため、Fiddler などのデバッグ プロキシを使用してください。
これを行うには、GCDS が Windows の信頼された証明書ストアを使用するように .vmoptions ファイルを更新し、CRL チェックをオフにします。GCDS で Fiddler をプロキシ サーバーとして設定します（通常は 127.0.0.1 のポート 8888）。Linux で GCDS を使用している場合、Windows の信頼された証明書ストアを使用できないため、Fiddler のルート証明書を GCDS の Java トラストストアにインポートする必要があります。これらの手順の詳細については、証明書に関する問題のトラブルシューティングをご覧ください。
通知用の SMTP リレーホストの設定で問題が発生した場合は、次のトラブルシューティング手順をお試しください。
接続に失敗する、SMTP ホストが不明であるというメッセージ
- コマンド プロンプトを開きます。
- SMTP サーバーの設定されたホスト名が IP アドレスに解決されるかどうかを確認するには、次のコマンドを入力します。
nslookup smtp-host-name.com
接続に失敗する、SMTP ホストに接続できないというメッセージ
GCDS を実行しているサーバーが SMTP ホストに接続できるかどうかを確認します。
- 接続を確認するには、Windows のコマンド ラインまたはターミナルから次のコマンドを入力します。
telnet smtp.gmail.com 587
- ホストに接続できない場合は、SMTP サーバーの内向きファイアウォール ルールと GCDS サーバーの外向きファイアウォール ルールを確認します。
- SMTP ポートでトラフィックが許可されていることを確認します。
ソケットを TLS に変換できないというエラーがログに記録される
証明書失効リスト（CRL）のチェックをオフにします。詳しくは、GCDS による証明書失効リストの確認についての記事をご覧ください。
別のパソコンに保存されている XML ファイルを開いたり、あるいは同じパソコンで別のユーザーとして XML ファイルを開く方法については、設定ファイルの使い方をご覧ください。
GCDS のトレースレベルのログに含まれる LDAP データが LDAP サーバーに保存されているデータと一致しない（ユーザーが見つからない、属性値が間違っているなど）場合は、LDAP ディレクトリから LDIF 形式でデータを書き出してください。書き出されたデータをサポートが GCDS ログの LDAP データと比較します。
データを書き出す際は ldapsearch（Linux）や ldifde（Windows）などの LDAP クエリツールを使用して、以下のとおり GCDS と同じ条件をシミュレートします。
- GCDS と同じ接続設定を使用する。
- GCDS が実行されているのと同じマシンでクエリツールを実行する。
- GCDS LDAP 認証と同じユーザー名を使用する。
例
GCDS 検索ルールが以下のとおり設定されているときに GCDS のログにユーザーの mail 属性が表示されない場合の例を示します。
- Base DN: ou=Ireland,dc=altostrat,dc=com
- Scope: Subtree
- Search filter: (&(objectCategory=person)(objectClass=user))
- Server: dc01.altostrat.com
- Port: 636
- Protocol: LDAP+SSL
- Authentication user DN: cn=GCDS,ou=Users,dc=altostrat,dc=com
次のコマンドを使用します。
- Linux の場合:
ldapsearch -v -b "ou=Ireland,dc=altostrat,dc=com" -s sub -h dc01.altostrat.com -p 636 -x -Z -D "cn=GCDS,ou=Users,dc=altostrat,dc=com" "(&(objectCategory=person)(objectClass=user))" mail givenname uniqueidentifier sn > out.ldif（システムによってはコマンドの一部を編集する必要があります）。 - Windows:
ldifde -f out.ldif -s dc01.altostrat.com -v -t 636 -d "ou=Ireland,dc=altostrat,dc=com" -r "(&(objectCategory=person)(objectClass=user))" -p SubTree -l mail,givenname,uniqueidentifier,sn -a "cn=GCDS,ou=Users,dc=altostrat,dc=com" PASSWORD（PASSWORDの部分を、GCDS に設定されている LDAP ユーザーのパスワードに置き換えます）。
該当ユーザーの mail 属性が出力ファイル（out.ldif）に含まれていない場合は、LDAP インフラストラクチャに問題があります。LDAP へのアクセスに使用しているユーザーの権限が原因である可能性があります（OpenLDAP と Active Directory の両方で属性レベルでの権限設定を許可しているなど）。あるいは、3268 や 3269 などのグローバル カタログ ポートを使用している場合は、グローバル カタログに属性が複製されないことが原因の可能性の場合もあります。
該当ユーザーの mail 属性が出力ファイルに含まれている場合は、次の情報を Google Workspace サポートにご提供ください。
- out.ldif ファイル
- コマンドを実行したコマンド プロンプトまたはターミナル ウィンドウのスクリーンショット
（必ずパスワードの部分を削除するようにしてください） - GCDS トレースレベルのログ
シミュレーションと同期
通知サーバーを使用せずに同期のシミュレーションを行いたい同期のシミュレーションを実行するには、メールの送信機能を備えたサーバーが必要です。メールサーバーのマシンで GCDS を実行している場合は、メールサーバーで IP アドレス 127.0.0.1 を使用できます。それ以外の場合は、正しいメール情報についてメール管理者にご確認ください。
コマンドラインで同期を実行しているものの同期が開始されない場合は、コマンドラインで -o 引数または --oneinstance 引数を使用したかどうかを確認します。
これらのいずれかの引数を使用すると、GCDS によって XML 設定ファイルに関連付けられた LOCK（.lock）ファイルが作成されます。そのため、同じサーバーで別の LOCK ファイルが見つかった場合、複数の GCDS インスタンスが同時に実行されないようにするため、GCDS は同期を実行しなくなります。
実行中の GCDS インスタンスが他にない場合は、サーバー上にある別の LOCK ファイルを確認します。ファイルを手動で削除して、もう一度同期してみてください。
同期が不完全な場合（たとえば、グループの全メンバーが同期されなかった）は、Directory API に問題が生じている可能性があります。問題が GCDS サービスではなく API に関連するかどうかを確認するには、Directory API を手動で呼び出し、結果を確認します。API を手動で呼び出すには、次の 2 つの方法のいずれかを選択します。
方法 1: API リファレンス ページを使用する
- Admin SDK API リファレンスの概要に移動します。
- 左側の [Directory API] をクリックし、[REST Resources] で、クエリを実行する REST リソースに移動します。
- 右側で試したい方法をクリックし、[試してみる] をクリックします。
API リファレンス ページに [試してみる] が表示されない場合は、「方法 2: OAuth 2.0 Playground を使用する」に進みます。
- GCDS の承認に使用した管理者認証情報を入力します。
詳しくは、Google ドメインの設定を定義するをご覧ください。
- 情報を確認して、API が期待どおりに応答したことを確認します。
方法 2: OAuth 2.0 Playground を使用する
- OAuth 2.0 Playground を開きます。
- 次のどちらかの操作を行います。
- リストからスコープを選択します。
- API リファレンス ページの認可スコープのリストからスコープをコピーします。次に、スコープを [Input your own scope] フィールドに貼り付けます。
- [Authorize APIs] をクリックします。
- GCDS の承認に使用した管理者認証情報を入力します。
詳しくは、Google ドメインの設定を定義するをご覧ください。
- [Exchange authorization code for tokens] をクリックします。
処理が成功すると、[手順 3: API へのリクエストを構成する] にリダイレクトされます。
- 必要な情報を入力します。
ヒント: ほとんどの情報は、API メソッドのリファレンス ウェブページで確認できます。
- [Send the request] をクリックします。
- 情報を確認して、API が期待どおりに応答したことを確認します。
エラー
EntityDoesNotExist/EntityExists エラーまたは競合が発生する原因XML 設定ファイルで useDynamicMaxCacheLifetime オプションを設定します。このオプションを有効にすると、GCDS のデータ キャッシュ期間が最大 8 日に設定され、小中規模のデータセットで頻繁にキャッシュの消去が行われるようになり、キャッシュ データが古くなったり新しいデータと競合したりする回数を減らします。GCDS 3.2.1 以降で作成された構成では、useDynamicMaxCacheLifetime オプションが自動で有効になっています。
注: このようなエラーは通常、Google ドメインで直接変更を加えた場合に発生します。同期に GCDS を使用する場合は、Google ドメインに直接変更を加えることは避け、代わりに LDAP ディレクトリでユーザー、グループ、その他のエンティティに変更を加えるようにしてください。その後 GCDS を使用して、その変更を Google ドメインと同期します。
メモリ関連のエラーが発生した場合は、Java 仮想マシンのヒープサイズを増やす必要があります。そのためには、GCDS のインストール ディレクトリにある sync-cmd.vmoptions ファイルと config-manager.vmoptions ファイルを編集します。関連するエントリは次のように記述されています。
- -Xmx1000m（ヒープサイズの最大メモリ容量）
- -Xms64m（ヒープサイズの最小メモリ容量）
sync-cmd.vmoptions ファイルと config-manager.vmoptions ファイルの両方を編集して、sync-cmd と設定マネージャーの両方のバージョンに変更を適用します。
-Xmxの数値（X の部分）を編集して、メモリ容量を増やします。数値の後の「m」は、メモリの単位がメガバイト（MB）であることを示します。適切なメモリ量は、GCDS サーバーにどれくらいのメモリ量があるか、同期にどれくらいのメモリ量が必要かによって異なります。正しいサイズを設定するまでに、何回か数値の変更が必要になる場合もあります。GCDS の実行に必要な RAM の空き容量について詳しくは、GCDS のシステム要件をご覧ください。
このエラーの原因は、除外ルールの設定に誤りがあるなど、設定上の問題である可能性があります。このような設定の誤りは、GCDS のキャッシュに隠れていることがあります。
GCDS では、Google サービス（Google Workspace や Cloud Identity など）のデータが最長 8 日間キャッシュに保存されます。キャッシュされたデータのサイズによっては、これより短い期間でキャッシュが削除されることがあります。ただし、キャッシュが削除されない場合は、更新が最長 8 日間表示されない可能性があります。
たとえば、LDAP データを同期して Google サービス（Google Workspace や Cloud Identity など）に新しいグループを作成します。その後、除外ルールを作成して、そのグループを以降の同期に含めないように設定します。この除外ルールの設定に誤りがあると処理は失敗するものの、以降の同期ではキャッシュされたデータが呼び出され、グループは Google サービスに残ります。キャッシュをクリアしてもう一度同期すると、設定に誤りがあるために Google サービスからグループが削除されます。
キャッシュを手動で削除するには:
- 設定マネージャーから同期を実行し、同期を行うときにキャッシュをクリアするオプションを選択します。
- コマンドから同期を実行し、引数 -f を使用してキャッシュを強制的にフラッシュします。
- XML 設定ファイルを変更して maxCacheLifetime の値を 0 に設定します。
重要: キャッシュを強制的にフラッシュすると、同期にかかる時間が大幅に長くなります。
ユーザーとグループ
すでに存在する Google ユーザーを GCDS が作成しようとしている理由「409: エンティティが既に存在します」というエラーが表示される場合は、すでに存在する Google ユーザーを GCDS が作成しようとしています。それ以降の同期でエラーが表示されない場合は、GCDS キャッシュが古くなっている可能性があります。このエラーは無視してかまいません。
問題が同期のたびに、または数日おきに発生する場合、最も可能性が高い原因として以下が考えられます。
- Google ユーザーの除外ルールの範囲が広すぎる - 除外ルールが、LDAP ディレクトリ内の一部の Google ユーザーに一致しています。
- クエリの範囲が狭すぎる - クエリが、LDAP ディレクトリ内の一部の Google ユーザーに一致していません。
どちらのシナリオでも、GCDS で既存の Google ユーザーが無視される可能性があります。こうしたユーザーが LDAP ユーザー検索ルールの結果に存在する場合、GCDS はご利用の Google アカウントでそれらのユーザーを作成しようとします。
この問題を解決するには、除外ルールまたは検索クエリを調整します。また、GCDS で LDAP ディレクトリ内のユーザーを完全に無視するようにするには、LDAP のユーザー検索ルールを調整するか、LDAP ユーザー除外ルールを作成します。詳しくは、除外ルールとクエリを使ってデータを除外するをご確認ください。
GCDS では、ユーザー検索ルールの結果とは別にグループ メンバーを同期できるように、デフォルトで INDEPENDENT_GROUP_SYNC オプションがオンになっています。グループの同期に member-reference 属性を使用している場合、GCDS はユーザー検索ルールにかかわらず、LDAP ディレクトリの各ユーザーのメールアドレスを解決しようとします。
ユーザー検索ルールの結果のみに基づいてグループ メンバーを同期するために設定 XML ファイルから INDEPENDENT_GROUP_SYNC を削除すると、GCDS は次のように動作します。
- ユーザー検索ルールの結果を使用してグループ メンバーシップを解決する
- ユーザー同期の対象に含まれているユーザーのみをグループ メンバーとして同期する。
- [General Settings] でユーザー アカウントの同期が無効にされていてもユーザー検索ルールを実行する
（ただし、条件を満たすユーザーがグループ メンバーに該当する場合、ユーザー検索ルールの結果はユーザーではなくグループ メンバーとして Google と同期されます）。
通常、この方法で同期を実行することはおすすめしません。特に、共有の連絡先を同期するときに、連絡先として登録されたグループ メンバーが含まれる場合、その連絡先はグループ メンバーとして同期されません。
この問題は、グループ名属性として設定されている LDAP 属性に完全なメールアドレスが含まれていない場合に発生します。この問題を解決するには、グループ検索ルールで、GCDS がグループ名に完全なメールアドレスを使っていることを確認します。確認は次のいずれかの方法で行います。
- グループ名属性を、メールなど各グループのメールアドレス全体を指定する別の LDAP 属性に設定します。
- [Google Domain Settings] で [Replace domain names in LDAP email addresses] をオンにし、グループ名属性が Google 側のグループ名と一致するようにします。
- グループ検索ルールでグループ名のサフィックスを指定して、ドメイン名をグループ名に追加します。
[LDAP Configuration] セクションの [Server Type] 欄で、[MS Active Directory] を選択していることを確認します。
このオプション（XML ファイル内では SUPPRESS_DOMAIN と表示されます）は、LDAP ディレクトリ内に保存されているメールアドレスのドメインが Google ドメインとは異なる場合に使用します。このオプションをオンにすると、GCDS で読み込まれるすべてのメールアドレスからドメインの部分が削除されます。
すべての処理がドメイン名なしで実行されます。メールアドレスに基づいた除外ルールを使用する場合、除外ルールを作成する際にメールアドレスのローカル部分だけを考慮する必要があります。
たとえば、[Replace domain names in LDAP email addresses] をオフにして完全一致除外ルールを作成する場合は、一致するユーザーのメールアドレスとして「luka@example.com」を入力します。一方、[Replace domain names in LDAP email addresses] をオンにしている場合は「luka」と入力します。比較する前に @example.com の部分が削除されるため、luka@example.com と一致させることはできません。
GCDS を使用してグループをプロビジョニングする場合、動的グループを静的グループの下に（または静的グループを動的グループの下に）ネストすることはできません。GCDS では、すべてのネストされたグループを同じクエリに含める必要があると同時に、静的グループと動的グループを分けてクエリを行う必要があります。
動的グループを静的グループとして実装する方法を探します（すべての動的グループに定期的にクエリを行ってディレクトリ内の静的グループにデータを入力する、というタスクを自動化する方法で実装できる可能性があります）。動的グループが静的グループとして実装されたら、動的グループから作成された静的グループを使って、GCDS がプロビジョニングを行います。この場合、動的グループのプロビジョニングは行われません。
LDAP クエリの結果は、設定マネージャーの設定と LDAP サーバーによって異なります。LDAP 検索ルールから予期しない結果が返される場合は、次のトラブルシューティングのヒントをお試しください。次のことを確認してください。
- LDAP クエリが設定マネージャーで正しく設定されている - 検索ルールを設定したら、[Test LDAP Query] をクリックして確認します。詳しくは、LDAP 検索ルールを使用してデータを同期するをご覧ください。
- 複数のクエリが競合していない - クエリの結果を変えてしまうような検索ルールや除外ルールを設定していないことを確認します。
- LDAP サーバーの承認済みユーザーに十分な権限がある - LDAP サーバーの認証に使用した管理者が、同じサーバーでコマンドラインを使用できることを確認してください。LDAP サーバーでクエリを実行して、結果を確認します。
GCDS ログに「Group ... could not be created. Message: Not Authorized to access this resource/api」というエラー メッセージが表示されることがあります。
トラブルシューティングを行うには、ユーザーとグループのメールアドレスのドメインを含む Active Directory（AD）属性が、特権管理者アカウントで使用されているドメインと一致していることを確認します。
コンタクトとカレンダー
GCDS で同期後にドメイン ディレクトリに連絡先が重複して表示される通常、この問題は、共有の連絡先を同期していて、かつ作成した検索ルールが適切でない場合に発生します。
GCDS で同期可能なオブジェクトのうち関連があるのは、次の 2 つです。
- ユーザー プロフィール - 電話番号や住所などの追加のデータが登録されている Google ドメインのユーザー。ドメインに存在するユーザーのプロファイルのみを同期できます。
- 共有の連絡先 - ドメイン内のユーザーが連絡する必要のある外部の連絡先。
この問題を解決するには、ドメイン内のユーザーを除外するように共有の連絡先の検索ルールを修正します。すると、次回の同期時に重複する連絡先の削除が試みられます。場合によっては、その最初の同期のときだけ、共有の連絡先の削除制限設定の調整が必要になります。
状況によっては、会議を設定したり調整したりするときに、ユーザーに Google カレンダーの主な勤務先が表示されないことがあります。
この問題が発生した場合は、[勤務地の種類] と [地域の属性] が「desk」に設定されていることを確認します。
ルール
検索ルールが機能しない検索結果に問題がある場合は、次の項目を確認します。
- ルールの適用先。適用先を サブツリー に設定する必要がある場合があります。
- 正しい検索ルールを使用している。
- 使用する属性が存在し表示可能であること。
LDAP クエリ。LDAP サーバーのクエリが、GCDS で設定した管理者ユーザー名と同じものを使用していることを確認します。
詳しくは、LDAP 検索ルールを使用してデータを同期するをご覧ください。
使用しているフォントが画面に対して大きすぎる可能性があります。このダイアログ ボックスは、大きなフォントや特大フォントに対応していません。フォントサイズを変更するか、XML ファイルを直接編集します。
関連トピック
Google Workspace に関して報告されている問題
Google、Google Workspace、および関連するマークとロゴは、Google LLC の商標です。その他すべての企業名および商品名は、関連各社の商標または登録商標です。