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
| Approach | Why it fails |
|---|
| Two enterprise apps with the same entity ID | Entra 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:
| Claim | Source attribute |
|---|
| Unique User Identifier (NameID) | user.mail (format: Email address) |
| FirstName | user.givenname |
| LastName | user.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:
-
Verify the enterprise application type is SAML, not OIDC.
-
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.
-
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.
-
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:
- Download the new Federation Metadata XML from Entra
- 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
- Repeat for each account.
Related information