Monday, April 24, 2017

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:

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

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:

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

Setting-up a Kerberos keytab to Automate AD join/unjoin operations (DevOps)

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

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

    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

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