Restoring Azure Arc connectivity after service principal secret expiration

Budi Nugroho 0 Reputation points
2026-09-11T07:27:01.81+00:00

I am currently facing a global issue where Bulk azure arc server onboarding scripts are failing with the error AADSTS7000215: Invalid client secret is provided. This problem started suddenly and has disrupted all automated deployments that rely on our service principal for authentication.

When I checked the Azure AD app registration, I found that the client secret used in these scripts has expired or been revoked. As a result, the Arc agent authorization process is failing across all servers.

I have already verified that the service principal has the correct permissions and roles assigned, but the scripts still fail due to invalid credentials.

I urgently need guidance on how to update the service principal credentials across all deployment scripts and restore agent authorization without breaking existing configurations

Windows for business | Windows 365 Business
0 comments

2 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-09-11T07:27:20.3666667+00:00

    For Azure Arc server onboarding with a service principal, AADSTS7000215: Invalid client secret is provided indicates the secret is wrong, invalid, or expired. For Azure Arc onboarding specifically, service principal logins also require the client ID and secret to be correct, unexpired, and from the same tenant where the server resource is created.

    Use this recovery path:

    1. Create or reset the service principal secret.
      • If the current secret expired or was revoked, generate a new client secret for the app registration.
      • Copy the client secret value immediately and use that value in automation. Do not use the secret ID.
    2. Update every onboarding script and credential store that still uses the old secret.
      • Replace the expired secret with the new client secret value anywhere the bulk Azure Arc onboarding scripts read credentials.
      • If the secret is stored in a centralized configuration, update it there first so all deployments consume the same current value.
    3. Validate the service principal inputs used by Azure Arc onboarding.
      • Confirm the client ID is correct.
      • Confirm the client secret is the new value and has not expired.
      • Confirm the service principal belongs to the same tenant where the Azure Arc-enabled server resource will be created.
    4. Re-run onboarding validation on a test server before restarting bulk deployment.
      • If onboarding still fails, check whether the issue is actually connectivity rather than credentials.
      • Run azcmagent check to verify required access to Microsoft Entra ID endpoints is not blocked by firewall or proxy.
    5. Resume bulk onboarding after one successful test.
      • Once a test machine authenticates successfully, redeploy the updated scripts across the remaining servers.

    Important operational notes:

    • The onboarding credential is only needed when azcmagent connect runs. If the onboarding credential expires later, servers that are already connected remain connected to Azure Arc.
    • To reduce recurrence risk, use certificates instead of secrets for Azure Arc service principals when possible, and regularly rotate credentials.

    If the failing automation is Azure Arc Data Controller rather than Azure Arc-enabled servers, the credential must also be updated in the Kubernetes secret used by the data controller:

    kubectl edit secret/upload-service-principal-secret -n <name of namespace>

    Then replace the base64-encoded values for clientID, clientSecret, and/or tenantID as needed. Do not edit other properties.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. HLBui 11,575 Reputation points Independent Advisor
    2026-09-11T08:27:29.8833333+00:00

    Hi Budi Nugroho

    Hey, he error you’re seeing (AADSTS7000215) is basically Azure telling you the client secret your scripts are using is no longer valid. Since you already confirmed the service principal itself is fine, the fix is to generate a new client secret in the Azure AD app registration, then update all your automation scripts to use that fresh secret.

    The safest way to handle this globally is to store the new secret in a secure location like Azure Key Vault and have your scripts pull it from there, rather than hardcoding it. That way, you only need to rotate the secret in one place next time it expires, and you won’t have to touch every script manually. If you’re using pipelines (Azure DevOps or GitHub Actions), update the service connection or secret variable there so all jobs pick it up automatically.

    Once you’ve replaced the expired secret everywhere, the Arc agent onboarding should start working again without breaking your existing configs. If this answer helps you get things back on track, please hit “accept answer” so we know it solved your issue.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.