AWS Managed Microsoft AD Deep Dive Part 3 – Active Directory Configuration

AWS Managed Microsoft AD Deep Dive  Part 3 – Active Directory Configuration

Welcome back to my series on AWS Managed Microsoft Active Directory (AD).  In my first post I provided an overview of the service.  In the second post I covered the setup of an AWS Managed Microsoft AD directory instance and demoed the seamless domain-join of a Windows EC2 instance.  I’d recommend you reference back to those posts before you jump into this.  I’ll also be referencing my series on Azure Active Directory Domain Serices (AAD DS), so you may want to take a read through that as well with the understanding it was written in February of 2018 and there may be new features in public preview.

For this post I’m going to cover the directory structure, security principals, group policy objects, and permissions which are created when a new instance of the managed service is spun up.  I’ll be using a combination of PowerShell and the Active Directory-related tools from the Remote Server Administrator Tools.  For those of you who like to dig into the weeds, this will be a post for you.  Shall we dive in?

Let’s start with the basics.  Opening the Active Directory Users and Computers (ADUC) Microsoft Management console (MMC) as the “Admin” account I created during setup displays the directory structure.  Notice that there are three organizational units (OU) that have been created by Amazon.

2awsadds1

The AWS Delegated Groups OU contains the groups Amazon has configured that have been granted delegated rights to perform typical administrative activities in the directory.  A number of the activities would have required Domain Admin or Enterprise Admin by default which obviously isn’t an option within a managed service where you want to limit the customer from blowing up AD.  Notice that Amazon has properly scoped each of the groups to allow for potential management from another trusted domain.

2awsadds2.png

The group names speak for themselves but there are a few I want to call out.  The AWS Delegated Administrators group is the most privileged customer group within the service and has been nested into all of the groups except for the AWS Delegated Add Workstations To Domain Users, which makes sense since the AWS Delegated Administrators group has full control over the customer OU as we will see soon.

2awsadds3.png

The AWS Delegated Kerberos Delegation Administrators group allows members to configure account-based Kerberos delegation.  Yes, yes, I know Resource-Based Constrained Delegation is far superior but there may be use cases where the Kerberos library being used doesn’t support it.  Take note that Azure Active Directory Domain Services (AAD DS) doesn’t support account-based Kerberos Constrained Delegation.  This a win for Amazon in regards to flexibility.

Another group which popped out to me was AWS Delegated Sites and Services.  Members of this group allow you to rename the Default-First-Site.  You would do this if you wanted it to match a site within your existing on-premises Windows AD to shave off a few seconds of user authentication by skipping the site discovery process.

The AWS Delegated System Management Administrators grants members full control over the domainFQDN\System\System Management container.  Creation of data in the container is a requirement for applications like Microsoft SCOM and Microsoft SCCM.

There is also the AWS Delegated User Principal Name Suffix Administrators which grants members the ability to create explicit user principal names.  This could pop up as a requirement for something like synchronize to Office 365 where your domain DNS name isn’t publicly routable and you have to go the alternate UPN direction.  Additionally we have the AWS Delegated Enterprise Certificate Authority Administrators which allows for deployment of a Microsoft CA via Active Directory Certificate Services (AD CS) by granting full control over CN=Public Key Services is the Configuration partition.  We’ll see why AD CS is important for AWS Managed Microsoft AD later in the series.  I like the AWS Delegated Deleted Object Lifetime Administrators which grants members the ability to set the lifetime for objects in the Active Directory Recycle Bin.

The next OU we have is the AWS Reserved OU.  As you can imagine, this is Amazon’s support staff’s OU.  Within it we have the built-in Administrator.  Unfortunately Amazon made the same mistake Microsoft did with this account by making it a god account with membership in Domain Admins, Enterprise Admins, and Schema Admins. With the amount of orchestration going into the solution I’d have liked to see those roles either broken up into multiple accounts or no account holding standing membership into such privileged roles via privileged access management system or red forest design.   The AWS Application and Service Delegated Group has a cryptic description (along with typos). I poked around the permissions and see it has write to the ServicePrincipalName attribute of Computer objects within the OU.  Maybe this comes into play with WorkDocs or WorkMail integration?  Lastly we have the AWSAdministrators which has been granted membership into the AWS Delegated Administrators group granting it all the privileges the customer administrator account has.  Best guess is this group is used by Amazon for supporting the customer’s environment.

2awsadds4

The last OU we’ll look at is the customer OU which takes on the NetBIOS name of the domain.  This is where the model for this service is similar to the model for AAD DS in that the customer has full control over an OU(s).  There are two OUs created within the OU named Computers and Users.  Amazon has setup the Computers OU and the User OU as the default locations for newly domain-joined computer objects and new user objects.   The only object that is pre-created in these OUs is the customer Admin account which is stored in the Users OU.  Under this OU you are free to do whatever needs doing.  It’s a similar approach as Microsoft took with AAD DS but contained one OU deep vs allowing for creation of new OUs at the base like in AAD DS.

2awsadds5.png

Quickly looking at Sites and Subnets displays a single default site (which can be renamed as I mentioned earlier).  Amazon has defined the entirety of the available private IP address space to account for any network whether it be on-prem or within a VPC.

2awsadds6.png

As for the domain controllers, both domain controllers are running Windows Server 2012 at the forest and domain functional levels of 2012 R2.

2awsadds7.png

Shifting over group policy, Amazon has made some interesting choices and has taken extra steps to further secure the managed domain controllers.  As you can see from the screenshot below, there four custom group policy objects (GPOs) created by default by Amazon.  Before we get into them, let’s first cover the Default Domain Policy (DDP) and Default Domain Controllers Policy (DDCP) GPO.  If you look at the image below, you’ll notice that while the DDCP exists it isn’t linked to the Domain Controllers OU.  This is an interesting choice, and not one that I would have made, but I’d be very curious as to their reasoning for their decision to remove the link.  Best practice would have been to leave it linked but create additional GPOs would override the settings in it with your more/less restrictive settings.  The additional GPOs would be set with a lower link order which would give them precedence over the DDCP.  At least they’re not modifying default GPOs, so that’s something. 🙂

Next up we have the DDP which is straight out of the box minus one change to the setting Network Security: Force logoff when logon hours expire.  By default this setting disabled and Amazon has enabled it to improve security.

The ServerAdmins GPO at the top of the domain has one setting enabled which adds the AWS Delegated Server Administrators to the BUILTIN\Administrators group on all domain-joined machine.  This setting is worth paying attention because it explains the blue icon next to the AWS Reserved OU.  Inheritance has been blocked on that OU probably to avoid the settings in the ServerAdmin GPO being applied to any Computer objects created within it.  The Default Domain Policy has then been directly linked to the OU.

