<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
Okta to Active Directory Provisioning Fails with Error "The Object Already Exists"
Directories
Overview

Okta returns a provisioning error when an attempt to create a user in Active Directory (AD) results in a conflict with an existing object attribute, such as the sAMAccountName or distinguishedName:

 

The object already exists

 

Resolve this error by enforcing uniqueness for the mapped attributes in Okta.

 

During AD provisioning, Okta first queries AD in an attempt to match the Okta user to an existing AD user using the username format configured in the integration.

AD Username Format

 

For example, if the Okta user being provisioned is example.user@domain.com, and the AD username format is Okta username, the resulting query appears as:

(&(sAMAccountType=805306368)(userPrincipalName=example.user@domain.com))

 

The following AD Agent log excerpt shows the query process:

2026/03/05 17:14:01.553-05:00 Info -- <serverHostName>(5) -- Query: (&(sAMAccountType=805306368) (userPrincipalName=<provisionedUserName>))
   Search root: DC=<domain>, DC=<domainExtension>
   Count of search roots: 1
...
2026/03/05 17:14:01.569-05:00 Info -- <serverHostName>(5) -- Query: (&(sAMAccountType=805306368) (userPrincipalName=<provisionedUserName>))
...
2026/03/05 17:14:01.569-05:00 Info -- <serverHostName>(5) -- Sending query to search root: LDAP://<serverHostName>.<domainName>/DC=<domain>,DC=<domainExtension>
...
2026/03/05 17:14:01.569-05:00 Info -- <serverHostName>(5) -- Query result 36431f79-4d18-4717-8961-833e5297e0dd fetched 0 objects

 

If the query returns a match, Okta matches the user to the existing AD user. If the query does not return a match, Okta attempts to create the user.

 

This error occurs when the new user creation contains an attribute value that violates AD uniqueness requirements, which most often occurs with sAMAccountName or distinguishedName.

 

The error appears in the System Log as the following event:

Syslog event 

 

The following Okta AD Agent log excerpt displays the resulting error returned by the domain controller:

2026/03/07 09:35:43.133-05:00 Error -- <serverHostName>(11) -- DirectoryServicesCOMException: The object already exists.
ErrorCode=80071392; ExtendedError=00000524, ExtendedErrorMessage=00000524: UpdErr: DSID-031A11FA, problem 6005 (ENTRY_EXISTS), data 0
2026/03/07 09:35:43.133-05:00 Error -- <serverHostName>(11) -- Error processing WRITE_OBJECT action rpc: :app.active_directory.agent.reply.<oktaInternalPointer>//<eventNumber>//<oktaRequestId>:<agentRequestId>:
2026/03/07 09:35:43.133-05:00 Info -- <serverHostName>   at System.DirectoryServices.DirectoryEntry.CommitChanges()
   at Okta.DirectoryServices.ActiveDirectoryAdapter.CommitChanges(IDirectoryEntry entry, IEnumerable`1 attributeChanges)
   at Okta.DirectoryServices.ActiveDirectoryAdapter.Create0bject(String targetDN, String cn, String schemaClass, List`1 properties)
   at Okta.Action.Handler.WriteActionHandler.Handle(AgentAction action, ActionContext context)
   at Okta.Action.Dispatch.MultiThreadedDispatcher.HandlerCallback(Object param)
System.DirectoryServices.DirectoryServicesCOMException received with message The object already exists.
 Source=System. DirectoryServices InnerException=.

 

Applies To
  • Okta Identity Engine (OIE)
  • Okta Classic Engine
  • Directories
  • Active Directory
  • Provisioning
Cause

If the Okta AD Agent LDAP query does not return a match, Okta attempts to create a user based on the integration attribute mappings. The error most often occurs due to one of the following conflicts:

  • Non-unique sAMAccountName: The default mapping String.substringBefore(user.login, "@") generates identical names for different users (for example, user@domain.com and user@domain.net both result in a sAMAccountName value of user). AD requires a unique sAMAccountName for every user object in the directory.
  • Non-unique distinguishedName: If two users have the same cn (Common Name) attribute mapping and Okta provisions them to the same Organizational Unit (OU), the resulting distinguishedName is identical. AD does not allow identical distinguishedName values. The default mapping for cn is user.firstName + " " + user.lastName. When provisioning users with the same first and last name to the same OU, Okta successfully provisions only the first user. Subsequent provisioning attempts fail with this error because the distinguishedName is not unique.
Solution

How is the object already exists error resolved in Active Directory provisioning?

To resolve this conflict, ensure that the attributes mapped to AD are unique. 

NOTE: Unassign users from the provisioning group to clear the task error and reassign them once the uniqueness issue is resolved.

 

Verify that the correct AD username format is selected. This setting correlates to the AD user UPN value.

  1. Go to Directory > Directory Integrations > [Active Directory] > Provisioning > To App.
  2. Verify the AD username format under the General section to ensure the User Principal Name (UPN) mapping is correct.

 

If the sAMAccountName duplicates an existing attribute, implement one of the following methods:

  • Create a custom Okta user attribute for sAMAccountName and enable the "Value must be unique for each user" restriction to enforce uniqueness within Okta.
  • Deploy an Okta Workflow to detect and alter duplicate sAMAccountName values during user creation.

 

If the distinguishedName duplicates an existing attribute, implement one of the following methods:

  • Adjust the cn attribute mapping to use a more unique value, such as user.displayName.
  • Use an Okta Workflow to programmatically modify the cn for users with identical names.
  • Assign the user to a different target OU to ensure the distinguishedName remains unique.

 

Okta Support cannot provide a single solution or best practice, as each organization has unique requirements.

 

Consult Okta Professional Services for assistance in creating custom Workflows to address this issue.

Loading
Okta to Active Directory Provisioning Fails with Error "The Object Already Exists"