トラブルシューティング
SSOを無効にする緊急時計画
OktaとGoogle Workspace間のSSOを直ちに無効にするには、次の手順を完了します。
- バックドアURL（http://www.google.com/a/mydomain.com）を使用してGoogle Workspaceにサインインします。
- を選択します。
- ［Enable Single Sign-On（シングルサインオンを有効にする）］チェックボックスをクリアします。
- 3つのURLフィールドをクリアします。
- ［Save Changes（変更を保存）］をクリックします。
SSOが無効化された後に、エンドユーザーがGoogle Workspaceにアクセスしようとすると、すべてのエンドユーザーに対してユーザー名/パスワードのサインインページが表示されます。この表示が出るまでに30秒程度のタイムラグが生じる場合があります。
SSOエラー
Google Context Aware Access（CAA）が有効になっているGoogle環境を使用している場合、Oktaでタイルをクリックすると問題が生じる場合があります。アクセス拒否エラーメッセージが表示された場合は、ページを更新してください。
Google APIとUI属性の不整合
Oktaの属性は、Google Directory APIのGoogleユーザースキーマにマッピングされています。Google管理者ユーザーインターフェイスや連絡先アプリのユーザーインターフェイスは、このGoogleユーザースキーマと整合性が取れていない場合があります。たとえば、APIである属性値が正しく自動入力されているにもかかわらず、ユーザーインターフェイスでは属性値が表示されないことがあります。また、Google管理者ユーザーインターフェイス（UI）で入力した属性値が、Googleユーザースキーマに正しく表示されない場合があります。一般的には、Directory APIに直接クエリを実行して、Oktaがユーザーのプロファイルを正しくGoogleにプッシュしたかどうかを判断します。次のユースケースでは、これらの不整合の影響と回避方法を示しています。
OktaからのGoogle Workspaceでのユーザー作成
Googleからのユーザーインポート、その後のOktaからの更新
Googleユーザースキーマでユーザーデータを検証する
Google APIs Explorerを使用して、Googleユーザースキーマのユーザーデータを検証します。
- users.getのドキュメントを参照してください。
- APIのアイコンをクリックしてAPIs Explorerを開きます。
- デフォルトのスコープでOAuthを認証します。
- ［userKey］フィールドに、目的のユーザーのプライマリメールを入力します。
OktaからのGoogle Workspaceでのユーザー作成
次のGoogle Workspaceユーザーの基本属性値はOktaで作成され、Google Workspaceにプッシュされます。これらの属性は連絡先アプリとGoogle管理者UIには表示されませんが、APIには表示されます。
- Second Email（予備のメール）
- Street address（番地）
- City（市）
- State（州）
- Zip code（郵便番号）
- Country Code（国番号）
Google Workspaceからのユーザーインポート
デフォルトでは、OktaはGoogle管理者UIで入力された一部のユーザー属性をインポートしません。これは、APIでこれらの属性値がGoogleユーザースキーマで誤って公開されているためです。提案されている回避策は、GAMのようなツールを使って属性値を再設定し、Oktaがそれをインポートできるようにすることです。この問題は、Google Workspaceからのインポートにのみ影響します。OktaからGoogle Workspaceへの属性のプロビジョニングは正常に機能します。
|
Google管理者UIの属性名 |
Googleに入力されたサンプルデータ |
APIからGoogleユーザースキーマに表示されるサンプルデータ |
GAMを使用して、Googleユーザースキーマのサンプルデータを再構成する |
Google Workspaceの基本属性またはカスタム属性に表示される属性 |
|---|---|---|---|---|
| Secondary Email（セカンダリメールアドレス） | mailto:myemail@test.com | emails: address=myemail@test.com, type=custom, customType="" | emails: type=work address=myemail@test.com |
|
| Phone (Work)（電話（勤務先）） | 111-111-1111 | phones: type=work value=111-111-1111 | GAMの更新は不要 |
|
| Phone (Home)（電話（自宅）） | 111-111-1111 | phones: type=home value=111-111-1111 | GAMの更新は不要 | カスタム属性として追加：
|
| Phone (Mobile)（電話（携帯）） | 111-111-1111 | phones: type=mobile value=111-111-1111 | GAMの更新は不要 |
|
| Address (Work)（住所（勤務先）） | 301 Brannan St San Francisco, CA 94105 | addresses: type=work formatted="301 Brannan St San Francisco, CA 94105" | addresses: type=work streetAddress="301 Brannan St" locality="San Francisco" Region="CA" PostalCode="94105" |
|
| Address (Home)（住所（自宅）） | 301 Brannan St San Francisco, CA 94105 | addresses: type=home formatted="301 Brannan St San Francisco, CA 94105" | addresses: type=home streetAddress="301 Brannan St" locality="San Francisco" Region="CA" PostalCode="94105" | カスタム属性として追加：
|
| Employee ID（社員ID） | 123 | externalIds: type=organization value=123 | GAMの更新は不要 | カスタム属性として追加：
|
| Manager（マネージャー） | admin@oktaskylab.net | relations: type=Manager value=admin@oktaskylab.net | GAMの更新は不要 |
|
| Title（タイトル） | Sales（営業担当） | organizations: title=Sales customType="" | organizations: title=Sales type="work" |
|
| Employee type（従業員タイプ） | Engineer（エンジニア） | organizations: description=Engineer customType="" | organizations: description=Engineer customType="work" | カスタム属性として追加：
|
| Department（部門） | Engineering（エンジニアリング） | organizations: department=Engineering customType="" | organizations: department=Engineering customType="work" |
|
| Cost Center（コストセンター） | EN101 | organizations: costCenter=EN101 customType="" | organizations: costCenter=EN101 customType="work" |
|
Googleからのユーザーインポート、その後のOktaからの更新
Google Workspaceユーザーが最初にGoogle管理者インターフェイスで作成されたと仮定します。Oktaでプロファイルを更新しても、Google Workspace UIで最初に自動入力された属性値は上書きされません（Oktaはこれに明示的にマッピングしません）。たとえば、 ［Cost Center（コストセンター）］属性がGoogle管理者ユーザーインターフェイスで最初に入力された場合、Oktaで［Organizations costCenter（組織のコストセンター）］を更新しても、Google管理者UIの更新にはつながりません。一方、［Phone (Work)（電話（勤務先））］属性が最初にGoogle管理者UIに入力されたと仮定します。この場合、Oktaでユーザーの［Primary phone（優先電話番号）］を更新すると、Google管理者UIでも更新が行われます。
既知の問題と一般的なエラー
-
複数語属性
シーケンスの検索バーでは、スペースが含まれる複数単語の属性名を検索できません。
-
プライマリメール属性の分離
Google Workspaceユーザープロファイルでは、［Primary Email（プライマリメールアドレス）］属性が別に表示されます。これは、Google Workspaceインスタンスが2015年1月のGA更新以前に作成されたものであり、廃止された実装であるためです。Okta orgで新しいGoogle Workspaceインスタンスをセットアップし、古いインスタンスを非アクティブ化します。これが不可能な場合は、既存のインスタンスを引き続き使用しても構いませんが、Oktaユーザー属性をGoogle Workspaceユーザーのプライマリメールアドレス属性にマッピングしないでください。
-
連絡先アプリが表示されない
Google Workspaceに対してユーザーをプロビジョニングした後も、［Contacts（連絡先）］アプリには更新されたユーザープロファイルが表示されません。これは想定どおりの動作です。更新された値が連絡先アプリのGoogle Workspaceディレクトリセクションに表示されるまで、最大で24時間かかる場合があります。
-
GoogleのグループはOktaによってどのような影響を受けますか？
Oktaは、ユーザーをGoogle Workspaceからインポートする場合、またはユーザーのGoogle WorkspaceアカウントをOktaアカウントに割り当てる場合、そのユーザーのグループをインポートします。ユーザーのインポートまたは割り当てが完了した後は、Google Workspaceでのグループの更新はOktaに反映されません。インポートを実行すると、Google Workspaceグループへのその後の変更を取得できます。
［Push Okta user profiles to Google Workspace（OktaのユーザープロファイルをGoogle Workspaceにプッシュ）］を選択し、Okta内でグループに加えられた変更をGoogle Workspaceにプッシュします。
-
インポートエラー
Googleで新しいorgユニットが追加された場合、インポートを実行する前にアプリのデータを更新する必要があります。更新しない場合、次のエラーが表示されることがあります。
Field error in object GoogleAppBaseProfile on field orgUnitPath: rejected value（orgUnitPathフィールドのGoogleAppBaseProfileオブジェクトのフィールドエラー：値が拒否されました）
-
カスタムスキーマ属性が表示されない
Google Workspaceで拡張スキーマ検出を使用しているにもかかわらず、Profile EditorでOktaに新しい属性が表示されない場合は、プロビジョニングタブで再認証を行い、OktaがGoogle Workspaceからカスタムスキーマをインポートできるようにする必要があります。
これを行うには、［Provisioning（プロビジョニング）］タブを開き、［API Integration（API統合）］を選択して再認証します。
-
プロファイル更新時のエラー
Google Workspaceの拡張スキーマ検出を使用している場合を考えてみましょう。Google Workspaceのカスタムユーザースキーマから一部のプロパティをインポートして割り当てたと仮定します（例：New_UserSchema）。Google Workspaceからそのスキーマを削除すると、次のエラーが発生する場合があります。
このエラーを解決するには、Profile EditorでGoogle Workspaceユーザーからカスタムプロパティを手動で削除します。「Profile EditorでOkta属性をアプリ属性にマッピングする」を参照してください。