Next up we have the other GPO linked to the AWS Reserved OU named AWS Reserved Policy:User.  The policy itself has a few User-related settings intended to harden the experience for AWS support staff including turning on screensavers and password protecting them and preventing sharing of files within profiles.  Nothing too crazy.

Moving on to the Domain Controllers OU we see that the two policies linked are AWS Managed Active Directory Policy and TimePolicyPDC.  The TimePolicyPDC GPO simply settings the authoritative the NTP settings on the domain controllers such as configuring the DCs to use Amazon NTP servers.  The AWS Managed Active Directory Policy is an interesting one.  It contains all of the policies you’d expect out of the Default Domain Controllers Policy GPO (which makes sense since it isn’t linked) in addition to a bunch of settings hardening the system.  I compared many of the settings to the STIG for Windows Server 2012 / 2012 R2 Domain Controllers and it very closely matches.  If I had to guess that is what Amazon is working with on a baseline which might make sense since Amazon touts the managed service as PCI and HIPAA compliant with a few minor changes on the customer end for password length/history and account lockout.  We’ll cover how those changes are possible in a few minutes.

Compare this to Microsoft’s AAD DS which is straight up defaults with no ability to further harden.  Now I have no idea if that’s in the roadmap for Microsoft or they’re hardening the system in another manner, but I imagine seeing those GPOs that are enforcing required settings will make your auditors that much happier.  Another +1 for Amazon.

2awsadds8.png

So how would a customer harden a password policy or configure account lockout?  If you recall from my blog on AAD DS, the password policy was a nightmare.  There was a zero character required password length making complexity dictate your length (3 characters woohoo!).  If you’re like me the thought of administrators having the ability to set three character passwords on a service that can be exposed to the Internet via their LDAPS Internet endpoint (Did I mention that is a terrible design choice) you have a recipe for disaster.  There was also no way to setup fine grained password policies to correct this poor design decision.

Amazon has taken a much saner and more security sensitive approach.  Recall from earlier there was a group named AWS Delegated Fine Grained Password Policy Administrators.  Yes folks, in addition to Amazon keeping the Default Domain Policy the out of the box defaults (better than nothing), Amazon also gives you the ability to customize five pre-configured fine grained password policies.  With these policies you can set the password and lockout settings that are required by your organization.  A big +1 for Amazon here.

2awsadds9

That wraps up this post.  As you can see from this entry Amazon has done a stellar job building security into this managed service, allowing some flexibility for the customer to further harden the systems, all the while still being successful in delegating commonly performed administrative activities back to the customer.

In my next post I’ll walk through the process to configure LDAPS for the service.  It’s a bit funky, so it’s worth an entry.  Once LDAPS is up and running, I’ll follow it up by examining the protocols and cipher suites supported by the managed service.

See you next post!

AWS Managed Microsoft AD Deep Dive Part 2 – Setup

AWS Managed Microsoft AD Deep Dive  Part 2 – Setup

Today I’ll continue my deep dive into AWS Managed Microsoft AD.  In the last blog post I provided an overview of the reasons an organization would want to explore a managed service for Windows Active Directory (Windows AD).  In this post I’ll be providing an overview of my lab environment and demoing how to setup an instance of AWS Managed Microsoft AD and seamlessly joining a Windows EC2 instance.

Let’s dive right into it.

Let’s first cover what I’ll be using as a lab.  Here I’ve setup a virtual private cloud (VPC) with default tenancy which is a requirement to use AWS Managed Microsoft AD.  The VPC has four subnets configured within it named intranet1, intranet2, dmz1, and dmz2.  The subnets intranet1/dmz1 and intranet2/dmz2 provide us with our minimum of two availability zones, which is another requirement of the service.  I’ve created a route table that routes traffic destined for IP ranges outside the VPC to an Internet Gateway and applied that route table to both the intranet1 and intranet2 subnets.  This will allow me to RDP to the EC2 instances I create.  Later in the series I’ll configure VPN connectivity with my on-premises lab to demonstrate how the managed AD can be used on-prem.  Below is a simple Visio diagraming the lab.

1awsadds1.png

To create a new instance of AWS Managed Microsoft AD, I’ll be using the AWS Management Console.  After successfully logging in, I navigate to the Services menu and select the Directory Service link under the Security, Identity & Compliance section as seen below.

1awsadds2.png

The Directory Service page then loads which is a launching pad for configuration of the gamut of AWS Directory Services including AWS Cloud Directory, Simple AD, AD Connector, Amazon Cognito, and of course AWS Managed Microsoft AD.  Any directory instance that you’ve created would appear in the listing to the right.  To create a new instance I select the Set up Directory button.

1awsadds3.png

The Set up a directory page loads and I’m presented with the options to create an instance of AWS Managed Microsoft AD, Simple AD, AD Connector, or an Amazon Cognito User Pool.  Before I continue, I’ll provide the quick and dirty on the latter three options.  Simple AD is actually Samba made to emulate some of the capabilities of Windows Active Directory.  The AD Connector acts as a sort of proxy to interact with an existing Windows Active Directory.  I plan on a future blog series on that one.  Amazon Cognito is Amazon’s modern authentication solution (looks great for B2C)  providing Open ID Connect, OAuth 2.0, and SAML services to applications.  That one will warrant a future blog series as well.  For this series we’ll be select the AWS Managed Microsoft AD option and clicking the Next button.

1awsadds4.png

A new page loads where we configure the directory information.  Here I’m given the option to choose between a standard or enterprise offering of the service.  Beyond storage I’ve been unable to find or pull any specifications of the EC2 instances Amazon is managing in the background for the domain controllers.  I have to imagine Enterprise means more than just 16GB of storage and would include additional memory and CPU.  For the purposes of this series, I’ll be selecting Standard Edition.

Next I’ll provide the key configuration details for forest which includes the fully qualified domain name (FQDN) for the forest I want created as well as optionally specifying the NetBIOS name.  The Admin password set here is used for the delegated administrator account Amazon creates for the customer.  Make sure this password is securely stored, because if it’s lost Amazon has no way of recovering it.

1awsadds5.png

After clicking the Next button I’m prompted to select the virtual private cloud (VPC) I want to service deployed to.  The VPC used must include at least two subnets that are in different availability zones.  I’ll be using the intranet1 and intranet2 subnets shown in my lab diagram earlier in the post.

1awsadds6.png

The next page that loads provides the details of the instance that will be provisioned.  Once I’m satisfied the configuration is correct I select the Create Directory button to spin up the service.

