When a server already recognizes a username due to existing local users or third-party integrations, Okta Advanced Server Access (ASA) and Okta Privileged Access (OPA) fail to provision the user. Removing the conflicting integration or updating the Unix username format resolves this issue. The provisioning process fails, and the system logs display the following error:

Failed adding user <username> exit code: 9

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Okta Advanced Server Access (ASA)
• Okta Privileged Access (OPA)
• System Security Services Daemon (SSSD)

The server already recognizes a user with the same name. This conflict occurs when the server contains existing local users that match the Unix username attribute of the Okta ASA or OPA user. Additionally, third-party integrations, such as System Security Services Daemon (SSSD), Lightweight Directory Access Protocol (LDAP), or cloud account linkages, can make the server aware of pre-existing usernames and cause the provisioning attempt to fail.

How are user provisioning conflicts resolved in Okta Advanced Server Access and Privileged Access?

Okta ASA and OPA expect to provision and manage local users on the server in accordance with the Unix username attribute. Resolve the username conflict by removing the conflicting integration, stopping the conflicting service, or updating the Unix username format.

• Remove the relevant integration or stop the relevant service causing the conflict. For example, stopping the SSSD service resolves conflicts caused by SSSD.
• Update the Unix username format in Okta ASA or OPA to avoid conflicts with existing local users.

Related References

• ASA User and Group Attributes
• OPA User and Group Attributes
• ASA User Management in Linux
• OPA User Management in Linux