Using AWS CloudWatch to monitor Centrify Audit Trail events in EC2 Windows instances

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://centrifying.blogspot.com/2017/04/using-aws-cloudwatch-to-monitor.html 

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

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.
 

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.
  

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.

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

 

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:
   
4. Repeat 3 more times.  This should trigger the alarm.
   
5. Review the Dashboard.  After a few minutes, the alarm will return to normal and you'll be notified
   

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 capabilities, 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.

Related Articles

CloudWatch and Centrify EC2 Linux:  http://centrifying.blogspot.com/2017/04/using-aws-cloudwatch-to-monitor.html

Using AWS CloudWatch to monitor Centrify Audit Trail events in EC2 Linux instances

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://centrifying.blogspot.com/2017/04/using-aws-cloudwatch-to-monitor_24.html

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

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

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 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-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.
   
5. Review the Dashboard.  After a few minutes, the alarm will return to normal and you'll be notified
   

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 capabilities, 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.

Related Article

Using CloudWatch to Monitor Windows systems running Centrify:  http://centrifying.blogspot.com/2017/04/using-aws-cloudwatch-to-monitor_24.html

Building a lab to test Centrify capabilities in Amazon AWS

This article is a republish of a blog post that I wrote for the Centrify Community Techblog.

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

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 # 1At 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

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.

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

Sanity Check # 2At 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.
  

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

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.

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 

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

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
     
     (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
   
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:
   
   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
  
• 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:

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:
   

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.
   
5. Press Save.

Sanity Check # 5At 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.