1awsadds7.png

Amazon states it takes around 20 minutes or so to spin up the instance, but my experience was more like 30-45 minutes.  The main Directories Services page displays the status of the directory as Creating.  As part of this creation a new Security Group will be created which acts as a firewall for the managed domain controllers.  Unlike some organization that try to put firewalls between domain-join clients and domain controllers, Amazon has included all the necessary flows and saves  you a ton of troubleshooting with packet captures.

1awsadds8

One of the neat features offered with this service is the ability to seamlessly domain-join Windows EC2 instances during creation.  Before that feature can be leveraged an AWS Identity and Access Management (IAM) role needs to setup that has the AmazonEC2RoleforSSM attached to it.  AWS IAM is by far my favorite feature of AWS.  At a very high level, you can think of AWS IAM as being the identity service for the management of AWS resources.  It’s insanely innovative and flexible in its ability to integrate with modern authentication solutions and in how granular you can be in defining rights and permissions to AWS resources.  I could do multiple series just covering the basics (which I plan to do in the future) but to progress this entry let me briefly explain AWS IAM Roles.  Think of an AWS IAM Role as a unique security principal similar to a user but without any credentials. The role is assigned a set of rights and permissions which AWS refers to as a policy.  The role is then assumed by a human (such as federated user) or non-human (such as EC2 instance) granting the entity the rights and permissions defined in the policy attached to the role.  In this scenario the EC2 instance I create will be assuming the AmazonEC2RoleforSSM.  This role grants a number of rights and permissions within AWS’s Simple System Manager (SSM), which for your Microsoft-heavy users is a scaled down SCCM.  It requires this role to orchestrate the domain-join upon instance creation.

To create the role I’ll open back up the Services menu and select IAM from the Security, Identity & Compliance menu.

1awsadds9.png

The IAM dashboard will load which provides details as to the number of users, groups, policies, roles, and identity providers I’ve created.  From the left-hand menu I’ll select the Roles link.

1awsadds10.png

The Role page then loads and displays the Roles configured for my AWS account. Here I’ll select the Create Role button to start the role creation process.

1awsadds11.png

The Create Role page loads and prompts me to select a trusted entity type.  I’ll be using this role for EC2 instances so I’ll select the AWS service option and chose EC2 as the service that will use the role.  Once both options are selects I select the Next: Permission button.

1awsadds12.png

Next up we need to assign a policy to the role.  We can either create a new policy or select an existing one.  For seamless domain-join with AWS Managed Microsoft AD, EC2 instances must use the AmazonEC2forSSM policy.  After selecting the policy I select the Next: Review button.

1awsadds13.png

On the last page I’ll name the role, set a description, and select the Create role button. The role is then provisioned and available for use.

1awsadds14.png

Navigating back to the Directory Services page, I can see that the geekintheweeds.com instance is up and running. This means we can now create some EC2 instances and seamlessly join them to the domain.

1awsadds15.png

The EC2 instance creation is documented endless on the web, so I won’t waste time walking through it beyond showing the screenshot below which displays the options for seamless domain-join. The EC2 instance created will be named SERVER01.

1awsadds16.png

After a few minutes the instance is ready to go. I start the Remote Desktop on my client machine and attempt a connection to the EC2 instance using the Admin user and credentials I set for the AD domain.

1awsadds17.png

Low and behold I’m logged into the EC2 instance using my domain credentials!

1awsadds18.png

As you can see setup of the service and EC2 instances is extremely simple and could made that much more simple if we tossed out the GUI and leveraged cloud formation templates to seamlessly spin up entire environments at a push of a button.

We covered a lot of content in this entry so I’ll close out here.  In the next entry I’ll examine the directory structure Amazon creates including the security principals and key permissions.

See you next post!

 

AWS Managed Microsoft AD Deep Dive Part 1 – Overview

AWS Managed Microsoft AD Deep Dive  Part 1 – Overview

Welcome back my fellow geeks!

Earlier this year I did a deep dive into Microsoft’s managed Active Directory service, Microsoft Azure Active Directory Domain Services (AAD DS).  I found was a service in its infancy and showing some promise, but very far from being an enterprise-ready service.  I thought it would be fun to look at Amazon’s (which I’ll refer to as Amazon Web Services (AWS) for the rest of the entries in this series) take on a managed Microsoft Active Directory (or as Microsoft is referring to it these days Windows Active Directory).

Unless your organization popped up in the last year or two and went the whole serverless route you are still managing operating systems that require centralized authentication, authorization, and configuration management.  You also more than likely have a ton of legacy/classic on-premises applications that require legacy protocols such as Kerberos and LDAP.  Your organization is likely using Windows Active Directory (Windows AD) to provide these capabilities along with Windows AD’s basic domain name system (DNS) service and centralized identity data store.

It’s unrealistic to assume you’re going to shed all those legacy applications prior to beginning your journey into the public cloud.  I mean heck, shedding the ownership of data centers alone can be a huge cost driver.  Organizations are then faced with the challenge of how to do Windows AD in the public cloud.  Is it best to extend an existing on-premises forest into the public cloud?  What about creating a resource forest with a trust?  Or maybe even a completely new forest with no trust?  Each of these options have positives and negatives that need to be evaluated against organizational requirements across the business, technical, and legal arenas.

Whatever choice you make, it means additional infrastructure in the form of more domain controllers.  Anyone who has managed Windows AD in an enterprise knows how much overhead managing domain controllers can introduce.  Let me clarify that by managing Windows AD, it does not mean opening Active Directory Users and Computers (ADUC) and creating user accounts and groups.  I’m talking about examining performance monitor AD counters and LDAP Debug logs to properly size domain controllers, configuring security controls to comply with PCI and HIPAA requirements or aligning with DISA STIGS, managing updates and patches, and troubleshooting the challenges those bring which requires extensive knowledge of how Active Directory works.  In this day an age IT staff need to be less focused on overhead such as this and more focused on working closely with its business units to drive and execute upon business strategy.  That folks is where managed services shine.

AWS offers an extensive catalog of managed services and Windows AD is no exception.  Included within the AWS Directory Services offerings there is a powerful offering named Amazon Web Services Directory Service for Microsoft Active Directory, or more succinctly AWS Managed Microsoft AD.  It provides all the wonderful capabilities of Windows AD without all of the operational overhead.  An interesting fact is that the service has been around since December 2015 in comparison to Microsoft’s AAD DS which only went into public preview at in 3rd Q 2017.  This head start has done AWS a lot of favors and in this engineer’s opinion, has established AWS Managed Microsoft AD as the superior managed Windows AD service over Microsoft’s AAD DS.  We’ll see why as the series progresses.

