Hook Azure AD with multiple AWS Accounts Seamlessly

Posted by

Over the years, I witness most of the organizations adopt Microsoft Active Directory (AD) as their preferred directory services. While Microsoft AD comes with different flavors, the cloud version Azure AD has an edge over others. Choosing Azure AD over the on-premise AD solution may embrace following benefits:

  1. Access Simplification: Self-service portal for users with intuitive UI.
  2. Single Sign-on (SSO): Integrations made simple and allows the users to seamlessly login to multiple SaaS applications
  3. Multi-factor Authentication (MFA): Tightens the security and less burden on IT level 1 support
  4. Access Panel: VPN is now legacy, unless a forced compliance

Azure cloud adoption has been witnessing an upward shift in last few years. 70% customers I worked in the past leverage Azure AD as their identity service provider.

As an Amazon Web Service (AWS) solution architect, I’ve had many challenges to integrate AD with AWS- not because of technicalities, but choice paralysis. AWS constantly innovates it’s IAM (identity and access management) service to stay on top. Also, I’ve seen a persistent demand on how seamlessly Azure AD & AWS can talk to each other. The solution is certainly straight-forward, for a single tenant AWS account, but the real challenge comes, when AWS has multiple accounts. Now-a-days, it’s a generic practice at AWS to have multiple environments, viz, Dev, Prod, Pre-Prod, QA etc. Though, Microsoft has few documents those guides how to setup single and multiple accounts, but in this we’ll try to simplify the account access from Azure AD to AWS.

This document will enable you to do following:

  1. Hook-up Microsoft Azure AD with Amazon Web Services (AWS)
  2. Enable Single Sign-on and auto sign-in from Microsoft Azure AD to AWS
  3. Provision Users/Groups from Microsoft Azure AD to multiple AWS accounts
  4. Retrieve all roles from multiple AWS accounts
  5. Assign appropriate roles from AWS to AD users
  6. Manage identity, role provisioning and account administration from Azure portal
  7. Use single enterprise application (AWS App) in Azure portal to provision users.

The overall architecture of the solution is depicted below:

Though Microsoft advises to maintain multiple version of the AWS app, for certificate, provisioning and automatic role management, but this approach would fetch all the roles (with couple of manual steps) with one single AWS apps deployment.

– Azure AD subscription
– Amazon Web Services console access, with at-least one account (master/root) defined

Scope: Azure AD
Step 1: Add AWS application from gallery

– Login to Azure Portal
– Click Azure Active Directory
– Go to Enterprise Applications, and then select All Applications
– Click on New Application
– Search for Amazon Web Services (AWS) and add it

Azure Login
Go to Azure Active Directory
Add New Enterprise Application
Add AWS App with Category as Developer Services

Scope: Azure AD
Step 2: Configure Azure AD Single Sign-on

– Select the newly installed AWS app
– Click Single Sign-on
– Choose SAML as method
– Click on the pen icon to edit the configuration
– All the application is pre-configured, and the necessary URLs are already pre-populated with Azure

Select Setup SSO for AWS App
SSO Setup Steps
Leave the Defaults and click Save

When the SAML payload hits AWS, it primarily expects 2 assertions.
1. Role
2. RoleSessionName

So we need to modify the default SAML assertion in AWS acceptable format
– To start with Click on the pencil icon of “User Attributes”. Refer the below screenshot.

SAML Claims must be updated

In the next screen click on “Add new claim” and enter the following values:

Enter New Claim as RoleSessionName
P.S.: The Source attribute needs to be chosen carefully. If you organization uses special character in email address, don’t take “user.displayname” instead take “user.userprincipalname
Enter New Claim as Role

Once done save the entries and go to “SAML Signing Certificate” Download the Federation Metadata XML, which we are going to upload AWS while creating the IDP (Identity Provider)

Download the federated metadata from Azure

Scope: Amazon Web Services (AWS)
Step 3: Configure AWS

Step 3.1: Configure AWS Identity Provider (IdP)
– Login to AWS Console (root account)
– Create Provider
– Choose Provider Type, Name & Metadata Document (which was download from the Azure AD)

Configure AWS AD Provider

Step 3.2: Create Necessary Roles with Trust to the SAML Federation
You can create number of roles here as per requirement.

Create appropriate role
Allow both API and Console Access to the Role

Step 3.3: Create IAM Read Role Policy
This policy is created for automatically sync AWS roles with Azure AD.
– Go to IAM -> Policies
– Create a IAM Read Role policy for AD to automatically read roles

From IAM, chose Policies
Check the Policy to make sure that the policy has only access to ListRoles action
Review Policy and Create the same

