Configuring Single Sign On to AWS Console using Active Directory, ADFS and Web Application Proxy

More articles and how to can be found on my website https://arche-type.com.au.

This is an article detailing the processes required to enable Single Sign On to AWS Console against Active Directory, using Active Directory Federation Services and Web Application Proxy.

I have used a combination of several different articles which are referenced below so I will aggregate them to what worked for our environment - in this case, multiple Groups in AD with different Role Permissions and one AWS account, using a Digicert wildcard signed certificate.

A Web Application Proxy is useful if you would like to be able to have a secure isolated website in a DMZ that can be publicly accessed through an external IP address and firewall and only has access the ADFS on two ports for security purposes.

If you intend on having your website hosted internally only, a Web Application Proxy is not necessary although certainly Best Practice and recommended.

You require a Windows 2012 R2 domain controller in the domain - I used the same server that has the ADFS role.

In your on Premise environment

Importing and Installing the Digicert certificate

Please see this article detailing how to create a CSR, upload it to Digicert, then download, import and then export your certificate for both the ADFS:

https://www.digicert.com/csr-creation-ssl-installation-ad-fs-windows-server-2012-digicert-utility.htm#adfs_ssl_certificate_install

Caveats:

• Most of this article needs be done before the installation of ADFS - The heading titled: Using the AD FS Management Console to Assign the SSL Certificate to the AD FS Service should be done after ADFS has been successfully installed
• The same certificate needs to imported into the Web Application Proxy server by following the process - Run > MMC > Add snap-in > Certificates > Computer Account > Personal > Import

 

 

Installing and Configuring Active Directory Federation Services

https://www.schmarr.com/Blog/Post/12/Installing-Windows-2012-R2-Server-ADFS-Service

The above article no longer goes anywhere but here is a PDF I made before it was removed:

Thanks to https://alanschmarr.wordpress.com/ for the awesome work.

At the page below it is very important to get the right details or you will not be able to establish a trust relationship between the Web Application Proxy and the ADFS service. Federation Service name must be URL to access ADFS / WAP - adfs.company.com for example.

NB> In the Federation Service name dropdown menu below in my case as it was a wildcard certificate it gave you the choice of company.com or *.company.com - you will need to change it to adfs.company.com - i.e. it can be edited.

This article is very helpful - another very important point that I cannot emphasise enough during setup is NOT getting ADFS to set up a Group Managed Service Account at this point of the ADFS Configuration wizard:

Initially I allowed it create one for me, it didn't work and then it took me a lot of time before I fixed it and I wish I could have done it the right way in the first place.

Having Googled the issue a lot it is very common for this to happen. Here is an article I wish I had found straight away that allows you to change the Managed Service Account AND the URL of the ADFS server:

https://social.technet.microsoft.com/wiki/contents/articles/1427.ad-fs-2-0-how-to-configure-the-spn-serviceprincipalname-for-the-service-account.aspx

It is for ADFS 2.0 (Windows 2012 R2 is ADFS 3.0) but it still works so this may be very helpful.

 

Installing and Configuring Web Application Proxy

Although I have covered the certificate installation this is also covered again in this article with the rest of the installation:

https://www.schmarr.com/Blog/Post/13/Installing-Reverse-Proxy-on-Windows-Server-2012-R2-(Web-Application-Proxy)

Caveats:

• Assuming the ADFS server is dc1.company.com with an IP address of 192.168.0.1 and Web Application Proxy Server is wap.company.com with an IP address of 192.168.0.2,
• then in AD DNS you would add an A record of 192.168.0.2 pointing to adfs.company.com (i.e. the Web Application Proxy Server) and on wap.company.com you would add the entry into the hosts file in essence redirecting adfs.company.com to ADFS - 192.168.0.1.
• If you have matching URLs in both WAP and ADFS you should have no problems installing. If you have different names see the link above about reconfiguring SPN / Service Account name.

 

 

On the AWS Console

Creating a SAML Identity Provider

From an internal computer's web browser with access to the ADFS, download the Federation Metadata file from your ADFS server - in this scenario:

https://adfs.company.com/federationmetadata/2007-06/FederationMetadata.xml

Then in your AWS Console > Identity and Access Management > Identity Providers > Create New Provider using the wizard. 

• Provider type is SAML, Provider Name MUST be ADFS if it is not then the regex claim script won't work. Metadata document is the one you just downloaded.
• 
  
• 
  

Create an AWS Role and associate it to the SAML Identity Provider

It is assumed you have created Role Permissions for your Groups - for more information please see:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html

Then in your AWS Console > Identity and Access Management > Roles > Create New Role

• Role name MUST be ADFS-Groupname where Groupname is the name you want to call your Group - if it does not have ADFS- before the group name then the regex claim script won't work.
• Role Type is Role for Identity Provider Access > Grant Web Single Sign-On (WebSSO) access to SAML Providers > Select
• SAML Provider MUST be ADFS
• Make a note of the Account number - it should be a 12 digit code. You will need this for the AD Groups
• Select Policy name to attach - in this case we will be doing ReadOnlyAccess. Select Next Step
• Confirm that your Role name is ADFS-something and your Trusted Entities should be arn:aws:iam::123456789012:saml-provider/ADFS - NB> your account number will be different.
• The account number is unique to AWS worldwide and allows AWS to authenticate you.

 