Over the course of this series I’ll be performing a similar analysis as I did in my series on Microsoft AAD DS.  I’ll also be examining the many additional capabilities AWS Managed Microsoft AD provides and demoing some of them in action.  My goal is that by the end of this series you understand the technical limitations that come with the significant business benefits of leveraging a managed service.

See you next post!

AWS and Microsoft’s Cloud App Security

AWS and Microsoft’s Cloud App Security

It seems like it’s become a weekly occurrence to have sensitive data exposed due to poorly managed cloud services.  Due to Amazon’s large market share with Amazon Web Services (AWS) many of these instances involve publicly-accessible Simple Storage Service (S3) buckets.  In the last six months alone there were highly publicized incidents with FedEx and Verizon.  While the cloud can be empowering, it can also be very dangerous when there is a lack of governance, visibility, and acceptance of the different security mindset cloud requires.

Organizations that have been in operation for many years have grown to be very reliant on the network boundary acting as the primary security boundary.  As these organizations begin to move to a software defined data center model this traditional boundary quickly becomes less and less effective.  Unfortunately for these organizations this, in combination with a lack of sufficient understanding of cloud, gives rise to mistakes like sensitive data being exposed.

One way in which an organization can protect itself is to leverage technologies such as cloud access security brokers (cloud security gateways if you’re Forrester reader) to help monitor and control data as it travels between on-premises and the cloud.  If you’re unfamiliar with the concept of a CASB, I covered it in a previous entry and included a link to an article which provides a great overview.

Microsoft has its own CASB offering called Microsoft Cloud App Security (CAS).  It’s offered as part of Microsoft’s Enterprise Mobility and Security (EMS) E5/A5 subscription.  Over the past several months multiple connectors to third party software-as-a-service (SaaS) providers have been introduced, including one for AWS.  The capabilities with AWS are limited at this point to pulling administrative logs and user information but it shows promise.

As per usual, Microsoft provides an integration guide which is detailed in button pushing, but not so much in concepts and technical details as to what is happening behind the scenes.  Since the Azure AD and AWS blog series has attracted so many views, I thought it would be fun and informative to do an entry for how Cloud App Security can be used with AWS.

I’m not in the habit of re-creating documentation so I’ll be referencing the Microsoft integration guide throughout the post.

The first thing that needs doing is the creation of a security principal in AWS Identity and Access Management (AWS IAM) that will be used by your tenant’s instance of CAS to connect to resources in your AWS account.   The first four steps are straightforward but step 5 could a bit of an explanation.

awscas1.pngHere we’re creating a custom IAM policy for the security principal granting it a number of permissions within the AWS account.  IAM policies are sets of permissions which are attached to a human or non-human identity or AWS resource and are evaluated when a call to the resource is made.  In the traditional on-premises world, you can think of it as something somewhat similar to a set of NTFS file permissions.  When the policy pictured above is created the security principal is granted a set of permissions across all instances of CloudTrail, CloudWatch, and IAM within the account.

If you’re unfamiliar with AWS services, CloudTrail is a service which audits the API calls made to AWS resources.  Some of the information included in the events include the action taken, the resource the action was taken upon, the security principal that made the action, the date time, and source IP address of the security principal who performed the action.  The CloudWatch service allows for monitoring of metrics and optionally triggering events based upon metrics reaching specific thresholds.  The IAM service is AWS’s identity store for the cloud management layer.

Now that we have a basic understanding of the services, let’s look at the permissions Microsoft is requiring for CAS to do its thing.  The CloudTrail permissions of DescribeTrails, LookupEvents, and GetTrailStatus allow CAS to query for all trails enabled on an AWS account (CloudTrail is enabled by default on all AWS resources), lookup events in a trail, and get information about the trail such as start and stop logging times.  The CloudWatch permissions of Describe* and Get* are fancy ways of asking for  READ permissions on CloudWatch resources.  These permissions include describe-alarms-history, describe alarms, describe-alarms-for-metric, get-dashboard, and get-metric-statistics.  The IAM permissions are similar to what’s being asked for in CloudWatch, basically asking for full read.

Step number 11 instructs us to create a new CloudTrail trail.  AWS by default audits all events across all resources and stores them for 90 days.  Trails enable you to direct events captured by CloudTrail to an S3 bucket for archiving, analysis, and responding to events.

awscas2.png

The trail created is consumed by CAS to read the information captured via CloudTrail.  The permissions requested above become a bit more clear now that we see CAS is requesting read access for all trails across an account for monitoring goodness.  I’m unclear as to why CAS is asking for read for CloudWatch alarms unless it has some integration in that it monitors and reports on alarms configured for an AWS account.  The IAM read permissions are required so it can pull user  information it can use for the User Groups capability.

After the security principal is created and a sample trail is setup, it’s time to configure the connector for CAS.  Steps 12 – 15 walk through the process.  When it is complete AWS now shows as a connected app.

awscas3.png

After a few hours data will start to trickle in from AWS.  Navigating to the Users and Accounts section shows all of the accounts found in the IAM instance for my AWS account.  Envision this as your one stop shop for identifying all of the user accounts across your many cloud services.  A single pane of glass to identity across SaaS.

awscas4.png

On the Activity Log I see all of the API activities captured by CloudTrail.  If I wanted to capture more audit information, I can enable CloudTrail for the relevant resource and point it to the trail I configured for CAS.  I haven’t tested what CAS does with multiple trails, but based upon the permissions we configured when we setup the security principal, it should technically be able to pull from any trail we create.

awscas7.png

Since the CAS and AWS integration is limited to pulling logging information, lets walk through an example of how we could use the data.  Take an example where an organization has a policy that the AWS root user should not be used for administrative activities due to the level of access the account gets by default.  The organization creates AWS IAM users accounts for each of its administrators who administer the cloud management layer.  In this scenario we can create a new policy in CAS to detect and alert on instances where the AWS root user is used.

First we navigate to the Policies page under the Control section of CAS.

awscas6.png

On the Policies page we’re going to choose to create a new policy settings in the image below.  We’ll designate this as a high severity privileged account alert.  We’re interested in knowing anytime the account is used so we choose the Single Activity option.

awscas7

We’ll pretend we were smart users of CAS and let it collect data for a few weeks to get a sampling of the types of events which are captured and to give us some data to analyze.  We also went the extra mile and leveraged the ability of CAS to pull in user information from AWS IAM such that we can choose the appropriate users from the drop-down menus.