Step 3.4: Create IAM User and Associate the Policy Crated Above
This step would add the policy to a user, which we’ll refer for auto provisioning of AWS roles to Azure AD.
– Once the User created, you must download the user credential .CSV file to note down the Access key ID & Secret access key.

Attach the policy we created in before step
Make a note of Client Secret and Secret Access Key which we’ll use in Azure for Auto provisioning
Make sure the User has necessary policy attached

Scope: Azure AD
Step 4: Configure Automatic Provisioning of Roles in Azure AD

– As we are going to use one Application for provisioning all roles. The landing AWS root account role is going to be Auto Synced. While for DEV & PROD accounts, Graph API would be used to sync.
– Login to Azure
– Go to Provisioning
– Then change the Provisioning Mode to Automatic
– Enter the clientsecret and Secret Token from the previous created user
– Test Connection
– Optionally put notification email in order to get notified in case of any sync failure.

You must enable Provisioning Status to “On” for automatic sync of roles from AWS to Azure. Then Save the changes.

You must Logout of Azure and Login afresh to see the “Current Status” and “Statistics to date” populated. As you see below, the 3 roles has been automatically synced from AWS.

Scope: Azure AD
Step 5: Use Microsoft Graph API to sync the other Account Roles

– You must create the AWS IdP in respective accounts
– Create necessary roles as described above
– Copy the AWS ARNs (Amazon Resource Names) for all the roles created in different accounts

I’ve created 4 PROD roles and 3 DEV roles as below. In next steps, we are going to sync them using MS Graph API.


Steps to Sync roles using Microsoft Graph API

  • Go ahead and open link:https://developer.microsoft.com/graph/graph-explorer
  • Sign in to the Graph Explorer site using the Global Admin/Co-admin credentials for your tenant.
  • You need to have sufficient permissions to create the roles. Click on modify permissions to get the required permissions
  • Make sure the following permissions are “Consented
  • If you are doing it for first-time, the portal will ask you to login again and accept the consent. After accepting the consent, you are logged into the Graph Explorer again.
  • Get the Object ID of the Azure Enterprise Application for AWS we created in the 1st step.
  • For that Login to Azure
  • Then Search for the Application
  • Click on Properties on left pane
  • Once you copy to the text editor. Now it’s time to change the “appRoles“.
  • Search for “appRoles” in the file and add the PROD and DEV entries

Following is a sample and you can take this as base. Modify the Description, DisplayName, ID & Value. In the Value, you need to replace the AWS ARNs we noted before. Also you would need to note down the IdP created in before steps.

"appRoles": [
        "allowedMemberTypes": [
        "description": "Admin,WAAD",
        "displayName": "Admin,WAAD",
        "id": "4aacf5a4-f38b-4861-b909-bae023e88dde",
        "isEnabled": true,
        "origin": "ServicePrincipal",
        "value": "arn:aws:iam::12345:role/Admin,arn:aws:iam::12345:saml-provider/WAAD"
        "allowedMemberTypes": [
        "description": "Auditors,WAAD",
        "displayName": "Auditors,WAAD",
        "id": "bcad6926-67ec-445a-80f8-578032504c09",
        "isEnabled": true,
        "origin": "ServicePrincipal",
        "value": "arn:aws:iam::12345:role/Auditors,arn:aws:iam::12345:saml-provider/WAAD"
    }    ]
  • Once you are done with the entries, now you can copy the whole roles into the original text you copied initially.
  • Carefully replace, the above entries as shown below.
  • You can only add new roles after the msiam_access for the patch operation. Also, you can add as many roles as you want per your Organization need. Azure AD will send the value of these roles as the claim value in SAML response.
  • Once you made changes to the necessary roles, you can now go back to the Graph API explorer.
  • Change the method from GET to PATCH. Patch the Service Principal object to have desired roles by updating appRoles property 
  • Make sure you get a Success message after the PATCH application
  • After the Service Principal is patched with more roles, you can assign Users/Groups to the respective roles. This can be done by going to portal and navigating to the Amazon Web Services application. Click on the Users and Groups tab on the top.
  • Add User and then Select the User
  • Add the necessary role
  • You can see that all roles are displayed irrespective of accounts
All Roles are displayed from Multiple AWS Accounts

Step 6: Test the Single Sign On
– You can test directly from Azure AD portal
– Navigate to Single Sign-on and Click Test this application
– Ens users can go to https://myapps.microsoft.com/cae.com to see the new AWS application assigned to them

  • Once you sign on, AWS Account selection page will appear
  • Hurray !!!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s