A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory - Part 4

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

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.
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 Videos

Deploy Centrify and Join Active Directory automatically using a stand-alone Puppet script

A few months ago I published a post titled "Deploy Centrify and Join Active Directory with a simple Chef Recipe" as customary, after I get asked about something 3 times, it's time to create a post, but now using Puppet by PuppetLabs.  This post is identical to the Chef post, just different tools.

Disclaimers and Acknowledgements

• This article provides a "quick basic configuration";  in a true deployment you have to account for high-availability, replication, security, package integrity, supported platforms, supported versions, change control, etc. 
• All names, logos and trademarks used in this articles correspond to their existing owners.
• I'm not Puppet, Chef or Bladelogic subject-matter experts, hence the use of a stand-alone script or recipe. 
• Puppet Master server/slaves/node architecture is outside the scope of this post
• This would not be possible without my customers/prospects asking and the tutorials available online.  Some great resources:
  - Introduction to Puppet:  https://docs.puppetlabs.com/guides/introduction.html
  - Willams' blog post "How to install Puppet in Stand-Alone mode on CentOS7"
  - Kudos to MaestroDev for the wget Puppet extension: https://forge.puppetlabs.com/maestrodev/wget

What is required?

• An Active Directory domain
• A Centrify zone (optional - if using Centrify in licensed mode/privilege management)
• A Centrify zone and a Computer Role  (optional)
• An Active Directory service account for joins and removals, plus a keytab for the account and a usable krb5.conf file.  Read this article if you want to know how to create the service account and obtain the keytab.
• A RHEL-based system with enough storage for the Centrify RPM packages for each platform (or just for the subset you need to support).  This system has to be set up as a YUM repository, as described in the the original orchestration article.
• A second RHEL-derivative system to install Puppet (see below), this system must have DNS settings configured correctly.

Note:  Although it's possible for you to follow this and put together a working prototype, I strongly-encourage that you really explore the concepts  of DevOps/infrastructure as code.  The whole philosophy promotes constant improvement, this means that if you expect this to be a "set it and forget it" solution, I advise that you realign your expectations.

Finally, By no means what's outlined here is ready for production.  Check out the reading list below.

Example Diagram


Implementation Steps

Planning
The goal of this lab is to be able to deploy the Centrify bits in a RedHat, CentOS, Scientific or Oracle system in a consistent way.  Also, if you know what you're doing, you can extend this to other OSs, and platforms as well.

The 'core' process without checking for major dependencies or issues is to:

1. Install Centrify DirectControl
2. Authenticate against Active Directory with an account with minimal rights
3. Join Active Directory

Building Blocks

• YUM Repository with Centrify RPMs (detailed instructions here)
• AD account + keytab (steps outlined in a previous post)
• Usable krb5.conf:  You can copy this file from any Centrified system; however, depending on where you're onboarding the system, you want to edit the file only with the DCs that are reachable to the new system.

Make the krb5.conf and service account keytab available to your infrastructure
In the original article, we piggy-backed on the Apache webserver as the transport for our repository.  Now we're going to create another folder for utilities (utils for short) and copy the keytab and krb5.conf file.
If you prepared this for the Chef article, you can skip to Puppet installation.

1. Create a folder under /var/www/html
   $ sudo mkdir /var/www/html/centrify/utils
2. Copy the RPMs to the folder.$ cd /path/to/files
   $ sudo mv krb5.conf  /var/www/html/centrify/utils
   $ sudo mv ad-joiner.keytab  /var/www/html/centrify/utils
3. Set the proper permissions in the folder
   chmod -R ugo+rX /var/www/html/centrify/utils
4. Verify that the files are accessible via the web server (you may have to check the firewall settings)
   

Install Puppet and the wget Extension

1. Add the Puppet repository (you must find the proper repository for your RHEL version, version 7 shown)
   $ sudo rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm
2. Install the bits
   $ yum install puppet
3. Make sure your system's DNS settings are up to date (yes, no "localsystem.localdomain")
   Can you ping your own system by name and FQDN?
   What is the output of the hostname command?
   Run this:
   

   facter | grep hostname
   facter | grep fqdn

   if the output isincorrect, you must edit the /etc/hosts and /etc/resolv.conf and speak to your DNS admin to set things straight