Since this is a demo and my AWS lab has a lot of activity by the root account we’re going to limit our alerts to the creation of new AWS IAM users.  To do that we set our filter to look for an Activity type equal to Create user.  Our main goal is to capture usage of the root account so we add another filter rule that searches for a User with the name equal to aws root user where it is the actor in an event.

awscas8.png

Finally we configure the alert to send an email to the administrator when the event occurs.  The governance capabilities don’t come into play in this use case.

awscas9

Next we jump back to AWS and create a new AWS IAM user named testuser1.  A few minutes after the user is created we see the event appearing in CloudTrail.

awscas10

After a few minutes, CAS generates and alert and I receive an email seen in the image below.   I’m given information as to the activity, the app, the date and time it was performed, and the client’s IP address.

awscas11.png

If I bounce back to CAS I see one new Alert.  Navigating to the alert I’m able to dismiss it, adjust the policy that generated it, or resolve it and add some notes to the resolution.

awscas12.png

I also have the option to dig deeper to see some of the patterns of the user’s behavior or the pattern of the behaviors from a specific IP address as seen below.

awscas13.png

awscas14.png

All this information is great, but what can we do with it?  In this example, it delivers visibility into the administrative activities occurring at the AWS cloud management layer by centralizing the data into a single repository which I can then send other data such as O365 activity, Box, SalesForces, etc.  By centralizing the information I can begin doing some behavioral analytics to develop standard patterns of behavior of my user base.  Understanding standard behavior patterns is key to being ahead of the bad guys whether they be insiders or outsiders.  I can search for deviations from standard patterns to detect a threat before it becomes too widespread.  I can also be proactive about putting alerts and enforcement (available for other app connectors in CAS but not AWS at this time) to stop the behavior before the threat is realized.  If I supplemented this data with log information from my on-premises proxy via Cloud App Discovery, I get an even larger sampling improving the quality of the data as well as giving me insight into shadow IT.  Pulling those “shadow” cloud solutions into the light allow me to ensure the usage of the services complies with organizational policies and opens up the opportunity of reducing costs by eliminating redundant services.

Microsoft categorizes the capabilities that help realize these benefits as the Discover and Investigate capabilities of CAS. The solution also offers a growing number of enforcement mechanisms (Microsoft categorized these enforcement mechanisms as Control) which add a whole other layer of power behind the solution.  Due to the limited integration with AWS I can’t demo those capabilities with this post.  I’ll cover those in a future post.

I hope this post helped you better understand the value that CASB/CSGs like Microsoft’s Cloud App Security can bring to the table.  While the product is still very new and a bit sparse on support with 3rd party applications, the list is growing every day. I predict the capabilities provided by technology such as Microsoft’s Cloud App Security will be as standard to IT as a firewall in the years to come.  If you’re already in Office 365 you should be ensuring you integrate these capabilities into your arsenal to understand the value they can bring to your business.

Thanks and have a wonderful week!

Integrating Azure AD and AWS – Part 4

Integrating Azure AD and AWS – Part 4

We’ve reached the end of the road for my series on integrating Azure Active Directory (Azure AD) and Amazon Web Services (AWS) for single sign-on and role management. In part 1 I walked through the many reasons the integration is worth looking at if your organization is consuming both clouds. In part 2 I described the lab I used to for this series, described the different way application identities (service accounts for those of you in the Microsoft space) are handled in Active Directory Domain Services versus Azure AD, and walked through what a typical application identity looks like in Azure AD. In part 3 I walked through a portion of the configuration steps, did a deep dive into the Azure AD and AWS federation metadata, examined a SAML assertion, and configured the AWS end of the federated trust through the AWS Management Console. This included creation of an identity provider representing the Azure AD tenant and creation of a new IAM role for users within the Azure AD tenant to assert.

In this final post I’ll cover the remainder of the configuration, describe the “provisioning” capabilities of Azure AD in this integration, and pointing out some of the issues with the recommended steps in the Microsoft tutorial.

Before I continue with the configuration, let me cover what I’ve done so far.

  • Part 2
    • Added the AWS application from the Azure AD Application Gallery through the Azure Portal.
  • Part 3
    • Assigned an Azure Active Directory user to the application through the Azure Portal.
    • Configured the Azure AD to pass the Role and RoleSessionName claims through the Azure Portal.
    • Created the SAML identity provider representing Azure AD in the AWS Management Console.
    • Created an AWS IAM Role and associated it with the identity provider representing Azure AD in the AWS Management Console.

At this point JoG users can assert their identity to their heart’s content but we don’t have a list of what AWS IAM roles stored in Azure AD for our users to assert.  So how do we assert a role from Azure AD if the listing of the roles exists in AWS?  The wonderful concept of application programmatic interfaces (APIs) swoops in and saves the day.  Don’t get me wrong, if you hate yourself you can certainly provision them manually by modifying the application manifest file every time a new role is created or deleted.  However, there is an easier route of having Azure AD pick up those roles directly from AWS on an automated schedule.  How does this work?  Well nothing works better than demonstrating how the roles can be queried from the AWS API.

The AWS SDK for .NET makes querying the API incredibly easy.  We’re not stuck worrying about assembling the request and signing it.  As you can see below the script is six lines of code in PowerShell.

Script.png

The result is a listing of the roles configured in AWS which includes the AzureADEC2Admins role I created earlier.  This example demonstrates the power a robust API brings to the table when integrating cloud services.

2

When Microsoft speaks of provisioning in regards to the AWS integration, they are talking about provisioning the roles defined in AWS to the the application manifest file in Azure AD.  This provides us with the ability to assign the roles from within the Azure Portal as we’ll see later.  This differs from many of the Azure AD integrations I’ve observed in the past where it will provision a record for the user into the software as a service (SaaS) offering.  Below is a simple diagram of the provisioning process.3

To do support provisioning we need to navigate to the AWS Management Console, open the Services Menu, and select IAM.  We then select Users and hit the Add User button.  I named the user AzureAD, gave it programmatic access type, and attached the IAMReadOnlyAccess policy.  AWS then presented me with the access key ID and secret access key I’ll need to provide to Azure AD.  Yes, we are going to follow security best practices and provide the account with the minimum rights and permissions it needs to provide the functionality.  The Microsoft tutorial instructs you to generate the credentials under the context of the AWS administrator effectively giving the application full rights to the AWS account.  No Microsoft, just no.

I next bounce back to the Azure portal and to the AWS application configuration.  From here I select the Provisioning option, switch the drop-down box to Automatic, and plug the access key ID into the clientsecret field and the secret access key into the secret token field.  A quick test connection shows success and I then save the configuration.  Note that you must first save the configuration before you can turn on the synchronization.

