Trying to use a private FQDN with AVS vCenter, get error "the service provider validation failed"

Chris Ajello 0 Reputation points
2026-06-16T17:37:24.7966667+00:00

I setup a DNS A-record to resolve to the IP address of my AVS vCenter server, but when I browse to the FQDN and click the button to "Launch vSphere Client" I get this error message instead:

[400] An error occurred while sending an authentication request to the vCenter Single Sign-On server - An error occurred when processing metadata during vCenter Single Sign-On setup: the service provider validation failed. Verify that the server URL is correct and is in FQDN format, or that the hostname is a trusted service provider alias.

Searching for this error in Broadcom's docs points me to whitelisting my FQDN using the vCenter Admin, but since it's AVS we don't have access to that. Is there some way to do this through the Azure portal or does MS professional services need to take the wheel here? (Or am I doing something wrong?)

Thanks!

Azure VMware Solution

3 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-06-16T17:37:44.2966667+00:00

    The error occurs because vCenter Single Sign-On validates the exact FQDN used to access vCenter against its configured service provider URL and trusted aliases. In Azure VMware Solution, the vCenter FQDN is predefined (for example, vc123.eastus.avs.azure.com) and is already registered in vCenter SSO. Using a different private FQDN (custom DNS A-record) to reach the same IP causes the SSO metadata validation to fail, which produces the “service provider validation failed” error.

    In Azure VMware Solution, there is no supported way in the Azure portal to add or modify vCenter SSO service provider aliases, and customers do not have direct vCenter SSO admin access to change this. As a result:

    • Access to vCenter must use the official AVS-provided vCenter FQDN, not a custom private FQDN.
    • DNS should be configured so that clients resolve and use the AVS vCenter FQDN directly.

    To find and use the correct vCenter FQDN for the AVS private cloud:

    1. Sign in to vCenter using the VMware credentials provided in the Azure portal for the AVS private cloud.
    2. In the vSphere Client, select the vCenter; the vCenter FQDN is displayed there.
    3. Use that FQDN (for example, vc...region.avs.azure.com) as the URL when launching the vSphere Client.

    If a private DNS name is required for internal resolution, configure DNS so that the official AVS vCenter FQDN resolves to the correct private IP (for example, via a private/public DNS forwarder as documented for AVS), rather than introducing a new alias FQDN for vCenter.

    If the scenario absolutely requires a different hostname than the AVS-provided FQDN, this would require changes on the vCenter SSO side, which are not exposed to customers; in that case, opening a support request with Microsoft to discuss options would be necessary.

    References:

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

    Was this answer helpful?

  2. Anonymous
    2026-06-16T21:43:23.9766667+00:00

    Thank you for sharing the details.

    Thank you for sharing the details.

    Based on the information provided, the issue is not related to DNS resolution — your custom FQDN is correctly pointing to the AVS vCenter IP. The problem is that vCenter's Single Sign-On (SSO) service is rejecting the authentication request because your custom hostname is not registered as a trusted Service Provider (SP) alias within vCenter SSO.

    In Azure VMware Solution, vCenter is a fully managed service. The default AVS vCenter FQDN provisioned during deployment is pre-configured with the required SSO trust settings. When a custom FQDN is created solely through DNS, vCenter SSO does not automatically inherit that trust — resulting in the error:

    "The service provider validation failed. Verify that the server URL is correct and is in FQDN format, or that the hostname is a trusted service provider alias."

    In a self-managed VMware environment, this would typically be resolved by adding the custom hostname as a trusted SP alias from the vCenter administration console. However, in AVS, customers do not have access to the underlying vCenter SSO/STS configuration, as the vCenter appliance is fully managed by Microsoft.

    As a first step, we recommend testing access using the default AVS vCenter URL available in the Azure portal (Azure VMware Solution Private Cloud → vCenter Server). This URL is already configured and trusted by vCenter SSO.

    You can also validate the DNS configuration by confirming that the custom FQDN resolves correctly to the AVS vCenter private IP and that any required DNS forwarding/private DNS configuration is working as expected.

    Please find below documentations for more reference:

    Configure DNS for name resolution for Private Cloud vCenter access from on-premises workstations

    Manage Private Cloud resources and activity

    Configure a DNS forwarder in the Azure portal

    Known issues: Azure VMware Solution

    Configure private and public DNS forward lookup zones

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments
  3. Jose Benjamin Solis Nolasco 12,201 Reputation points Volunteer Moderator
    2026-06-16T21:45:58.1633333+00:00

    Welcome to Microsoft Q&A

    Hello @Chris Ajello I hope you are doing well,

    The error you are encountering is a built-in security mechanism of VMware vCenter's Single Sign-On (SSO) architecture, and you are not doing anything wrong based on standard on-premises VMware practices.

    When you initiate a login, vCenter SSO strictly validates the HTTP Host header against its configured Service Provider metadata. If you attempt to access vCenter using a custom vanity URL (like vcenter.corp.local) that is not explicitly registered as a Trusted Service Provider Alias within SSO, it forcefully rejects the authentication request with a 400 error to prevent potential spoofing attacks.

    The AVS Constraint: In a traditional on-premises environment, you would log into the vCenter appliance via SSH or the VAMI as administrator@vsphere.local and use the sso-config.sh tool to whitelist your custom FQDN. However, because Azure VMware Solution is a managed PaaS-like service, your cloudadmin@vsphere.local account is intentionally restricted. You do not have the root-level privileges required to modify the SSO configuration, and there is currently no "Run Command" in the Azure Portal to inject SSO aliases.

    """"""You cannot use a custom private FQDN for AVS vCenter. You must strictly use the official Microsoft-provided FQDN (e.g., vc-XXXXXX.region.avs.azure.com)."""""""""""""""

    To resolve the routing internally: Instead of creating a custom A-record (like vcenter = 10.x.x.x), you must configure a DNS Forwarder on your internal network. You need to configure a conditional forwarder zone for avs.azure.com (or the specific region domain) that points to the AVS DNS IP. This ensures that when your engineers type the official Microsoft FQDN, your internal DNS correctly resolves it to the private AVS vCenter IP rather than routing out to the public internet.

    😊 If my answer helped you resolve your issue, please consider marking it as the correct answer. This helps others in the community find solutions more easily. Thanks!

    Was this answer helpful?

    1 person found this answer helpful.

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.