ユーザーの外部 ID 情報の表示
ユーザーが SAML を使用して正常に認証できない場合は、GitHub でユーザーのアカウントにリンクされているシングル サインオン ID に関する情報を表示すると便利な場合があります。 詳しくは、「Enterprise へのユーザの SAML アクセスの表示および管理」をご覧ください。
ユーザー名の競合
Enterprise が Enterprise Managed Users を使用している場合、GitHub 上に各個人のユーザー名を作成するために SCIM API 呼び出しで ID プロバイダー (IdP) から送信された SCIM userName 属性値は、GitHub Enterprise Cloud によって正規化されます。 複数のアカウントが同じ GitHub のユーザー名に正規化される場合、最初のユーザー アカウントのみが作成されます。 詳しくは、「外部認証のユーザー名に関する考慮事項」をご覧ください。
認証構成を切り替えるときのエラー
SAML SSO 構成を組織からエンタープライズ アカウントに変更するときや、Enterprise Managed Users の SAML から OIDC に移行するときなど、異なる認証構成間で切り替えるときに問題が発生する場合は、変更に関するベスト プラクティスに従っていることを確認します。
SSO を使用できない場合の Enterprise へのアクセス
構成エラーまたは ID プロバイダー (IdP) の問題によって SSO を使用できない場合は、回復コードを使用して Enterprise にアクセスできます。 詳しくは、「ID プロバイダーが使用できない場合の Enterprise アカウントへのアクセス」をご覧ください。
SCIM プロビジョニング エラー
GitHub Enterprise Cloud のレート制限を超えないようにするには、IdP の SCIM 統合に 1 時間あたり 1,000 人を超えるユーザーを割り当てないでください。 グループを使って IdP アプリケーションにユーザーを割り当てる場合、1 時間あたり 1,000 人を超えるユーザーを各グループに追加しないでください。 これらのしきい値を超えると、ユーザーをプロビジョニングしようとすると、"レート制限" エラーが発生して失敗する可能性があります。 試した SCIM プロビジョニングまたはプッシュ操作がレート制限エラーに起因して失敗したかは IdP ログで確認できます。 プロビジョニング失敗に対する反応は IdP によって異なります。
Microsoft Entra ID (旧称 Azure AD) は、次の Entra ID 同期サイクル中に自動的に SCIM プロビジョニングを再試行します。 Entra ID の既定の SCIM プロビジョニング間隔は 40 分です。 この再試行動作の詳細については、Microsoft ドキュメントを参照してください。さらにサポートが必要な場合は、Microsoft サポートにお問い合わせください。
Okta は、SCIM プロビジョニングに失敗した場合、Okta 管理者の手動介入により再試行します。 Okta 管理者が特定のアプリケーションに対して失敗したタスクを再試行する方法の詳細については、Okta ドキュメントをご覧いただくか、さらなるサポートが必要であれば Okta サポートまでお問い合わせください。
SCIM が全般的に正常に機能している マネージド ユーザーを含む Enterprise では、個々のユーザーの SCIM プロビジョニングの試行が失敗することがあります。 ユーザーは、アカウントが GitHub にプロビジョニングされるまでサインインできません。 これらの個々の SCIM ユーザー プロビジョニング エラーにより、HTTP 400 状態コードが発生します。これらのエラーは、通常、ユーザー名の正規化またはユーザー名の競合に関する問題が原因で発生します。これは、同じ正規化されたユーザー名を持つ別のユーザーが既に Enterprise に存在するということです。 「外部認証のユーザー名に関する考慮事項」をご覧ください。
SAML 認証エラー
ユーザーが SAML で認証を行おうとするとエラーが発生する場合は、「SAML認証」をご覧ください。