Background

Centrify recently commissioned a study with Forrester Research that yielded some important information about the state of Security.  Bottom-line, we have decided to throw money and resources to the problems around information security rather than rethinking our approach, the results are more breaches and exposures.

You can access the study results here: https://www.centrify.com/lp/rethink-security-ebook

 

A key conclusion on over 200 organizations surveyed is that those with higher Identity and Access Management (IAM) maturity were breached 50% less while maintaining operational efficiency. 

 

As you read the previous paragraph, you may ask yourself: what is the first step the journey to the continuous improvement required for IAM maturity?  As illustrated in the model below,
model.png

a the key component is to establish identity assurance with technologies like MFA or PKI, however this is challenging enough because many organizations have not achieved this on-premises, much less in IaaS/PaaS platforms like Amazon AWS.

 

This is where Centrify can help.  This article is about guiding you on how to use the Centrify platform to establish identity assurance in several use cases:  

  • Accessing the AWS Consoles with shared accounts (like Amazon root) or Federated identities
  • Accessing EC2 instances locally (Linux or Windows)
  • Accessing AWS commands via the CLI (E.g. PowerShell or Python)

Please note that identity assurance concepts apply to both users and systems (due to API access);  in this use case we'll focus on interactive (user) use cases.  For system/system or app/app, other mechanisms like PKI or Kerberos can be used and we can cover in another entry.

 

The Centrify Advantage

The biggest advantage for Centrify lies in it's platform and integrations, as a company that covers both Identity as a Service (IDaaS) as well as Privileged Identity Management (PIM) we understand that everything starts with Identity Consolidation.   This is not the "legacy" (metadirectory/connector-based mid-2000s) identity consolidation, this is the "straight-to-the-source" standards based approach using Federation in the IDaaS side, plus direct-integration (with Kerberos) in the case of heterogeneous OS platforms.  We add to this a series of services:

  • A policy service
  • A multi-factor authentication engine (that includes modern and legacy-based support)
  • A risk-based engine (analytics) 

Our native integrations with Active Directory make us a prime vendor to consolidate capabilities;  here's an example, if an organization wants to secure access to a web app, integrate a non-windows platform to a central directory like AD and get MFA, they may engage 3 distinct vendors, however Centrify can help with world-class solutions on the three areas.  Let's look at a the examples.

  

Securing Shared or Federated Access to the AWS Console

Centrify Identity Service provides several turn-key templates to help with shared or federated (via SAML or using the AWS API) SSO for Amazon Web Services.  We have covered these integrations here:

 

However, the powerful policy engine and the support for multiple authentication profiles makes this integration simple and flexible.  

anatomy-of-rule.png

Here's a quick demo on how this integration is enabled and the user experience:

Notice how we achieved our goals:  identity consolidation and assurance while maintaining usability.

 

Securing Access to Linux and Windows AWS EC2 Instances

Centrify Server Suite provides native integration with Active Directory, regardless of your deployment model. 

multi.png

By leveraging AD (hosted by you or in AWS), you are eliminating the duplication of identity sources caused by SSH keys with the addition of DirectAuthorize technology that provides role-based access control and privilege elevation and is fully-integrated with the policy and authentication profiles provided by Identity Service or Privilege Service.  We have discussed these integrations here:
 

Provided the Identity Service/Privilege Service setup is correct and the proper PKI trust is in place, for Access and Privilege elevation, all we need to do is set up the proper checkbox at the role, UNIX command or Windows desktop or application.

 anatomy-ss.png

Here's the user experience that meets the requirements for identity assurance via MFA for both Linux and Windows in the context of access and privilege elevation.

 

Notice how we achieved our goals:  identity consolidation and assurance while maintaining usability.

 

Securing Access to AWS CLI (e.g. PowerShell)

Administration of AWS Services is often performed via the AWS CLI (implemented via Windows PowerShell or UNIX CLI).

If you're using Centrify Identity Service with SAML federation into AWS, you can implement the SSO plugin provided with the template.

aws-plugin.png

References:

Here's the user experience in PowerShell.  Note that the experience will be based on the authentication profile that applies to the user by policy.

pt1.png

If you have multiple roles, you get to select them:

rolesel.png 

Finally, the authentication token is stored in the $me variable and the user can move-on to use AWS PowerShell commandlets.   See the pattern here?  Identity assurance with MFA and role-based access without compromising usability and achieving this with with a single solution set.

  

Metrics

A cliché of business schools is the statement "you can't manage what you can't measure"; but since we're dealing with IT security, you may want to track how we are performing towards our goal of consistent identity assurance, in these AWS examples, we can use AWS CloudWatch metrics to measure the percentage of access in the proper context (e.g. Console, EC2, etc) is performed with assurance.  Therefore a good metric to track would be:

 iaratio.png

 

MFA events are tracked for Linux, Windows and Identity Platform, this allows you to be creative and get information from CloudWatch or from Identity Service.

assurancedash.png

Note the CloudWatch widgets above.  In my Linux space, I have a ratio of close to 60% identity assurance (4 out of 7 successful logins were with MFA), however my track record on the sample data I created on Windows is much better (100%).  You use the same approach for privilege elevation via Centrify-enhanced sudo or Centrify Agent for Windows.

 

In the case of Identity Service or Privilege Service, the platform provide dashboards and reports like the Security Overview - User Logins

dash.png

These dashboards allow for reviewing information within 7 days or 24 hours and to look at specific date-time ranges. 

 

Conclusion

Identity assurance is closer than what you think, with the "barriers of entry" for MFA solutions going down, it's all about working with the right partner and Centrify excels at securing apps, endpoints, infrastructure and secrets; finally, the obvious challenge is organizational dynamics;   If you still have groups opposed to centralizing directories or maintaining legacy infrastructure, you can split the project in several phases and attack the platforms that are easier from a people/process standpoint.  Once you can demonstrate identity assurance within those applications or infrastructure, it's going to be hard for those "holding on to the past" to ignore that the best practices are here to stay. The model applies to all aspects of any risk-sensitive information technology area and like every other framework it's not a silver bullet; new threats, attack vectors, compliance requirements and tools are introduced, therefore this has to evolve as well.

 

Related Articles

Using Centrify Audit Trail for UNIX/Linux with AWS CloudWatch

http://community.centrify.com/t5/TechBlog/Labs-Using-Centrify-Audit-Trail-for-UNIX-Linux-with-AWS/ba...

[Labs] Using Centrify Audit Trail for Windows with AWS CloudWatch

http://community.centrify.com/t5/TechBlog/Labs-Using-Centrify-Audit-Trail-for-Windows-with-AWS-Cloud...

[Security Corner] Reviewing your Access and Privilege Management Model with Centrify tools: http://community.centrify.com/t5/TechBlog/Security-Corner-Reviewing-your-Access-and-Privilege-Manage... 

Background

As more and more organizations run infrastructure in IaaS platforms like Amazon AWS, there's an increased need to enhance security operations and prove effective implementation of security controls.  AWS provides a solution set that includes CloudWatch.  

 

About CloudWatch

As defined by Amazon "CloudWatch monitors your Amazon Web Services (AWS) resources and the applications you run on AWS in real time. You can use CloudWatch to collect and track metrics, which are variables you can measure for your resources and applications." 

For more information, check out the Getting Started guide for CloudWatch:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html

 

The goal of this article, is to provide some initial guidance to leverage AWS CloudWatch to collect, track and measure Centrify Audit Trail events in Windows systems running in AWS.

For a companion article that covers UNIX/Linux instances, click here:  http://community.centrify.com/t5/TechBlog/Labs-Using-Centrify-Audit-Trail-for-UNIX-Linux-with-AWS/ba...

 

About Centrify Audit Events

Centrify Audit Events (CentrifyAuditTrail) is the cross-platform framework used by Centrify Server Suite to document and provide access, privilege and audit trail event data. When a Centrify-enabled service is invoked, an audit trail event is written to UNIX syslog or Windows event log.  These events are documented in the  Audit Events Administrator's Guide for the current version of Server Suite.  The types or content of the events vary depending on the edition (Standard or Enterprise)

 

For more information, check out the current guide for Server Suite 2017: https://docs.centrify.com/en/css/suite2017/centrify-audit-events-guide.pdf

 

Pre-Requisites

For this lab, you'll need:

  • An AWS Account with the proper VPC setup, privileges in CloudWatch and IAM
  • Active Directory (run by you or managed by Amazon) and the proper VPC name resolution and communications
  • A Centrify zone, sample users and access/privilege setup
  • At least one Windows system joined to Active Directory and the Centrify zone
  • The Windows system should have some Centrify data (e.g. access, privilege elevations) present in the application event log.

Centrify AWS Lab:  You'll need to be at Standard Edition level to follow this lab, more info here:

http://community.centrify.com/t5/TechBlog/Labs-Setting-up-an-AWS-Test-Lab-for-Centrify/ba-p/27771

 

