Both the Azure DevOps portal and authenticated REST API fail when updating the connection, including a metadata-only rename.

Sign out of Azure DevOps and retry the edit from an InPrivate browser session authenticated directly with an account in the directory associated with the target Azure subscription; Microsoft documents expired session state as the resolution path for “Failed to obtain an access token” during ARM service-connection operations.^1^

1. Refresh the update-time user authentication context

The connection being isReady: true only indicates endpoint state; it does not establish that the interactive user token needed by the edit operation can be acquired.^2^

1. Sign out of all Azure DevOps sessions.
2. Open an InPrivate/incognito browser window.
3. Navigate directly to the Azure DevOps organization.
4. Sign in using the exact UPN—not an email alias—of the account that has access to the organization and the target tenant.
5. Select the organization and project.
6. Go to Project settings → Pipelines → Service connections → Production connection → Edit.
7. Make only the metadata change and select Save.

Do not alter the client ID, tenant ID, issuer, subject, scope, or federation configuration during this test. A successful save updates the same service endpoint, so its endpoint ID and pipeline references remain intact. Editing an existing connection is the supported management operation.^3^

2. Validate which identity is failing

The unexplained ID in GetUserAccessToken should not automatically be treated as the workload identity’s client or object ID. The failure occurs while Azure DevOps is obtaining a user access token for the update operation, whereas pipeline authentication uses the service connection’s federated workload identity.

Capture the following without changing anything:

• Full failing ID and error response from the browser’s Network trace.
• Azure DevOps correlation/activity ID and timestamp.
• Signed-in user’s exact UPN and home tenant.
• Azure DevOps organization’s connected tenant.
• Service connection’s Directory (tenant) ID, client ID, issuer, and subject.
• App registration’s application/client ID and object ID.

Compare IDs by type; application/client IDs, service-principal object IDs, user object IDs, and tenant IDs are distinct identifiers. An identity lookup that finds only a similar ID does not resolve the failing one.

Because the organization and Azure resources are in different tenants, verify that:

• The interactive account exists in the required directory, directly or as a guest.
• The service connection’s tenant ID is the directory containing the workload identity and the target subscription context.
• The exact signed-in identity—not merely another account with a similar display name—has the necessary access.

If the user is only a guest in the subscription directory, an Entra administrator must grant sufficient directory permissions or perform the operation with an appropriately authorized account. Microsoft notes that directory changes can take 15–20 minutes to propagate.^1^

3. Check Azure DevOps endpoint administration

The caller needs the Administrator role on this specific service connection, not merely permission to use it.

1. Open Project settings → Pipelines → Service connections.
2. Open the Production connection.
3. Select More actions → Security.
4. Confirm the editing user or an applicable group has Administrator.

The User role permits pipeline use; Administrator is the management role.^4^

Since both portal and authenticated REST updates reach the same failure, changing REST API versions or switching to CLI is unlikely to bypass an update-time identity/token validation failure. There is no documented safe flag that suppresses this validation.

4. Inspect federation without changing it

Compare the service connection’s generated Issuer and Subject identifier with the federated credential on the associated app registration or managed identity. Microsoft documents that mismatches can cause authentication failure.^1^

Also inspect the issuer:

• https://login.microsoftonline.com/... — Microsoft Entra issuer.
• https://vstoken.dev.azure.com/... — legacy Azure DevOps issuer.

Only if Azure DevOps displays an issuer-conversion warning should conversion be considered. The supported conversion updates the existing service connection rather than recreating it, preserving endpoint references, but it changes federation configuration and therefore does not meet the current constraint unless approved.^5^

5. Escalate if a clean session still fails

If the InPrivate attempt fails with the same unidentified identity, open an Azure DevOps support case. Include:

• Organization and project names.
• Existing service endpoint ID.
• UTC timestamp, correlation/activity ID, HTTP status, and complete response body.
• Failing identity GUID.
• Organization tenant ID, service-connection tenant ID, and signed-in user’s home tenant.
• Confirmation that both portal and REST updates fail, including a metadata-only rename.
• Confirmation that pipeline dependencies require preserving the endpoint ID and federation settings.

Azure DevOps backend identity records and token-broker state are not exposed through a documented public repair API. Support must correlate the unidentified ID and determine whether the organization has a stale identity association or server-side token state. Do not delete or recreate the Production connection while that investigation is active.

References

1. Troubleshoot Azure Resource Manager service connections
2. ServiceEndpoint interface-Property Details
3. Manage service connections
4. Manage security in Azure Pipelines
5. Convert service connections from the Azure DevOps issuer to the ...