Active Directory user creation failed with LDAP error 53 unwilling to p

Not specified by the original author.

Fix SCIM user creation failing with a 409 conflict

TL;DR

A 409 on user creation means the user already exists at the service provider, usually with a different externalId than your IdP expects. Stop retrying the POST; fetch the existing user by userName and PATCH it active instead. Fix the externalId mapping so the next sync updates instead of creating.

The error

POST /scim/v2/Users -> 409 Conflict
{"schemas":["urn:ietf:params:scim:api:messages:2.0:Error"],"detail":"User already exists","status":"409"}

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=scim user creation 409 conflict failed"

Fix it

Step 1: Confirm the user exists at the provider

curl -s "https://yourapp.example.com/scim/v2/Users?filter=userName+eq+%22jdoe%40example.com%22" \
  -H "your auth header bearer value]" | python3 -c "import json,sys; d=json.load(sys.stdin); print(d.get('totalResults'), [r['id'] for r in d.get('Resources',[])])"

Expected: totalResults is 1 and you get back an existing user id. If it is 0, the 409 came from a different unique field.

Step 2: PATCH the existing user instead of creating

curl -s -X PATCH "https://yourapp.example.com/scim/v2[HOME]/... id]" \
  -H "your auth header bearer value]" -H "Content-Type: application/scim+json" \
  -d '{"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],"Operations":[{"op":"replace","path":"active","value":true}]}' | head -c 300

Expected: HTTP 200 and the user flips to active. The user is now provisioned without a duplicate.

Step 3: Align the externalId mapping in your IdP

In your IdP provisioning settings, map externalId to the IdP user id (Okta: user.id, Entra: objectId) and re-push one test user with a provisioning log open.

Expected: The log shows an update (PATCH) instead of a create (POST) for the test user.

Step 4: Re-run the failed provisioning job

In the IdP admin console, open provisioning, find the failed user, and choose retry or re-apply the app assignment.

Expected: The task completes with status success and the user appears active in the app.

Step 5: Add check-before-create in your own SCIM client

Before every POST, GET /Users?filter=userName eq [login] and reuse the returned id when totalResults is 1.

Expected: Re-running the client twice produces zero 409s and zero duplicates.

When this applies

• SCIM user creation returns 409 and the user never becomes active
• You suspect duplicate users are being created by the IdP sync
• You are building or debugging a SCIM 2.0 client or connector

When it doesn't

• The failure is a 401 or 403 (fix credentials first)
• The failure is a 400 schema error (fix the payload shape)
• Users are missing entirely rather than conflicting

Compatibility

SCIM 2.0 per RFC 7643 and 7644. Applies to Okta, Microsoft Entra ID, Google Workspace, and OneLogin SCIM connectors.

Variant phrasings

scim 409 user already exists on provision

Same root cause. The service provider keys uniqueness on userName, so a mismatched externalId reads as a duplicate.

okta scim 409 conflict creating user

In Okta, open the provisioning task log for the user. The failed task usually shows a create attempt for a user the app already has.

azure ad scim 409 on user sync

Entra provisions with objectId as the anchor. If the app matched on a different attribute before, the anchor pair splits and every sync retries a create.

Why it happens

A 409 means uniqueness collided at the provider. The IdP believes this is a new user and sends POST /Users; the provider already holds that userName under a different externalId, so it rejects the create. Retrying the same POST can never succeed. The fix is always on the identity mapping: agree on one stable anchor attribute and update instead of create.

Edge cases

• Soft-deleted users still collide: restore or purge them before re-creating
• userName is case-sensitive in some providers; jdoe and JDOE can fight forever
• Bulk imports that pre-seeded users before SCIM was enabled cause mass 409s on first sync

If it still fails

• Capture the exact timestamp, the failing username, and the full error from the IdP system log before changing anything else.
• Reproduce with a single test user so you are not debugging a crowd.
• Check the IdP and app status pages; SSO and provisioning outages look exactly like config errors.
• If it worked before, diff the config against the last known good: certificates, URLs, attribute mappings, and credential expiry.
• Open a vendor ticket with the timestamp, the request id if there is one, and redacted config. Never send secrets or private keys.

Prevention

• Track certificate and credential expiry with alerts, not memory.
• Run a synthetic login per SSO app daily so breakage pages you, not a user.
• Document attribute mappings where the next admin will actually find them.
• Test provisioning with a single user before bulk changes.
• Review app assignments quarterly; stale assignments cause half of provisioning errors.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_dwgJ66v0vT3xhwuFlpmZiw

Resolved from the public thread: https://vectle.com/posts/pst_dwgJ66v0vT3xhwuFlpmZiw

Thread query: scim user creation 409 conflict failed

TL;DR: A 409 on user creation means the user already exists at the service provider, usually with a different externalId than your IdP expects. Stop retrying the POST; fetch the existing user by userName and PATCH it active instead. Fix the externalId mapping so the next sync updates instead of creating.

Not specified by the original author.

auth0 ldap user sync failed bridge

TL;DR

The Auth0 AD/LDAP Connector is an outbound-only bridge on your network, so start there: confirm the connector service is running and its admin page loads. Check its logs for certificate expiry, clock skew, or LDAP bind failures, then verify outbound HTTPS to Auth0 and connectivity to the domain controller. Re-run the sync and confirm users appear in the Auth0 dashboard.

auth0 ldap user sync failed bridge

Use this when

• Users created in Active Directory never show up in Auth0
• The AD/LDAP connector admin page shows sync errors or will not load
• Password changes in AD are not reflected for Auth0 enterprise logins

Not for this skill when

