google workspace scim endpoint unreachable during provisioning

Not specified by the original author.

Fix Google Workspace auto-provisioning failing on an unreachable SCIM endpoint

TL;DR

Google's provisioning service cannot reach the app's SCIM URL - a DNS, firewall, or bad-URL problem, not a Google problem. Make the endpoint publicly reachable over HTTPS with a valid certificate, confirm no extra auth sits in front of it, and re-test the connection from the Google Admin console. Most failures are a URL typo or a non-public endpoint.

The error

Auto-provisioning error: Could not reach the SCIM endpoint
Google Admin / Apps / Web and mobile apps / [app] / Auto-provisioning / logs show "Connection failed"

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=google%20workspace%20scim%20endpoint%20unreachable%20during%20provisioning"

Fix it

Step 1: Verify the exact SCIM URL in the Admin console

Open Google Admin / Apps / Web and mobile apps / [app] / Auto provisioning and copy the SCIM base URL character by character.

Expected: a clean https URL like YOUR_HOST/scim/v2 with no typos. Typos here are the most common cause.

Step 2: Prove the endpoint is reachable from the public internet

curl -s -o /dev/null -w "%{http_code}" YOUR_HOST/scim/v2/ServiceProviderConfig

Expected: 200 (or 401 if it requires auth - that still proves reachability). A DNS failure, timeout, or connection refused means the host is not publicly routable, and that is the whole problem.

Step 3: Check TLS and anything in front of the endpoint

Confirm a valid publicly trusted certificate, and that no WAF challenge, IP allowlist, or login page sits in front of the SCIM path.

Expected: a plain HTTPS response with a trusted cert. Google's provisioner cannot pass a CAPTCHA or an IP allowlist.

Step 4: Re-test the connection in the Admin console

In Auto provisioning settings, re-enter the bearer credential if needed and run the connection test.

Expected: success. If it still fails here after steps 1-3 pass, the URL in the console does not match the URL you tested.

Step 5: Trigger a manual sync for one user

Assign the app to a single test user and check the auto-provisioning audit log for that user.

Expected: the user provisions successfully and the log shows no connection errors.

When this applies

• Google auto-provisioning reports the endpoint unreachable or connection failed
• The connection test in the Admin console fails
• Provisioning never succeeded, not even once

When it doesn't

• The connection test passes but users fail to provision (check mappings and credentials)
• SAML login itself fails (separate from provisioning)
• Failures started suddenly on a working setup (check for expired certs or firewall changes)

Compatibility

Google Workspace auto-provisioning for SAML apps, SCIM 2.0 endpoints.

Variant phrasings

google workspace provisioning connection failed

Same root cause family. Work through reachability before touching credentials or mappings.

scim base url unreachable google admin

Double-check the path: some apps want /scim/v2 and others /api/scim. The vendor docs name the exact path.

Why it happens

Google's provisioning service runs from Google infrastructure, not from the admin's browser. Anything that is not publicly routable - internal hostnames, VPN-only hosts, IP-allowlisted endpoints, self-signed certificates - fails from Google's side even though it works from the admin's laptop. Public-internet reachability is the entire requirement.

Edge cases

• Trailing slash differences (/scim/v2 vs /scim/v2/) break some providers; match the vendor docs exactly
• IPv6-only hosts fail if the app does not listen on IPv6
• Endpoints that return an HTML login page instead of SCIM JSON fail schema checks later; fix the path

If it still fails

• Capture the exact timestamp, the username, and the full error from the system log before changing anything else.
• Reproduce with a single test user so you are not debugging a crowd.
• If it worked before, diff the config against the last known good, then open a vendor ticket with the timestamp and request id. Never send secrets or private keys.

Prevention

• Track credential and certificate expiry with alerts, not memory.
• Run a synthetic check per app daily so breakage pages you, not a user.
• Document mappings, URLs, and runbook steps where the next admin will find them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6cZMwA-CbOErFN4tbGB0tg

Resolved from the public thread: https://vectle.com/posts/pst_6cZMwA-CbOErFN4tbGB0tg

Thread query: google workspace scim endpoint unreachable during provisioning

TL;DR: Google's provisioning service cannot reach the app's SCIM URL - a DNS, firewall, or bad-URL problem, not a Google problem. Make the endpoint publicly reachable over HTTPS with a valid certificate, confirm no extra auth sits in front of it, and re-test the connection from the Google Admin console. Most failures are a URL typo or a non-public endpoint.

Not specified by the original author.

Fix Google Workspace SCIM provisioning failing for suspended users

TL;DR

Google Workspace skips SCIM provisioning for suspended users by design, and the failure looks like an error. Either unsuspend the user if they should have access, or exclude suspended users from the provisioning scope. Do not treat the skip as a connector bug.

The error

Google Workspace SCIM provisioning: Failed
Error: Cannot provision suspended user to target application

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=google workspace scim provisioning failed suspended user"

Fix it

Step 1: Confirm the user is suspended in Google Admin

Google Admin -> Directory -> Users -> [user], check the status.

Expected: The user shows Suspended.

Step 2: Decide: should this user have app access

Check with the manager or the offboarding ticket whether access should exist.

Expected: You have a clear yes or no for each failing user.

Step 3: If yes, restore the user

Unsuspend the user in Google Admin, then retry provisioning.

Expected: Provisioning succeeds on the next sync.

Step 4: If no, exclude suspended users from scope

Adjust the provisioning scope or app assignment to exclude suspended users.

Expected: The failures stop because suspended users are no longer in scope.

Step 5: Verify the failure list is clean

Re-check the provisioning error report after the next sync.

Expected: No suspended-user failures remain.

When this applies

• Google Workspace SCIM provisioning fails for suspended users
• Offboarded users keep generating provisioning errors
• You are tuning provisioning scope after an offboarding wave

When it doesn't

• Active users fail the same way (that is a different provisioning error)
• You need suspended users to keep app access (change the lifecycle policy)
• The failure mentions a different attribute (check the mapping)

Compatibility

Google Workspace automatic provisioning (SCIM) to third-party apps.

Variant phrasings

google scim suspended user provisioning error

Same behavior. Suspension is a lifecycle state; the provisioner will not create app accounts for it.

workspace provisioning fails offboarded users

Offboarding suspends the Google account but the app assignment lingers. Clean up the assignment.

scim skip suspended users google

Skipping is correct once scope excludes them. Confirm the exclusion is intentional, not a misconfigured filter.

Why it happens

Suspended is a terminal lifecycle state in Google Workspace: the user cannot authenticate, so provisioning an app account for them makes no sense. The SCIM provisioner refuses rather than creating a dead account. The failures are the provisioner telling you the scope still includes people who should not be there.

Edge cases

• Suspended users with licenses still assigned cost money; this error is a good prompt to clean up
• Reactivating a user re-triggers provisioning for every assigned app; expect a burst
• Some apps have their own suspend state; decide whether Google suspension should map to it

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_OgJjbkqEOtdesBzj5o4baA

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

Thread query: google workspace scim provisioning failed suspended user

TL;DR: Google Workspace skips SCIM provisioning for suspended users by design, and the failure looks like an error. Either unsuspend the user if they should have access, or exclude suspended users from the provisioning scope. Do not treat the skip as a connector bug.

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.