トラブルシューティング

Oktaの属性は、Google Directory APIのGoogleユーザースキーマにマッピングされています。Google管理UIや［Contacts (連絡先)］アプリのUIは、このGoogleユーザースキーマと整合性が取れていないケースがあります。例えば、ある属性値がAPIで正しく自動入力されているにもかかわらず、UIでは表示されないことがあります。また、Google管理UIで入力した属性値が、Googleユーザースキーマに正しく表示されない場合があります。 Googleでは、このようなUIとAPIの不整合を認識しており、解決に向けて取り組んでいると伝えています。一般的には、Directory APIに直接クエリを実行して、Oktaがユーザーのプロファイルを正しくGoogleにプッシュしたかどうかを判断します。特定のユースケースにおけるこの不整合の影響と、その回避方法について以下で詳しく説明します。

Googleユーザースキーマでユーザーデータを検証する

Google API Explorerツールを使用して、Googleユーザースキーマのユーザーデータを検証します。

https://developers.google.com/apis-explorer/#s/admin/directory_v1/directory.users.getにアクセスします。
デフォルトのスコープでOauthを認証します。
userKeyフィールドには、ユーザーのプライマリメールを入力します。

OktaからのGoogle Workspaceでのユーザー作成

Oktaで作成され、Google Workspaceにプッシュされた以下のGoogle Workspaceユーザー基準属性値は、Contacts (連絡先)アプリやGoogle管理UIでは表示されませんが、APIでは表示されます。

Second Email（予備メール）
Street address (番地)
City (市)
State (州)
Zip code (郵便番号)
Country Code（国コード）

Google Workspaceからのユーザーインポート

デフォルトでは、OktaはGoogle管理UIで入力された一部のユーザー属性をインポートしません。これは、これらの属性値がAPI経由でGoogleユーザースキーマで誤って公開されているためです。この問題はGoogleによって解決されるかもしれませんが、提案されている回避策は、GAMのようなツールを使って属性値を再設定し、Oktaがそれをインポートできるようにすることです。この問題はG Suiteからのインポートにのみ影響します。OktaからGoogle Workspaceへの属性のプロビジョニングは正常に機能します。

Google管理UIの属性名	Googleに入力されたサンプルデータ	API経由でGoogleユーザースキーマに表示されるサンプルデータ	GAMを使用して、Googleユーザースキーマのサンプルデータを再構成する	属性は、G Suiteの基準属性またはカスタム属性に表示されます。
Secondary email (セカンダリーメール)	mailto:myemail@test.com	emails: address=myemail@test.com, type=custom, customType=""	emails: type=work address=myemail@test.com	Work email (仕事用メール)
Phone (Work) (電話 (勤務先))	111-111-1111	phones: type=work value=111-111-1111	GAMのアップデートは不要	Primary phone (メインの電話番号)
Phone (Home) (電話 (自宅))	111-111-1111	phones: type=home value=111-111-1111	GAMのアップデートは不要	カスタム属性として追加 Phones Home Value (自宅の電話番号の値)
Phone (Mobile) (電話 (携帯))	111-111-1111	phones: type=mobile value=111-111-1111	GAMのアップデートは不要	Phones WorkMobile Value (勤務先の携帯電話番号の値)
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"	Street address (番地) City (市) State (州) Zip code (郵便番号)
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"	カスタム属性として追加: addressesHomeStreetAdress addressesHomeLocality addressesHomeRegion addressesHomePostalCode
Employee ID (従業員ID)	123	externalIds: type=organization value=123	GAMのアップデートは不要	カスタム属性として追加: ExternalIds Organization Value (組織の外部ID値)
Manager (マネージャー)	admin@oktaskylab.net	relations: type=Manager value=admin@oktaskylab.net	GAMのアップデートは不要	Manager (マネージャー)
Title（役職）	Sales (営業担当)	organizations: title=Sales customType=""	organizations: title=Sales type="work"	Organizations title (組織での役職)
Employee type (従業員タイプ)	Engineer (エンジニア)	organizations: description=Engineer customType=""	organizations: description=Engineer customType="work"	カスタム属性として追加: Organizations Work Description (組織の仕事の説明)
Department (部門)	Engineering (エンジニアリング)	organizations: department=Engineering customType=""	organizations: department=Engineering customType="work"	Organization Department（組織の部門）
Cost Center（コストセンター）	EN101	organizations: costCenter=EN101 customType=""	organizations: costCenter=EN101 customType="work"	Organizations costCenter (組織のコストセンター)

Googleからのユーザーインポート、その後のOktaからのアップデート

Google管理UIで作成されたGoogle Workspaceユーザーの場合、Oktaでプロファイルを更新しても、Google Workspace UIで最初に自動入力され、Oktaが明示的にマッピングしていない属性値は上書きされません。例えば、「Cost Center (コストセンター)」属性がGoogle管理UIで最初に記入された場合、Oktaで「Organizations costCenter (組織のコストセンター)」を更新しても、Google管理UIの更新にはつながりません。一方、「Phone (Work) (電話 (勤務先))」属性がGoogle管理UIで最初に記入されている場合、Oktaで「Primary phone (プライマリ電話)」を更新すると、Google管理UIでも更新されます。

既知の問題/一般的なエラー

複数語属性
［People (ユーザー)］>［Profile Editor (プロファイルエディター)］>［Google Workspace User (Google Workspaceユーザー)］>［Add Attribute (属性の追加)] シーケンスの検索バーでは、スペースを含む複数単語の属性名を検索できません。
プライマリメール属性の分離
Google Workspaceユーザープロファイルでは、［Primary Email (プライマリメール)］属性が別に表示されます。これは、Google Workspaceインスタンスが2015年1月のGAアップデート以前に作成されたものであり、廃止された実装であるためです。ベストプラクティスは、Okta orgで全く新しいGoogle Workspaceインスタンスを設定し、古いものを非アクティブ化することです。これが不可能な場合は、既存のGoogle Workspace インスタンスを引き続き使用しても構いませんが、Okta ユーザー属性を Google Workspaceの［User Primary Email (ユーザープライマリメール)］属性にマッピングしないでください。
連絡先アプリが表示されない
Google Workspaceに対してユーザーをプロビジョニングした後、［Contacts (連絡先)］アプリに更新されたユーザープロファイルが表示されないという問題がありました。アップデートされた値が［Contacts (連絡先)］アプリの［Google Workspace Directory (Google Workspaceディレクトリ)］セクションに表示されるまで、最大で24時間かかるため、これは想定内の動作です。
GoogleのグループはOktaによってどのような影響を受けますか？
Oktaは、ユーザーをGoogle Workspaceからインポートする場合、またはユーザーのGoogle WorkspaceアカウントをOktaアカウントに割り当てる場合、そのユーザーのグループをインポートします。ユーザーのインポートまたは割り当てが完了した後は、Google Workspaceでのグループの更新はOktaに反映されません。
［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アプリケーションで拡張スキーマ検出を使用しているにもかかわらず、プロファイルエディターでOktaに新しい属性が表示されない場合は、［Provisioning (プロビジョニング)］タブで再認証を行い、OktaがGoogle Workspaceからカスタムスキーマをインポートできるようにする必要があります。
これを行うには、［Provisioning (プロビジョニング)］タブを開き、［API Integration (API統合)］を選択して再認証します。
プロファイルアップデート時のエラー
Google Workspaceアプリケーションに拡張スキーマ検出を使用していて、Google Workspaceのカスタムユーザースキーマからいくつかのプロパティをインポートして割り当てた後、そのカスタムユーザースキーマをGoogle Workspaceから削除した場合、以下のエラーが表示されることがあります（以下のスクリーンショットのNew_UserSchemaがGoogle Workspaceから削除されたスキーマです）。
このエラーを解決するには、［Profile Editor (プロファイルエディター)］でOktaのGoogle Workspaceユーザーからカスタムプロパティを手動で削除する必要があります。