Implementation Overview

  1. Set-up your AWS Windows Instances for CloudWatch Logs (use AWS's docs)
  2. Verify Centrify Audit Trail events in the CloudWatch log group
  3. Identify Access and Privilege-related Metrics provided by Centrify
  4. Create the Filters and Assign a Metric
  5. Create a Dashboard
  6. Create an Alarm

 

Set-up your AWS Linux Instances for CloudWatch Logs

For information on this topic, please review AWS's documentation:
http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/UsingConfig_WinAMI.html#send_logs_to_cwl

 

Note that Centrify Audit Trail resides in the Windows Application log.  To gather the proper event data, make sure you are capturing information and warning messages, this is configured by modifying the AWS.EC2.Windows.CloudWatch.json file in the proper location based on your deployment (stand alone or using SSN service) and under teh ApplicationEventLog stanza, setting the Levels to 7 as illustrated below:

 

{
    "Id": "ApplicationEventLog",
    "FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch",
    "Parameters": {
        "LogName": "Application",
        "Levels": "7"
    }
},

Once you have the Windows logs logs for your instances in the corresponding Log Group, please proceed to the next section.

 

Verify Centrify Audit Trail events in the CloudWatch log group

  1. Go to your CloudWatch console: https://console.aws.amazon.com/cloudwatch/home
  2. Click on Logs > Click on the log group for your Windows instances (e.g. "Default-Log-Group"  or the group you are using for your Windows event logs)
  3. Click on Search log group and in filter events, type "AUDIT_TRAIL"
  4. Verify the results.
     win-audit.png
    If you have a Windows system that was joined to the Centrify zone, there will be event data about access, privileges and other activities.

Now you have verified that your systems are streaming syslog data with Centrify Audit Trail information.

 

Identify Access and Privilege-related Metrics provided by Centrify

The Centrify Agent for Windows™ provides access control,multi-factor authentication and role-based privileged elevation; this component is called DirectAuthorize.  DirectAuthorize controls how users access the system and what commands they can run. The implementation of privilege elevation leverages roles defined in Active Directory and the DirectAuthorize client for Windows.

 

Example 

The metrics that you'll track will depend in your objectives and in your maturity level.  For illustration purposes, let's track successful and unsuccessful access and privilege elevation in my Windows EC2 instances. After reviewing the Centrify Audit events guide, I identify the following events:

 

Access Control

Windows Remote Login Success:  These events are recorded when an authorized user from the Centrify zone is succesfully granted access to the Windows system;  the Centrify Event Id is 6003.
6003.png
You can leverage the Audit Trail admin guide for a full catalog.

 

Windows Remote Login Failure:  The opposite of the event above, it's a warning stating that the user was not authorized to log in from the current station.  This may denote an attempt at lateral movement. The Event Id is 6011.
6011.png
 

Privilege Elevation

Run with Privilege Success:  Indicates successful privilege elevation the Centrify Agent for Windows; this may be a privileged desktop or an application; the event ID is 6012.
6012.png  

Run with Privilege Success:  Indicates an unsuccessful attempt at privilege elevation the Centrify Agent for Windows; this may be a privileged desktop or an application and could be user error or an abuse attempt; the event ID is 6018.

6018.png

 

Create the Filters and Assign a Metric

  1. Go to your CloudWatch console: https://console.aws.amazon.com/cloudwatch/home
  2. Click on Logs and select the radio buttion next to your log group (e.g. Default-Log-Group)
  3. Click Create Metric Filter
    • In filter pattern, type: centrifyEventID=6003
    • Press "Assign Metric" 
  4. In Filter Name, type a unique name for the filter
  5. In Metric details, create a new namespace (e.g. CentrifyAuditTrail) or browse for it if you already have it.
  6. In Metric name, give it a descriptive metric.
    metric-2.png
  7. Press Assign Metric.
  8. Repeat the process for all the metrics you've identified.

Create a Dashboard

Before creating a dashboard, you may want to plan how to visualize the data.  In some instances it's useful to see the aggregate data (# of events), in others it's useful to see a trend (graphs overlapped with time).

Once you have thought of how to visualize the data, it's time to get started with your Dashboard. 

 

  1. Go to your CloudWatch console: https://console.aws.amazon.com/cloudwatch/home
  2. Click on Dashboards > Create Dashboard and give it a name, then press Create Dashboard
  3. To add aggregated information, select the Number widget
  4. Select your Namespace, Dimension and check the metric(s) to be measured
  5. Go to the graphed metrics tab, and select the proper statistic and period  (e.g. sum and 1 day) and press Update Widget.
  6. Once you have the Widget in the dashboard, adjust the size and label.

Repeat the process with the trend using with a line or stacked area.

 

Below is a simple dashboard that includes the metrics above.

dzwin-dash.png 

Create an Alarm

A meaningful alarm could be based on a pattern outside expected behavior, an availability issue or another event (or aggregation of events) based on the risk that wants to be corrected.  This example is for illustration purposes only.

Example:  The threshold for attempted abouse of privilege elevation feature of the Centrify Agent for Windows for  3 or more attempts within a 5 minute period, when this happens, an email should be triggered to the members of the Security Operations distribution list.

  1. Go to your CloudWatch console: https://console.aws.amazon.com/cloudwatch/home
  2. Click Browse Metrics and next to Centrify-dzdo-Denied, click the alarm icon.
  3. In create alarm:
    Name: Alarm-DZWin-Privilege-Abuse
    Whenever: is equal or greater than 3 for 1 consecutive period
    Period: 5 minutes
    Statistic: Sum
  4. Actions
    Whenever this alarm state is Alarm
    Create a new list (secops@your-domain.com)

Trigger the alarm

  1. Sign-in to your Windows instance with your administrator
  2. For any application in your desktop, right click and select "Run with Privilege" 
  3. You should get this message:
    dzwin-denied.png
  4. Repeat 3 more times.  This should trigger the alarm.
    alarm21.png
  5. Review the Dashboard.  After a few minutes, the alarm will return to normal and you'll be notified
    alarms.png

Conclusion

We have only scratched the surface of the capabilities provided by AWS CloudWatch, however in the context of Identity and Access Management, the enrichment of security operations via logs, alerts and dashboards should be done via standard tools; otherwise if each tool duplicates these capabilties, then security operations won't know where to go first.  Centrify provides native plugins for Splunk, IBM QRadar and HP ArcSight.  These tools provide both operational data as well as like the following privilege command pie chart.
most-used.png

 

Related Articles

[Using Centrify Audit Trail for UNIX/Linux with AWS CloudWatch] 

http://community.centrify.com/t5/TechBlog/Labs-Using-Centrify-Audit-Trail-for-UNIX-Linux-with-AWS/ba...

[Security Corner] Reviewing your Access and Privilege Management Model with Centrify tools: http://community.centrify.com/t5/TechBlog/Security-Corner-Reviewing-your-Access-and-Privilege-Manage...  

Setting a Centrify AWS Test Lab: http://community.centrify.com/t5/TechBlog/Labs-Setting-up-an-AWS-Test-Lab-for-Centrify/ba-p/27771
Using AWS OpsWorks (Chef 12) to deploy Centrify DirectControl on EC2 Linux instances: http://community.centrify.com/t5/TechBlog/Labs-Using-AWS-OpsWorks-Chef-12-to-deploy-Centrify-DirectC

Centrify Audit Trail Administrator's guide (2017): https://docs.centrify.com/en/css/suite2017/centrify-audit-events-guide.pdf 

Background

As more and more organizations run infrastructure in IaaS platforms like Amazon AWS, there's an increased need to enhance security operations and prove effective implementation of security controls.  AWS provides a solution set that includes CloudWatch.  

 

About CloudWatch

As defined by Amazon "CloudWatch monitors your Amazon Web Services (AWS) resources and the applications you run on AWS in real time. You can use CloudWatch to collect and track metrics, which are variables you can measure for your resources and applications." 

For more information, check out the Getting Started guide for CloudWatch:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html

 

The goal of this article, is to provide some initial guidance to leverage AWS CloudWatch to collect, track and measure Centrify Audit Trail events in UNIX, Linux systems running in AWS.

For a companion article that describes the process for Windows instances, go here: http://community.centrify.com/t5/TechBlog/Labs-Using-Centrify-Audit-Trail-for-Windows-with-AWS-Cloud...

 

About Centrify Audit Events

Centrify Audit Events (CentrifyAuditTrail) is the cross-platform framework used by Centrify Server Suite to document and provide access, privilege and audit trail event data. When a Centrify-enabled service is invoked, an audit trail event is written to UNIX syslog or Windows event log.  These events are documented in the  Audit Events Administrator's Guide for the current version of Server Suite.  The types or content of the events vary depending on the edition (Standard or Enterprise).

 

For more information, check out the current guide for Server Suite 2017: https://docs.centrify.com/en/css/suite2017/centrify-audit-events-guide.pdf

 

Pre-Requisites

For this lab, you'll need:

  • An AWS Account with the proper VPC setup, privileges in CloudWatch and IAM
  • Active Directory (run by you or managed by Amazon) and the proper VPC name resolution and communications
  • A Centrify zone, sample users and access/privilege setup
  • At least one Linux system joined to Active Directory and the Centrify zone
  • The Linux system should have some Centrify data (e.g. logins, privilege elevations) present in syslog.

Centrify AWS Lab:  You'll need to be at Standard Edition level to follow this lab, more info here:

http://community.centrify.com/t5/TechBlog/Labs-Setting-up-an-AWS-Test-Lab-for-Centrify/ba-p/27771

 

Implementation Overview

  1. Set-up your AWS Linux Instances for CloudWatch Logs (use AWS's docs)
  2. Verify Centrify Audit Trail events in the CloudWatch log group
  3. Identify Access and Privilege-related Metrics provided by Centrify
  4. Create the Filters and Assign a Metric
  5. Create a Dashboard
  6. Create an Alarm.

 

Set-up your AWS Linux Instances for CloudWatch Logs

For information on this topic, please review AWS's documentation:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html

Once you have the /var/log/messages logs for your instances, please proceed to the next section.

 

Verify Centrify Audit Trail events in the CloudWatch log group

  1. Go to your CloudWatch console: https://console.aws.amazon.com/cloudwatch/home
  2. Click on Logs > Click on the log group for your Linux instances (e.g. "/var/log/messages"  or the group you are using for your Linux syslog)
  3. Click on Search log group and in filter events, type "AUDIT_TRAIL"
  4. Verify the results
     audit-trail.png
    If you have a system that was joined to the domain via Centrify, there will be event data about access, privileges and other activities.

Now you have verified that your systems are streaming syslog data with Centrify Audit Trail information.

 

Identify Access and Privilege-related Metrics provided by Centrify

Centrify DirectControl provides access control and role-based privileged elevation; this component is called DirectAuthorize.  DirectAuthorize controls how users access the system and what commands they can run. The implementation of privilege elevation leverages Centrify-enhanced sudo.

 

Example 

The metrics that you'll track will depend in your objectives and in your maturity level.  For illustration purposes, let's track successful and unsuccessful access and privilege elevation in my Linux EC2 instances. After reviewing the Centrify Audit events guide, I identify the following events:

 

Access Control

PAM Authentication Granted:  These events are related to the UNIX framework;  the PAM Auth module is used by any PAM-enabled application.  This can be a catch-all for any app using it (e.g. OpenSSH server, Switch User (su), etc);  the Centrify Event Id is 24100.

pamev.png

Centrify SSHD Denied:  My EC2 instances are running Centrify-enhanced OpenSSH.  I'm interested in looking at this metric, especially on instances with public IPs because it may denote attempts to break-in or move laterally. The Event Id is 27101.

 

Privilege Elevation

Centrify dzdo Granted:  Indicates successful privilege elevation using Centrify-enhanced sudo.  Event id: 30000.

Centrify dzdo Denied :  Indicates denied privilege elevation using Centrify-enhanced sudo.  It may allow to identiy attempts for privilege abuse.  Event id: 30001.

 

Create the Filters and Assign a Metric

  1. Go to your CloudWatch console: https://console.aws.amazon.com/cloudwatch/home
  2. Click on Logs and select the radio buttion next to your log group (e.g. /var/log/messages)
  3. Click Create Metric Filter
    • In filter pattern, type: centrifyEventID=24100
    • Press "Assign Metric" 
  4. In Filter Name, type a unique name for the filter
  5. In Metric details, create a new namespace (e.g. CentrifyAuditTrail) or browse for it if you already have it.
  6. In Metric name, give it a descriptive metric.
    metric.png
  7. Press Assign Metric.
  8. Repeat the process for all the metrics you've identified.

Create a Dashboard

Before creating a dashboard, you may want to plan how to visualize the data.  In some instances it's useful to see the aggregate data (# of events), in others it's useful to see a trend (graphs overlapped with time).

Once you have thought of how to visualize the data, it's time to get started with your dashboard. 

 

  1. Go to your CloudWatch console: https://console.aws.amazon.com/cloudwatch/home
  2. Click on Dashboards > Create Dashboard and give it a name, then press Create Dashboard
  3. To add aggregated information, select the Number widget
  4. Select your Namespace, Dimension and check the metric(s) to be measured
  5. Go to the graphed metrics tab, and select the proper statistic and period  (e.g. sum and 1 day) and press Update Widget.
  6. Once you have the Widget in the dashboard, adjust the size and label.

Repeat the process with the trend using with a line or stacked area.

 

Below is a simple dashboard that includes the metrics above.

 

dash.png

Create an Alarm

A meaningful alarm could be based on a pattern outside expected behavior, an availability issue or another event (or aggregation of events) based on the risk that wants to be corrected.  This example is for illustration purposes only.

Example:  The threshold for attempted abuse of Centrify-enhanced sudo is 3 or more attempts within a 5 minute period, when this happens, an email should be triggered to the members of the secops distribution list.

  1. Go to your CloudWatch console: https://console.aws.amazon.com/cloudwatch/home
  2. Click Browse Metrics and next to Centrify-dzdo-Denied, click the alarm icon.
  3. In create alarm:
    Name:  Alarm-Abuse-dzdo
    Whenever: is equal or greater than 3 for 1 consecutive period
    Period: 5 minutes
    Statistic: Sum
  4. Actions
    Whenever this alarm state is Alarm
    Create a new list (secops@your-domain.com)

Trigger the alarm

  1. Sign-in to your Linux instance with homer
  2. Type 'dzdo su - root' and press enter
  3. You should get this message:
    [homer@cdctest2 ~]$ dzdo su -
    Sorry, user homer is not allowed to execute '/bin/su -' as root on cdctest2.\
  4. Repeat 3 more times.  This should trigger the alarm.
    alarm.png
  5. Review the Dashboard.  After a few minutes, the alarm will return to normal and you'll be notified
    alarm2.png

Conclusion

We have only scratched the surface of the capabilities provided by AWS CloudWatch, however in the context of Identity and Access Management, the enrichment of security operations via logs, alerts and dashboards should be done via standard tools; otherwise if each tool duplicates these capabilties, then security operations won't know where to go first.  Centrify provides native plugins for Splunk, IBM QRadar and HP ArcSight.  These tools provide both operational data as well as like the following privilege command pie chart.
most-used.png

 

Related Articles

[Labs] Using Centrify Audit Trail for Windows with AWS CloudWatch:

http://community.centrify.com/t5/TechBlog/Labs-Using-Centrify-Audit-Trail-for-Windows-with-AWS-Cloud...

[Security Corner] Reviewing your Access and Privilege Management Model with Centrify tools: http://community.centrify.com/t5/TechBlog/Security-Corner-Reviewing-your-Access-and-Privilege-Manage...  

Setting a Centrify AWS Test Lab: http://community.centrify.com/t5/TechBlog/Labs-Setting-up-an-AWS-Test-Lab-for-Centrify/ba-p/27771
Using AWS OpsWorks (Chef 12) to deploy Centrify DirectControl on EC2 Linux instances: http://community.centrify.com/t5/TechBlog/Labs-Using-AWS-OpsWorks-Chef-12-to-deploy-Centrify-DirectC

Centrify Audit Trail Administrator's guide (2017): https://docs.centrify.com/en/css/suite2017/centrify-audit-events-guide.pdf 

Background

As Amazon AWS's popularity increases as an IaaS platform, many organizations are looking to extend current capabilities like consolidated identities and privilege management out to those environments.

 

AWS provides a framework for DevOps called AWS OpsWorks.  This framework allows the use of solutions like Chef or Puppet to manage the lifecycle of Linux or Windows instances.

 

Centrify customers and prospects have requested sample configurations to control the lifecycle of the deployment of Centrify DirectControl out in AWS.  The typical goals are:

  • Windows or Linux instances are launched in AWS
  • Centrify DirectControl is installed
  • The system is joined to Active Directory (Linux) and the Centrify Zone, Child Zone and/or Computer Role (Windows, Linux)
  • On termination, the system(s) leave the domain and Centrify zone (freeing-up the Centrify license)

This way, while the system is running:

  • Administration is Centralized and not duplicated (like with SSH keys)
  • Assurance is achieved, for example, with MFA
  • Privileged User Management is based on roles
  • There are reporting and attestation mechanisms.

Pre-flight Checklist

  • You have AWS account set up with a VPC set up correctly for DNS and Active Directory communication
  • Your account has AWSOpsWorksFullAccess and permission to create, modify, read, list and delete IAM Policies and Roles
  • You have Active Directory (managed by you or with Amazon) and a Centrify Zone
  • You have tested joining a Linux system to your AD and Centrify zone successfully.  Your users can authenticate and perform privilege management duties.
  • You have an AWS S3 Bucket and permission to create and upload files to it.
  • You have a Kerberos key table for a service account authorized to join systems to Active Directory and Centrify Zones
    For an article on this topic, click here:  http://community.centrify.com/t5/TechBlog/DevOps-Creating-a-Kerberos-Keytab-to-Automate-DirectContro...
  • You know the  DN for your Computers container (e.g. "ou=servers,ou=centrify"), this is where the service account can create (or delete) computer objects.
  • You have a Centrify Repo credential, zone information (E.g. Name) or an alternate repo with the Centrify packages for your platform type (yum, apt, zypper)
  • Optional:  A domain-joined Windows server with Centrify tools (for verification purposes)
  • Optional:  You have an AWS key-pair to deploy our EC2 instances to connect for troubleshooting purposes

A Centrify-AWS Lab article has been written for the pre-requisites

http://community.centrify.com/t5/TechBlog/Labs-Setting-up-an-AWS-Test-Lab-for-Centrify/ba-p/27771

You need to be at the Standard Edition set up to follow this lab.

statepoint5.png

 

Note:  for abbreviated instructions and the source code for the methods use here, go to https://github.com/centrify/AWS-OpsWorks

 

Supported Platforms

  • Amazon Linux
  • Centos 7
  • Red Hat Enterprise 7
  • Ubuntu 16.04 LTS
  • Ubuntu 14.04 LTS
  • Chef 12

Configuration Overview

  1. Copy your Kerberos keytab to your S3 bucket
  2. Create an IAM policy for use by the IAM role for the instances created by OpsWorks
  3. Create an IAM role to grant EC2 instances to access AWS resources
  4. Create and configure Chef 12 OpsWorks custom stack
  5. Add a layer to your stack
  6. Add instances and troubleshooting
  7. Verifying success for provisioning and deprovisioning

 

Copy your Kerberos keytab to your S3 bucket

  1. Sign-in to the system that has the keytab (if the keytab file is in Linux, copy it to your Windows system)
  2. Open Go to the S3 console: https://console.aws.amazon.com/s3/home
  3. Click your S3 bucket and then click upload
    krb-upload.PNG
  4. Press Upload, click on the uploaded file and note the link.  E.g.
    https://s3-your-region.amazonaws.com/your-bucket-name-here/login.keytab

Create an IAM policy for use by the IAM role for the instances created by OpsWorks

  1. Go to the IAM home:  https://console.aws.amazon.com/iam/home and click on Policies, then Create Policy
  2. Select "Create your own Policy"
  3. In the review policy page, give it a name (e.g. Centrify-Keytab-S3-Access-Policy and a description)
  4. The policy should contain the following
    {
    	"Version": "2012-10-17",
    	"Statement": [ 
    		{
    		"Effect":"Allow",
    		"Action":[
    			"s3:GetObject",
    			"s3:ListObject"
    		],
    		"Resource":[ "arn:aws:s3:::your_s3_bucket/login.keytab" ]
    		},
    		{
    		"Action": ["ec2:*",
    			"iam:PassRole",
    			"cloudwatch:GetMetricStatistics",
    			"cloudwatch:DescribeAlarms",
    			"ecs:*",
    			"elasticloadbalancing:*",
    			"rds:*"],
    		"Effect": "Allow",
    		"Resource": ["*"] 
    		}
    	]
    }
    Substitute "your_s3_bucket" for the name of the S3 bucket you have from the AWS Centrify lab or from your environment.
  5. Press Validate Policy and then Press Create Policy.

Now you have a Policy.
policy-1.PNG

 

Create an IAM role to grant EC2 instances to access AWS resources

  1. Go to the IAM home:  https://console.aws.amazon.com/iam/home and click on Policies, then Create New Role
  2. In Select Role Type  under Amazon Role Service Amazon EC2, click Select
  3. In attach policy, find the previously-created policy  (e.g. Centrify-Keytab-S3-Access-Policy) and check the box next to it, then press Next Step.
  4. In set role name and review, give the role a name and optionally a description.
  5. Click on the newly-created role and go to the Trust Relationship tab and press edit and substitute with this:
    { 
        "Version": "2012-10-17", 
        "Statement": [ 
            { "Effect": "Allow", 
            "Principal": { 
                "Service": [ "opsworks.amazonaws.com", "ec2.amazonaws.com" ]
                
            }, "Action": "sts:AssumeRole" 
                
            }] 
        
    }
  6. Press Update Trust History

Now you have a role associated to your policy
role-1.PNG

Create and configure Chef 12 OpsWorks custom stack

In this step, we'll configure the stack to be used for deploying DirectControl, here we'll add custom JSON with information about your environment.

 

Create a Stack 

  1. Go to the AWS OpsWorks home:  https://console.aws.amazon.com/opsworks/home and Press Add Stack
  2. Select Chef 12 stack and complete the following info:
    • Name, Region and Subnet > based on your AWS Settings
    • Operating System > Linux and select your OS/version based on the supported platforms above
    • Default SSH Key > select yours if needed (do this at first to troubleshoot)
    • Use Custom Chef cookbok > Yes
    • Repository type: Git
    • Repository URL:  https://github.com/centrify/AWS-Opsworks.git
  3. Select Advanced Options and in Custom JSON add:
    {
    	"CENTRIFY_REPO_CREDENTIAL":"your-repo-credential",
    	"CENTRIFYDC_JOIN_TO_AD": "yes",
    	"CENTRIFYDC_ZONE_NAME": "AWS",
    	"CENTRIFYDC_KEYTAB_S3_BUCKET": "centri-bucket",
    	"CENTRIFYDC_ADDITIONAL_PACKAGES": "centrifydc-openssh",
    	"CENTRIFYDC_ADJOIN_ADDITIONAL_OPTIONS": "--ldap --verbose --container ou=servers,ou=centrify"
    }
    The information (in red) in this JSON file is based on my example configuration:
    CENTRIFY_REPO_CREDENTIAL is the cyphered username/password combination assigned to you in the Centrify Download repo page.
    CENTRIFY_ZONE_NAME is the name of the Centrify Zone in AD that I want my Linux systems to be joined to
    CENTRIFY_KEYTAB_S3_BUCKET is the name of the S3 bucket that contains the login.keytab file for the service account.
    CENTRIFY_ADJOIN_ADDITIONAL_OPTIONS:  has been set with the --container option that points to the DN of where my service account can add computer objects (e.g. ou=servers,ou=centrify)
  4. Press Add Stack

Add a Layer

The desired state is that when the system is launched, the Centrified system is joined to AD and to the Zone.  Once the system is shutdown, the system leaves AD, the Centrify license is freed and the access/privilege reports reflect the proper information.

  1. In your newly-created stack, click on layers and press Add Layer
  2. Give it a name and a short name and press Add Layer
  3. In the layers, click on Recipes tab, this will display the Custom Recipes lifecycle
    • Setup box:  centrify_agents::deploy_centrifydc
    • Shutdown box:  centrify_agents::undeploy_centrifydc
      Press Save
  4. On the Network tab, select the option based on your AWS VPC setup (e.g. Public IP addresses yes)
  5. On the Security tab, press Edit and in
    Security Groups select your Security group
    EC2 Instance Profile select the IAM Role created in the previous step (e.g. Centrify-IAM-Role-4EC2)
  6. Press Save.

Adding instances to your stack  

Adding instances is the opportunity to debug your newly-created stack recipes.

  1. In your stack, click Instances and click Add an Instance
    • Hostname:  give it a name (e.g. test1)
    • Size: select a size (e.g. t2-micro)
    • Subnet: select a subnet from your VPC (must have AD connectivity and DNS resolution)
  2. Press Add Instance
    cdc-inst.PNG
  3. Press Start

 

Troubleshooting and Debugging

Your troubleshooting can happen from the OpsWorks console.  If there's an issue with your setup, the console will provide you with an error and a log with the actions yielded by Chef.  For example, while debugging, I saw this issue:

issue.png 

Note that the erros will be quite explicit.  The category of errors that you'll see may be dependent on the sanity checks that you perform along the way.

 

Known Errors

  • Invalid CENTRIFYDC_ADDITIONAL_PACKAGES attribute:   the JSON value contains an invalid value.  Valid entries include:  centrifydc-openssh, centrifydc-ldapproxy, etc.  Modify the value of the custom JSON attributes in the stack.
  • Either user your-user@YOURDOMAINNAME. does not have sufficient permissions to update
    the YOUR_ZONE zone computer information: this means that the service account can't create the computer object in the target container.  Note that if you did not modify the JSON parameter for the stack called CENTRIFY_ADJOIN_ADDITIONAL_OPTIONS to have the --container switch with the proper DN, adjoin will try to add the system to the default computers container in AD.  This is atypical.

 

Verifying Success - Provisioning

The layman's test is to be able to sign-in to the system and perform privilege elevation
success.PNG

The OpsWorks console shows the system online.

lisa.png

In Active Directory, there should be a computer object in the target OU:

success2.png

 Attestation reports can be generated with who has access to which system(s), what type of access they have, what privileged commands they can run, and where the privileges came from.

reportcdc.png

 

Verifying Success - Deprovisioning

 The best test here is to stop the system and verify that the objects don't exist in AD and the system no longer is present in the Access/Privilege reports.


gone1.PNG

 

Conclusion

You can leverage Centrify's Github https://github.com/centrify/ for different private and public cloud configurations.  This scenario is only the first of many to come.   

 

Related Articles

Setting a Centrify AWS Test Lab: http://community.centrify.com/t5/TechBlog/Labs-Setting-up-an-AWS-Test-Lab-for-Centrify/ba-p/27771

Creating a Kerberos Keytab for DirectControl joins/unjoins: http://community.centrify.com/t5/TechBlog/DevOps-Creating-a-Kerberos-Keytab-to-Automate-DirectContro...

Background

In order to automate Active Directory instance joins and unjoins, we need a keytab file corresponding to an AD user that has the proper rights in AD and in the Centrify zone.

Because a keytab is pretty much a credential, we are going to adhere to the following principles:

  • The credential for the keytab shall have least minimum access
  • The password for the credential shall be unknown
  • The keytab file shall always be deleted once it's used.

 

What you'll need:

  • You may need assistance from your Active Directory lead
    • Why? First and foremost separation of duties.  Also, in practicality, the UNIX/Linux/Mac teams in enterprises are different from the AD teams.
    • What do they need to do for me?  They need to create an AD account, provide delegation (see below) and they may have to type their credential when running the adkeytab command.
    • How many times do we need to do this?  Only once. 

Create an AD User

When you create an AD service account, you have to align with the security policy governing these accounts.  The overhead can come depending on the frequency of password changes.  Since adkeytab scrambles the password and it's effectively unknown, the account can be set with a Password Never Expires/User cannot change password flag, however for due-diligence you may rotate it once a year.  Each time the password is rotated, the key table file has to be generated again.

 

  1. Open Active Directory Users and Computers
  2. Navigate to the container or OU for this service account
  3. Select New > User
  4. In the New Object form, set the information based on your naming convention
    ad-joiner.png
    Note:  the "common name" of the user is typically the same as the display name.  If this contain spaces, you have to make note of this for when you use the adkeytab command (samaccountname vs cn).
  5. In the New Object - User form, type a password and set the options according to your service account policy
    ad-joiner2.png
    Remember, if you do the right thing, adkeytab will randomize the password and this can be a compensating control.  If you are required to change this password, you must re-generate the keytab and redistribute, otherwise your scripts or recipes will fail.

If you prefer PowerShell instead, you can use the New-ADUser commandlet.

Now you should have a service account.  Make note of the username (e.g. ad-joiner) vs. the cn (AD Joiner Service Account).

 

Delegate Permissions

There are 2 delegations needed to make sure the automation of joins/removals works.  The service account should be able to create/remove  computer objects in your designated AD container for UNIX/Linux or Mac systems, plus if you're using Centrify zones, the system has to have the ability to join, remove and modify computer profiles.

Optionally, there's a third delegation related to Computer Roles (contained in AD groups); for this you need to provide the "manage group membership" delegation to the target groups (or OU that contains the groups).

 

Let's illustrate the steps using this OU structure

oustruc.png

 In this scenario, I plan to add the UNIX/Linux computers to the Servers SubOU under Centrify; this means that I have to delegate at that level to preserve the least privilege principle.  In a real-world deployment, you may have a different layout (perhaps based on sites), in that case you have to delegate in multiple places.

 

To delegate the computer object in the target OU 

  1. In ADUC (as a privileged AD user), right click the Servers SubOU and select "Delegate Control"
  2. Welcome Page > Next
  3. Users or Groups > press Add, find the service account, select and press OK, then Next
  4. Task to Delegate > Select "Create custom task to delegate" and press Next
  5. Object Type > Select "Only the following objects in the folder"; check the Computer Objects box and check  Create and Delete.
    custom.png
  6. Permissions tab > Check "Full Control" under permissions and press Next.
    You can dial this down, however we have this scoped down to the OU and type of object.
  7. Completing page > Finish

 Now the service account can create/remove computer objects in the Servers container.

 

To delegate at the Centrify Zone level

You must know all the Centrify zones that the service account will be leveraged for automation.  In my example I have one zone (AWS). Centrify provides PowerShell to perform bulk delegations (see Set-CdmDelegation, in this link)

  1. Open Centrify DirectManage Access Manager
  2. If needed, open your target zone(s)
  3. Right-click the zone and select "Delegate Zone Control"
  4. Selected Objects > Press Add and find and select  your service account, press OK and Next
  5. Tasks to Delegate > check join and modify computer operations to the zone (3 check boxes)
    Access Manager - delegation of computer ops.jpg
  6. Completing Page > Press Finish.

At this point, if you're not using DirectAuthorize Computer Roles you are done.

Note:  You can always verify delegations by running the "Zone Delegation Report"

 

Optional:  To delegate for Computer Roles 

Computer Roles allow the grouping of systems as "teams of servers" this gives administrators the flexibility granting access/privileges to systems to  multiple user populations, the only operation required is the the system is a "Member" of the Computer role, and this can be accomplished any time or during system setup by automating add/removal of the computer account into the AD security groups that make-up the computer role.

 

In my example, I'm leveraging the Centrify recommended OU structure and all my AD Security groups for the purposes of Computer Roles are stored in the Computer Roles SubOU under the Centrify OU.  This means that I only need to make one delegation.  Based on your design, this may vary and you may have to perform multiple delegations.

 

  1. In ADUC (as a privileged AD user), right click the Computer Roles" SubOU and select "Delegate Control"
  2. Welcome Page > Next
  3. Users or Groups > press Add, find the service account, select and press OK, then Next
  4. Task to Delegate > Select "Modify Membership of a Group" and press Next
    ADUC - delegation membership group.jpg
  5. Completing > Press Finish

From this point on, the service account will be able perform add/removals of objects into any existing or new AD group in that container.

 

Create the Keytab File

Creating the keytab may require two individuals.  One individual can run privileged commands on UNIX/Linux/Windows, the other is an authorized AD user that can perform certain operations on the AD user (like changing it's password).

You need to know the account's samaccounname vs the common name.  You can quickly see this using the Attribute Editor in ADUC or PowerShell
adjoiner.png

This is important because the last parameter of the adkeytab command is the common name.  If you assume they are the same, you may hit this error:

 

AD Object found: CN=AD Joiner,OU=Service Accounts,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net
Error: The account name does not match the SAM account name. You must supply both on the command line.
Adkeytab return code: 23
Failed: Adopt Account: ad-joiner

 

Here's a simple way of constructing an adkeytab command

  • Elevation required:  root or credential for sudo or dzdo required:  sudo adkeytab
  • Operation:  adopt  (needs the sammacount name, an authorized account and the common name):  --adopt
  • Authorized user (e.g. AD administrator): --user admin
  • AD user: --samname ad-joiner
  • Keytab File name (e.g. login.keytab):  --keytab login.keytab  (the file will be owned by root)
  • Common Name (if the CN is different from samaccount name):  "AD Joiner"  (since there are spaces, it has to be double-quoted)
  • Verbose output recommended (-V)

Here's the command

dzdo adkeytab --samname ad-joiner --adopt --user admin --keytab login.keytab -V "AD Joiner"

Here's a sample output:

dzdo adkeytab --samname ad-joiner --adopt --user admin --keytab login.keytab -V "AD Joiner"
[dzdo] password for lisa:
ADKeyTab version: CentrifyDC 5.4.0-286
Options
-------
use machine ccache: no
domain: awsrealm.centrifying.net
server: null
user: admin
container: null
account: AD Joiner
trust: no
des: no
admin@AWSREALM.CENTRIFYING.NET's password:
Attempting bind to awsrealm.centrifying.net site:Default-First-Site-Name server:dc1.awsrealm.centrifying.net: ccache:MEMORY:0x644640
Bind successful to server dc1.awsrealm.centrifying.net
Searching for AD Object: filter = (samAccountName=ad-joiner), root = DC=awsrealm,DC=centrifying,DC=net
AD Object found: CN=AD Joiner,OU=Service Accounts,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net
Key Version = 4
Activating AD account: CN=AD Joiner,OU=Service Accounts,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net. Clearing existing SPNs: No
Account 'CN=AD Joiner,OU=Service Accounts,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net' All SPNs already present
Adding managed account keys to configuration file: AD Joiner
Changing account 'AD Joiner' password with user 'rpimentel@AWSREALM.CENTRIFYING.NET' credentials.
Searching for AD Object: filter = (samAccountName=ad-joiner), root = DC=awsrealm,DC=centrifying,DC=net
AD Object found: CN=AD Joiner,OU=Service Accounts,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net
Key Version = 5
Updated properties to config file /etc/centrifydc/centrifydc.conf.
Success: Adopt Account: AD Joiner

Verify the keytab is correct.  List the principals

 dzdo /usr/share/centrifydc/kerberos/bin/klist -kt login.keytab
Keytab name: FILE:login.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   5 04/20/2017 17:49:43 ad-joiner@AWSREALM.CENTRIFYING.NET
   5 04/20/2017 17:49:43 ad-joiner@AWSREALM.CENTRIFYING.NET
   5 04/20/2017 17:49:43 ad-joiner@AWSREALM.CENTRIFYING.NET
   5 04/20/2017 17:49:43 ad-joiner@AWSREALM.CENTRIFYING.NET
   5 04/20/2017 17:49:43 ad-joiner@AWSREALM.CENTRIFYING.NET

 Testing your Keytab for Join/Removal Operations

 You can test the keytab by removing and rejoining Active Directory.  You'll need to use kinit to authenticate with the key table file, then leverage adjoin or adleave to check the results.  Optionally, you can use the --computerrole switch of adjoin to check for those operations.

 

Authenticating using the key table file

  1. Sign-in to your system with a privileged user (remember, the key table file is owned by root)
  2. Change directories to the location of the key table file.
  3. Run the kdestroy command
    /usr/share/centrifydc/kerberos/bin/kdestroy
  4. Run kinit with the kt option to get a TGT for the service account and klist to verify the TGT
    sudo /usr/share/centrifydc/kerberos/bin/kinit -kt login.keytab ad-joiner
    [dzdo] password for lisa:
    $ /usr/share/centrifydc/kerberos/bin/klist
    $ dzdo /usr/share/centrifydc/kerberos/bin/klist
    Ticket cache: FILE:/tmp/krb5cc_cdc1702888528_Hw29E6
    Default principal: ad-joiner@AWSREALM.CENTRIFYING.NET
    
    Valid starting       Expires              Service principal
    04/20/2017 17:59:19  04/21/2017 03:59:19  krbtgt/AWSREALM.CENTRIFYING.NET@AWSREALM.CENTRIFYING.NET
            renew until 04/21/2017 17:59:20
    

 

Testing adjoin and adleave operations

Depending on the state of your system, you may test removal or joining first.  Since my system is already joined, I'm testing removal first (note that I switched to ec2-user since I was logged in as an AD user).  Note that I'm copying the centrify-populated krb5.conf file, since this file will be rolled-back once the system left the domain.

$ dzdo su ec2-user
$ sudo cp /etc/krb5.conf .
$ sudo adleave --remove Using domain controller: dc1.awsrealm.centrifying.net writable=true Left domain. Centrify DirectControl stopped.

Attempting adjoin to the Zone an the "Utility-Servers" computer role.

$ sudo env KRB5_CONFIG=krb5.conf  /usr/share/centrifydc/kerberos/bin/kinit -kt login.keytab ad-joiner
$  sudo adjoin --zone AWS --container ou=servers,ou=centrify --computerrole Utility-Servers awsrealm.centrifying.net
Using domain controller: dc1.awsrealm.centrifying.net writable=true
Join to domain:awsrealm.centrifying.net, zone:AWS successful

Centrify DirectControl started.
Initializing cache
.
You have successfully joined the Active Directory domain: awsrealm.centrifying.net
in the Centrify DirectControl zone: CN=AWS,CN=Zones,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net


You may need to restart other services that rely upon PAM and NSS or simply
reboot the computer for proper operation.  Failure to do so may result in
login problems for AD users.

 

What next?

At this point you have to distribute your keytable file to your distribution points web server, repository, file share, etc. Note that this file needs to be deleted after it's used for added security.  For example, you can upload this file to an AWS S3 bucket to use it with your AWS OpsWorks or CloudFormation scripts.

Related Articles

 

The goal of this article is to set up the building-blocks to test Centrify Server Suite and Privilege Service in an AWS environment.  This article is the foundation for several how to guides in development.

 

Audience:  Technical leads  looking to test capabilities in a lab environment.

Knowledge level:  You must be familiar with AWS, Linux , Windows, TCP/IP, Domain Name System and with basic Centrify product capabilities

 

Levels

  1. Standard Edition Level - allows you to complete labs related to Centrify DirectControl
  2. Privilege Service Level - allows you to complete labs related to Privilege Service

 

Basic AWS Setup

The basic steps to set up an AWS Playground lab are:

  1. Sign Up for AWS

  2. Create an IAM User (optional)

  3. Create a Key Pair

  4. Create a Virtual Private Cloud (VPC)

  5. Create a Security Group

Once you have this set-up, we can talk about some planning scenarios.

 

Planning to modify your Security Rules

  1. In this playground, here's the connectivity you'll need:
    • RDP from your client to your Windows systems
    • SSH from your client to your Linux instances
    • You need your instances to talk to each other via AD ports and others (to simplify things, you can allow any traffic between your EC2 instances).
      sec-rules.png

Create an S3 Bucket

Official instructions here: http://docs.aws.amazon.com/AmazonS3/latest/UG/CreatingaBucket.html

  1. Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/.
  2. Click Create Bucket.
  3. In the Create Bucket dialog box, in the Bucket Name box, type a name for your bucket (nmust be unique)
  4. In the Region box, click the region where you want the bucket to reside.
  5. Optional - Enable logging.
  6. Click Create.

 

Sanity Check # 1
At this point, you should have:

  • At this point you should have several credentials:
    • An amazon account (your root account) that has all the rights to your AWS account - this account is your email account.
    • If you created an IAM user, you should have that credential too.
  • An AWS key-pair that allows you to SSH into Linux instances using the ec2-user or decrypt Windows Administrator passwords.
  • You have created a virtual private cloud (VPC)
  • You have configured a security group that allows you to access the AWS EC2 instances/services  and communications between them.  You'll be using this security group for all newly-created EC2 instances.
  • You have an S3 bucket that you can use later to host files.

 

Active Directory in AWS

Active Directory in AWS (or other clouds) can be deployed in different ways.  This all boils down to the connectivity between corporate and AWS.  If there's a dedicated VPN, provided that DNS and Security rules are well-designed, you an either extend or duplicate your AD infrastructure in AWS.

For more information:  http://docs.aws.amazon.com/quickstart/latest/active-directory-ds/architecture.html

 

multi.png

This article is not concerned with that.  If you are doing a lab, most likely you'll be using the scenario where AD is run in AWS (hosted by you in EC2 instances) or hosted by AWS (SimpleAD or AWS Directory Service).

 

1. Setting-up Active Directory in AWS

Hosting your own Active Directory Domain Controller in an AWS EC2 Instance

There are many resources like the official recipe from Amazon here: http://docs.aws.amazon.com/quickstart/latest/active-directory-ds/step1.html, however for a small lab, I recommend that you have the following:

  • One VPC
  • One EC2 Instance running your domain controller and DNS (you could also leverage Route53)
  • One EC2 Instance running your member server (e.g. APP1 or MEMBER)

For setup, you can can reuse the instructions from the Microsoft Test Lab Guides to onboard a DC1 and APP1 servers.

 

2. Configuring Microsoft DNS with a  Forwarder

If you are managing your own DC running Microsoft DNS, as a measure, you may want to add the Amazon-provided DNS servers as forwarders.  This will ensure public name resolution to AD clients.

On your DC, in an administrative powershell, run this command:

Set-DnsServerForwarder -IPAddress "w.x.y.z" -PassThru

Where w.x.y.z is your Amazon-provided DNS server IP address.
forwarder.png

 

Using an Amazon-hosted option

Simple AD:  http://docs.aws.amazon.com/directoryservice/latest/admin-guide/cloud_setup_tutorial.html

Active Directory:  http://docs.aws.amazon.com/directoryservice/latest/admin-guide/create_directory.html

 

Note that whether you set up your own, or are using a hosted option, you should have the domain name,  IP address(es) for the domain controller(s) and an admin credential.  The addresses are needed for the next step, and the credential is needed to manage AD with tools like AD Users and Groups.

 

3. Modify DHCP Option Sets to align with your new DNS

 Without properly functioning DNS, there is no Active Directory functionality.  DHCP option sets in AWS make your life very easy and you don't need to add Route53 (AWS's DNS Service) complexity.

 

  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.

  2. In the navigation pane, choose DHCP Options Sets.

  3. Select Create DHCP Options Sets.

  4. Add the options for your domain name and DNS Servers (your DC and the Amazon-provided DNS).  In the name tag, provide a descriptive name, domain name servers, type the IP address of the DC(s) and an Amazon-provided DNS, and the AD domain name in the domain name.
    opt-set-pic.PNG

  5. Press Yes, Create
  6. In the navigation pane, choose Your VPCs.

  7. Select the VPC(s) for your lab, and select Edit DHCP Options Set from the Actions list.

  8. In the DHCP Options Set list, select the set you created  from the list, and then choose Save
    opt-sets.PNG

 

Sanity Check # 2
At this point, you should have:

  • A running your domain controller managed by you or hosted Active Directory and you should be able to connect to it as an administrative user.
  • Your domain controller should be running Microsoft DNS hosting the AD records.  Write down the IP address and domain name.
  • DNS resolution in your subnets, when you launch an EC2 instance and you ping your DC by name, it should be resolvable as well as public FQDNs.
    scriptx.png

 

Centrify Standard Edition Lab Setup - Member Server

The member server will be running the Active Directory and Centrify tools.  In addition, we can use the server as a Centrify Connector and DirectAudit Infrastructure.  This post will focus on AD and Centrify tools:

  • DirectManage Access Manager - GUI tool manipulate Centrify data in AD
  • DirectManage PowerShell - Use PowerShell commandlets to manage Centrify data in AD
  • GPMC Extensions - configure and enforce Group Policies in UNIX, Linux and Mac systems
  • Centrify PuTTY - Leverage Kerberos with PuTTY
  • Licensing Service - A required component for Centrify Standard Edition 2017 and above
  • Report Services - Generate and customize attestation reports

Add Windows Features

  1. Launch a Windows Server (2012R2 or 2016) and log in as the local administrator.
  2. Make sure the system can ping the domain controller by name.
  3. Run PowerShell as Administrator and join the domain
    Add-Computer -DomainName domain.name -Credential administrator@domain.name
    Provide the credentials and reboot.
  4. Sign-in to your member server as your domain administrator account, re-launch PowerShell as administrator and add the Group Policy Management, DNS and Active Directory management tools.
    Add-WindowsFeature GPMC, RSAT-DNS-Server, RSAT-ADDS

 

Install Centrify Standard Edition Tools

  1.  Download Centrify Standard Edition 2017 (or Enterprise to use later)
    https://www.centrify.com/support/customer-support-portal/download-center/
  2. Unzip the file, navigate to the DirectManage folder and run Setup.  These are the components you're adding
    comp.png
  3. Follow the prompts.  You may have to follow the instructions to set up Report Services.  For more information go here:
    http://community.centrify.com/t5/TechBlog/LABS-Setup-and-test-the-Centrify-Reports-feature-of-Server...

 Initialize Centrify Standard Edition

  1. Double-click the Access Manager icon, this will start the setup wizard
  2. Welcome page - press next
  3. User Credentials - press next (unless you're not using a privileged user)
  4. Deployment Structure - Check the box > generate default deployment structure
  5. Choose container - Browse - Select your domain and press OK.
  6. License Container - should be set to  [your domain]/Centrify/Licenses and press Next
    You'll be informed that the container will be set as read only for all users.  Press Yes.
  7. Install License Keys - Type your centrify license key and press add, then press next
  8. Default Zone Container - Should be set to [your domain]/Centrify/Zones, press next
  9. Delegate Permission - Uncheck the box (we aren't placing systems in the default computers container)
  10. Notification Handler - Should be unchcecked, press next
  11. Summary - press next
  12. Competing Page -  press Finish.  Access Manager will open.  Close it.

Initializing Access Manager, has deployed the Centrify recommended OU structure.  This is where the objects will reside for Centrify-related data.
oustruc.png

For more information about this OU structure, check out @Fabrice's article here:
http://community.centrify.com/t5/TechBlog/Best-practice-Active-Directory-OU-structure/ba-p/21470

 

At this point you should have the base configuration to perform the Standard Edition labs.

 

Sanity Check # 3

At this point, you should:

  • Have a domain-joined Windows Server and you should be able to log in with domain users.
  • The system should have the GPMC and RSAT ADDS tools
  • The system should have Centrify DirectManage Access Manager, PowerShell, PuTTY and Centrify Report Services
  • In Active Directory, you have laid-out the Centrify-recommended OU structure.

 

Set-up a Cast of Characters and Implement a basic Access and Privilege Model

Users, Groups and Roles

  • ad-admin - your AD Domain Administrator
  • cps-admin (privilege service) - is your
  • Lisa  -  Linux Administrator (will be a member of AWS Windows Administrator)
  • Maggie  - Windows Administrator (will be an AWS Linux Administrators)
  • Bart  - Security Officer (will be an AWS Security Analyst)
  • Homer  - An auditor (will be a Mixed Auditor)
  • ad-joiner - Service account for automated joins
  • centrify.reports - Service account for Report Services

Groups

  • Unix-Users - Catch-all group for all UNIX users (unix-users);  maggie, bart and homer are members.

Sample User Creation Script

Write-Host "Creating Users..."  -ForegroundColor red -BackgroundColor white
$ou = New-ADOrganizationalUnit -Name AWSDemo -Path "dc=example,dc=com" -ProtectedFromAccidentalDeletion $false
$oupath = (Get-ADOrganizationalUnit -Filter 'Name -like "AWSDemo"').DistinguishedName 
$passwd = (ConvertTo-SecureString "AWSPlayGround2017!@" -AsPlainText -force)
New-ADUser -Name "Lisa" -SamAccountName lisa -AccountPassword $passwd  -Description "Linux Administrator" -ChangePasswordAtLogon $false -Path $oupath -Enabled $true 
New-ADUser -Name "Bart" -SamAccountName bart -AccountPassword $passwd  -Description "Security Officer" -ChangePasswordAtLogon $false -Path $oupath -Enabled $true 
New-ADUser -Name "Maggie" -SamAccountName maggie -AccountPassword $passwd  -Description "Windows Administrator" -ChangePasswordAtLogon $false -Path $oupath -Enabled $true 
New-ADUser -Name "Homer" -SamAccountName homer -AccountPassword $passwd  -Description "Auditor (Cross-platform)" -ChangePasswordAtLogon $false -Path $oupath -Enabled $true 
New-ADGroup -Name "unix-users" -GroupCategory Security -GroupScope Global -Path $oupath
Get-ADGroup unix-users | Add-ADGroupMember -Members Lisa, Bart, Maggie, Homer
Write-Host "User creation completed."  -ForegroundColor red -BackgroundColor white

 This script creates our cast of AD users and a group inside the AWSDemo OU.  Make sure you change the text in red to fit your environment.

script0.png

Create and Configure a Centrify Zone

Our zone name will be AWS, and it will have a very simple set up.  All users will be UNIX-enabled and there will be three roles:  A UNIX Sysadmin role, a Windows Sysadmin role and a regular UNIX user role.

 

Zone Creation and User UNIX-enablement

$zone = New-CdmZone -Name AWS -Container "CN=Zones,OU=UNIX,DC=centrify,DC=vms"
Write-Host "Unix-Enabling Users..."  -ForegroundColor red -BackgroundColor white
New-CdmUserProfile -Zone $zone –User lisa@example.com -login lisa -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
New-CdmUserProfile -Zone $zone –User bart@example.com -login bart -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
New-CdmUserProfile -Zone $zone –User maggie@example.com -login maggie -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
New-CdmUserProfile -Zone $zone –User homer@example.com -login homer -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
Write-Host "Unix-enabling complete." -ForegroundColor red -BackgroundColor white

 This script creates the AWS zone and enables our users 

script1.png 
UNIX and Windows Admin Roles + Assignments

$cmd1 = New-CdmCommandRight -Zone $zone -Name "Run any command as root" -Pattern "*" -MatchPath "*" -Authentication user 
$cmd2 = Get-CdmPamRight -Zone $zone -Name "login-all" 
$role1 = New-CdmRole -Zone $zone -Name "UNIX Sysadmin" -UnixSysRights login, ssologin, nondzsh, visible -HasRescueRight $true -AuditLevel possible

Add-CdmCommandRight -Right $cmd1  -Role $role1 
Add-CdmPamRight  -Right $cmd2 -Role $role1 

New-CdmRoleAssignment -Zone $zone -Role $role1 -TrusteeType ADUser  -ADTrustee (Get-ADUser -Filter 'Name -like "lisa"')

$desktop1 = New-CdmDesktopRight -Zone $zone -Name "Admin Desktop" -RunasSelfGroups "Builtin\Administrators" -RequirePassword $true
$role2 = New-CdmRole -Zone $zone -Name "Windows Admin" -WinSysRights console, remote -AuditLevel possible

Add-CdmDesktopRight -Role $role2 -Right $desktop1
New-CdmRoleAssignment -Zone $zone -Role $role2 -TrusteeType ADUser  -ADTrustee (Get-ADUser -Filter 'Name -like "maggie"')

New-CdmRoleAssignment -Zone $zone -Role (Get-CdmRole -Zone $zone -Name "UNIX Login") TrusteeType ADGroup  -ADTrustee (Get-ADGroup -Filter 'Name -like "unix-users"')

This script creates the roles and assigns them to the proper users/groups

script2.pngscript3.png

 

 

Install Centrify DirectControl and run adcheck

  1. Launch a new EC2 Linux instance (e.g. Amazon Linux)
  2. Log in as ec2-user
  3. Run sudo vi /etc/yum.repos.d/centrify.repo and populate it with:
    [centrify]
    name=centrify
    baseurl=https://username:password@repo.centrify.com/rpm-redhat/
    enabled=1
    repo_gpgcheck=1
    gpgcheck=1
    gpgkey=https://downloads.centrify.com/products/RPM-GPG-KEY-centrify
    make sure you substitute the user/password with your own (this is in the repo page of the Download Center)
  4. Install CentrifyDC
    sudo yum install CentrifyDC
    answer any prompts that come up.
  5. Run adcheck and correct any errors
    $ adcheck awsrealm.centrifying.net
    OSCHK    : Verify that this is a supported OS                          : Pass
    PATCH    : Linux patch check                                           : Pass
    PERL     : Verify perl is present and is a good version                : Pass
    SAMBA    : Inspecting Samba installation                               : Pass
    SPACECHK : Check if there is enough disk space in /var /usr /tmp       : Pass
    HOSTNAME : Verify hostname setting                                     : Warning
             : Computer name should not be localhost or
             : localhost.localdomain. You may edit /etc/hosts or your
             : DNS server to set your hostname correctly or you must
             : use the --name option when running adjoin.
    
    NSHOSTS  : Check hosts line in /etc/nsswitch.conf                      : Pass
    DNSPROBE : Probe DNS server 172.31.26.75                               : Pass
    DNSPROBE : Probe DNS server 172.31.38.176                              : Warning
             : This DNS server does not respond to requests. This is a serious problem
    
    DNSCHECK : Analyze basic health of DNS servers                         : Warning
             : One or more DNS servers are dead or marginal.
             : Check the following IP addresses in /etc/resolv.conf.
             :
             : The following table lists the state of all configured
             : DNS servers.
             :  172.31.26.75 (ip-172-31-26-75.us-west-2.compute.internal): OK
             :  172.31.38.176 (unknown): dead
             : Only one good DNS server was found
             : You might be able to continue but it is likely that you
             : will have problems.
             : Add more good DNS servers into /etc/resolv.conf.
    
    WHATSSH  : Is this an SSH that DirectControl works well with           : Pass
    SSH      : SSHD version and configuration                              : Pass
    DOMNAME  : Check that the domain name is reasonable                    : Pass
    ADDC     : Find domain controllers in DNS                              : Pass
    ADDNS    : DNS lookup of DC dc1.awsrealm.centrifying.net               : Pass
    ADPORT   : Port scan of DC dc1.awsrealm.centrifying.net 172.31.26.75   : Pass
    ADDC     : Check Domain Controllers                                    : Pass
    ADDNS    : DNS lookup of DC dc1.awsrealm.centrifying.net               : Pass
    GCPORT   : Port scan of GC dc1.awsrealm.centrifying.net 172.31.26.75   : Pass
    ADGC     : Check Global Catalog servers                                : Pass
    DCUP     : Check for operational DCs in awsrealm.centrifying.net       : Pass
    SITEUP   : Check DCs for awsrealm.centrifying.net in our site          : Pass
    DNSSYM   : Check DNS server symmetry                                   : Pass
    ADSITE   : Check that this machine's subnet is in a site known by AD   : Pass
    GSITE    : See if we think this is the correct site                    : Pass
    TIME     : Check clock synchronization                                 : Pass
    ADSYNC   : Check domains all synchronized                              : Pass
    3 warnings were encountered during check. We recommend checking these before proceeding
    

Make sure you correct any major errors outlined by adcheck.  The key here will be name resolution and connectivity with your domain controllers; if you laid-out your security rules correctly and have DNS set to resolve AD records, you should be fine. 

 

Modify default AWS EC2 SSH Server Settings

By default, OpenSSH in AWS EC2 is not configured to allow password authentication.  Although with Centrify the underlying authentication uses Kerberos to talk to DCs, ultimately the user must be allowed to type their password in an SSH session.

  1. Sign-in to your EC2 instance with the ec2-user
  2. Modify the /etc/ssh/sshd_config file and set these directives (e.g. usin vi - sudo vi /etc/ssh/sshd_config)
    PasswordAuthentication yes
    # PasswordAuthentication no 
  3. Save the file.
  4. Restart the SSH server
    sudo service sshd restart

Join your EC2 Linux instance to Active Directory Manually

$ sudo adjoin -z AWS -c "ou=servers,ou=centrify" -n demo3 -u admin awsrealm.centrifying.net
admin@AWSREALM.CENTRIFYING.NET's password:
Using domain controller: dc1.awsrealm.centrifying.net writable=true
Join to domain:awsrealm.centrifying.net, zone:AWS successful

Centrify DirectControl started.
Initializing cache
.
You have successfully joined the Active Directory domain: awsrealm.centrifying.net
in the Centrify DirectControl zone: CN=AWS,CN=Zones,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net


You may need to restart other services that rely upon PAM and NSS or simply
reboot the computer for proper operation.  Failure to do so may result in
login problems for AD users.

 

Verify your UNIX Access and Privilege model

  1. Connect to your Linux system using SSH (e.g. PuTTY or ssh), log in as one of your AD users (e.g. lisa)
    login as: lisa
    Server refused our key
    lisa@172.31.44.61's password:
    Created home directory
    
           __|  __|_  )
           _|  (     /   Amazon Linux AMI
          ___|\___|___|
    
    https://aws.amazon.com/amazon-linux-ami/2017.03-release-notes/
    2 package(s) needed for security, out of 2 available
    Run "sudo yum update" to apply all updates.
  2.  Verify lisa's role using Centrify-enhance sudo
    1. $ dzinfo --role
      User: lisa
      Forced into restricted environment: No
      Centrify MFA Service authentication: Supported
      
        Role Name        Avail Restricted Env
        ---------------  ----- --------------
        UNIX             Yes   None
        Sysadmin/AWS
      

     Now you can logout Lisa.

  3. Reconnect again, and try to log in with Homer, then verify his role
    login as: homer
    Created home directory
    $ dzinfo --roles
    User: homer
    Forced into restricted environment: No
    Centrify MFA Service authentication: Supported
    
      Role Name        Avail Restricted Env
      ---------------  ----- --------------
      UNIX Login/AWS   Yes   None
    
    Note the different role for Homer.
  4. Close the session.  You have now verified your Linux access model.

Join your EC2 Windows member to the Centrify Zone

Grant your test users remote desktop access

  1. In your member server, right-click the start menu and select Run
  2. Type compmgmt.msc and press enter
  3. Navigate to Local Users and Groups > Groups and double-click Remote Desktop Users
  4. Press Add.  Now add the test users (or a group) you want to have RDP access.  E.g. (maggie)
  5. Press OK.

Install the Centrify Agent for Windows

  1. Open Windows Explorer and navigate to the folder with the Centrify Server Suite bits.
  2. Browse to the > Agent and run Centrify Agent for Windows64.exe (press Yes to the UAC prompt)
    • Welcome Page > Press Next
    • EULA Page > check the box and press Next
    • Custom Setup Page > Select only the Access Components
      dzwin-comp.png
      (This is unless you are planning or have added DirectAudit)
    • Components Page > Next
    • Confirmation Page > Install
    • Completed Page > Make sure the "Run Agent Configuration Wizard" is checked, press Finish
  3. Now you'll configure the Agent to join your zone.  
    • Configuration Page > Press Next
    • (Optional) Associate DirectAudit Installation > Select your Installation
    • Join to a Zone > Select the zone you created earlier (AWS) and Press Next
      Note, you may be asked to add the Domain Administrators to the Login role.  You must do this, otherwise the only user that will be able to sign-in will be maggie (in this example).
    • Configuration completed, Press Finish.
  4. If asked to restart, press Yes when you are ready.

Verify your Windows Access and Privilege model

  1. Sign-in to your Windows system as a member of the Domain Admins group
  2. Right click start and run mstsc -v member -w:800 -h:600 (this launches an RDP session)
  3. Attempt to log in with maggie  (she should be able to log in) 
  4. Open the Windows systray and right-click the Centrify icon > Authorization Center and click on the Effective roles tab
    maggie.png
  5. Note Maggie's current roles in the AWS zone.  Logoff.
  6. Repeat step 2, and now try to log in with Bart.  The result should be:
    bart.png
    This is because Bart has not been assigned a role that allows for Windows access.

  7. Press OK and close.  At this point, you have tested the access model on Windows.

 

 

Sanity Check # 4 

At this point you should have

  • Centrify tools installed in your member server (e.g. DirectManage)
  • You have a domain-joined Amazon linux instance 
  • In the Centrify zone, you have a linux instance and your Windows member server
    state.png
  • You have tested your access and privilege model in both Linux and Windows platforms.

MILESTONE:  Now you have a system that you can use for sanity checks and to generate some of the tools required for the Standard Edition AWS labs.  This is the state of your lab:

 

statepoint5.png

 

Privilege Service Lab Setup - Centrify Tenant and Connector 

Obtain a Privilege Service Tenant

  1. Get Centrify Privilege Service
    https://www.centrify.com/free-trial/privilege-service-form/
    Once your tenant is approved, you'll receive an email with your URL, credential and one-time link.  When you click on it, you will be logged-in.  Make sure you change your password.
  2. Once your tenant is set up, open its URL from the browser in your EC2 Windows instance (member server)
    Note that you may have to relax the IE ESC settings on Windows or download an alternative browser like Chrome or Firefox.  E.g. https://your-tenant.my.centrify.com/manage
  3. Navigate to Settings > Network and click "Add Centrify Connector";  this will download the Connector bits.
  4. Double-click the Connector zip file, and run the included setup file, this will start the wizard
    - Welcome Page - press next
    - EULA Page - check the box and press next
    - Custom Setup - only install the Centrify Connector
    - Ready to install - press next.  When complete, press Finish.  This will launch the configuration Wizard.
  5. In the Configuration Wizard:
    - Welcome Page - press next
    - Centrify Connector Configuration - provide your admin account name and password
    - Connector Configuration - Optional: check the box in the domain (you may not be able to if you're using a managed AD.
    - Connection test - should be successful if your instance is allowed to go out to the Internet, press Next
    - Configuring connector - Next and then Finish.
  6. Once completed, the Settings > Network > Centrify Connectors should display your aws connector:
    connect.png

Configure Resource Subnet Mapping
This step is very important, especially if you're using the Privilege Service tenant in other environments like local VMs.

  1. Log in to privilege manager (https://your-tenant.my.centrify.com/resources)
  2. Go to Settings click on Resource Subnet Mapping and Press Add
  3. Type the CDIR for your AWS Subnet (repeat if you have many - e.g. 172.31.0.0/16
  4. Select "Choose" and check the box next to your AWS Windows Server running the Centrify Connector.
    ccsubnet.png
  5. Press Save.

 

Sanity Check # 5
At this point, you should:

  • Have a Privilege Service tenant and you should know its URL, an admin user and password.
  • Have a privilege service should ready to authenticate your AD users (see below) and to provide password and session services for your AWS subnet.

MILESTONE: You should be ready to perform the AWS Privilege Service Labs, and this should be the state of your lab.

 state-with-bucket.png

 

Related Articles
Creating a Kerberos Keytab for DirectControl joins/unjoins: 
http://community.centrify.com/t5/TechBlog/DevOps-Creating-a-Kerberos-Keytab-to-Automate-DirectContro...

Using AWS OpsWorks (Chef 12) to deploy Centrify DirectControl on EC2 Linux instances: http://community.centrify.com/t5/TechBlog/Labs-Using-AWS-OpsWorks-Chef-12-to-deploy-Centrify-DirectC...

Background

Amazon AWS is at the heart of many of our customers workloads.  Last year I started a series of tech blogs to discuss how to leverage Centrify's product portfolio to secure your AWS assets.

 

This year, I've had the opportunity to review the AWS Security Best Practices document and in this new series we'll provide guidance on how to implement controls to meet or exceed the Shared Responsibility Model.  

 

About the Shared Responsibility Model

The concept is very straightforward.  Amazon AWS will implement controls to provide assurance for confidentiality (e.g. encryption at rest and in transit), integrity (transaction trust), availability (redundancy of hardware, power, etc), however, depending on your business requirements, you may need to add additional controls to increase your security posture or to provide assurances to your customers beyond what's offered by AWS.
aws-shared-responsibility.png

Amazon AWS Defines a "Shared Responsibility" model that has the following scope

  • Infrastructure Services: Controls that apply to IaaS services like EC2, VPCs and Block Storage.
  • Container Services: Controls that apply to PaaS servides like RDS Database, EMR MapReduce or Elastic Beanstalk
  • Abstracted Services: Controls that apply to Services like S3 Storage, SES SMTP, etc.

 In this article we'll focus on how to use Centrify Privilege Service to secure access to Windows AMIs.

 

The Challenge:  Extend Existing Enterprise Identity and Access Management in Public Clouds

In a previous entry of this series, we discussed the additional controls that can be implemented on top of Amazon's IAM and cryptography-based controls.  However, organizations may already have capabilities for Centralized Identity which is at the heart of strong access controls.  This may mean that organizations need to find ways to extend this infrastructure out to public clouds like Amazon.  This may imply:

  • Re-creation of infrastructure (e.g. standing-up Active Directory or LDAP-like infrastructure)
  • Network extension (e.g. treating the public cloud like a branch by implementing site-to-site VPNs)
  • Capability duplication (e.g. implementing software and services in AWS)

In this article we'll discuss how organizations can leverage Centrify Privilege Service and the new Linux Agent (Identity Broker) to secure Linux instances and extend Enterprise Identity out to public clouds without the need of the additional overhead.

 

Centrify Privilege Service

cps-snap.PNG

Privilege Service is Centrify's answer to the traditional "password-driven" use cases (the industry refers as Shared Account Password Management, Privilege Session Management, etc);  however unlike other solutions, there are several capabilities areas that set it apart from the traditional "Password Vault"

  • Flexible deployment:  Both as SaaS and On Premises  (in fact, it was designed as a SaaS solution first)
  • Identity Sourcing and Federation built-in (includes Identity Service, this means support for AD, LDAP, Google and others  plus simplified SAML-based federation and 3K+ ready web and mobile apps)
  • Policy, Workflow and MFA Engine:  Policies for time and geo-location, RBAC, step-up authentication and Multi-factor including Smartcard, plus a built-in access request system (+ServiceNow integration)
  • Infrastructure Extensibility:  Privilege Service can be extended to any network using a Windows-based Centrify Connector via web protocols.

 

New Linux Agent

The new Linux agent takes advantage of a capability called "Identity Broker" this allows the bridging of identities known to Centrify Privilege Service;  this is done via the Centrify connector.  This means that the overhead of duplicating enterprise identity infrastructure or extending the enterprise to the public network can be avoided in this particular use case;  all that is required is to deploy a Centrify connector wherever you want to extend Password-related services and Linux authentication.  Let's show an illustration.

 

Company X needs to provide identity-based reporting and attestation of who has access to their public cloud EC2 instances in AWS;  their primary identity source is AD.  They could have used any model (independent forest, one-way trust + site2site VPN or RODC) to extend AD to AWS  or they could have deployed Amazon IAM roles and used SSH keys; but any of these models implied additional overhead.  With CPS and Identity Broker, all they did is this:

ibconcept.png

With this model, CompanyX not only can accomodate their corporate IT users, but external entities as well.  And as we discussed before, password, session and additional services are consolidated as well, both on premises and on any public cloud.  Plus

  • No need to deploy "jumpboxes" to the private clouds (limits exposure)
  • Shared account passwords for local accounts (Linux, Windows) or databases (like Amazon RDS) can be controlled
  • Access Request provides the assurance of "documented approvals" to sensitive systems
  • Deploy MFA or access only from the OnPrem network as additional controls.

This topic was covered in this post.

 

Agent Architecture

The client architecture is using UNIX frameworks like Name Service Switch (Identity) and Pluggable Authentication Modules (Auth).  It also supports offline login as well as direct or proxy-based user/password or OAUTH-based enrollment codes (very useful for automation). This client implements the CLI tookit for setting, retrieving or deleting credentials under management.

 

Supported Platforms

agent-platforms.PNG 

UNIX Identity

Following on the legacy of Server Suite, the new agent generates identity like DirectControl in workstation mode.

Login - user's short name (must use the fully-qualified name the first time)

UID - auto-generated based on the GUID

Primary group - auto-private (same as UID)

GECOS - the display name in Centrify Identity Service

Home/Shell - configurable in the Settings tab.

ibgecosshell.png

Since most public clouds don't need legacy identity (for services like NFS), this makes the client very lightweight.

 

Automation

There's an implied expectation of DevOps "friendliness" when a private or public cloud solution is implemented.  The new Linux agent leverages enrollment codes for this capability.

ib-enroll.PNG

Centrify provides a sample AWS script that can be used with enrollment codes in the User Data field or with any other framework like OpsWorks (see attachment)

 

Identity Broker

Privilege Service can accomodate several identities, including:

ib-sources.PNG

Note that it can accommodate identities from Active Directories without any trust relationships.

These identities can be aggregated using Identity Service Roles:

ib-role.PNG

 Roles, in turn can be assigned the AgentAuth privilege on a Linux Resource:

IB-aws resource.png

As you can see the model works like this:

Users or groups from Identity Sources are added to CIS Roles that are granted the AgentAuth right in CPS.

 

Basic Commands

Agent Operation

  • cinfo – obtain information about the agent
  • cenroll – enroll the identity platform and enable features
  • cunenroll – leave the platform and optionally delete resource and any managed accounts
  • cflush – flush the local cache

IB login.PNG

 

AAPM

  • csetaccount – add a managed account for the resource
  • cgetaccount – obtain a managed account’s password
  • cdelaccount - delete a managed account's password

 

To test-drive the new Linux agent and to see how it can secure your public-cloud Linux instances, request a CPS trial today:  https://www.centrify.com/free-trial/privilege-service-form/

 

Related Articles

AWS Shared Responsibility - Securing the Amazon Account

AWS Shared Responsibility - Securing Windows AMIs with Centrify Windows MFA

AWS Shared Responsibility - Securing Amazon RDS Instances

Background

Amazon AWS is at the heart of many of our customers workloads.  Last year I started a series of tech blogs to discuss how to leverage Centrify's product portfolio to secure your AWS assets.

 

This year, I've had the opportunity to review the AWS Security Best Practices document and in this new series we'll provide guidance on how to implement controls to meet or exceed the Shared Responsibility Model.  

 

This article discusses how you can use Centrify Privilege Service to meet or exceed the requirements to secure shared database accounts in Amazon RDS.

 

About the Shared Responsibility Model

The concept is very straightforward.  Amazon AWS will implement controls to provide assurance for confidentiality (e.g. encryption at rest and in transit), integrity (transaction trust), availability (redundancy of hardware, power, etc), however, depending on your business requirements, you may need to add additional controls to increase your security posture or to provide assurances to your customers beyond what's offered by AWS.
aws-shared-responsibility.png

Amazon AWS Defines a "Shared Responsibility" model that has the following scope

  • Infrastructure Services: Controls that apply to IaaS services like EC2, VPCs and Block Storage.
  • Container Services: Controls that apply to PaaS services like RDS Database, EMR MapReduce or Elastic Beanstalk
  • Abstracted Services: Controls that apply to Services like S3 Storage, SES SMTP, etc.

 

How are Amazon RDS instances secured?

 

The WS Security Best Practices document specifies the following information:

aws-rds.png

 

Amazon best practices provide information about data security and encryption and additional controls in each database, however, it's up to you to secure other areas like shared database accounts.  This is where Centrify Privilege Service can help you meet or exceed your goals for shared responsibility.

 

Note that it still possible for you to add your instance to an infrastructure like Active Directory; however, you can control the account, and use least privilege with other users.

 

The Database Shared Account issue

The problem is straightforward.  When you provision an Amazon RDS instance, you are provided with an administrative account that is typically shared amongst administrators.  

sql-shared.png

 

In an enterprise environment, depending on the data classification, risk profile, regulation or policy, you have to be able to control the shared account lifecycle:

  • Governance/Business Process:  Request/Approve
  • Password operations:  Check out-Check-in, Rotate/Update, Maintain History.
  • Policy:  length, complexity, expiration, rotation requirements, etc.
  • Operations:  Provide input for security operations (monitoring, remediation) and compliance

Controlling the Governance Lifecycle

Centrify Privilege Service provides the ability to take control over this process and enhance your capabilities, it can implement an Access Request model (native or with ServiceNow) to control requests and approval flow.

 

sn-aws.png

 

Controlling Password Operations Everywhere

The SAPM process is enhanced by Centrify by providing the ability to control both on-premises or public cloud database deployments.  The Connector infrastructure facilitates the deployment.

agent.png

 

 

Identity Flexibility

Leverage your Enterprise Directory (AD or LDAP) and have the flexibility to use federated identity, Google for Work or the built-in Centrify Directory for added flexibility.

 

dir-svc.png

 

RBAC, Policy Engine and Multi-factor Authentication (MFA)

Role-based access controls starts with a great grasp on identity.  With CPS, roles can be constructed leveraging any identity source visible to the platform.

 

Establish controls like accessibility only from inside the network, geo-location, plus using modern Multi-factor (Smart Card, Yubikey, OATH, Authenticator), step-up methods (e-mail, phone factor, SMS) or your own legacy (SecurID, Vasco, Symantec) infrastructure.

 polic.pngap.png

 

Enhance Security Operations

Provide flexible mechanisms to export event information (REST, SQL) to integrate with your existing monitoring infrastructure, or leverage the provided dashboards and activity feeds.

secov.png

 

activity.png

 

Demo:  Setting-up Centrify Privilege Service to Manage a SQL Server-based Amazon RDS Instance

 

 

Related Articles

AWS Shared Responsibility - Securing the Amazon Account

AWS Shared Responsibility - Securing Windows AMIs with Centrify Windows MFA

AWS Shared Responsibility - Securing Linux Systems using Centrify's new Identity Broker

I was recently reading an article about AWS security blunders.  The article takes a very common-sense approach to what can be applied on any Public or Private Cloud.   

 

My personal observation is that many of the challenges on any public cloud relate to the complexities of extending enterprise capability out to a public cloud and Identity and Access Management is as the heart of it. Starting with the Amazon Account and IAM, these could potentially be managed in parallel from the current IT infrastructure; this slowly becomes a management nightmare while increasing security exposure.  

 

The good news is that at Centrify we provide products and capabilities to meet and exceed the Access Control requirements for AWS around IaaS and our platform is uniquely positioned to help you today.

 

plaform.png

 

Leverage your Identity and Access Management to secure your AWS IaaS

In the article, blunders like “not knowing who is in charge of security” typically happen due to infrastructure duplication and fragmentation.  Since everything starts with Identity, at Centrify we allow you to integrate Amazon’s Identity and Access Management (IAM) with your existing directory (Active Directory or LDAP) leveraging SAML or the Native APIs.

aws.png 

To address the issue of “giving away too many privileges” & “not taking root seriously”  securing the Amazon Account and Implementing Amazon IAM are key areas and quick wins that can be accomplished with minimal effort using Centrify’s Identity Platform. 

Here are a few Tech Blogs that cover this topic:

 gears.png

 

The article also mentions challenges with Passwords and Keys (“relying too much on passwords” & “exposed secrets and keys”).  Passwords exist in web apps, Linux and Windows servers and even within scripts (a very insecure habit).  A big benefit of the Centrify Identity Platform is that you can implement Shared Password capabilities for web apps (password walleting), and vaulting of Windows, Linux and other systems.

 

See a technical showcase on CPS here:  http://community.centrify.com/t5/Community-Tech-Blog/A-Playbook-to-secure-your-Amazon-AWS-Infrastruc...

 

AWS and the Identity Challenge

A common strategy is to implement or extend Active Directory to AWS.  This will eliminate the need to rely on keys.  With products with our Centrify Server Suite, an access control and privilege management model can be implemented quickly and it provides a single-pane of glass that can provide security and visibility across Windows and Linux systems in AWS.  Learn more here:

http://community.centrify.com/t5/Community-Tech-Blog/A-Playbook-to-secure-your-Amazon-AWS-Infrastruc...

 

However, this does require either the implementation of AD in the cloud (new forest) or the extension by implementing a site-to-site VPN and using either a 1-way trust or an RODC setup.  Although these are great best practices for the enterprise, they come with cost and complexity when working with public clouds.

 

Exciting New Alternatives to Secure Extend your Enterprise Identity to AWS

With our November release of the Identity Platform, we are providing two exciting capabilities:

 

a) Centrify Agent for Windows:  Extends our award-wining Windows PIM capabilities to Identity Service or Privilege Service customers looking to secure Windows systems on console login, RDP or screen unlock.

methods.PNG

The back-end services supported are MFA methods like Mobile Authenticator, Yubikey, OATH Token or even your legacy tokens via RADIUS (e.g. SecurID, Vasco, Symantec), plus step-up methods like Phone Factor, SMS, or E-mail.

To see an article that covers this new capability, click here:  http://community.centrify.com/t5/Community-Tech-Blog/AWS-Shared-Responsibility-Login-MFA-for-Windows...

 

This new capability provides security mechanisms for organizations using Windows systems as AWS jumpboxes or that simply it is required based on the system's risk profile.

 

b) New Platform Agent for Linux -  an alternative way to provide Authentication and AAPM services for Linux systems in private or public clouds like AWS.  It’s a brand-new, “lightweight” Centrify agent.

This client works with the identity platform.  Linux systems are “enrolled” to our service and we act as an Identity Broker for your enterprise AD or LDAP-based identities.

 

The convenience of the new agent lies in its simplicity and low overhead.  Since newer workloads don’t require legacy support for NIS-like services this makes the footprint very small and the infrastructure requirements minimal in comparison of deploying a full AD forest or LDAP tree, and simpler than alternatives like one-way trusts or RODCs.   Simply drop a Centrify connector in your AWS (or other) cloud and that’s it.  Connector to cloud and agent to connector (or cloud) only requires HTTPS connectivity.  Enrollment can be fully automated using codes.

 

Here's a quick demo

 

 

The architecture of Centrify Privilege Service for AWS (or any public loud) is quite simple.  The Centrify connector talks to our service over HTTPS and extends cross-platform services like federation, policy, MFA, shared account password management, privilege session brokering, application-to-application password management and more.

 

The huge benefit is the service's identity flexibility.  Regardless of your identity source (traditional LDAP or AD), modern (Google Directory, Federated Identity, Centrify Cloud Directory) you can extend application access and PIM services.  All you need is the Centrify connector where you want those services available. 

 

 agent.png

 

In conclusion, regardless of your Public cloud, you will find that with Centrify you can meet or exceed your security requirements PLUS you can balance value and functionality, keeping capability fragmentation at bay.

Background

Amazon AWS is at the heart of many of our customers workloads.  Last year I started a series of tech blogs to discuss how to leverage Centrify's product portfolio to secure your AWS assets.

 

This year, I've had the opportunity to review the AWS Security Best Practices document and in this new series we'll provide guidance on how to implement controls to meet or exceed the Shared Responsibility Model.  

 

About the Shared Responsibility Model

The concept is very straightforward.  Amazon AWS will implement controls to provide assurance for confidentiality (e.g. encryption at rest and in transit), integrity (transaction trust), availability (redundancy of hardware, power, etc), however, depending on your business requirements, you may need to add additional controls to increase your security posture or to provide assurances to your customers beyond what's offered by AWS.

Amazon AWS Defines a "Shared Responsibility" model that has the following scope

  • Infrastructure Services: Controls that apply to IaaS services like EC2, VPCs and Block Storage.
  • Container Services: Controls that apply to PaaS servides like RDS Database, EMR MapReduce or Elastic Beanstalk
  • Abstracted Services: Controls that apply to Services like S3 Storage, SES SMTP, etc.

 In this article we'll focus on how to use Centrify Privilege Service to secure access to Windows AMIs.

 

How is access to Amazon Windows AMIs secured today?

 

The AWS Security Best Practices document specifies the following information:

aws-sec-windows.PNG

At a basic level, this just means that beyond providing the ability to decrypt the administrator password based on your private key, it's up to the customer to deploy additional controls (including x.509 authentication, Active Directory or local accounts).

 

For large organizations, both x.509 or local accounts may create an additional identity silo; this means that Active Directory (either an extension of the on-prem directory or an instance running in AWS is the main option).

 

Centrify Privilege Service and Centrify Server Suite provide the flexibility to implement these controls and we'll cover more in subsequent posts, now let's explore the benefits of combining Privilege Service with the Centrify Agent for Windows for Centralized Sessions and Windows MFA

 

Privilege Session Brokering facilitated by CPS provides these benefits:

  • Centralized Identity Source:  You can leverage your existing on-premises Active Directory to authenticate users accessing EC2 Windows AMIs.
    dirsvc.png
  • Centralized Session Initiation:  This control centralizes all RDP sessions from a central management perspective.  With CPS, this capability is enhanced by providing watch and terminate options  (session proctoring) and session recording (capture and replay).
    watch-terminate.png
  • Limited Exposure:  by not using public IP addresses for your Windows systems, you are limiting exposure to attacks.
  • Additional controls:  CPS's ability to implement RBAC, Geo/time fencing can meet or exceed policy requirements.
  • Password Services:  Shared account password management for local Windows and UNIX accounts;  AD accounts, Oracle and SQL databases, Windows services and scheduled tasks.

Multi-Factor Authentication with the Centrify Agent for Windows provides these benefits:

  • You can enforce MFA using different factors like:  Mobile Authenticator, OATH OTP, Legacy (e.g. SecurID), Phone factor, SMS, e-mail or security question.
    methods.PNG
  • Contexts:  You can limit this to login or privilege elevation (if you're using Centrify Server Suite zones technology - will be covered later).
  • Enhanced controls:  If you're allowing direct connectivity, users must provide MFA and authenticate with their AD credentials.
  • Offline Access and Rescue Rights:  Leverate OATH OTP codes for MFA in case there's no access to Centrify services
    offline.png

 

Conclusion

With Centrify Privilege Service + the Windows MFA capabilities enabled by the Centrify Agent for Windows we can secure Windows AMIs by providing ways to leverage your existing AD infrastructure to centralize sessions, provide SAPM services and provide MFA enforced at the local level. 

 

Demo Video

In this demo we show how we can centralize session origination using Centrify Privilege Service, how we can use a shared account or log in manually.   We'll configure Windows MFA for a demo user and we'll demonstrate how the control is enforced via the jumpbox or if the user chooses to connect to the Windows AMI directly.

 

Related Articles

AWS Shared Responsibility - Securing the Amazon Account

AWS Shared Responsibility - Securing Amazon RDS Instances

AWS Shared Responsibility - Securing Linux Systems using Centrify's new Identity Broker

Background

Amazon AWS is at the heart of many of our customers workloads.  Last year I started a series of tech blogs to discuss how to leverage Centrify's product portfolio to secure your AWS assets.

 

This year, I've had the opportunity to review the AWS Security Best Practices document and in this new series we'll provide guidance on how to implement controls to meet or exceed the Shared Responsibility Model.  

 

About the Shared Responsibility Model

The concept is very straightforward.  Amazon AWS will implement controls to provide assurance for confidentiality (e.g. encryption at rest and in transit), integrity (transaction trust), availability (redundancy of hardware, power, etc), however, depending on your business requirements, you may need to add additional controls to increase your security posture or to provide assurances to your customers beyond what's offered by AWS.
aws-shared-responsibility.png

Amazon AWS Defines a "Shared Responsibility" model that has the following scope

  • Infrastructure Services: Controls that apply to IaaS services like EC2, VPCs and Block Storage.
  • Container Services: Controls that apply to PaaS services like RDS Database, EMR MapReduce or Elastic Beanstalk
  • Abstracted Services: Controls that apply to Services like S3 Storage, SES SMTP, etc.

 In this article we'll focus on how to use Centrify Identity Service (or Privilege Service) to secure the Amazon Account.

 

What's the Amazon account?

The amazon account (or Amazon root account) holds the keys to the AWS Kingdom.  This is the first account set up, most likely used to set up billing, IAM roles and groups, keys, etc.

 

What constitutes a bad practice?

If your organization is sharing the Amazon account with several members of your IT staff and you're not adding additional controls around it, you are going against several security best practices.  

 

What is Amazon's guideline?

Amazon's guidelines are simple:

  • Limit access and usage of the Amazon account
  • Add multi-factor authentication
  • Implement Amazon's Identity and Access Management groups

The basic guideline is to implement a model of least privilege access.   At Centrify that's what we have traditionally preached in the context of Operating Systems and Apps.   Additional complexity is added depending on your AWS deployment model.  This is an except from the AWS Security Best Practices document (August 2016, Pg 16).

 

amazon-root.PNG

 

How can Centrify help?

Centrify Identity Service (and Privilege Serivce) provide a simple-to-use federation engine that allows the implementation of Amazon IAM without the overhead of federation services.  In addition, it provides a powerful policy and multi-factor authentication engine that allows the deployment of controls to secure the account.

 

Enhancements since the previous entry

Last year when I wrote the original post, I outlined how to implement MFA to secure the root account.  The Amazon AWS (User/Password) app is deployed leveraging the password wallet built-in to the platform.  Since the password is securely replayed, users just click on the app link, they don't rely on shared credentials.

 

A big benefit of our approach was flexibility.  In addition to Smart Card or Yubikey for pre-authentication, you could use the Centrify Mobile Authenticator and individual OATH codes for each user, you could use Phone factor, e-mail, SMS and security question as step-up authentication when the application is lauched.  

 

Enhancements since last year

  • Radius Client as MFA - this means that you can use your legacy (or modern) tokens (RSA SecurID, Vasco, Symatntec, DUO, Microsoft) via our platform
  • Workflow and approvals - this means that you can use our existing access request or external worklow like our ServiceNow App Access app for governance and documented approvals
    sn-amazon.PNG
  • Policy at the application level - this was just released, and as announced by @Friedsam this weekend, 16.10 provides application granularity.
    add-policy.png

Example

With Centrify assets, you can deploy controls that limit access to users that have been explicity approved access to the application, and to use the Amazon account they must use multi-factor authentication, only from inside the corporate network and during business hours.  You can have different combinations of controls on different environments (accounts).

 

Conclusion

With Centrify Identity Platform (Identity Service and Privilege Service) not only you can meet, but exceed the Shared Responsibility of securing your  Amazon account. 

 

Demo

In this demo, we implement three controls:

- Documented Approvals (with ServiceNow)

- Secure the shared password (not available/visible)

- Multi-factor Authentication

 

 

 

Related Articles

AWS Shared Responsibility - Securing Windows AMIs with Centrify Windows MFA

AWS Shared Responsibility - Securing Amazon RDS Instances

AWS Shared Responsibility - Securing Linux Systems using Centrify's new Identity Broker

 

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.

Read more...

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.

 

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

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 or IP addresses that are translated via NAT for outbound internet connectivity 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

 

 

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

Amazon AWS is quickly becoming one of the most popular options for Enterprises to extend their Data Center infrastructure out in the cloud. IaaS vendors like Amazon provide an array of services that include directory services, orchestration, automation, APIs and more.  

 

It's important to understand that flexibility can slowly become chaos, especially for enterprises that have fought hard to consolidate processes around Identity and Access Management.

 

This multi-part series discusses a basic IAM playbook that can be enabled with Centrify’s Identity Platform (Identity Service, Server Suite and Privilege Service). The principles continue to be the same: Implement Strong Access Controls using what you have: Active Directory as the Identity Store and enhance the experience and security controls leveraging Centrify Technologies.

Read more...

Showing results for 
Search instead for 
Do you mean 
Labels
Leaderboard

Community Control Panel