Background

This is the fourth article in the series titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" in the previous post we discussed how to secure Amazon Identity and Access Management (IAM)  by leveraging Centrify Identity Service and your on-premises Active Directory.

In this article we'll discuss how to use Centrify Server Suite to secure your AWS Server instances by leveraging Active Directory (in AWS, on-premises or a mixed environment).  The drivers behind this are:

• To continue to leverage Active Directory as the source of identity and privileges
• To eliminate the reliance on SSH keys or fragmented identities
• To provide a tried and true privileged elevation mechanism (sudo) without the inconveniences of sudoers files
• To be able to deploy additional controls such as time-fencing and multi-factor authentication for linux
• To be able to quickly attest who can access systems, their roles, privileges and how the privileges were granted
  
• To enforce the principle of separation of duties

Active Directory and AWS

The prescriptions outlined on this article depend on how your Active Directory AWS strategy is designed.  It's even possible that there's no AD in your AWS deployment today, in that case you'd benefit from looking at the next entry in the series (that focuses on session brokering and password management).  Assuming you are using AD in AWS, here are some of the models we've seen with our customers:

The Connected Model

This model implements some degree of permanent connectivity between AWS and your on-premises infrastructure (e.g. Amazon DirectConnnect, Firewall ACLs, VPNs/Tunneling, etc); the end result in the Active Directory layer is that the following models can be implemented:

• Account-resource model:  With accounts living on-premises and a resource domain existing in AWS (for example, with a one-way trust).
• Extended model:  Domain controllers extend to AWS (writable or read-only).

The connected model allows for organizations to extend their AD and Centrify deployments and treat AWS as another site.  As far as Centrify goes, it's like adding another branch or site.

The implications of this model are permanent connectivity (and costs), plus the need to implement the network and security components prior to the AWS deployment.  Once it is in place, the administration is simplified.

The Disconnected Model

This model uses the opposite approach.  It treats AWS as a disconnected entity.  Users connect to AWS through the Internet.  Directory services are separated.

In this scenario, independent AD forests exist on premise and in AWS.  The benefits of this model are:

• Faster-to-production because there's no need to wait for dedicated connectivity to be set up.
• No need to architect a security model around AD.

The obvious drawback of this model is dual administration.

Commonalities and Customer Inquiries

When communicating with prospects and customers on the field, these are the commonalities that I have observed:

• They want to extend the Centrify Server Suite benefits to these environments
• They have questions about their AD architecture (the two models below hint at how things would be designed and managed)
• They have questions about the instance lifecycle:
  • How can I automate Centrify client deployment?
  • How can I automate AD joins when systems are launched?
  • How can I automate AD leaves when systems are terminated?
• They have questions about management frameworks  (e.g. Scripts, DevOps, Amazon OpsWorks)
• They want to automate privileged operation leveraging PowerShell
• They want to deploy additional controls (like multifactor authentication or time-bounding)
• They have miscellaneous questions about pre-validation and the use of DirectAudit (session capture and replay)

Fortunately the building-blocks for all the questions asked above are scattered in the Tech Blogs and the Centrify Knowledgebase.  Instead of using the Plan-Do-Check-Adjust model in this article (because of the combination of scenarios), I will speak about each bullet-point individually.

Extending Centrify Server Suite to Amazon Web Services

This one is straightforward.  CSS requires Active Directory and there are several avenues that you can use.  This all depends on the access and privilege model to be implemented. 

• If status-quo will be maintained and the same user population retains the same rights to AWS
  • You may only need to create a child zone or a computer role in your existing zone structure.
  • Active Directory design principles are maintained: 
    - AD Sites and Services (subnets/sites) need to be created and maintained. 
    - Global Catalog location needs to be accounted for, especially if Universal or nested groups are used.
  • If RODCs are in use, adjust your instance provisioning model based on the prescriptions of the Server Suite planning guide (pg. 205).
• If there's a different access model being implemented
  • If there will be a completely new governance model within the same forest, then a parallel zone may need to be created and delegated to the proper group.
  • If a brand-new forest with a 1-way trust is created, then a zone in the resource domain will have to be created and principals from the trusted domain have to be added to provisioning and role-granting groups.

EC2 Instance Lifecycle

The EC2 lifecycle (Launch, Stop, Terminate) has implications depending on the use cases.  In permanent environments, systems are expected to be there for a long time;  in elastic environments systems may be alive for a few weeks while an app is tested, or may be scaled-up or down depending on load or business seasonality.

