外部認証のユーザー名に関する考慮事項

Enterprise Managed Users のエンタープライズを使用する場合、エンタープライズのメンバーは、SAML ID プロバイダー (IdP) を介して にアクセスするように認証します。 詳細については、「Enterprise Managed Users について」および「ID とアクセス管理について」を参照してください。

は、ユーザー アカウントが SCIM を介してプロビジョニングされるときに、各ユーザーのユーザー名を自動的に作成します。

• ユーザー名を作成するために、 は IdP によって提供される識別子を正規化します。
• .com では、 によって、各ユーザー名の末尾にアンダースコアとエンタープライズのショートコードも追加されます。

複数の識別子が同じユーザー名に正規化されると、ユーザー名の競合が発生し、最初のユーザー アカウントのみが作成されます。 ユーザー名の問題を解決するには、正規化されたユーザー名が一意であり、39 文字の上限に収まるように IdP で変更を加えます。

マネージド ユーザー アカウント を使用する各エンタープライズには、ショートコード (3 - 8 文字の英数字文字列) が関連付けられています。

.com で マネージド ユーザーを含む Enterprise を作成する場合は、すべてのエンタープライズ メンバーのユーザー名のサフィックスとして使用されるショートコードを選択します。

• ショートコードはエンタープライズ固有にする必要があります。特殊文字を含めることはできません。
• マネージド ユーザーを含む Enterprise が作成された後はショートコードを変更することはできないため、慎重に選択します。

SAML SSO を構成するセットアップ ユーザーのユーザー名は、SHORT-CODE_admin の形式になります。 例えば、お客様の企業のショートコードが「octo」の場合、セットアップユーザーは「octo_admin」となります。

アイデンティティプロバイダーから新規ユーザーをプロビジョニングすると、新しい マネージド ユーザー アカウント には、 のユーザー名が (例:「mona-cat_octo」) のような**@IDP-USERNAME_SHORT-CODE**形式で設定されます。

でのショートコード

データ所在地付き Enterprise Cloud を使用する場合は、GHE.com で マネージド ユーザーを含む Enterprise を作成すると、エンタープライズのショートコードがランダムに生成されます。

• データ所在地が付きマネージド ユーザー アカウントの場合、ショートコードは非表示になりますが、プロビジョニングされたユーザーのユーザー名にサフィックスとして追加されます。
• ショートコードを目にする可能性が高い唯一の場所は、セットアップ管理者のユーザー名です。2abvd19d_admin のようになります。

ユーザー名は、IdP から送信された SCIM userName 属性値を正規化することによって形成されます。

これらの規則により、IdP が複数のユーザーに同じ IDP-USERNAME を提供する可能性があります。 たとえば、Entra ID の場合、次の UPN は同じユーザー名になります。

• [email protected]
• [email protected]
• bob#EXT#[email protected]
• bob_example#EXT#[email protected]
• bob_example.com#EXT#[email protected]

これによりユーザー名が競合し、最初のユーザーのみがプロビジョニングされます。 詳しくは、「ユーザー名の問題の解決」をご覧ください。

ユーザー名 (アンダースコアと短いコードを含む) は 39 文字を超えてはなりません。

のユーザー アカウントのユーザー名には、英数字とダッシュ (-) のみを含めることができます。

SAML 認証を構成する場合、 は IdP から送信された SCIM userName 属性値を使って、 上の対応するユーザー アカウントのユーザー名を決定します。 この値にサポートされていない文字が含まれている場合、 は次の規則に従ってユーザー名を正規化します。

1. は、アカウントのユーザー名に含まれている非英数字をダッシュに変換します。 たとえば、mona.the.octocat というユーザー名は mona-the-octocat に正規化されます。 変換されたユーザ名の先頭及び末尾はダッシュであってはならないことに注意してください。 2つの連続するダッシュを含めることもできません。

2. メール アドレスから作成されたユーザー名は、@ 文字の前の正規化された文字から作成されます。

3. ドメイン アカウントから作成されるユーザー名は、\\ 区切りの後の正規化された文字から作成されます。

4. 複数のアカウントが変換後に同じユーザー名になる場合、最初のユーザー アカウントだけが作成されます。 同じユーザ名のそれ以降のユーザは、サインインできません。 詳しくは、「ユーザー名の問題の解決」をご覧ください。

新しいユーザーをプロビジョニングするときに、ユーザー名が Enterprise 内の既存のユーザーと競合する場合、プロビジョニングの試行は 409 エラーで失敗します。 ユーザー名が 39 文字より長い場合 (アンダースコアとショート コードを含めて)、プロビジョニングの試行は 400 エラーで失敗します。 発生する可能性があるユーザー プロビジョニング状態コードの詳細な一覧については、「SCIM の REST API エンドポイント」を参照してください。

この問題を解決するには、正規化されたすべてのユーザー名が文字数制限内に収まり、一意になるように、IdP で次のいずれかの変更を加える必要があります。

• 問題を引き起こしている個々のユーザーの userName 属性値を変更します
• 全ユーザーの userName 属性のマッピングを変更します
• 全ユーザーのカスタムの userName 属性を構成します

属性のマッピングを変更すると、既存の マネージド ユーザー アカウント のユーザー名が更新されますが、アクティビティ履歴を含め、アカウントに関して他は何も変更されません。

Entra ID でユーザー名の問題を解決するには、競合しているユーザーのユーザー プリンシパル名の値を変更するか、userName 属性の属性マッピングを変更します。 属性マッピングを変更する場合は、既存の属性を選択するか、式を使用して、プロビジョニングされたすべてのユーザーが一意の正規化されたエイリアスを持っていることを確認できます。

1. Entra ID で Enterprise Managed User アプリケーションを開きます。
2. 左側のサイドバーで、 [プロビジョニング] をクリックします。
3. [プロビジョニングの編集] をクリックします。
4. [マッピング] を展開し、[Entra ID ユーザーのプロビジョニング] をクリックします。
5. userName 属性マッピングをクリックします。
6. 属性マッピングを変更します。
   • Entra ID の既存の属性を の userName 属性にマッピングするには、目的の属性フィールドをクリックします。 次に、プロビジョニング サイクルが約 40 分以内に発生するまで保存して待機します。
   • 既存の属性の代わりに式を使用するには、Mapping 型を「式」に変更し、この値をすべてのユーザーに対して一意にするカスタム式を追加します。 たとえば、[FIRST NAME]-[LAST NAME]-[EMPLOYEE ID] を使用できます。 詳細については、Microsoft Learn の「Microsoft Entra ID で属性マッピングの式を記述するためのリファレンス」を参照してください

Okta でユーザー名の問題を解決するには、 Enterprise Managed User アプリケーションの属性マッピング設定を更新します。

1. Okta で Enterprise Managed User アプリケーションを開きます。
2. [サインオン] をクリックします。
3. [設定] セクションで [編集] をクリックします。
4. "アプリケーション ユーザー名の形式" を更新します。