Viewing external identity information for a user
If a user is unable to successfully authenticate using SAML, it may be helpful to view information about the single sign-on identity that's linked to the user's account on GitHub. For more information, see Viewing and managing a user's SAML access to your enterprise.
Username conflicts
If your enterprise uses Enterprise Managed Users, GitHub Enterprise Cloud normalizes the SCIM userName attribute value that is sent by an identity provider (IdP) in a SCIM API call to create each person's username on GitHub. If multiple accounts are normalized into the same GitHub username, a username conflict occurs, and only the first user account is created. For more information, see Username considerations for external authentication.
Errors when switching authentication configurations
If you're experiencing problems while switching between different authentication configurations, such as changing your SAML SSO configuration from an organization to an enterprise account or migrating from SAML to OIDC for Enterprise Managed Users, ensure you're following our best practices for the change.
- Switching your SAML configuration from an organization to an enterprise account
- Migrating from SAML to OIDC
- Migrating your enterprise to a new identity provider or tenant
Accessing your enterprise when SSO is not available
When a configuration error or an issue with your identity provider IdP prevents you from using SSO, you can use a recovery code to access your enterprise. For more information, see Accessing your enterprise account if your identity provider is unavailable.
SCIM provisioning errors
To avoid exceeding the rate limit on GitHub Enterprise Cloud, do not assign more than 1,000 users per hour to the SCIM integration on your IdP. If you use groups to assign users to the IdP application, do not add more than 1,000 users to each group per hour. If you exceed these thresholds, attempts to provision users may fail with a "rate limit" error. You can review your IdP logs to confirm if attempted SCIM provisioning or push operations failed due to a rate limit error. The response to a failed provisioning attempt will depend on the IdP.
Microsoft Entra ID (previously known as Azure AD) will retry SCIM provisioning attempts automatically during the next Entra ID sync cycle. The default SCIM provisioning interval for Entra ID is 40 minutes. For more information about this retry behavior, see the Microsoft documentation or contact Microsoft support if you need additional assistance.
Okta will retry failed SCIM provisioning attempts with manual Okta admin intervention. For more information about how an Okta admin can retry a failed task for a specific application, see the Okta documentation or contact Okta support.
In an enterprise with managed users where SCIM is generally functioning properly, individual user SCIM provisioning attempts sometimes fail. Users will be unable to sign in until their account is provisioned to GitHub. These individual SCIM user provisioning failures result in an HTTP 400 status code and are typically caused by issues with username normalization or username conflicts, where another user with the same normalized username already exists in the enterprise. See Username considerations for external authentication.
SAML authentication errors
If users are experiencing errors when attempting to authenticate with SAML, see Troubleshooting SAML authentication.