4. Logout and log back in to verify the ruby path
   $  sudo puppet module install maestrodev-wget
   You should be ready to get going.

Create and test your stand-alone Puppet Script
To recap, the sequence to automate Installation and joins is as follows:

1. Retrieve a usable krb5.conf file
2. Retrieve the keytab of a valid service account with minimum rights to join systems to the target AD OU, to the target zone (if using in zone mode) and if adding to a Computer role, with rights to add to the target AD groups.
3. Install the Centrify Package and use the kinit tool to obtain a TGT
4. Run adjoin with the proper options.
5. Perform cleanup

Here is the Non-idenpotent Puppet Script:

# This stand-alone recipe will install the Centrify Agent on RHEL derivatives, 
# joins Active Directory and places the system in a Computer Role
# Notes: This recipe is not idempotent (achieving this is up to you!)

include wget

# Variables for my environment (see blog post)
# domain is the most basic parameter to join Active Directory

$adname = "centrify.vms"  
# Notice that I could not use "domain" like in the Chef example.  
# That word seems to be reserved in Puppet

# In Zone Mode (licensed with UNIX identity and Access Control) the zone
# parameter corresponds is where the system will be placed.  Not needed
# if working in workstation or express mode.

$zone = "Global"

# OU is where your computer object will be placed in Active Directory
# your ad-joiner account should be able to join systems to this container

$ou = " ou=servers,ou=unix"

# A Computer role is one of the ways to group systems and define access 
# control.  A system may be a member of multiple computer roles.  
# E.g.  a LAMP system may be accessible by Web Admins, Developers and 
# DBAs with different access rights and privileges.

$crole = "App Servers"

# nodes are the managed system in Puppet;  in a true deployment you can
# apply to individual systems or collections of systems.  Since this is not
# idempotent, you must specify the fqdn.

node "your-system-fqdn" {

# Centrify's utilities are Kerberized, this means that they will use the current
# user's Kerberos TGT to attempt the transaction against AD.  However, in a 
# virgin system, there are no working krb5.conf files, therefore kinit won't know
# how to find a KDC to authenticate against.  This is why we need a krb5.conf 
# file from a working system (or that points to a reachable Domain Controller), 
# in the previous blog entry, we piggy-backed on an Apache Web server to 
# serve those files (engcen6).

wget::fetch {"download a working krb5.conf":
  source             => 'http://engcen6.centrify.vms/centrify/utils/krb5.conf',
  destination        => '/temp/krb5.conf',
  timeout            => 0,
  verbose            => true,
  nocheckcertificate => true,
  before => Exec["kinit"]
}

# The keytab corresponds to a service account that has the minimal rights, in 
# this case, the rights to write a computer object in the designated container 
# (ou), centrify zone and the AD group that contains the "App Servers"computer
# role needless to say, you need to treat this file with care and if possible, 
# remove when complete.

wget::fetch {"download the ad-joiner keytab file":
  source             => 'http://engcen6.centrify.vms/centrify/utils/ad-joiner.keytab',
  destination        => '/temp/ad-joiner.keytab',
  timeout            => 0,
  verbose            => true,
  nocheckcertificate => true,
  before => Exec["kinit"]
}

# We leverage Puppet to ensure the files are present. This will be used later
# to guarantee proper sequencing.

file {"ad-joiner.keytab":
  ensure => present,
  path   => '/temp/ad-joiner.keytab'
}

file {"krb5.conf":
  ensure => present,
  path   => '/temp/krb5.conf'
}

# In this command, we authenticate against AD with the keytab of our service 
# account.  Note that we are using the usable krb5.conf file so kinit can reach
# a KDC (domain controller).  The end-result is that root (or sudo) user will
# have a TGT and you don't need to put keys, hashes or passwords in your 
# script.  The before/subscribe and require Puppet directives guarantee proper 
# sequencing.

exec {"kinit":
  command =>  "/bin/env KRB5_CONFIG=/temp/krb5.conf /usr/share/centrifydc/kerberos/bin/kinit -kt /temp/ad-joiner.keytab ad-joiner",
  before => Exec["adjoin"],
  subscribe => [
        File["/temp/ad-joiner.keytab"],
        File["/temp/krb5.conf"],
  ],
  require => Package["CentrifyDC"],
}


# In a pre-requiste blog entry, I outlined how to create a YUM repository for 
# RHEL and derivatives.  This means that you need a yum or apt repo with 
# the Centrify packages.  Puppet will simply make sure the package is present
# notice the differences, I declared this after the previous directives, when
# the package is a pre-requisite.

package {"CentrifyDC":
    ensure => 'installed',

}

# Finally we run adjoin.  At this point we are using the variables from my 
# environment.  Although in doing so, we broke the 'idempotent principles, I'm 
# certain that Puppet experts can find ways to improve on this.  

exec { "adjoin":
  command => "/usr/sbin/adjoin -z $zone -c $ou -R \"$crole\" -V $adname",
  require => Package["CentrifyDC"]

}

# In the cleanup phase, we clear the TGT and delete the utility files
# Although the keytab provides very specific limited AD rights, always make
# a habit of cleaning-up.

exec {'kdestroy':
  command => '/bin/env KRB5_CONFIG=/tmp/krb5.conf /usr/share/centrifydc/kerberos/bin/kdestroy',
  require => Exec['adjoin'],
}

exec {"/bin/rm -f /temp/*":
  require => Exec['kdestroy'],
}

} # End of Script

