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

Enterprise Managed Users をお使いの場合、GitHub は特定の規則に従って、Enterprise 内の各ユーザー アカウントのユーザー名を決定します。

この記事で

これらのステップを実行してください：

メモ

この記事は、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」となります。

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

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

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

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

メモ

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

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

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

ID プロバイダーGitHub のユーザー名
Microsoft Entra ID (旧称 Azure AD)IDP-USERNAME は、ゲスト アカウントの @ を含まない UPN (ユーザー プリンシパル名) の #EXT# 文字の前の文字を正規化することによって形成されます。
OktaIDP-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.OctocatThe-Octocat_SHORT-CODEこのユーザ名の作成は成功します。
!The.Octocat-The-Octocat_SHORT-CODEこのユーザ名はダッシュで始まるので作成されません。
The!!OctocatThe--Octocat_SHORT-CODEこのユーザ名には連続する2つのダッシュが含まれるので作成されません。
The!OctocatThe-Octocat_SHORT-CODEこのユーザ名は作成されません。 正規化されたユーザ名は正当ですが、すでに存在しています。
The.Octocat@example.comThe-Octocat_SHORT-CODEこのユーザ名は作成されません。 正規化されたユーザ名は正当ですが、すでに存在しています。
internal\\The.OctocatThe-Octocat_SHORT-CODEこのユーザ名は作成されません。 正規化されたユーザ名は正当ですが、すでに存在しています。
mona.lisa.the.octocat.from.github.united.states@example.commona-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 の既存の属性を GitHub の userName 属性にマッピングするには、目的の属性フィールドをクリックします。 次に、プロビジョニング サイクルが約 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. "アプリケーション ユーザー名の形式" を更新します。