4

After the screen refreshes I move down to the Settings section and turn the Provisioning Status to On and set the Scope to Sync only assigned users and groups (kind of a moot point for this, but oh well).  I then Save the configuration once again and give it about 10 minutes to pull down the roles.

I then navigate back to the Users and Groups section and edit the Rick Sanchez assignment.  Hitting the role option now shows me the AzureADEC2Admins role I configured in AWS IAM.


5.png

Let’s take another look at the service principle representing the AWS application in PowerShell.  Using the Azure AD PowerShell cmdlets I referenced in entry 2 we connect to Azure AD and run the cmdlet Get-AzureADServicePrincipal which when run shows the manifest has been updated to include the newly synchronized application role.

6

We’ve configured the SAML trust on both ends, defined the necessary attributes, setup synchronization, and assigned Rick Sanchez an IAM role. In a moment we’ll demonstrate all of the pieces coming together.

Before I wrap it up, I want to quickly mention a few issues I ran into with this integration that seemed to resolve themselves without any intervention.

  1. Up to a few nights ago I was unable to get the Provisioning piece working.  I’m not putting it past user error (this is me we’re talking about) but I tried numerous times and failed but was successful a few nights ago.  I also noticed from some recent comments in the Microsoft tutorial people complaining of similar errors.  Maybe something broke for a bit?
  2. The value of the audience attribute in the audienceRestriction section of the SAML assertion generated by Azure AD doesn’t match the identifier within the AWS federation metadata.  Azure AD inserts some garbage looking audience value by default which was causing the assertions to be rejected by AWS.  After setting the identifier to the value of urn:amazon:webservices as referenced in the AWS federation metadata the assertion was consumed without issue.  I saw similar complaints in the Microsoft tutorial so I’m fairly confident this wasn’t just my issue.The story gets a bit stranger.  I wanted to demonstrate the behavior for this series by removing the identifier I had previously added.  Oddly enough the assertion was consumed without issue by AWS.  I verified using Fiddler that the audience value was populated with that garbage entry.  Either way, I would err on the side of caution and would recommend populating the identifier with the entry referenced in the AWS metadata as seen below.7.png

The last thing I want to point out is the Microsoft tutorial states that you are required to create the users in AWS prior to asserting their identity.  This is inaccurate as AWS does not require a user record to be pre-created in AWS.  This is different from a majority (if not all) of the SaaS integrations I’ve done in the past so this surprised me as well.  Either way, it’s not required which is a nice benefit if you’ve ever had to deal with the challenging of managing the identify lifecycle across cloud offerings.

Let’s wrap up this series by having Rick Sanchez log into the AWS Management Console and shutdown an EC2 instance.  Here I have logged into the Windows 10 machine named CLIENT running in Azure.  We navigate to https://myapps.microsoft.com and log into Azure AD as Rick Sanchez.  We then hit the Amazon Web Services icon and are seamless logged into the AWS Management Console.

8.png

Examining the assertion in Fiddler shows  the Role and RoleSessionName claims in the assertion.

9.png

Navigating to the EC2 Dashboard displays the instance I prepared earlier using my primary account.  Rick has full rights over administration of the instance for activities such as starting and starting the instance.  After successfully terminating the instance I log into the AWS Management Console as my primary AWS account and go to CloudTrail and see the log entries recording the activities of Rick Sanchez.

10.png

With that let’s cover some key pieces of information to draw from the series.

  1. The Azure AD and AWS integration differs from most SaaS integrations I’ve done when it comes to user provisioning.  Most of the time a user record must exist prior to the user authenticating.  There are a growing number of SaaS providers provisioning upon successful authentication as provisioning challenges grow to further consumption of cloud services, but they are still few and far between.  AWS does a solid job with eliminating the pain of pre-provisioning users.
  2. The concept of associating roles with specific identity providers is really neat on Amazon’s part.  It allows the customer to manage permissions and associate those permissions with roles in AWS, but delegate the right on a per identity provider basis to assert a specific set of roles.
  3. Microsoft’s definition of provisioning in this integration is pulling a listing of roles from AWS and making them configurable in the Azure Portal.
  4. The AWS API is solid and quite easy to leverage when using the AWS SDKs. I would like to see AWS switch from what seems to be proprietary method of application access to OAuth to become more aligned with the rest of the industry.
  5. Don’t trust vendors to make everything point and click. Take the time to understand what’s going on in the background. In a SAML integration such as this, a quick review of the metadata can save you a lot of headaches when troubleshooting issues.

I learned a ton about AWS over these past few weeks and also got some good deep dive time into Azure AD which I haven’t had time for in a while.  Hopefully you found this series valuable and learned a thing or two yourself.

In my next series I plan on writing a simple application to consume the Cognito service offered by AWS.  For those of you more familiar with the Microsoft side of the fence, it’s similar to Azure AD B2C but with some unique features Microsoft hasn’t put in place yet making a great option to solve those B2C identity woes.

Thanks and have a wonderful holiday!

Integrating Azure AD and AWS – Part 3

Welcome!  This entry continues my series in the integration of Azure AD and AWS.  In my first entry I covered what the advantages of the integration are.  In the second entry I walked through my lab configuration and went over what happens behind the scenes when an application is added to Azure AD from the application gallery.  In this post I’m going to walk through some of the configuration we need to do in both Azure AD and AWS.  I’ll also be breaking open the Azure AD and AWS metadata and examining the default assertion sent by Microsoft out of the box.

In my last entry I  added the AWS application to my Azure AD tenant from the Azure AD Application Gallery.  The application is now shown as added in the All Applications view of the Azure Active Directory blade for my tenant.

pic1.png

After selecting AWS from the listing of applications I’m presented with a variety of configuration options.  Starting with Properties we’re provided with some general information and configuration options.  We need to ensure that the application is enabled for users to sign-in and that it’s visible to users so we can select it from the access panel later on.  Notice also that that I’m configuring the application to require the user be assigned to the application.pic2

On the Users and groups page I’ve assigned Rick Sanchez to the application to allow the account access and display it on the access panel.

pic3

After waiting about 10 minutes (there is a delay in the time it takes for the application to appear in the application panel) I log into the Access Panel as Rick Sanchez and we can see that the AWS app has been added for Rick Sanchez.

pic4

Back to the properties page of the AWS application, my next stop is the Single sign-on page. Here I drop down the Single Sign-on Mode drop box and select SAML-based Sign-on option. Changing the mode to SAML-based Sign-on exposes a ton of options. The first option that caught my eye was the Amazon Web Services (AWS) Domain and URLs. Take notice of the note that says Amazon Web Services (AWS) is pre-integrated with Azure AD and requires no mandatory URL settings. Yeah, not exactly true as we progress through this series.

pic5.png

Further down we see the section that allows us to configure the unique user identifier and additional attributes.   By default Microsoft includes the name, givenName, surName, and emailAddress claims.  I’ll need to make some changes there to pass the claims Amazon requires, but let’s hold off on that for now.

pic6.png

Next up a copy of the Azure AD metadata (IdP metadata) is provided for download.  Additionally some advanced options are available which provide the capability to sign the SAML response, assertion, or both as well as switching the hash algorithm between SHA1 and SHA256.

pic7.png

Now like any nerd, I want to poke around the IdP metadata and see what the certificate Azure AD is using to sign looks like.  Opening up the metadata in a web browser parses the XML and makes the format look pretty.  From there I grab the contents X509Certificate tag (the base-64 encoded public-key certificate), dump it to Notepad, and renam it with a file extension of cer.  Low and behold, what do we see but a self-signed certificate.  This is a case where I can see the logic that the operational overhead is far greater than the potential security risk.  I mean really, does anyone want to deal with the challenge of hundreds of thousands of customers not understanding the basics of public key infrastructure and worrying about revocation, trust chains, and the like?  You get a pass Microsoft… This time anyway.

pic8.png

Before I proceed with the next step in the configuration, let’s take a look at what the assertion looks like without any of the necessary configuration.  For this I’ll use Fiddler to act as a man-in-the-middle between the client and the web.  In session 6 of the screenshot below we see that the SAML response was returned to the web browser from Azure.

pic9.png

Next up we extract that information with the Text Wizard, base-64 decode it, copy it to Notepad, save it as an XML file, and open it with IE.  The attributes containing values of interest are as follows:

  • Destination – The destination is the service provider assertion consumer URI

pic10.png

  • NameID – This is the unique identifier of the used by the service provider to identify the user accessing the service

pic11.png

  • Recipient– The recipient attribute references the service the assertion is intended for.  Oasis security best practices for SAML require the service provider to verify this attribute match the URI for the service provider assertion consumer URI

pic12.png

  • Audience – The audience attribute in the audienceRestriction section mitigates the threat of the assertion being stolen and used to impersonate a user.  Oasis security best practices require the service provider to verify this when the assertion is received to ensure it is recognizes the identifier.  The way in which this is accomplished is the value in the audience attribute is checked against the service provider EntityID attribute.

pic13.png

Additionally we have some interesting claims including tenantid, objectidentifier of the user object in Azure AD, name, surname, givenname, displayname, identityprovider, and authnmethosreferences.  I don’t think any of these need further explanation.

pic14.png

Let’s now take a look at the AWS (service provider in SAML terms) metadata.  The AWS metadata is available for download from here.  After it’s downloaded it can be opened with IE.

pic15.png

The fields of interest in this set of metadata is:

  • EntityID – The entityID is the unique identifier AWS will provide in its authentication requests.  Let’s note the value of urn:amazon:webservices for later as it will come in handy due to some issues with Microsoft’s default settings.

pic16

  • NameIDFormat – This tells me both transient and persistent are accepted.  I won’t go into details on Name ID format, you can review that for yourself in the Oasis standard.  Suffice to say the Name ID format required by the service provider can throw some wrenches into integrations when using a more basic security token service (STS) like AD FS.

pic17

  • AssertionConsumerService – This is where our browser will post back the SAML assertion after a successful authentication.  Note the URI in the location field.

pic18.png

  • RequestedAttributes – This provides us with a listing of all the attributes AWS will accept in an assertion.  Note that the only two required attributes are Role and RoleSessionName.

We’ve added the AWS application to Azure AD, granted a user access to the application, and have started the SAML setup within Azure AD (Identity Provider).  Let’s continue that setup by configuring which attributes Azure AD will include in the assertions delivered to AWS.  From review of the AWS metadata we know that we need to  send claims of Role and RoleSessionName.  The RoleE will match to an an AWS IAM Role handling authorization of what we can do within AWS and the RoleSessionName provides a unique identifier for the user asserting the entitlement.

Back in the Azure AD Portal I’m going to click the option to View and edit all other user attributes.  The exposes the attributes Microsoft sends by default.  These include givenName, suName, emailAddress, and name.  Since the AWS metadata only requires RoleSessionName and Role, I’m going to delete the other attributes.  No sense in exposing additional information that isn’t needed!

pic19.png

After the extra attributes are deleted I create the two required attributes as seen in the screenshot below.

pic20.png

I’m now going to bounce over to the AWS Management Console.  After logging in I navigate to the Services menu and choose IAM.

pic21.png

On the IAM menu I choose the Identity providers menu item and hit the Create Provider button.

pic22.png

On the next screen I’m required to configure the identity provider settings.  I choose SAML from the drop-down box enter a provider name of MAAD and upload the IdP metadata I downloaded from Azure AD referenced earlier in the blog entry and hit the Next Step button.

pic23.png

On the next page I verify the provider name and the type of identity provider and hit the Create button.  Once that is complete I see the new entry listed in identity providers list.  Easy right?

pic24.png

We have an identity provider, but that identity provider needs some IAM roles to be associated with the identity provider that my fictional users can assert.  For that I go to the Roles section and hit the Create Role button.

pic25.png

On the next screen I select the SAML button as the type of trusted entity since the role is going to be asserted via the SAML trust with Azure AD.  Here I select the MAAD provider and choose the option to allow the users to access both the AWS Management Console and the API and then hit the Next: Permissions button.

pic26.png

As I referenced in my first entry to this series, the role I’m going to create is going to be capable of managing all EC2 instances.  For that I choose the AmazonEC2FullAccess policy template and then hit the Next:Review button.

pic267.png

On the last screen I name the new role AzureADEC2Admins, write a short description, and hit the Create Role button.

pic28.png

The new role is created and can be seen associated to the identity provider representing the trust between AWS and Azure AD.

pic29.png

Let’s sum up what we did for this entry.  We examined the key settings Microsoft exposes for configuration with the AWS integration.  We examined the Azure AD (IdP) and AWS (SP) metadata to understand which settings are important to this integration and what those settings do.  We examined an assertion generated out of Azure AD prior to any of the necessary customization being completed to understand what a canned assertion looks like.  Finally, we completed a majority of the tasks we need to complete on the AWS side to create the SAML trust on the AWS end and to create a role JoG users can asserts.  Are your eyes bleeding yet?

In my last post in this series I’ll walk through the rest of the configuration needed on the Azure AD end.  This will include going over some of the mistakes the Microsoft tutorial makes as well as covering configuration of Azure AD’s provisioning integration as to what it means and how we can effectively configure it.  Finally, we’ll put all the pieces of the puzzle together, assert our identity, and review logs at AWS to see what they look like when a federated user performs actions in AWS.

The journey continues in my fourth entry.

Integrating Azure AD and AWS – Part 2

Today I will continue the journey into the integration between Azure AD and Amazon Web Services.  In my first entry I covered the reasons why you’d want to integrate Azure AD with AWS and provided a high-level overview of how the solution works.  The remaining entries in this series will cover the steps involved in completing the integration including deep dives into the inner workings of the solution.

Let me start out by talking about the testing environment I’ll be using for this series.

lab.png

The environment includes three virtual machines (VMs) running on Windows Server 2016 Hyper V on a server at my house.  The virtual machines consists three servers running Windows Server 2016 with one server acting as a domain controller for the journeyofthegeek.local Active Directory (AD) forest, another server running Active Directory Federation Services (AD FS) and Azure AD Connect (AADC), and the third server running MS SQL Server and IIS.  The IIS instance hosts a .NET sample federated application published by Microsoft.

In Microsoft Azure I have a single Vnet configured for connectivity to my on-premises lab through a site-to-site IPSec virtual private network (VPN) I’ve setup with pfSense.  Within the Vnet exists a single VM running Windows 10 that is domain-joined to the journeyofthegeek.local AD domain.  The Azure AD tenant providing the identity backend for the Microsoft Azure subscription is synchronized with the journeyofthegeek.local AD domain using Azure AD Connect and is associated with the domain journeyofthegeek.com.  Authentication to the Azure AD tenant is federated using my instance of AD FS.  I’m not synchronizing passwords and am using an alternate login ID with the user principal name being synchronized to Azure AD being stored in the AD attribute msDS-CloudExtensionAttribute1.  The reason I’m still configured to use an alternate login ID was due to some testing I needed to do for a previous project.

I created a single test user in the journeyofthegeek.local Active Directory domain named Rick Sanchez with a user principal name (UPN) of rick.sanchez@journeyofthegeeklocal and msDS-CloudExtensionAttribute1 of  rick.sanchez@journeyofthegeek.com.  The only attribute to note that the user has populated is the mail attribute which has the value of rick.sanchez@journeyofthegeek.com.  The user is being synchronized to Azure AD via the Azure AD Connect instance.

In AWS I have a single elastic compute cloud (EC2) instance running Windows Server 2016 within a virtual private cloud (VPC).  I’ll be configuring Azure AD as an identity provider associated with the AWS account and will be associating an AWS IAM role named AzureADEC2Admins.  The role will grant full admin rights over the management of the EC2 instances associated to the account via the AmazonEC2FullAccess permissions policy.

Let’s begin shall we?

The first step I’ll be taking is to log into the Azure Portal as an account that is a member of the global admins and navigate to the Azure Active Directory blade.  From there I select Enterprise Applications blade and hit the New Application link.

entapps.png

I then search the application gallery for AWS, select the AWS application, accept the default name, and hit the Add button.  Azure AD will proceed to add the application and will then jump to a quick start page.  So what exactly does it mean to add an application to Azure AD?  Good question, for that we’ll want to use the Azure AD cmdlets.  You can reference this link.

Before we jump into running cmdlets, let’s talk very briefly about the concept of application identities in AAD.  If you’ve managed Active Directory Domain Services (AD DS), you’re very familiar with the concept of service accounts.  When you needed an application (let’s call it a non-human to be more in-line with industry terminology) to access AD-integrated resources directly or on-behalf of a user you would create a security principal to represent the non-human.  That security principal could be a user object, managed service account object, or group managed service account object.  You would then grant that security principal rights and permissions over the resource or grant it the right to impersonate a user and access the resource on the user’s behalf.  The part we want to focus in on is the impersonation or delegation to access a resource on the behalf of a user.  In AD DS that delegation is accomplished through the Kerberos protocol.

When we shift over to AAD the same basic concepts still exist of creating a security principal to represent the application and granting that application direct or delegated access to a resource.  The difference is the protocol handling the access shifts from Kerberos to OAuth 2.0.  One thing many people become confused about is thinking that OAuth handles authentication.  It doesn’t.  It has nothing do with authentication and everything to do with authorization, or more clearly delegation.  When we add an application the AAD a service principal object and sometimes application object (in AWS instance both are created) are created in the AAD tenant to represent the application.  I’m going to speak to the service principal object for the AWS integration, but you can read through this link for a good walkthrough on application and service principal objects and how they differ.

Now back to AWS.  So we added the application and we now have a service principal object in our tenant representing AWS.  Here is a few of the attributes for the object pulled via PowerShell.

awsservice.png

Review of the attributes for the object provide a few pieces of interesting information.   We’ll get to experiment more with what these mean when we start doing Fiddler captures, but let’s talk a bit about them now.  The AppRoles attribute provides a single default role of msiam_access.  Later on we’ll be adding additional roles that will map back to our AWS IAM roles.

Next up we have the KeyCredentials which contains two entries.  This attribute took me a while to work out.  In short, based upon the startDate, I think these two entries are referencing the self-signed certificate included in the IdP metadata that is created after the application is added to the directory.  I’ll cover the IdP metadata in the next entry.

The Oauth2Permissions are a bit funky for this use case since we’re not really allowing the application to access AWS on our behalf, but rather asking it to produce a SAML assertion asserting our identity.  Maybe the delegation can be thought of as delegating Azure AD the right to create logical security tokens representing our users that can be used to assert an identity to AWS.

The PasswordCredentials contains a single entry which shares the same KeyID as the KeyCredential.  As best I can figure from reading the documentation is this would normally contain entries for client keys when not using certificate authentication.  Given that it contains a single entry with the same KeyID as the KeyCredential for signing, I can only guess it will contain an entry even with a certificate is used to authenticate the application.

The last attributes of interest are the PreferredTokenSigningKeyThumbprint which references the certificate within the IdP metadata and the replyURLs which is the assertion consumer URI for AWS.

So yeah, that’s what happens in those 2 or 3 seconds the AWS application is registered with Azure AD.  I found it interesting how the service principal object is used to represent trust between Azure AD and AWS and all the configuration information attached to the object after the application is simply added.  It’s nice to have some of the configuration work done for us out of the box, but there is much more to do.

In the next entry I’ll walk through the Quick Start for the AWS application configuration and explore the metadata Azure AD creates.

The journey continues in my third entry.