Summary: How to log in to the AWS console using your Entra ID credentials.
Date: Around 2018
Refactor: 1 March 2025: Checked links and formatting.

After Getting Started With AWS and Getting Started With Office 365 I now also want to login to the AWS console using Azure Active Directory. This article describes the steps to do so. Used technologies:

• AWS IAM
• Azure AD
• Azure AD Enterprise App

Note that the goal here is to keep user provisioning in Azure Active Directory, something that is already common for many organizations and that I don't want to create users in AWS IAM. I just want to login to AWS using the original account.

We start with configuring the Azure AD part.

First we want to create groups in Azure AD so users with privileged access can become a member and have access based on their group membership.

Note that you need Azure AD Premium to assign Azure AD groups to an Enterprise App which we'll create later on. I don't have that (yet - because of the costs), so even though I am creating them here I won't use them later on. If you have an Azure AD subscription which allows you to use group membership in Enterprise Apps I highly recommend doing so.

Follow these steps to create Azure AD groups:

• Log into the azure portal with the office365 global administrator account we created earlier
• Go to Azure Active Directory → Groups
• Create the group as described in the table below, note that I'm right now creating only two groups, both with the same account as a member. When you start adding multiple accounts you should name your Azure AD groups accordingly to separate them from each other.

Note that the AWS columns can be ignored for now, and that the AWS Role Name is the only easy way to separate different roles for a user, so include the accountname.

Now we need to create an Enterprise App in Azure. This way the AWS Console App shows up in the myapps page for users with access.

• Log into the azure portal with the office365 global administrator account we created earlier
• Go to Azure Active Directory → Enterprise Applications → New Application
• In the “Add from the gallery” section search for “Amazon Web Services (AWS)” and select the Application
• In the new blade keep all the default settings and click “Add”. Wait for the application to be added. When done, the overview page of the AWS Application will open.
• In the “Amazon Web Services (AWS) - Overview” page go to “Single sign-on”, and Select SAML as your single sign-on method by clicking on the tile
  • Keep Section 1, Basic SAML Configuration, default, AWS is pre-integrated so you do not need to change this
    • Note that both the identifier and reply url should be filled in as https://signin.aws.amazon.com/saml
  • Edit Section 2, User Attributes & Claims, by clicking on the edit icon, and add the two attributes from the table below by clicking on “Add New Claim”
    • Go back by closing the User Attributes & Claims blade
  • Edit Section 3, SAML Signing Certificate, by clicking on the edit icon, and create a new certificate by clicking the “New Certificate” link
    • Fill in a valid notification email address, and click save.
    • Click the three dots on the right to activate the certificate.
    • Go back by closing the SAML Signing Certificate blade
  • In Section 3, SAML Signing Certificate, you can now download the “Federation Metadata XML” file by clicking the link.

SessionDuration: provide a value between 900 seconds (15 minutes) to 43200 seconds (12 hours)
Depending on the version and interface you're using the names of the different fields such as Name/Claim Name may differ. Please use the screenshots below of both the new interface as the old one to verify your settings:

New interface:

Old interface:

During my configuration I ran into a problem. Microsoft switches the experience for the Enterprise Application SAML Single Sign-on to a new one, changing the look and feel compared to when I done this previously in the past. Still, all information was still valid and everything still worked the way I expected. However, when trying to log start the Amazon Web Services (AWS) from the myapps page I was asked to fill in the AWS account number and my credentials. Something was not right, so after checking all settings I decided to check the old experience, and I noticed that in the advanced URL setting the Identifier (Entity ID): field got automatically updated with “https://signin.aws.amazon.com/saml”. I saved this and tested the SAML connection by using the “Test SAML Settings” button and I got a success back. Now the myapps application worked as well.

Note that it kept working after switching back to the new experience.

We now continue with AWS.

We must now set Azure AD as an Identity Provider with AWS IAM:

• Log in to the account you want to federate with your root account and go to the IAM service
• Go To “Identity Providers” and click “Create Provider”
  • Provider Type: SAML
  • Provider Name: AzureAD
  • Metadata Document: Select the “Federation Metadata XML” you downloaded in the previous step
  • Click Next Step and Create to finish creating the provider
• When the provider is created click on the name to see the details and note the ARN, as you will need it later: arn:aws:iam::**accountnr**:saml-provider/AzureAD

• Still in the IAM service, go to Roles and click “Create Role”
  • Type: SAML 2.0 Federation
  • SAML Provider: AzureAD
  • Allow programmatic and AWS Management Console access
  • Click “Next:Permissions”
  • Attach Permissions as in the table above
  • Click “Next: Tags” and “Next: Review”
  • Role Name and description as in the table above
• When the role is created click on the name to see the details and note the ARN, as you will need it later: arn:aws:iam::**accountnr**:role/AWSAdminsInAzureAD & arn:aws:iam::**accountnr**:role/AWSReadOnlyInAzureAD

In case you want to allow accounts accessing AWS using CLI and or the API to have a longer session duration than 1 hour, change the “Maximum CLI/API session duration” to your needs as it is only 1 hour by default. You can find this setting at the default summary page of your role.

Note that you have to repeat creating an Identity Provider and Roles for every account you want to enable for federated login.

This is where the two worlds come together. Now we integrate the AWS roles into the Azure AD Enterprise Application:

• Log into the azure portal with the office365 global administrator account we created earlier
• Go to Azure Active Directory → App Registrations → Select the “Amazon Web Services (AWS)” Application (make sure the app selector is set to “all apps”)
• Click Manifest and click Edit to edit. Start by making a copy of the default:

Default Manifest:

{
"appId": "16a70ec9-1e72-49f4-8c9e-d07e913df89a",
"appRoles": [
{
"allowedMemberTypes": [
"User"
],
"displayName": "msiam_access",
"id": "7dfd756e-8c27-4472-b2b7-38c17fc5de5e",
"isEnabled": true,
"description": "msiam_access",
"value": null
}
],
"availableToOtherTenants": false,
"displayName": "Amazon Web Services (AWS)",
"errorUrl": null,
"groupMembershipClaims": null,
"optionalClaims": null,
"acceptMappedClaims": null,
"homepage": "https://signin.aws.amazon.com/saml?metadata=aws|ISV9.1|primary|z",
"informationalUrls": {
"privacy": null,
"termsOfService": null
},
"identifierUris": [
"http://awsDCF3C61462CA401EAAB9E02D5E8B5E35",
"http://instanceid_8b1025e4-1dd2-430b-a150-2ef79cd700f5_780DF1B728DE452FBAA10356F5475FD2",
"http://aws/68a80f15-7f9e-4968-9b80-59892d509128"
],
"keyCredentials": [],
"knownClientApplications": [],
"logoutUrl": null,
"oauth2AllowImplicitFlow": false,
"oauth2AllowUrlPathMatching": false,
"oauth2Permissions": [
{
"adminConsentDescription": "Allow the application to access Amazon Web Services (AWS) on behalf of the signed-in user.",
"adminConsentDisplayName": "Access Amazon Web Services (AWS)",
"id": "1a6a3f4d-d629-4326-8b9b-d4d267500be3",
"isEnabled": true,
"type": "User",
"userConsentDescription": "Allow the application to access Amazon Web Services (AWS) on your behalf.",
"userConsentDisplayName": "Access Amazon Web Services (AWS)",
"value": "user_impersonation"
}
],
"oauth2RequirePostResponse": false,
"objectId": "c86f145a-1c55-4d7a-b57c-1dbc72ac3910",
"parentalControlSettings": {
"countriesBlockedForMinors": [],
"legalAgeGroupRule": "Allow"
},
"passwordCredentials": [],
"publicClient": false,
"replyUrls": [
"https://signin.aws.amazon.com/saml"
],
"requiredResourceAccess": [],
"samlMetadataUrl": null
}

The part to add the roles is the allowedmembertypes. Replace it with the correct values, like this:

• displayName: AccountName_AdminAccess
• Id: Must be unique within the enterprise application. Format is like “00000000-0000-0000-0000-000000000001” (note that only 0 is not a valid number)
• Description: AccountName_AdminAccess_AccountNR
• Value: ARN Role, ARN identity provider

{
"allowedMemberTypes": [
"User"
],
"displayName": "Warmetal_AdminAccess",
"id": "00000000-0000-0000-0000-000000000001",
"isEnabled": true,
"description": "Warmetal_AdminAccess_**accountnr**",
"value": "arn:aws:iam::**accountnr**:role/AWSAdminsInAzureAD,arn:aws:iam::**accountnr**:saml-provider/AzureAD"
},
{
"allowedMemberTypes": [
"User"
],
"displayName": "Warmetal_ReadOnlyAccess",
"id": "00000000-0000-0000-0000-000000000002",
"isEnabled": true,
"description": "Warmetal_ReadOnlyAccess_**accountnr**",
"value": "arn:aws:iam::**accountnr**:role/AWSReadOnlyInAzureAD,arn:aws:iam::**accountnr**:saml-provider/AzureAD"
},
{
"allowedMemberTypes": [
"User"
],
"displayName": "msiam_access",
"id": "7dfd756e-8c27-4472-b2b7-38c17fc5de5e",
"isEnabled": true,
"description": "msiam_access",
"value": null
}

Note that the different allowedmembertypes sections are separated by commas (except for the last one)
Also note that you need to add all accounts with their roles to the manifest

Don't forget to click save to save your changes to the manifest.

• Log into the azure portal with the office365 global administrator account we created earlier
• Go to Azure Active Directory → Enterprise Applications → Amazon Web Services (AWS)
• Go to Users and Groups → Add User

We now see an error: “Groups are not available for assignment due to your Active Directory plan level.” To be able to assign groups to Enterprise Applications you need either E5 or Azure AD Premium P2.

• You can still select the individual users and assign the role you want to assign.
• Repeat these steps to assign all the roles to all the users you need.

You can now test by logging into myapps.microsoft.com as the user you assigned the role to in the Enterprise Application. You should see the Amazon Web Services (AWS) listed. Clicking on it should let you choose between the different roles you were assigned so you can log in.

Billing information is by default not available for IAM users. To enable this for a specific role log into your master organization account using your original root credentials:

• Go to My Account
• Scroll down to “IAM User and Role Access to Billing Information” and click edit next to it
• Click Activate IAM Access and click Update

Now the full Access as configured and described above also gives access to the billing dashboard

• https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/aws-multi-accounts-tutorial
• https://aws.amazon.com/blogs/security/enable-federated-api-access-to-your-aws-resources-for-up-to-12-hours-using-iam-roles/