In your on Premise environment

Create the Group or Groups that will have access to AWS

As an example, let's assume in the last step we created two Roles - one role ADFS-Readonly and one role ADFS-PowerUsers - ADFS-Readonly has only ReadOnly access to AWS and ADFS-PowerUsers has the PowerUsers policy assigned to it.

In Active Directory we will make two groups for the two access levels based on our account number being 123456789012

AWS-123456789012-ADFS-ReadOnly

AWS-123456789012-ADFS-PowerUsers

In it we will place the ReadOnly users in the first group and the PowerUsers in the second Group.

The easiest way to do this if you have existing groups is place an existing group which is the Readonly group in the AWS-123456789012-ADFS-ReadOnly group and place an existing group which is the PowerUsers group in the AWS-123456789012-ADFS-PowerUsers group so you don't have to double up administrative tasks.

Note the Format must be exactly right or it won't work. It MUST start with AWS- followed by your account number- followed by ADFS- and finally the Group name must be the same.

 

Create the relying Party Trusts

Now we have created the Identity provider from ADFS in AWS, the Roles on AWS and the Groups in Active Directory it is time to create the Trust relationship to make it actually work.

Open up ADFS GUI on the ADFS server.

1.Select Trust Relationships > Relying Party Trusts > Right click and Select Add Relying Party Trust Wizard

 

2. In the Add Relying Party Trust Wizard, click Start.

 

3. Check Import data about the relying party published online or on a local network, enter

https://signin.aws.amazon.com/static/saml-metadata.xml, and then click Next.

The metadata XML file is a standard SAML metadata document that describes AWS as a relying party.

4. Set the display name for the relying party and then click Next.

 5. We will ignore the MFA settings for now

6. Choose your authorisation rules. For my scenario, I chose Permit all users to access this relying party. When you’re done, click Next.

 

7. Review your settings and then click Next.

You are now finished.

Add Claim Rules for the Amazon Web Services Relying Party Trusts

Right click on the Amazon Web Services Relying Party Trusts and select "Edit Claim rules" and then Add Rules in the Issuance Transform Rules.

• Chain rule Template is: Send Claims Using a Custom Rule 
• The Claim Rule Name needs to be NameId
• Paste the following into the Custom rule box:

c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]

=> issue(Type = "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["https://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent");

• Press OK

Repeat the whole process but the claim rule name needs to be RoleSessionName and the custom rule should be:

c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]

=> issue(store = "Active Directory", types = ("https://aws.amazon.com/SAML/Attributes/RoleSessionName"), query = ";mail;{0}", param = c.Value);

 

Repeat the whole process but the claim rule name needs to be Get AD Groups and the custom rule should be:

c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]

=> add(store = "Active Directory", types = ("https://temp/variable"), query = ";tokenGroups;{0}", param = c.Value);

 

Repeat the whole process but the claim rule name needs to be Roles and the custom rule should be:

c:[Type == "https://temp/variable", Value =~ "(?i)^AWS-([^d]{12})"]

=> issue(Type = "https://aws.amazon.com/SAML/Attributes/Role", Value = RegExReplace(c.Value, "AWS-([^d]{12})-", "arn:aws:iam::$1:saml-provider/ADFS,arn:aws:iam::$1:role/"));

 

Press OK to close, then restart ADFS service on ADFS server and IIS - iisreset on the command line of the Web Application Proxy and everything should be setup.

 

The last Roles claim rule name allows more than one group to access different Roles in AWS - If you read the section: Create the Group or Groups that will have access to AWS

the Roles claim rule specifies - the Group name must be AWS-12digitaccountcode - (?i)^AWS-([^d]{12})

and this part: arn:aws:iam::$1:saml-provider/ADFS

Is where the previous account number is stated and ADFS HAS to be the name of the identity provider for this to work.

 

Customising the ADFS webpage

Please see the following link to customise the default webpage to access the ADFS SSO home page.

https://technet.microsoft.com/en-us/library/dn280950.aspx

Related articles

https://www.schmarr.com/Blog/Post/12/Installing-Windows-2012-R2-Server-ADFS-Service-

https://mizitechinfo.wordpress.com/2015/01/08/simple-step-install-configure-adfs-in-windows-server-2012-r2/

https://www.digicert.com/csr-creation-ssl-installation-ad-fs-windows-server-2012-digicert-utility.htm#adfs_ssl_certificate_install

https://blogs.aws.amazon.com/security/post/Tx2989L4392V75K/How-to-Set-Up-SSO-to-the-AWS-Management-Console-for-Multiple-Accounts-by-Using-A

https://c7solutions.com/2014/06/changing-ad-fs-3-0-certificates

https://tristanwatkins.com/changing-adfs-url-windows-server-2012-r2/

https://cloudar.be/awsblog/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml/