AWS Advent 2014 – Integrating AWS with Active Directory

11. December 2014 2014, Uncategorized 0

Today’s post on Integrating AWS with Active Directory comes to us from Roger Siggs, who currently helps architect clouds at DataLogix.

Introduction

One of the most popular directory services available is Microsoft’s Active Directory. Active Directory serves as the authoritative system to coordinate access between users and their devices to other resources which could include internal applications, servers, or cloud-based systems and applications. The challenge with AD is not that it is inherently a bad piece of software, but more that the dynamics of the IT landscape have changed. In the past few years there has been a dramatic shift to cloud-based infrastructure. IT applications and an organization’s server infrastructure is increasingly based in the cloud. As a result, how does AD manage that remote infrastructure?

Previous security models were built with the idea of protecting the on-premises environment from outside attacks. How does an Active Directory based model support that model when the environment spans a far larger footprint? The second major trend is toward heterogeneous computing environments. AD was introduced to answer the problems of enterprises that were primarily Windows based.

That is no longer true with Macs and Linux devices infiltrating all sizes of organizations, not to mention tablets and phones. Trends such as these are significant issues and IT admins are struggling with how to leverage them with legacy software and infrastructure. A key part of that struggle is with how to connect and manage their employees and their devices and IT applications. AD doesn’t let them connect everything together – at least not without significant effort.  

Amazon Web Services offers several different methods to provision user access and permissions management through its Identity and Access Management (IAM) service but as a user repository it is lacking in many important features for larger enterprises. The need for more granular levels of access and control on the actual instance, as well as the need to connect and manage employees, devices, and legacy applications, often requires the use of an on-premises directory to provide a centralized and authoritative list of employees, their roles, and their access rights. For many organizations, this on-premises directory is Active Directory. To support their growing customer base, Amazon has released several different methods to integrate your existing directory services with AWS.

Integration Types

The ‘simplest’ form of leveraging AD services into AWS is to just extend your existing footprint into your Amazon environment. This answers some issues around latency for logins, as well as provides relatively quick and easy support for disaster recovery and scalability. Using Cloud-init and various configuration management tools (Puppet, Chef, Powershell, etc) instances can be deployed and automatically join an existing domain- centralizing user management at the instance level. A good working knowledge of AWS services (in particular security group configuration and DHCP Option Sets) is required to ensure replication and other AD specific functionality is supported. The AWS Reference Architecture available here provides much greater detail in both the exact process and step-by-step methodology for this type of integration. This method, while quick and fairly simple, does not allow for access to the back-end systems of AWS. Extending your AD infrastructure in this fashion replicates your existing management processes, but does not provide API or console access to AWS.

Another common form of Directory Service integration is an SSO-based, Federation model. Federation allows for delegated access to AWS resources using a 3rd party Authentication resource. With identity federation, external identities (federated users) are granted secure access to resources in your AWS account without having to create IAM users. These external identities can come from your corporate identity provider ( e.g. Active Directory) or from a web identity provider, such as Amazon Cognito, Login with Amazon, Facebook, Google or any OpenID Connect (OIDC) compatible provider. This allows for users to retain their existing set of usernames, passwords and authentication credentials, while still accessing the AWS resources they need to perform their roles. Depending upon the roles allowed to an authenticated user, this method can provide Console Access, API Access (through the STS GetFederationToken api call), and even Workspaces and Zocalo access.

Federation with Active Directory is configured using SAML (Security Assertion Markup Language) to create a connection between an Identity Provider (IDP), and a Service Provider (SP). In this instance, Active Directory is the IDP, and AWS the SP. This process, detailed below, allows for secure and granular access based on the requesting users role within the organization, and the capabilities that role is allowed within the AWS environment.

 

image

 

  1. The user browses to the internal federation resource server.

  2. If the user is a logged into a computer joined to the AD domain and their web browser supports Windows authentication, they will be authenticated using Windows integrated authentication. If the user is not logged into a computer joined to the domain, they will be prompted for their Windows username and password. The proxy determines the Windows username from the web request and uses this when making the session request.

After an AD user is authenticated by the proxy the following occurs:

  1. The proxy retrieves a list of the user’s AD group membership.

  2. The proxy retrieves IAM user credentials from a web configuration file (web.config) configured during setup. By default, the sample encrypts the secret access key using Windows Cryptographic Services. The proxy uses these credentials to call the ListRoles API requesting a list of all the IAM roles in the AWS account created during setup.

  3. The response includes a list of all the IAM roles available within the AWS account for the requesting user.

  4. The proxy determines user entitlements by taking the list of AD groups and the list of IAM roles and determines the intersection of these two lists based on name mapping. The proxy takes the intersection and populates a drop down box with all the available roles for the current user. The user selects the role they want to use while logging into the AWS management console. Note: if the user is not a member of any AD groups that match a corresponding IAM role, the user will be notified that no roles are available and access will be denied.

  5. Using the Amazon Resource Name (ARN) of the selected role, the proxy uses the credentials of the IAM user to makes an AssumeRole request. The request includes setting the ExternalId property using the security identifier (SID) of the AD group that matches the name of the role. This adds an additional layer of verification in event the AD group is ever deleted and recreated using the same display name. By default the expiration is set to the maximum of 3600 seconds.

  6. The proxy receives a session from Amazon Security Token Service (STS) that includes temporary credentials: access key, secret key, expiration and session token.

  7. (ADFS specific) The proxy uses the session token along with the SignInURL and ConsoleURL from the web configuration file (web.config) to generate a temporary sign-in url.

  8. Finally the user is redirected to the temporary sign-in url which automatically logs them into the AWS Management Console (or API session) is valid until the session expires.

Federation methods can become very complex, depending on the individual use case. Amazon has a large amount of documentation around this feature, but a good starting point is the IAM ‘Manage Federation’ topic available here.

The third method of Integration is using the new AWS Directory Service. This is a cloud-based, managed service that allows for a direct connection between your existing AD environment and your AWS resources. This service has two different directory types- the ‘AD Connector’ for existing systems; and the ‘SimpleAD’ directory type for new, cloud-only environments. The ‘AD Connector’ serves as a proxy between your on-premises infrastructure and AWS and eliminates the need for federation services. To use the AWS Directory Service, you must have AWS Direct Connect, or another secure VPN connection into an AWS VPC (Virtual Private Cloud). The AD Connector allows you to provision access to Amazon Workspaces, Amazon Zocalo, and to provide access to the AWS Console to existing groups in your Active Directory structure. Access is also automatically updated in the event of organizational changes (employee terminations, promotions, team changes) to your AD environment. Additionally, your existing security policies – password expiration, password history, account lockouts and the like are all enforced and managed from a central location.  

Conclusion

There are almost as many methods to address authentication and authorization needs as there are companies who need the problem resolved. With AWS, existing organizations have a number of resources available to custom tailor their hybrid infrastructure to meet the needs of their employees and customers moving forward, without sacrificing the security, stability, and governance that is the hallmark of an on-premises environment. This overview of the topic will hopefully provide some direction for IT Administrators looking to answer the question of how their identity management systems will bridge the gap between yesterday and today.