AWS Client VPN with AzureAD SAML SSO

Posted byevanspaederPosted inUncategorized

The ability to use SAML with AWS Client VPN is an awesome new feature because it gives us tons of options for allowing guest access for folks who aren’t in our AD. Currently AWS says they are only supporting Okta as an IdP. I was able to successfully set this up with AzureAD using the steps below:

Create an Enterprise App in AzureAD for your VPN client. You can’t use the same Enterprise App that you use for console SSO, you must create a new one. Use a “Non-Gallery Application” as the built in AWS app wont let you change some necessary settings.

First go to the “Users and Groups” blade and assign each of the groups or users that you want to give access. Client VPN allows us to delegate access by security group so I recommend using groups.

Next go to the “Single sign-on” blade. Select SAML 2.0 as your SSO method.
Click the Edit button on part 1 – “Basic SAML Configuration”
Your Identifier (Entity ID) will be: urn:amazon:webservices:clientvpn
For the reply URL, the field conditions will not allow us to save the value that we need here, but as it is a required field, we need to put something there. As you can see, I set mine to https://whatever

Now click the edit button for part 2 – “User Attributes and Claims”
Delete all the default additional claims. And then configure the following:
Claim Name: FirstName Value: user.givenname
Claim Name: LastName Value: user.surname
Add a group claim for this last one: Claim Name: memberOf Value: user.groups
Make sure that you select “Groups assigned to this application” as shown here

Your completed claims section should look like this:

Now click the edit button on part 3 – “SAML Signing Certificate”
Change the “Signing Option” to “Sign SAML response and assertion”, then click save.

Now download your federation metadata (as shown below) and save it for later:

Now go back to AzureAD and go to “App Registrations.” Find the new app that we just created and select it. Open the “Manifest” blade.
Scroll down in the manifest to find the JSON key “replyUrlsWithType”. You will see here the reply URL that you entered above (in my case https://whatever). Change this url to the following: http://127.0.0.1:35001 Once this is done, save the manifest.

We are finished with AzureAD, now move over to AWS. First go to the IAM console.
Click on “Identity Providers” and then select “Create Provider”
Provider Type: SAML
Provider Name: This can be any name you want to give it.
Metadata Document: Select the Federation Metadata file that we downloaded from AzureAD
Click Next, and Click Create.

We are now finished with IAM. You don’t need to create any roles or policies for Client VPN.

Go to the VPC console, and then select Client VPN Endpoints. I am going to skip over all of the Client VPN setup basics. If you need them, you can follow Amazon’s setup guide here

When you are creating your endpoint, in the “Authentication Information” section, you will choose “Use user-based authentication” and then “Federated authentication” then you will pick the ARN of your new IAM IdP that we just created.

Once you have created your Client VPN endpoint, you can authorize access by security group. When authorizing ingress, you can select “Allow access to users in a specific access group.” AzureAD sends over the Access Group ID as the groups GUID. To get this go to Groups in AzureAD and you will see it listed next to the group name:

You can use this Object ID to set up your authorization rules

That’s it! When you connect from the AWS VPN Client it will launch a browser and have you authenticate to AzureAD (MFA is supported).

If you have any problems, feel free to reach out!

16 thoughts on “AWS Client VPN with AzureAD SAML SSO”

  2. This was exactly what I needed, and it worked great. Thank you!!

    There was one exception however. On the VPN side, with the default configs I was not able to authorize ingress using a specific Azure AD group. The group ID was not being included in the SAML assertion from Azure until I updated the following in the manifest for the app registration:

    “groupMembershipClaims”: “ApplicationGroup” —-> “groupMembershipClaims”: “SecurityGroup”

    Thanks again for the writeup.

    Like

    Reply

  3. Hi, Currently we have AWS SSO setup with Azure AD Authentication. This allows us to manage multiple AWS account using Azure AD. This is great for hoping between accounts with our Microsoft account.
    Will AWS Client VPN with SAML support allow access to VPCs in different AWS account?

    Like

    Reply

  4. Hi there, I noticed that “Sign in URL” is no longer optional. I think that might be giving me headaches, but I’m not sure. I can get the self-service site to authenticate, but when I try to connect, I constantly get “The credentials received were incorrect”. Cloudwatch/connections tab shows “N/A” for username, so it’s like it’s not getting passed properly.

    Like

    Reply

    1. Hmm… I’ve not seen “Sign in URL” become mandatory. I just tested myself and it still shows optional. In any case it should only matter if you’re trying to use IdP initiated sign on, so you can just put any old URL there.
      To resolve the credentials error – did you configure your attribute mappings correctly? And did you change the setting in the enterprise app to sign the SAML request?

      Like

      Reply

      1. Yes, it’s mandatory for me.

        And I’m not sure what to put in this field. Isn’t Azure handling the sign on?

        Like

  5. Hi there

    Huge thanks for providing the documentation to do this. I am stumped in two respects:

    (1) You’ve set the reply URL to: http://127.0.0.1:35001 –> what is the significance of this IP and why have you set it to this one?

    (2) What is the sign on URL? Azure is asking me to enter a sign-on URL, but I was expecting Azure itself to provide the sign on URL? So I am a little confused.

    Any pointers would be much appreciated.

    chrs

    Like

    Reply

    1. 127.0.0.1 is a loopback to your localhost. The aws vpn client hosts a web server on port 35001. After successful authentication with 365, your browser is instructed to redirect to 127.0.0.1:35001 and send the SAML assertion there. The aws vpn client receives it and uses it to complete the connection.

      Azure should let you skip the sign on url. That’s only needed for IDP initiated sign-on, which is not possible with this vpn client.

      Like

      Reply

  6. Hi there

    I have followed the setup and in my case the 127.0.0.1:35001 returns “Site can’t be reached 127.0.0.1 refused to connect” Is this a local firewall issue?

    Like

    Reply

  7. Was getting “The credentials received were incorrect” until I found this and changed “Signing Option” to “Sign SAML response and assertion”. You sir, deserve an internet.

    Like

    Reply

  8. Hi There,
    is it just me or others are facing issues on this step:

    “Scroll down in the manifest to find the JSON key “replyUrlsWithType”. You will see here the reply URL that you entered above (in my case https://whatever). Change this url to the following: http://127.0.0.1:35001 Once this is done, save the manifest.anyone ”

    I am not able to save it, it says is not allowed http:// any one has this problems?

    Thanks
    Steve

    Like

    Reply

  10. I am getting this when trying to authenticate

    AADSTS50011: The reply URL ‘http://127.0.0.1:35001’ specified in the request does not match the reply URLs configured for the application ‘urn:amazon:webservices:clientvpn’. Make sure the reply URL sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/urlMismatchError to learn more about how to fix this.

    Like

    Reply

      1. I’m having the exact same problem when accessing the AWS Client VPN self-service portal, and my manifests are configured with the replyUrlsWithType according to the guide here. Everything else works correctly, does the self service portal work for you?

        Like

Leave a comment