The 56K.Cloud team is fortunate enough to experience a diverse set of projects. Our goal is to share our knowledge from these projects to the broader tech community. One technology that we see deployed often is Office365 (O365) and Azure Active Directory (Azure AD).
Regardless of the Cloud or Vendor, Azure AD is growing in dominance in the Enterprise space when it comes to Identity and Single Sign-on. Microsoft has made Azure AD ridiculously simple to integrate with SaaS, Public Clouds, or any other application. O365 comes pre-packaged with Azure AD in the backend. Azure AD is already deployed at customers by default, which lowers the barrier of entry to start using advanced Azure AD capabilities like identity or Single Sign-on.
Password managers are rising in popularity as our brains run out of CPU cycles, trying to remember all the usernames and passwords for all the different tools. From an organization perspective, it isn't easy to manage user access to hundreds of tools within a typical organization. Compound this with all the different user management tools adds to a massive overhead for an IT department.
Single Sign-On or SSO is one of the answers to reduce complexity. The Microsoft documentation does a great job highlighting the benefits of using SSO versus no SSO.
With single sign-on, users sign in once with one account to access domain-joined devices, company resources, software as a service (SaaS) applications, and web applications. After signing in, the user can launch applications from the Office 365 portal or the Azure AD MyApps access panel. Administrators can centralize user account management and automatically add or remove user access to applications based on group membership.
Without single sign-on, users must remember application-specific passwords and sign in to each application. IT staff needs to create and update user accounts for each application, such as Office 365, Box, and Salesforce. Users need to remember their passwords, plus spend the time to sign in to each application.
We can use Azure AD to integrate with AWS IAM. The integration enables Azure AD users to login directly to the Amazon AWS console using their Azure AD credentials. If the user is logged into their AzureAD account already, then the sign-on to AWS is seamless without prompting for a new login.
The documentation from Microsoft is quite good about configuring SSO with AWS, but missing why to setup SSO we explained above and the next steps after establishing SSO.
Start the Azure AD configuration using this guide from Microsoft - https://docs.microsoft.com/en-gb/azure/active-directory/saas-apps/amazon-web-service-tutorial
Once you reach the Configure Azure AD SSO section in the documentation we hit a snag. The instructions mention to configure the Basic SAML configuration. Below are replace steps for the Configure Azure AD SSO section.
I've also opened a Pull Request in the Azure AD documentation which has been bouncing around internally at Microsoft. They claim that it works yet I have proven with several different deployments that this error persists.
The steps below will help you remedy the issues discovered in the documentation
These values are not pre-populated as indicated and should be added as follows:
If you have more than one instance of the Amazon Web Service Azure AD Application deployed, you should add a unique identifier at the end of the Identifier and Reply URL's using
#<value> see the example
Another point that is missing if you are deploying an Azure AD SSO application for the first time is the SAML Signing Certificate. You will need to provision a new certificate before being able to download the
Federation Metadata XML
New Certificate. Enter an email address for Certificate notifications.
3. In the SAML Signing Certificate section, find Federation Metadata XML and select Download to download the certificate and save it on your computer.
Using SSO is amazingly simple. First, open apps.office.com.
Next, expand All Apps. Here you will find the newly created Amazon Web Services App. Not sure why they don't default the name to just "AWS," but you can rename if you want.
Click the Amazon Web Services app, and it will execute the SSO process with your current logged in Office365 user. Next, SSO logs you into the console of AWS. Below is a GIF of the workflow.
As a next step, it is best practice to set up several SAML Roles inside of AWS. The SAML roles can and should be granularly defined down to the AWS account and resource level.
Here are some example roles to get started with:
On the Azure AD side, we recommend creating groups for each of the above Roles. The assign users to the group, and they are then automatically assigned to the AWS role. Using groups makes a bit easier to manage large amounts of users.
AzureAD with AWS SSO Setup - https://docs.microsoft.com/en-gb/azure/active-directory/saas-apps/amazon-web-service-tutorial
Azure AD Documentation Pull Request - https://github.com/MicrosoftDocs/azure-docs/pull/56950
What is AzureAD - https://azure.microsoft.com/en-us/services/active-directory/
O365 Apps shortcut - https://apps.office.com
We love Cloud, IoT, Containers, DevOps, and Infrastructure as Code. If you are interested in chatting connect with us on Twitter or drop us an email: info@56K.Cloud. We hope you found this article helpful. If there is anything you would like to contribute or you have questions, please let us know!