Aspect that require planning include naming conventions, properly deprovisioning systems and using the analyze wizard to make sure things are tidy.  Some resources:

• Server Suite Documentation: Deployment and Planning Guide
• Technet: Naming conventions in Active Directory for computers, domains, sites, and OUs
  
• Utilities - The Analyze Wizard tool

Deploying the Centrify Software and Joining (or leaving) AD automatically

Deployment depends on the approach.  I've seen customers that bake the software into their private AMIs (this allows for them to test and validate any corporate software) or I've seen the use of repositories and configuration management software.  The guidance here is consistent:  If you want the system to participate in your AD, you must align your hostname with your naming convention,  specify the domain name, and automate the AD join (using a krb5.conf file and a service account keytab).

Baking the software and utilities to an image makes things more predictable; however using a DevOps framework is the way of the future (given the testing orientation). 

This article shows how to create these building blocks: [HOWTO] Use Centrify Tools for Public/Private Cloud Automation Activities

The Termination sequence is relatively the same:  retrieve utility files, run kinit and instead of adjoin, run "adleave --remove" this will remove the computer from AD and Centrify, freeing-up the license.

DevOps Frameworks

Amazon AWS provides a great set of tools based on Chef (OpsWorks).  If you choose to use this framework, you need to have your recipes and underlying infrastructure in place (e.g. an APT/YUM repo, or Chef infrastructure) to host the dependencies.  If you are looking at the DirectControl, DirectAudit or CLI toolkit as an app, you have to sequence the triggering of the script based on your design (e.g. user-data, setup/configure/deploy/undeploy/shutdown). 

Here are some avenues:

User Data field:

OpsWorks:

These articles show the same sequence using Chef or Puppet:

• Basics - Using a Chef recipe to deploy Centrify and join Active Directory
  
• Basics - Using Puppet standalone to deploy Centrify and join Active Directory

AutoScaling, OpsWorks and Automation Resources

• AWS AutoScaling Group Scripts:  https://github.com/centrify/AWS-AutoScalingGroup
• AWS OpsWorks (Chef 12):  https://github.com/centrify/AWS-OpsWorks
• AWS Automation:  https://github.com/centrify/AWS-Automation

Automating Access and Privilege Operations with PowerShell

Amazon AWS provides a powerful toolset that has been implemented in PowerShell.  This is very aligned with Centrify's efforts (both Centrify Suite Standard and Enterprise edition provide PowerShell management tools). 

The subject of PowerShell is very broad, here are a few resources:

• Access Control and Privilege Management Scripting Guide
• Auditing and Analysis Scripting Guide
• Use the Centrify PowerShell Module to Automate Access and Privilege Operations

Securing Windows Servers in AWS

Some of you are also using Windows servers in AWS and ask us how we can help.  The windows security model has been challenged by modern threats like PtH and the dependency on high-privileged accounts (like Administrator) and groups (like Administrators and Domain Administrators).  Centrify DirectAuthorize provides a powerful mechanism to control access and privilege elevation.

This article goes to length to explain the process for Windows:  http://community.centrify.com/t5/Community-Tech-Blog/HOWTO-Eliminate-the-use-the-shared-Root-UNIX-Linux-and/ba-p/19470

Automation: In Suite 2016, Centrify added the ability to join zones automatically with the dzjoin command.  This can be combined with the EC2Config tasks for your Windows based AWS systems.  The User's Guide for Windows describes dzjoin in detail.

Advanced Controls and Reporting

Depending on the data classification or risk profile of the systems hosted in AWS, organizations may want to deploy additional controls to provide the assurance that only authorized users are accessing these systems, in addition, these systems may be subject to attestation requirements just like on-premise systems.  We will explore other controls in part 5, however Centrify Standard Edition provides multi-factor authentication for access and privilege elevation as well as several mechanisms to obtain access data.

Related Articles

Part I: Securing AWS Series Overview

Part II: Securing the Amazon AWS Root Account with Centrify Identity Service and Active Directory

Part III: Securing Amazon IAM using Centrify Identity Service and Active Directory

Part IV: Securing AWS EC2 Linux instances with Centrify Server Suite and Active Directory

Part V: Securing AWS EC2 Session Access (Jumpbox) and Passwords using Centrify Privilege Service