Review the results

$ sudo puppet apply centrify-build.pp
Notice: Compiled catalog for engcen7.centrify.vms in environment production in 1.77 seconds
 Info: Applying configuration version '1458157258'
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Package[CentrifyDC]/ensure: created
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/File[krb5.conf]/ensure: created
 Info: /Stage[main]/Main/Node[engcen7.centrify.vms]/File[krb5.conf]: Scheduling refresh of Exec[kinit]
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Wget::Fetch[download a working krb5.conf]/Exec[wget-download a working krb5.conf]/returns: executed successfully
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/File[ad-joiner.keytab]/ensure: created
 Info: /Stage[main]/Main/Node[engcen7.centrify.vms]/File[ad-joiner.keytab]: Scheduling refresh of Exec[kinit]
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Wget::Fetch[download the ad-joiner keytab file]/Exec[wget-download the ad-joiner keytab file]/returns: executed successfully
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[kinit]/returns: executed successfully
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[kinit]: Triggered 'refresh' from 2 events
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[adjoin]/returns: executed successfully
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[kdestroy]/returns: executed successfully
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[/bin/rm -f /temp/*]/returns: executed successfully
 Notice: Finished catalog run in 38.32 seconds

Verification Video

A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory - Part 3

Background
This is the third 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 the Amazon Root account.
In this article we'll discuss how Centrify can secure Amazon Identity and Access Management by leveraging Active Directory or any other supported Identity Source. 

About Amazon AWS Identity and Access Management (IAM)
For those who aren't familiar with Amazon IAM, it provides capabilities that allow organizations to centrally manage Users, Roles, Rights and Policies efficiently for all services (compute, storage, database, application) provided by the platform. 

Another Identity Silo
Each time a new infrastructure or application is introduced, it has the potential to create another identity silo, Amazon AWS is not the exception.  Large organizations often find themselves duplicating effort by managing their own enterprise directory (like AD) and also having to manage the directory out in the IaaS or SaaS provider.
Many of our customers and prospects due to timing of adoption or while developing cognitive knowledge, find themselves manually managing Amazon IAM.  The typical tasks include user creation, credential/password/key management, password resets, group/entitlement management and attestation. The basic IAM best practices are outlined when you log in to the IAM dashboard:



Once we adopt this "dual-management" we are promoting IT fragmentation, the potential consequences are complexity, limited productivity and possible security expose.  Finally, depending on the data classification or risk profile of the assets in AWS, this identity silo is subject to the corporate security policy (password policies, user attestation reporting, least access management, etc.)

In the past few years, Amazon has recognized this challenge and provides vast extensibility to IAM, via APIs and using standards like SAML and OpenID Connect. 

This article provides a practical example that not only meets but exceeds the best practices around Amazon AIM, eliminates dual-administration and aligns administration with internal policies.

Using Centrify CIS & Active Directory to Secure Amazon's IAM
In this post I describe a framework to leverage Centrify Identity Service  to meet and exceed the Identity Management requirements for Amazon AIM while maintaining the corporate directory (AD) as the single-source of truth. 

The example used in this blog post focuses on Active Directory, however, those who are familiar with Centrify know that the user sources can be or any other internal LDAP source, Google Directory, Federated Partner or even Social Identity providers.
The solution outlined below establishes a SAML federation agreement between Centrify Identity Service (CIS) acting as the Identity Provider (IdP) and Amazon AWS IAM acting as as the Service Provider (SP);  Since CIS will be using Active Directory principals as an identity source, AD continues to be the single-source of truth for the enterprise and AD group memberships, AWS IAM Roles and CIS roles can be used to manage entitlements.

Enhanced Objectives

• Eliminate duplicated administration efforts and align Amazon IAM users with corporate policy
• Leverage AD Group membership (or CIS Roles) for Amazon IAM provisioning (add/moves/changes/deletions)
• Leverage AD Group membership (or CIS Roles) and IAM Groups for Entitlement Management
• Provide SSO to Amazon AWS with minimal federation infrastructure required
• Enforce Advanced Policies: Require Multi-factor Authentication or Enforce Access from the Corporate Network
• Limit access to IAM credentials to those with business need-to-know

Planning
Stakeholders

• Identity and Access lead:  Organizes and coordinates the effort.
• Security SME: Outlines the security requirements based on policy or risk profile
• Infrastructure SMEs: Execute the implementation of the tasks

Planning Discussions
Below are planning discussions that can be had around IAM:

1. What are the services being used in AWS? Will there be a process defined when new services are used?
2. Are there any AWS IAM Groups that provide separation of duties (e.g. EC2 Management vs. IAM Management)?
3. Will Active Directory Groups be mapped to AWS IAM Groups? or Will Centrify Roles be used?
4. Will contextual policy be needed?  E.g. restrict access to corporate sites, geo-fencing or time-fencing?
5. What will be the attestation process for AWS users?  (e.g. AD Group Management or CIS Roles/Reports)
6. Will Multi-factor authentication be required for IAM users?  What factors (Centrify MFA, Amazon Virtual Token (OATH), SMS, Phonefactor or Email?
7. Will approvals be required for IAM access?  (Request/Approval)
8. Will just-in-time provisioning be used (E.g. AD group addition triggers an AWS IAM provisioning)?
9. Will SAML, OpenID Connect or Amazon's API be used to establish AWS integration? 
10. Will users be allowed to log in with their AWS password or just with SSO?
11. How will users be uniquely identified in AWS? (should shortname, email, UPN or another field be used?)

 Our Example

• The organization uses Amazon EC2 to hosts servers in the cloud
• There are two types EC2 of users:  Users with Full Access and ReadOnly Users.
• Users with full access will be managed via AD Security group Membership (AWS-EC2-FullAccess)
• Users with read-ony access will be requested on-demand (must be approved) via a CIS Role;
• Another group (AWS-IAM-Managers) can manage IAM in AWS and will approve requests.
• All users must provide step-up authentication via Token, Email, SMS or Phone to access AWS
• The implementation will use the Centrify-provided SAML template
• The Centrify-Provided PKI Certificate will be used for the SAML Assertion
• Users will be identified in AWS with their Shortname.

 Technical Requirements

• Active Directory with security groups created and populated
• Centrify Identity Service Tenant
• A Member Server running the Centrify Cloud Connector with the AD Proxy capability enabled and connected
• An Amazon AWS Account and a user with IAM rights to create an Identity Provider and Roles

Implementation
This process implies a partial configuration in CIS, followed by the configuration in AWS, finishing-up in CIS again.

Initial Configuration in Centrify Identity Service
Add and Configure the Amazon Web Services (AWS) Console: SAML+Provisioning

1. In Cloud Manager, navigate to Apps > Add Web App
2. In the Search Box, type AWS and press Enter, on the results, pick the "Amazon Web Services AWS Console SAML+Provisioning" template and click Add.
   
3. When ask to confirm if you want to add the app, click Yes. This will open the app template for configuration.
4. In Application Settings:
   - Type your AWS Account ID (if you don't know it, go to "My Account" in AWS)
   - Click the "Download SAML provider metadata document"  link, this will save the XML file in your downloads folder
   
5. In Description, give the application a descriptive name (e.g. AWS Role-Based SSO)
6. Skip User Access and Policy (we'll revisit)
7. In Account Mapping , use the "Use Account Mapping Script" option and type the following:

   LoginUser.Username = LoginUser.Shortname

   This option will send the user's shortname as the identifier.  If there are duplicates, you can switch to mail or UPN.
8. Press Save, you'll have to return here for adjustments.

Configuration in AWS
Create the Centrify SAML IDP

1. Sign-in to AWS and navigate to Security and Identity > Identity and Access Management
2. On the left pane, click Identity Providers and press the Create Provider button on the right
3. Select SAML in provider type
4. In provider name type a descriptive name like "Centrify" or "CentrifySAML"
5. In Metadata Document, browse to the downloads location where the XML file from step 4 above was saved, press Next Step and press Create.

Configure the AWS IAM Roles for the Centrify SAML IdP

1. On the Amazon AWS IAM Dashboard, Click Roles > Create New Role
   The names of the roles about to be created must match the role names in Centrify Identity Service.
2. Example: EC2 Administrators - this role grants the ability to manage all aspects of EC2 instances, therefore a policy that matches that entitlement has to be tied to the role.
   Name: AmazonEC2Admins
   Role Type:  Role for Identity Provider Access > Grant Single Sign-On (WebSSO) access to SAML providers [Select]
   Establish Trust:  SAML Provider > Select Centrify > Press Next Step
   Verify RoleTrust: Press Next Step
   Attach Policy: type "AmazonEC2FullAccess" and Check the box
   This corresponds to the administrative role for EC2 instances
   Review:  Press Create Role
3. Repeat the process for the rest of the roles.  Make Sure that you are writing down the names of the Roles.

Finishing the Configuration in Centrify Identity Service
Create and Populate the Centrify Identity Service Roles

1. In Cloud Manager, navigate to Roles > Add New Role
2. Name: AmazonEC2Admins  (must match the name of the corresponding role in AWS)
3. Members: Populate based on your requirements.  For AmazonEC2Admins I'm leveraging AD membership
   
4. Press Save.
   Repeat with any other roles created in AWS

Complete the User Access Section of the AWS Role-Based SSO App

1. In Cloud Manager, navigate to Apps > Click your AWS SAML App
2. Go to User Access and check the box on the roles you've created.
   
3. Press Save, you are ready to verify.

Verification
At this point you can verify access.  If using Active Directory, simply add a user to any of the AD Security groups that grant access and the user will get the App automatically.  Upon clicking on it they'll be able pick the role (or roles, in case of multiple entitlements) and simply press sign-in.

They should only be entitled to the activities allowed by the policies associated with the role.  For example, in the case above the user will only be able to manage EC2 instances and details, no more than that.


Adjustments
Adding Multifactor Authentication , Limiting Access from the Corporate Network and Workflow and Approvals

• MFA is built-in to Centrify Identity Service.  All you need to do is check the box, and provided there's an authentication profile that will support the step-up methods you will be set.  These include and are not limited to:  Centrify's Mobile Authenticator, Phone call, SMS, Security Question, Email or OATH Based OTP (Duo, Google Authenticator, Amazon Virtual OTP)
• To limit access based on the corporate IP range, all you need to do is populate the NAT addresses for the organization and check the appropriate box.
• To establish a workflow and approvals scheme, a role needs to be designated as the approver, see the video playlist below or the one included in part two to view the particulars.

Provisioning of IAM Users
There are instances in which it is desirable to have a provisioned user inside AWS IAM.  What needs to be reconciled is if users will know their IAM passwords, in that case they can go directly to the sign-in page and bypass the controls outlined above.  We can extend the SAML template to provide provisioning capabilities as well.

Enhancements of CIS 2016.2
Amazon AWS provides an virtual MFA capability that leverages OATH.  As of February 2016, Centrify allows you to use any OATH based OTP mechanisms, this means that you can leverage those mechanisms as well.

Video Playlist

A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory - Part 2

Background
In a previous entry, I wrote an article titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" and I described the use of Centrify Identity Platform and Active Directory  to implement enhanced security controls to protect AWS deployments.

In this first part, we'll address how to secure the AWS Root Account.  Amazon suggests protecting the root account with Multi-Factor Authentication, however, in this article I'm describing a strategy to not only meet but exceed the requirements to protect this account.



Enhanced Objectives

• Eliminate sharing of the Amazon AWS root account
• Protect the password by not exposing it to any users
• Limit access only from the corporate network
• Limit access to the AWS account to those with business need-to-know
• Activate MFA with Centrify Step-Up Methods (Mobile Authenticator, Phone factor, SMS, Email, Security Question)
• Activate MFA with Amazon's OATH-based virtual MFA

The Value of Centrify Identity Service
Centrify Identity Service provides a powerful policy engine that allows for the implementation of these controls, not only for the Amazon AWS app, but for any web application that has a user/password authentication pattern and uses a shared account.

As customary, we'll use the Plan-Do-Check-Adjust methodology.

Planning
Role-Based Access Control
- Should the application always be accessible by a limited group of users?
   - Should application access be governed by AD group membership or Centrify Role?
Should the application be accessible to nobody and only requested on demand?
   - Who will approve the application access request?

Additional Controls

• Should the application be accessible only from the corporate network?
• Should the application be accessible at certain times?
• Should the application require step-up authentication.
• What should be the step-up mechanisms? (Centrify MFA, OATH OTP, Phone factor, Email, SMS, Amazon Virtual OTP,  etc)

An example
Access Control will be controlled by AD group membership (e.g. AWS-Root-Users); ad-hoc access will be controlled via workflow. The app will be accessible with a step-up mechanism. The approvers will be an AD group called AWS-Root-Approvers.

Implementation
This implementation steps assume you have a Centrify cloud connector set up providing bridging for an AD domain.

Access Control Building-Blocks
Create the AD Groups

1. In Active Directory Users and Computers, navigate to an OU for a CIS bridged-domain.
2. Create Two AD groups:

- AWS-Root-Users: add the permanently authorized users.
- AWS-Root-App-Approvers: add a set of users that will approve access requests (ideally not the same as above to enforce separation of duties)

Create the AWS Root Role
Members of this role will have permanent access to the AWS Console as root. This is controlled by AD group membership.

1. In Cloud Manager, navigate to Role and Click Add Role
2. Description: AWS Root
3. Members: Go to the Members section and click the Add button and browse for the "AWS-Root-Users" AD group.

 
Create the AWS Root Approvers Role
Members of this role will be able to approve who gets to access this app. This is controlled by AD group membership.

1. In Cloud Manager, navigate to Role and Click Add Role
2. Description: AWS Root Approvers
3. Members: Go to the Members section and click the Add button and browse for the "AWS-Root-Users" AD group.

Configuration in Identity Service
Add and Configure the AWS User/Password App

1. In Cloud Manager, navigate to Apps > Add Web App
2. In the Search Box, type AWS and press Enter, on the results, pick the "Amazon Web Services AWS User/Password" template and click Add.
   
   
   
3. When ask to confirm if you want to add the app, click Yes. This will open the app template for configuration.
4. Description - in this step you will change the name to something descriptive to your environment. 
   
5. User Access - check the box next to the role you created for this purpose (in our example AWS Root)
   
6. Policy - we'll revisit this in the "Adjustments" section.
7. Account Mapping - This is where you'll securely store the AWS credentials. Select
   a) Select "Everybody shares a single username"
   b) Populate the username with the AWS root account email address and the password with the current password.
   
8. Press Save, you're ready for initial testing.

Verification
At this point you can sign-in to Centrify Identity Service with any user in the AWS Root CIS role or an access request can be triggered via the "Add Apps" menu of the User portal.

1. Sign-in to the Centrify Identity Service User Portal with a user from the AWS Root Role
2. You should see the AWS As Root App.  Click on it.
3. This should launch a new browser tab and provide you with assisted injection of the credentials using the Centrify Browser Extension.
4. You can also test the Access Request/Workflow capability by logging in with a user that is not entitled to the application, then click "Add App" and search for the newly-created app. 

Adjustments
Limiting Access only from the Corporate Network
This is desirable if you want to make sure users can only access the AWS console from the on-premises corporate network. The planning steps imply the addition of corporate subnets to the Centrify Identity Service Settings and using the Policy tab of the AWS Root App to enforce these controls.

Adding Multifactor Authentication or Other Controls
MFA is built-in to Centrify Identity Service.  All you need to do is check the box, and provided there's an authentication profile that will support the step-up methods you will be set.

Enhancements of CIS 2016.2
Amazon AWS provides an virtual MFA capability that leverages OATH.  As of February 2016, Centrify allows you to use any OATH based OTP mechanisms, this means that you can leverage those mechanisms as well.

Video Playlist