Skip to content

How do I use SAML-based federated authentication with multiple AWS Client VPN endpoints across accounts?

4 minute read
Content level: Intermediate
2

I want to use multiple AWS Client VPN endpoints in different AWS accounts with the same Microsoft Entra ID (Azure AD) tenant for SAML authentication. When I create a second enterprise application in Entra, I receive errors like:

"The Reply URL specified in the request does not match the reply URLs configured for the application."

Or, after setting up the endpoints, users see:

"The credentials received were incorrect. Contact your IT administrator."

Short description

AWS Client VPN uses a fixed entity ID (urn:amazon:webservices:clientvpn) and fixed Assertion Consumer Service (ACS) URLs for all endpoints regardless of account or region. You cannot create multiple Entra enterprise applications with the same entity ID. Instead, use a single enterprise application and create separate IAM SAML identity providers in each AWS account referencing the same federation metadata.

Resolution

Understand the architecture

All AWS Client VPN endpoints send the same values in SAML authentication requests:

  • Entity ID (Audience): urn:amazon:webservices:clientvpn
  • ACS URL (desktop client): http://127.0.0.1:35001
  • ACS URL (self-service portal): https://self-service.clientvpn.amazonaws.com/api/auth/sso/saml

These values are fixed by AWS and cannot be customised per endpoint or per account. This means a single IdP application serves all endpoints.

Why creating multiple enterprise applications fails

ApproachWhy it fails
Two enterprise apps with the same entity IDEntra does not allow duplicate entity IDs in a single tenant
Second app with a modified entity ID (e.g., appending :account2)Client VPN always sends urn:amazon:webservices:clientvpn in the AuthnRequest - the IdP cannot match it to the custom ID

Configure multiple endpoints with a single enterprise application

Step 1: Use an existing enterprise application

Keep the Entra enterprise application that is working for your first Client VPN endpoint. If you don't have one, create it from the Entra gallery by searching for "AWS ClientVPN".

Step 2: Verify SAML signing settings

In Entra, navigate to Enterprise applications > your app > Single sign-on > SAML Signing Certificate > Edit.

Set the following:

  • Signing Option: Sign SAML response and assertion
  • Signing Algorithm: SHA-256

Important: The default setting is "Sign SAML assertion" only. AWS Client VPN requires both the Response and the Assertion to be signed. If only the assertion is signed, you receive "The credentials received were incorrect."

Step 3: Verify claims configuration

In the Attributes & Claims section, confirm:

ClaimSource attribute
Unique User Identifier (NameID)user.mail (format: Email address)
FirstNameuser.givenname
LastNameuser.surname

Step 4: Download the federation metadata

Navigate to Single sign-on > SAML Signing Certificate > Federation Metadata XML > Download.

Save this file. You use the same file in every AWS account.

Step 5: Create an IAM SAML provider in each account

In each AWS account that needs a Client VPN endpoint, create an IAM SAML identity provider referencing the same metadata:

aws iam create-saml-provider \
  --saml-metadata-document file://federation-metadata.xml \
  --name EntraID-ClientVPN

Note: Replace federation-metadata.xml with the path to your downloaded file.

Step 6: Create the Client VPN endpoint in each account

Create a Client VPN endpoint with federated-authentication as the authentication type, referencing the IAM SAML provider ARN you created in Step 5.

Users differentiate between endpoints through their .ovpn configuration files, which contain the endpoint-specific DNS name. The IdP does not need to distinguish between endpoints.

Troubleshoot "The credentials received were incorrect"

If authentication fails after following the steps above, check the following in order:

  1. Verify the enterprise application type is SAML, not OIDC.

  2. Verify both Response and Assertion are signed. Use a SAML-tracer browser extension to capture the SAML response. Both the <samlp:Response> and the <saml:Assertion> elements must contain a <ds:Signature> block.

  3. Verify NameID is non-empty. In the decoded SAML assertion, check that the <NameID> element contains a value. If it's empty, the source attribute (e.g., user.mail) is null for that user.

  4. Verify the signing certificate matches. Compare the X.509 certificate in the SAML assertion with the certificate in your IAM SAML provider's metadata document. They must match.

Rotate certificates or update metadata

When the Entra signing certificate rotates or you update the app's metadata:

  1. Download the new Federation Metadata XML from Entra
  2. Update the IAM SAML provider in each account:
aws iam update-saml-provider \
  --saml-provider-arn arn:aws:iam::111122223333:saml-provider/EntraID-ClientVPN \
  --saml-metadata-document file://new-federation-metadata.xml
  1. Repeat for each account.

Related information