Authors: Caio Ribeiro César, Marcio Morales, Irani Siavash, Dean Suzuki (Last Updated: 4/1/20)
Customers who have Azure AD want to allow their users to use the same username and password in Azure AD to login into AWS. They are also interested in using the groups in Azure AD to control what permissions these users have in their AWS accounts.
In this lab, you will walkthrough this configuration and will connect Azure Active Directory to AWS leveraging the AWS Single Sign-On (SSO) service. Once you complete this connection step, users can use their Azure AD username/passwords to login into AWS. Azure AD is the authentication source. AWS SSO is authorization mechanism, which specifies what users can do in your AWS accounts.
AWS Single Sign-On (SSO) is a cloud SSO service that makes it easy to centrally manage SSO access to multiple AWS accounts and business applications. With just a few clicks, you can enable a highly available SSO service without the upfront investment and on-going maintenance costs of operating your own SSO infrastructure. With AWS SSO, you can easily manage SSO access and user permissions to all of your AWS accounts in AWS Organizations centrally.
AWS SSO makes it simple for you to manage SSO across all your AWS accounts, cloud applications, and custom SAML 2.0–based applications without custom scripts or third-party SSO solutions. Use the AWS SSO console to quickly assign which users should have access to the applications that you have authorized from their personalized end-user portal.
In this lab, you will integrate Azure Active Directory as the Identity Provider (IdP) and AWS as the Service Provider (SP).
You will also enable the automatic provisioning of user and groups in Azure AD into AWS SSO. This new automatic provisioning capability leverages the SCIM protocol. This simplifies the configuration by automatically creating the appropriate users and groups from Azure AD into AWS SSO instead of having to manually create and maintain the users and groups in AWS SSO.
For more information about AWS Single Sign-On, please visit our developers guide.
To go through the lab, you need the following:
An existing Azure AD directory with users and groups.
An active Azure AD Premium License for the creation of the Non-Gallery Application.
An AWS account with an AWS IAM user / role with privileges to AWS Single Sign-On.
A region where AWS SSO is available. Please refer to Regional products and Services.
Set up the AWS Organizations service and have All features set to enabled. If you haven’t done this before, we’ll do this in section 1.
Sign in with the AWS Organizations master account credentials before you begin setting up AWS SSO. These credentials are required to enable AWS SSO.
Login to the AWS Console into the AWS master account in the AWS organization. Navigate to AWS Single Sign-On console.
Make sure you are in the correct region by checking on the top right corner in the AWS Console.
If this is the first time you are opening the Single Sign-On service in this region, you’ll be prompted with the following welcome screen. Click on “Enable AWS SSO”.
If you don’t already have AWS Organization setup, you’ll see the following screen prompting you to create the AWS Organization first. Click on “Create AWS organization”.
If you already have an AWS Organization that is setup only for billing consolidation and not with full features, you will receive a warning message. In this case, please delete the existing organization and try to enable the AWS SSO (which will create a new organization) or change the Organization features by clicking on “AWS Organizations console” link, then click on your existing organization, then click on settings on the right and click on “Enable all features”.
The process for enabling AWS SSO will take about 30 seconds. Once it’s completed, you will see the message below. You can now proceed to section 2.
Login to the Azure portal (https://portal.azure.com/).
On the top search bar, search for “Azure Active Directory” as shown below.
Select “Azure Active Directory” and then click on “Enterprise Applications”.
Select the option “New Application”.
Select the option “New Application”, “Non-Gallery Application” and then “Add”. In order to create this application, you need an Azure Premium License. Note that a common mistake in the lab is that participants select the wrong option. Please be sure to select “Non-gallery application.”
Give the application a name (e.g. AWS Single Sign-on)
In the new recently created application, select the option “Single Sign On” and then “SAML” as the single sign on method.
Download Azure AD Federation Metadata XML in the “Download” option and save it as Azure Federation Metadata.xml.
Login to the AWS Console and navigate to AWS Single Sign-On.
Click on “Choose your Identity Source” as shown below:
Currently, the identity source should be configured to AWS SSO. Click on “Change”.
Select “External Identity Provider”.
Select “Download metadata file” and save this file as “*AWS Federation Metadata.xml*”.
* Some users have experienced problems downloading this file using Microsoft Edge as the browser. This works just fine using Chrome, Firefox and Safari.
Still on the same screen, you will see the option to upload a metadata file. This time, we are uploading Azure Federation Metadata.xml to AWS SSO. Then, click “Next: Review”.
Finally, type “CONFIRM” and press Change Identity Source button
Be sure to be logged as the user that was added in both Azure AD and AWS SSO. Select the option “Sign in as current user” and add this user credentials:
*Some users have informed that this authentication fails when their browser already have auth cookies from another IdP. This is default behavior. In order to workaround this matter, use In-Private Browser features.
In this section, you will use the power of the SCIM protocol in order to export users and groups from Azure AD and create them in AWS SSO. To enable this automatic provisioning, some changes will made to the attribute mappings by Azure AD and AWS SSO. Be sure to follow the SCIM protocol pre-requirements for user provisioning, such as having mandatory attributes (example – FirstName and LastName). Objects without mandatory attributes will not be exported to AWS SSO.
You will be prompted with the information below. Save this information into a notepad file safely for further use. Do not share this information with others.
SCIM Endpoint – this is the address Azure AD is going to reach in order to provision new objects.
Access token – this is the OAuth bearer token used by Azure AD in order to have the authorization of creating new objects.
Go back to Azure AD Enterprise Application, select the option “Provisioning”.
Add the information collected previously in AWS SSO. For “Tenant URL” use the SCIM Endpoint and for “Secret Token”, use your “Access Token”. Press Save.
Now go to “Mappings” and select the option “Synchronize Azure Active Directory Users to customappsso”. Remove the synchronism of the attributes mobile and facsimileTelephoneNumber. Change the Source Attribute for mailNickname to objectId. Press Save.
Go back to the Provisioning screen in Azure AD, enable provisioning by switching it on. This will push the initial sync from objects in Azure AD to AWS SSO and enable delta syncs for every 40 minutes.
In AWS SSO, you will see that the users and groups are now provisioned to AWS SSO “Users” and “Groups”: Note, you will also see the Azure AD groups that you specified being provisioned into AWS.
Now that you have enabled the automatic provisioning of users and groups from Azure AD into AWS, the next step is to assign what permissions that you want these users to have within AWS.
As a best practice, you assign these permissions to the groups (versus users). You assign permissions inside AWS using a capability called Permissions Sets.
In the lab, an Azure AD group called Test was synchronized from Azure AD into AWS. The steps in this section assign this group the permissions of Database Administrator.
Open the SSO Console. Select AWS Accounts in the left hand navigation.
You will create a Permission Set for the Database team. Select the Permissions Sets tab.
Select Create a Permission Set
Select Use an existing job function policy and then below that select DatabaseAdministrator. Press Create.
The system will create a Permission Set that grants the permissions for Database Administration. Note that these permissions are IAM policies. You can create your own custom IAM policies if you have scenarios that are not provided by the default policies.
Selecting the AWS organization tab. Select which AWS account that you would like to assign. Press Assign users. Please note that if you had multiple AWS accounts, then you would pick the appropriate AWS account that you want to grant this access.
Click the Groups tab. Pick the Azure AD group that you want to assign the permission set. Note in the lab, we synchronized a group called Test from Azure AD. Press Next: Permission sets.
Select the DatabaseAdministrator permission set that you created earlier. Press Finish.
Click Proceed to AWS accounts.
If you click your AWS account that you just made the assignment, you will be able to see the mappings between the Azure AD users and groups to AWS permission sets that you created.
Next, you will login as a member of the Test Group and check what permissions that you have inside AWS.
To login. Go to Settings and under the User portal area, copy the URL provided and paste it into a new incognito/private browser window.
You will be redirected to the Microsoft sign-in page.
Enter the Azure AD credentials of a user (In the lab, pick someone who is a member of the Test group).
After successfully authenticating, you will be presented with the SSO App Portal screen (see below). Select AWS Account. Select the AWS account that you would like to access. The screen below shows one AWS account, however if there were multiple AWS accounts that the user was granted access to then they would be listed.
Once you select on the AWS Account, then the list of AWS permissions sets will be shown. The screen below shows one permission set. However, you could have assigned the user to multiple permission sets, they would show up under the account. The user could then select which permission set that they would like to use for this session. Below is an example where the logged in user was assigned to three different permission sets.
Once you select the Permission Set items, you will be logged into the AWS account with those permissions. If you do further testing, you will discover that this specific user can create an RDS database Instance, but does not have S3 access to delete a S3 bucket.
You have successfully connected and integrated AWS SSO with Azure AD and tested this setup by logging into AWS Console using an account from your Azure AD. You can cleanup all the resources you deployed in this lab to stop accruing AWS charges.
You can troubleshoot user and group provisioning in both Azure AD and AWS.
Azure AD: inside the “Enterprise App/Provisioning”, there are options called Synchronization Detail and Audit Logs. These will redirect you to the export logs.
One common issue related to SCIM mandatory attributes for exports with the error “SystemForCrossDomainIdentityManagementBadRequest”. This was being caused by the lack of “FirstName” and “LastName”:
Failed to create User ‘joao\@caiocesarribeirohotmail.onmicrosoft.com’ in customappsso; Error: The SCIM endpoint is not fully compatible with the Azure Active Directory SCIM client. Please refer to the Azure Active Directory SCIM provisioning documentation and adapt the SCIM endpoint to be able to process provisioning requests from Azure Active Directory. StatusCode: BadRequest Message: Processing of the HTTP request resulted in an exception. Please see the HTTP response returned by the ‘Response’ property of this exception for details. Web Response: This operation was retried 4 times. It will be retried again after this date: 2019-12-17T12:22:25.5093736Z UTC
AWS: you can use AWS CloudTrail logs in order to grab the import logs from Azure AD to AWS SSO. Depending on how many “CreateUser” errors you are running into, use Athena to query CloudTrail logs:
SELECT count (\*) as TotalEvents, eventname, errorcode, errormessage FROM your_athena_table_name where errorcode is not null and eventname = 'CreateUser' and eventtime \>= '2019-02-19T14:00:00Z' and eventtime \<= '2019-02-19T15:15:00Z' group by eventname, errorcode, errormessage order by TotalEvents desc