When an attempt is made to link an existing account in GitHub Enterprise Managed User (EMU), the following provisioning error appears in the System Log:
Push new user to external application FAILURE: Bad Request. Errors reported by remote server: Another user already owns the account. Please have your administrator check the authentication log.
This article presents the reason behind this error and how it can be solved.
- GitHub Enterprise Managed User (EMU)
- Provisioning
- User Lifecycle Management
This error occurs when attempting to provision a user that already exists as an Enterprise Managed User (EMU) in GitHub but was created by a different identity provider (IdP), such as Azure or Entra ID. The issue stems from the design of the GitHub System for Cross-domain Identity Management (SCIM) API, which prevents one identity provider from viewing or linking to users provisioned by another.
Okta's provisioning flow begins by searching for an existing user in the target application. Due to the SCIM API limitation, the search does not find the user created by the other provider, making the account effectively hidden from Okta. Believing the user does not exist, Okta then attempts to create a new one. However, during this creation call, the GitHub API enforces global username uniqueness, detects the conflicting account, and blocks the creation, which triggers the error.
According to GitHub Support, the only method to resolve this conflict is to de-provision the user from GitHub and then reprovision the user through Okta. This is required due to the implementation of the GitHub SCIM server.
-
De-provision the user from GitHub. This action will delete the existing managed user account.
-
Assign the user to the GitHub EMU application within Okta. This will trigger the provisioning process to create a new managed user account for that user under Okta's management.
Username conflicts can also arise from GitHub's username normalization process. GitHub may treat certain usernames that appear different as identical after normalization. For example, the process converts usernames to lowercase and removes or replaces non-alphanumeric characters. This means if a user Jane.Doe already exists, an attempt by a provisioning service to create jane-doe for a different user will likely fail because GitHub normalizes both usernames to jane-doe, resulting in a conflict.
For more details on this behavior, refer to the documentation:
