Skip to main content

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

認証に Enterprise Managed Users、GitHub は一定のルールに従って、エンタープライズ内の各ユーザーアカウントのユーザー名を決定します。

メモ

この記事は、 Enterprise Managed Usersにのみ適用されます。 GitHub Enterprise CloudなしでEnterprise Managed Usersを使用する場合、ユーザー名はGitHubではなくユーザーによって作成されます。

外部認証を使用するユーザー名について

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

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

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

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

メモ

競合は、同じ Enterprise 内のユーザー間でのみ発生します。 マネージド ユーザー アカウント では、IdP の識別子とメール アドレスを、そのエンタープライズ外の GitHub.com 上の他のユーザー アカウントと共有することができます。

のショートコードについて マネージド ユーザー アカウント

マネージド ユーザー アカウントを使用する各企業は、3 ~ 8 文字の英数字の文字列であるショートコードに関連付けられています。

GitHub.com のショートコード

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

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

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

ID プロバイダーから新しいユーザーをプロビジョニングすると、新しいマネージド ユーザー アカウントには@IDP-USERNAME_SHORT-CODE形式の**** ユーザー名が付けられます (例: "モナcat_octo")。

GHE.com 上のショートコード

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

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

メモ

非表示のショートコードが含まれているため、ユーザー名の文字制限が 39 文字から データ所在地付き GitHub Enterprise Cloudは 30 文字に制限されます。

正規化されたユーザ名について

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

| ID プロバイダー | GitHub ユーザー名 | |-----------------------------------|----------------------| | Microsoft Entra ID (旧称 Azure AD) | IDP-USERNAME は、ゲスト アカウントの @ を含まない UPN (ユーザー プリンシパル名) の #EXT# 文字の前の文字を正規化することによって形成されます。 | | Okta | IDP-USERNAME は、IdP によって提供される、正規化されたユーザー名属性です。 |

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

  • bob@contoso.com
  • bob@fabrikam.com
  • bob#EXT#fabrikamcom@contoso.com
  • bob_example#EXT#fabrikamcom@contoso.com
  • bob_example.com#EXT#fabrikamcom@contoso.com

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

アンダースコアや短いコードを含むユーザー名は 39 文字以下にする必要があります。

ユーザー名の正規化について

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

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

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

  2. IdP から提供された値の中にある大文字と小文字は、正規化されたユーザー名の中で保持されます。

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

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

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

ユーザー名の正規化の例

| プロバイダーの識別子 | GitHub.com上の正規化されたユーザー名 | 結果 | | :- | :- | :- | | The.Octocat | The-Octocat_SHORT-CODE | このユーザ名の作成は成功します。 | | !The.Octocat | -The-Octocat_SHORT-CODE | このユーザ名はダッシュで始まるので作成されません。 | | The!!Octocat | The--Octocat_SHORT-CODE | このユーザ名には連続する2つのダッシュが含まれるので作成されません。 | | The!Octocat | The-Octocat_SHORT-CODE | このユーザ名は作成されません。 正規化されたユーザ名は正当ですが、すでに存在しています。 | | The.Octocat@example.com | The-Octocat_SHORT-CODE | このユーザ名は作成されません。 正規化されたユーザ名は正当ですが、すでに存在しています。 | | internal\\The.Octocat | The-Octocat_SHORT-CODE | このユーザ名は作成されません。 正規化されたユーザ名は正当ですが、すでに存在しています。 | | mona.lisa.the.octocat.from.github.united.states@example.com | mona-lisa-the-octocat-from-github-united-states_SHORT-CODE | このユーザー名は、39 文字の制限を超えているため、作成されません。 |

ユーザー名の問題の解決

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

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

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

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

メモ

GitHub のサポート では、属性マッピングのカスタマイズやカスタム式の構成に関するサポートは提供できません。 ご質問がある場合は、IdP にお問い合わせください。

Entra ID に関するユーザー名の問題の解決

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

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

Okta に関するユーザー名の問題の解決

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

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