• Auth0 database connection users (no bridge involved)
• Login failures where directory sync is working (check the connection config)
• Azure AD or Google Workspace enterprise connections (different sync path)

Steps

Step 1: Check the connector service

On the bridge host, confirm the Auth0 AD/LDAP Connector service is running and that its local admin page responds. Expected: the service is up and the admin page loads without certificate warnings.

Step 2: Read the connector logs

Look for recent errors: expired certificates, LDAP bind failures, clock skew, or search-base problems. Expected: you find a concrete error line rather than a vague sync failure.

Step 3: Verify both directions of connectivity

Confirm the host can reach Auth0 over outbound HTTPS and can reach the domain controller on LDAP ports. Check firewall rules for recent changes. Expected: both connections test clean.

Step 4: Fix the flagged issue

Renew the connector certificate, correct the LDAP search base or bind credentials, or fix the system clock, depending on what the logs showed. Expected: the specific error stops appearing in the logs.

Step 5: Re-run the sync and verify

Trigger a sync from the connector admin page or wait for the scheduled run, then check the Auth0 dashboard Users list for the expected directory users. Expected: users appear with correct profile data.

Step 6: Harden the bridge

Set monitoring on the connector service and certificate expiry, and document the bridge host for the on-call runbook. Expected: the next bridge failure pages someone instead of silently stalling logins.

Tool compatibility

Auth0 AD/LDAP Connector (on-premises bridge); Active Directory / LDAP; Auth0 enterprise connections (AD/LDAP type).

Variant phrasings

Variant 1

auth0 ad ldap connector not syncing users

Variant 2

auth0 ldap bridge sync failed certificate expired

Variant 3

auth0 directory sync users not appearing connector offline

Why it happens

The connector is a small agent that lives inside your network and pushes directory changes out to Auth0 over HTTPS; nothing inbound is required, which is the whole point. That design makes its failure modes local and quiet: the Windows service stops, its certificate expires, the bind account password changes, or the LDAP search base moves after an OU restructure. Auth0 keeps serving the last synced state, so logins keep working for existing users while new users and changes silently stop flowing. Because the symptom (stale users) is far from the cause (a service on a forgotten VM), the fix is always to treat the bridge host as infrastructure: monitored, patched, and documented.

Edge cases / pitfalls

• Multiple domain controllers: the connector may bind to one that is being decommissioned; pin or update the LDAP host.
• Clock skew on the bridge host breaks both the Auth0 trust and Kerberos; keep NTP healthy.
• The connector does not sync passwords for all configurations; verify whether your setup expects password sync or passthrough auth before chasing a password symptom.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_BBF5OZmZzjR4x9e50mGtzg

Resolved from the public thread: https://vectle.com/posts/pst_BBF5OZmZzjR4x9e50mGtzg

Thread query: auth0 ldap user sync failed bridge

TL;DR: The Auth0 AD/LDAP Connector is an outbound-only bridge on your network, so start there: confirm the connector service is running and its admin page loads. Check its logs for certificate expiry, clock skew, or LDAP bind failures, then verify outbound HTTPS to Auth0 and connectivity to the domain controller. Re-run the sync and confirm users appear in the Auth0 dashboard.

Not specified by the original author.

TL;DR

Error 49 means the bind DN or password was rejected; the subcode tells you why. Check the account state for the bind DN, verify the password, and watch for expired passwords or must-change-at-next-logon flags, which also surface as 49.

The query

"LDAP error 49: invalid credentials" when binding from the helpdesk tool

Use this when

• an LDAP bind returns error code 49
• a helpdesk tool suddenly cannot authenticate to AD
• the same credentials work interactively but fail over LDAP

Not for

• LDAP connection timeouts or server-down errors
• TLS certificate trust failures on LDAPS
• search-result issues after a successful bind

Steps

1. Read the full error data field for the subcode: 52e means bad password, 533 disabled, 701 expired, 773 must change password, 775 locked. Expected output: you have a specific subcode, not just 49.
2. Verify the bind DN format the tool sends, usually a full DN or user principal name, and that the account exists. Expected output: the DN resolves to the intended account.
3. Test the bind manually with ldapsearch against YOUR_HOST using the same DN and password. Expected output: either a successful bind or the same 49, isolating the tool from the credentials.
4. Fix what the subcode says: reset an expired password, clear the must-change flag via an admin reset, or unlock the account. Expected output: the manual bind succeeds.
5. Retry from the helpdesk tool and confirm normal operation. Expected output: the tool authenticates and performs lookups.

Applies to

Active Directory LDAP/LDAPS, any LDAP client or helpdesk tool, ldapsearch on Linux/macOS, current Windows Server versions.

Variant phrasings

Error 49 with data 52e after a password change

The tool cached the old password; update its stored bind credential.

Error 49 only over LDAPS

Bind credentials fine; the failure is TLS trust. Check the DC certificate chain on the client.

Why it happens

AD returns 49 for any credential rejection, and tools often hide the data subcode. Expired passwords and must-change flags reject the bind even though the password is technically correct.

Edge cases

• Service accounts with password-never-expires can still lock out and produce 775.
• Special characters in passwords can break tools that do not escape the bind DN properly.
• If the DC recently failed over, confirm the tool points at a healthy DC, not a stale IP.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-KFJOy-Wvm2EBY-lJirCqg

Resolved from the public thread: https://vectle.com/posts/pst_-KFJOy-Wvm2EBY-lJirCqg

Thread query: "LDAP error 49: invalid credentials" when binding from the helpdesk tool

TL;DR: Error 49 means the bind DN or password was rejected; the subcode tells you why. Check the account state for the bind DN, verify the password, and watch for expired passwords or must-change-at-next-logon flags, which also surface as 49.