[TIPS] A Centrify for Mac Cheat Sheet

By Centrify Contributor III yesterday - last edited yesterday

This Cheat Sheet should be used with Centrify Mac Agent version 5.2.4 and higher.

 

The Centrify Mac Diagnostic Tool location:
/Library/Application Support/Centrify/MacDiagnosticTool.app

  

 

Centrify Agent

 

To join the domain in Auto Zone:
sudo /usr/local/sbin/adjoin --user domain_admin_username --workstation domain.com

 

To join the domain in Zone mode:
sudo /usr/local/sbin/adjoin --user domain_admin_username --zone zonename domain.com

 

To leave the domain and disable the computer object:
sudo /usr/local/sbin/adleave --user domain_admin_username 

 

To leave the domain and remove the computer object:
sudo /usr/local/sbin/adleave --user domain_admin_username --remove

 

To leave the domain and leave the computer object untouched in Active Directory:
sudo /usr/local/sbin/adleave --user domain_admin_username --remove

 

To print information for the domain:
/usr/local/bin/adinfo

 

To print network diagnostic information for the domain:
sudo /usr/local/bin/adinfo --diag

 

To view licensing mode:

/usr/local/sbin/adlicense

 

To enable licensed features:

sudo /usr/local/sbin/adlicense --licensed

 

To look up an Active Directory user's information:

/usr/local/bin/adquery user -A username

 

To look up an Active Directory computer's information:

/usr/local/bin/adquery user -A computername$

 

To look up an Active Directory computer's Manager (managedBy attribute used with FileVault policy):

 

/usr/local/bin/adquery user -b managedBy computername$

 

To look up an Active Directory group's information:

/usr/local/bin/adquery group -A groupname

 

To change the currently logged in user's Active Directory password:

/usr/local/bin/adpasswd

 

To change an Active Directory user's password:

/usr/local/bin/adpasswd --adminuser domain_admin_username username@domain.com

 

To flush the Mac agent cache (Active Directory users will need to login again to cache their credentials after this is ran):

sudo /usr/local/sbin/adflush

 

The location of the Centrify configuration file:
/etc/centrifydc/centrifydc.conf

 

The location of Centrify Kerberos tools:
/usr/local/share/centrifydc/kerberos/bin/

 

To restart the Mac agent:
sudo /usr/local/share/centrifydc/bin/centrifydc restart 


 

To turn on logging:
sudo/usr/local/share/centrifydc/bin/cdcdebug on

 

To turn off logging:
sudo/usr/local/share/centrifydc/bin/cdcdebug off 

 

To clear out the current log file:

sudo/usr/local/share/centrifydc/bin/addebug clear


Log file location:
/var/log/centrifydc.log

 

To uninstall the Mac agent:
sudo /usr/local/share/centrifydc/bin/uninstall.sh

 

To uninstall silently:
sudo /usr/local/share/centrifydc/bin/uninstall.sh --std-suite

 

 

Group Policy

 

To force group policy updates for both user and machine policies:
/usr/local/bin/adgpupdate

 

To update group policy for user policies only:
/usr/local/bin/adgpupdate --target User

 

To update group policy for machine policies only:
/usr/local/bin/adgpupdate --target Computer

 

To view the curent set group policies:

/usr/local/bin/adgpresult

 

To view the curent set user group policies:

/usr/local/bin/adgpresult --user username

 

To view the curent set machine group policies:

/usr/local/bin/adgpresult --machine

 

The location of computer group policy reports:
/var/centrifydc/reg/machine/gp.report 

 

The location of the user group policy reports:
/var/centrifydc/reg/user/username/gp.report  

 

The location of login scripts:
/var/centrifydc/loginscripts/machine
/var/centrifydc/loginscripts/user/username

/var/centrifydc/scripts/additional/login
/var/centrifydc/scripts/additional/logout

 

To retrieve machine certificates:
sudo /usr/local/share/centrifydc/sbin/adcert --machine --keychain

 

To retrieve user certificates:
/usr/local/share/centrifydc/sbin/adcert --user --keychain

 

The location of machine certificates:
/var/centrify/net/certs

 

The location of user certificates:
~/.centrify

/Users/username/.centrify

 

 

Directory Services

 

To see if the machine is joined to the domain using the Apple plugin:
/usr/sbin/dsconfigad –show

 

To unbind from the domain using the Apple plugin:

sudo /usr/sbin/dsconfigad –remove -username domain_admin_username

 

To list all of the users in the Directory Service and in Active Directory for the zone:
/usr/bin/dscl /Search -list /Users

 

To list only the Active Directory users enabled for the zone:
/usr/bin/dscl /CentrifyDC -list /Users

 

To display detailed information about the specified Active Directory user:
/usr/bin/dscl /CentrifyDC -read /Users/username

 

To list all of the groups in the DirectoryService and in Active Directory for the zone:
/usr/bin/dscl /Search -list /Groups


 

To list only the Active Directory groups enabled for the zone:
/usr/bin/dscl /CentrifyDC -list /Groups

 

Command to display detailed informationa bout the specified Active Directory group name:
/usr/bin/dscl /CentrifyDC -read /Groups/groupname

  

 

FileVault

 

To see if FileVault is enabled:

/usr/bin/fdesetup status

 

To list FileVault enabled users:

/usr/bin/fdesetup list

 

To disable FileVault:

sudo /usr/bin/fdesetup disable

 

To add a local or mobile account to the FileVault user list:

sudo /usr/bin/fdesetup add -usertoadd username

 

 

Smart Card

 

To see if smart card support is enabled: 
/usr/local/bin/sctool --status

 

To enable smart card support: 
/usr/local/bin/sctool --enable

 

To disable smart card support: 
/usr/local/bin/sctool --disable

 

To dump out all the certificates and Active Directory information present on the smart card:

/usr/local/bin/sctool --dump

 

To get a new kerberos ticket: 

/usr/local/bin/sctool --pkinit

 

Related Articles:

 

A Centrify Server Suite Cheat Sheet

By default PostgreSQL creates and stores user accounts in the SQL database. With a little work, the accounts can be managed from Active Directory and the passwords can be rotated on a regular basis using Centrify Privilege Service. 

Read more...

Centrify provides an account migration tool that simplifies the process of converting a local account's home directory into the Active Directory account. Migrating the account helps to save the user's files, application settings, and browser bookmarks.

Read more...

Centrify for Google Chromebook Single Sign-On Configuration Guide

 

Google G Suite has become one of the most popular on-demand business software in the market and your organization took the plunge to migrate to Google G Suite. You need to assign licenses to your end users automatically, and give them single sign-on. You’re worried about Chrome Book device management and BYOD, and how to manage all that for on-premises apps and cloud apps, too. You’ve got a few questions, and are looking for answers. Without SSO user productivity is greatly affected, without Multi Factor Authentication the risk of exposing inappropriate access increases and without automated account provisioning / de-provisioning IT has to manage all accounts manually.

 

Fortunately, Centrify Identity Service (CIS) provides a solution. CIS for Google G Suite offers a complete, robust, and easy-to-use Active Directory (AD) or CIS Cloud Directory integration with Google G Suite, providing a seamless authentication experience for Google G Suite users and an easy to use intuitive Administrative interface for IT staff to automate the process of on- and off-boarding employees with day one productivity.

With CIS you can ensure that users have seamless access via single sign-on (SSO) and that their Google G Suite accounts are created, updated, and deactivated on an integrated cycle with the rest of the systems in IT.

 

Centrify Identity Service enables integration with any web application that also enables administrators to:

  • SSO via SAML or CIS form fill to all Google G Suite: Gmail, Docs, Sites, Calendar, Analytics, etc.
  • Provide secure SSO with Active Directory integration
  • Automatically provision/de-provision users & apps by Active Directory group
  • Demonstrate compliance through usage auditing
  • Increase application ROI with seat-utilization reporting

Secure Application Access via MFA from unauthorized systems or locations

Read more...

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

Centrify Identity Service now includes a turnkey Munki solution for application management for managed Macs delivering a best in class user experience without any setup or configuration hassle.

Read more...

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 

[How To] - Installing Centrify Connector

By Centrify Contributor III Friday - last edited Sunday

 Thank you for choosing Centrify!

 

The purpose of this guide is to help walk you through an installation of the Centrify Connector. The Centrify Connector is a feature rich lightweight application that provides the following services:

  • Active Directory/LDAP Proxy
  • Application Gateway 
  • RADIUS Server
  • Web Server (IWA)

 

Server hardware requirements

The Centrify Connector is installed on a Windows computer to establish the communications link between the Centrify Identity platform and Active Directory domain controller.

 

If you are referencing accounts in an Active Directory tree or forest, the cloud connector can be joined to any domain controller in the tree (it does not need to be the root). In addition, that domain controller must have two-way, transitive trust relationships with the other domain controllers. 

 

This computer must be in your internal network and meet or exceed the following requirements:

  • Windows Server 2008 R2 or newer (64-bit only) with 8 GB of memory, of which 4 GB should be available for Centrify Connector cache functions.
  • Has Internet access so that it can access the Centrify Identity Services platform.
  • Has a Baltimore Cyber Trust Root CA certificate installed in the Local Machine Trusted Certificate root authorities store.
  • Microsoft .NET version 4.5 or later; if it isn’t already installed, the installer installs it for you.
  • Be a server or server-like computer that is always running and accessible.

 

Let's Get Started

 

1) Download the Centrify Connector package by logging into your Identity Services 'Admin Portal' navigating to 'Settings' -> 'Network' -> 'Centrify Connectors' -> 'Add Centrify Connector'

 

Screenshot 2017-04-21 14.52.00.png

 

 

2) Click on the ’64-bit’ link to download the installation package to the server you want to install the Cloud Connector on. 

 Screenshot 2017-04-23 09.27.01.png

 

 

3) Install the Centrify Connector on the member server by double clicking on the executable file.

 

9 - installing cloud connector.png

 

4) Click ‘Next’ to continue.

 

Screenshot 2017-04-21 15.03.18.png

 

5) Review the Centrify End User Software License and Services Agreement, accept the terms of the agreement, then click ‘Next’ to continue.

 

Screenshot 2017-04-21 15.03.36.png

 

6) Click ‘Install’ to install the Centrify Connector on the server.

 

Screenshot 2017-04-21 15.09.00.png 

 

7) Click ‘Finish’ to complete installation of the Centrify Connector on the server.

 

Screenshot 2017-04-21 15.31.43.png

 

8) A second installation wizard will appear to initiate the connection between active directory and your Centrify Identity Service tenant. Once the window does appear, click ‘Next’ to continue.

 

Note: The second installation wizard may take up to a few minutes to appear. 

 

Screenshot 2017-04-23 09.50.29.png

 

 

9) Provide your Centrify Identity Service administrator username and password. This is the default administrator password provided during activation to your Centrify Identity Service tenant. Click ‘Next’ to continue.

 

Screenshot 2017-04-21 15.15.16.png

 

10) If you are installing the Centrify Connector on a proxy server, add those configurations in this window. While available as an option, a web proxy server is not required for the Centrify Connector. Click ‘Next’ to continue.

 

Screenshot 2017-04-21 15.19.44.png

 

11) The Centrify Connector requires read permissions to the Deleted Objects container in active directory. This permission is required for the auto de-provisioning feature to appropriately delete/disable users from applications when deleted or disabled in active directory. If you are using an account that has read permissions to the Deleted Objects container, such as a user with Domain Admin and/or Enterprise Admin level permissions to the domain, the Connector will inherit the permissions of the account automatically. Click ‘Next’ to continue.

 

Screenshot 2017-04-21 15.19.28.png 

 

12) If you are installing the Centrify Connector with credentials that do not have read access to the Deleted Objects folder, you can specify alternate credentials by clicking on 'Edit -> Specify alternate user credentials'. The Centrify Connector will inherit permissions of the credentials you specify in this menu or by the user installing the Centrify Connector on the server. If you specify alternative credentials, click 'OK' then 'Next' to continue. 

 

Screenshot 2017-04-21 15.19.57.png

 

13) The Centrify Connector will attempt to connect to your Centrify Identity Service tenant. When you see five successes, click ‘Next’ to continue.

 

Screenshot 2017-04-21 15.20.09.png

 

14) Click ‘Finish’ to continue.

 

Screenshot 2017-04-21 15.20.40.png

 

15) The Centrify Connector Configuration console will display upon completion of the installation. Verify the connection is successful within the ‘Status’ tab.

 

Note: You can install multiple connectors to architect high availability and redundancy in your environment. Repeat the installation steps to install additional Centrify Connectors in your environment for redundancy and high availability. Centrify Connectors work active/active, load balance authentication traffic and are sight aware. 

 

Screenshot 2017-04-23 09.57.25.png

 

 

16) The ‘Centrify Connector’ tab within the Centrify Connector Configuration console, gives you the ability to 'Start'/'Stop' the connection to your Identity Service tenant. You can also 'View Log' from the persistent outbound connection the Centrify Connector has established to your Identity Service tenant.  

 

Screenshot 2017-04-23 09.59.11.png

 

 

 

17) In Centrify, refresh the web-page and verify that the Centrify Connector connection to your Centrify Identity Service tenant has appeared and the connection was successful - designated by statues of ‘Active’. If you have multiple Centrify Connectors, you will see each instance of those connections listed in this menu. 

 

23 - cloud connector confirmation.png

 

We hope you found this guide helpful. Feel free to post questions in this thread or contact Centrify for additional information. 

Centrify for Google G Suite offers a complete, robust, and easy-to-use Active Directory (AD) or Centrify Cloud Directory integration with Google G Suite providing a seamless authentication experience for Google G Suite users and an easy to use intuitive Administrative interface for IT staff to automate the process of on- and off-boarding employees with day one productivity.

 

With Centrify you can ensure that users have seamless access via single sign-on (SSO) and that their Google G Suite accounts are created, updated, and deactivated on an integrated cycle with the rest of the systems in IT.

Secure access to Google G Suite from any device. Enforce and update mobile security settings, and remotely lock or wipe devices. Lock the Centrify Mobile App with a passcode or fingerprint, and prevent unauthorized users from accessing your Google data. No separate software required.

 

The Google G Suite Deployment Guide covers…

 

  • Preparing your Google G Suite and Google G Suite developer account
  • Limiting access to certain Google G Suite based on Security Group
  • Configuring automated account provisioning into Google G Suite
  • Enabling Single Sign On in Google G Suite
  • Provisioning new Users
  • Integration with Active Directory
  • Securing the Administrative Account for Google G Suite

 

Read more...

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

Thank you for choosing Centrify!

 

The following is an end-to-end guide for integrating Concur with the Centrify Identity Service platform. The integration helps to eliminate identity silos with administrators having to manage user's access across multiple systems and end users having to remember multiple usernames and passwords. The integration allows administrators to manage user's access from one common directory (i.e. Active Directory), including inheritance of your active directory group policies to secure access to Concur. End users enjoy the benefit of single sign-on to Concur, leveraging a credential they already know and use on a daily basis - their active directory credentials. 

 

Install time ~ 1-3 hours

 

Requirements

1) Concur account

2) Centrify Identity Service account

3) Active Directory

4) Windows server for Centrify Connector (requirements below)

 

Let's get started

 

1) Log into your Centrify Identity Service tenant. 

 

5 - login page.png

 

2) Once logged on, you will be presented with Centrify’s configuration wizard. You can choose to use the wizard for general setup, however, for purposes of this guide, you can check the ‘Don’t show this to me again’ box and close the window. This will stop the wizard from appearing during the configuration process.

 

6 - wizard.png

 

3) Install the Centrify Connector following this guide: 

http://community.centrify.com/t5/TechBlog/How-To-Installing-Centrify-Cloud-Connector/ba-p/27840

 

 

4) Next, we must create roles in Centrify to contain the users of the Concur application. Concur has two roles a user can be assigned: (1) administrator or (2) end user. For the purposes of this guide, we will create an administrator role for all the Concur administrators and an end users role for all non-administrator users (e.g. employees of a company). To create a role, navigate to 'Roles' -> 'Add Role'. Name the role 'Concur Administrators'. 

 

Screenshot 2017-04-16 16.08.21.png

 

5) In the 'Members' tab, add the administrator users from your active directory. Members can be individual users or security groups with one or more users within the group. In this example, I've added the 'Domain Admins' group as the users who will have administrator access to Concur. 

 

Screenshot 2017-04-16 16.08.55.png

 

 

 6) Add another role for Concur end users. Add the appropriate users from active directory as members to the role. 

 

Screenshot 2017-04-16 16.09.18.pngScreenshot 2017-04-16 16.12.02.png

 

 7) Next, navigate to the 'Apps' menu, click 'Add Web Apps', then search for the 'Concur' application. Choose the 'Concur SAML + Provisioning' template by clicking 'Add'. 

 

Screenshot 2017-04-16 16.17.05.png

 

8) Within the 'Application Settings' page, you will see the 'Identity Provider Logout URL' and 'Download Signing Certificate'. To enable single sign-on for Concur, you must contact your Concur customer success manager and provide them the following two configurations from your Centrify Identity Service console. Download the Centrify certificate and provide the file and the logout Identity Provider Logout URL to Concur. Concur will enable single sign-on and apply the settings to your Concur tenant. 

 

Screenshot 2017-04-16 16.17.27.png

 

9) Next, open the 'User Access' tab. Select the Centrify roles you've created for Concur and click 'Save'. 

 

Screenshot 2017-04-16 16.17.38.png

 

10) When Concur has completed enabling your Concur tenant for single sign-on, log into your Centrify Identity Service user portal. Click on the Concur application tile to confirm you are able to log into Concur. 

 

Screenshot 2017-04-16 16.18.56.png

 

 

We hope this guide was helpful. If you have any questions, please use this forum thread as a resource or contact Centrify - https://www.centrify.com/about-us/contact/

 

Thank you!

Thank you for choosing Centrify!

 

The following is an end-to-end guide for integrating Zendesk with the Centrify Identity Service platform. The integration helps to eliminate identity silos with administrators having to manage user's access across multiple systems and end users having to remember multiple usernames and passwords. The integration allows administrators to manage user's access from one common directory (i.e. Active Directory), including inheritance of your active directory group policies to secure access to Zendesk. End users enjoy the benefit of single sign-on to Zendesk, leveraging a credential they already know and use on a daily basis - their active directory credentials. 

 

Install time ~ 1-3 hours

 

Requirements

1) Zendesk account

2) Centrify Identity Service account

3) Active Directory

4) Windows server for Centrify Connector (requirements below)

 

Let's get started

 

1) Log into your Centrify Identity Service tenant. 

 

5 - login page.png

 

2) Once logged on, you will be presented with Centrify’s configuration wizard. You can choose to use the wizard for general setup, however, for purposes of this guide, you can check the ‘Don’t show this to me again’ box and close the window. This will stop the wizard from appearing during the configuration process.

 

6 - wizard.png

 

3) Install the Centrify Connector following this guide: 

http://community.centrify.com/t5/TechBlog/How-To-Installing-Centrify-Cloud-Connector/ba-p/27840 

 

4) Next, we must create roles in Centrify to contain the users of the Zendesk application. Zendesk has 3 roles (Admin, Agent and End-User) that can be leveraged. A minimum of one Centrify role must be created and mapped to a Zendesk role (See Step 32 below). For the purposes of this guide, we will create an administrators role for all the Zendesk administrators. Additional roles can be created in Centrify similarly to the administrator role done in this guide. To create a role, navigate to 'Roles' -> 'Add Role'. Name the role 'Zendesk Administrators'. 

 

Screenshot 2017-04-16 14.01.46.png

 

5) Next, navigate to the 'Members' tab and select the users that you want to grant 'Administrator' access in Zendesk. This can be individual users in active directory or a security group that contains multiple users. Search for the users or security groups and click 'Add'

 

Screenshot 2017-04-16 14.02.17.png

 

6) Next, navigate to 'Apps' menu from the navigation bar, then 'Add Web Apps'. Search for the Zendesk application and choose the 'Zendesk SAML + Provisioning' template. Click 'Add' to continue. 

 

Screenshot 2017-04-16 14.03.17.png

 

7) Click 'Yes' to continue. 

 

Screenshot 2017-04-16 14.03.24.png

 

8) Next, open a new browser tab login to Zendesk with your administrator account. Under 'Security', enable the 'Single Sign-on (SSO)' configuration, then enable 'SAML' as the protocol. 

 

Screenshot 2017-04-16 14.05.46.png

 

9) With both the Centrify 'Application Settings' page and the Zendesk 'Single sign-on (SSO)' tabs open, exchange the following configurations as illustrated below. The 'Zendesk Account Name' is your Zendesk account name which can be taken from your login URL (i.e. The 'https://centrifydemo236.zendesk.com' Zendesk tenant URL will have the account name 'centrifydemo236'). Click 'Save' in both Centrify and Zendesk once complete.  

 

Screenshot 2017-04-16 14.07.24.png

 

10) Next, navigate to the 'User Access' tab in Centrify. Select the Centrify roles you created for Zendesk in Step 24. 

 

Screenshot 2017-04-16 14.08.39.png

 

11) Next, navigate to the 'Provisioning' tab. Click 'Enable provisioning for this application' and provide an administrator (1) Username, (2) Password and (3) Redirect URL in the form fields. Click 'Verify' to complete this step. 

 

** Provisioning allows administrators to manage Zendesk users from active directory. For example, in step 15, we added the 'Domain Admins' security group as a member to the 'Zendesk Administrators' Centrify role. Adding a new hire to the 'Domain Admins' group will prompt Centrify to auto provision a Zendesk account with administrator level access. 

 

Screenshot 2017-04-16 14.11.30.png

 

12) Once verified, scroll down to the 'Role Mappings' section and click 'Add'. As the first option, choose the 'Zendesk Administrator' role created in Step 24 and map to the 'Destination Role' 'Admin' in the Zendesk application. Click 'Done' to complete. 

 

Screenshot 2017-04-16 14.11.51.png

 

13) If you have created other roles for Zendesk, repeat the step as shown for the 'Zendesk End Users' role. 

 

Screenshot 2017-04-16 14.12.06.png

 

14) Once you've mapped all roles you've created for your Zendesk users, click 'Save' to complete the provisioning configurations. 

 

Screenshot 2017-04-16 14.12.20.png

 

15) To complete the integration, navigate to 'Settings' -> 'Users' -> 'Outbound Provisioning'. Under the 'Provisioning Enabled Applications', choose the 'Zendesk' application then click on the 'Start Sync' button. 

 

Screenshot 2017-04-16 14.37.44.png

 

16) Click the 'bypass caching and re-sync all objects' then 'Yes' to initialize the first integration and sync between Centrify and Zendesk. This step may take a few minutes depending on the number of users Centrify is provisioning into Zendesk. 

 

Screenshot 2017-04-16 14.12.50.png

 

17) Once complete, navigate to your 'User Portal' and verify that you can log into the Zendesk application by clicking on the application tile. 

 

Screenshot 2017-04-16 14.14.11.png

 

We hope this guide was helpful. If you have any questions, please use this forum thread as a resource or contact Centrify - https://www.centrify.com/about-us/contact/

 

Thank you!

Updating Active Directory passwords for Mac users can be a nightmare both to endusers and IT. Centrify provides several ways to help prevent the dreaded Keychain prompts from appearing.

Read more...

For customers that already use Symantec VIP for MFA and want to layer on the Symantec VIP MFA solution to the features that Centrify Server Suite provides, you can use this guide to add Symantec VIP MFA through PAM chaining. This allows you to leverage your existing investment in Symantec VIP until a time when you are ready to explore Centrify's fully integrated MFA Everywhere capability. 

Read more...

There are many occasions where a Centrify administrator needs to change UNIX Data on a specific Centrify Zone, specially when the Zone Provisioning Agent is not enabled. For example, a Centrify admin might need to change the shell for many users at the same time. If you have a lot of users in your UNIX Data / Users folder, this could be time consuming.

 

You can use adedit to achieve this. Continue reading...

Read more...

Background

 

Audit Events have been part of DirectAudit for many major releases of Centrify Server Suite, Enterprise Edition, and the Audit Analyzer console allows auditors a convenient, central location to view audited sessions that contain audited events (or elevated privileged events). Not only can they utilize the predefined queries to quickly and efficiently find audit events, but they can create their own queries by defining search filters such as users, computers, event time, event type, and the session result.

 

 

Group Policy - Adjust Audit Trail Targets

 

In addition to the Audit Event framework in Audit Analyzer, there is also an obscure group policy that is available to customers called "Set Global Audit Trail Targets". This policy allows Centrify administrators to specify the target location for audit trail information, and from the Group Policy Management Editor, it is located at:

 

Computer Configuration > Policies > Administrative Templates > Centrify Audit Trail Settings

 

AuditTrailPolicy.jpg

 

 

If you set this group policy to Not configured or Disabled, the destination of audit trail information depends on which version of DirectAudit is installed. If DirectAudit 3.2 or later is installed, audit trail information is sent to the local logging facility and DirectAudit. If a DirectAudit version earlier than 3.2 is installed, audit trail information is only sent to the local logging facility.
 
If you set this group policy to Enabled, you can specify the target for audit trail information. Possible settings are:
0 - Audit information is not sent.
1 - Audit information is sent to DirectAudit. This capability is supported by DirectAudit version 3.2 and later.
2 - Audit information is sent to the local logging facility (syslog on UNIX systems, Windows event log on Windows systems).
3 - Audit information is sent to both DirectAudit and the local logging facility.
 
NOTE: This group policy modifies the audittrail.targets setting in the centrifydc.conf agent configuration file.
 
 
Catalogued Events
 
When Centrify Server Suite 2015 was released, it included a new, convenient feature that documented all audit trail events into a single XML file called "AuditTrailEvents.xml", and it's located in the Centrify DirectManage installation directory on Windows. Not only were all of the events documented, they were catalogued, with each event having its own unique Event ID. Here is a short snippet of the current v2 file:
 
AuditTrailXML.jpg
 

 

On Windows clients, the audit trail event is written in Windows Application Event Logs with the unique event ID as Event ID and a Windows Event Source called "Centrify AuditTrail V2". On Unix/Linux clients, the Event IDs are written to local syslog in the centrifyEventID field.

 

NOTE: Please refer to the Centrify Audit Trail Events XML documentation for a complete list of Audit Trail events and their corresponding unique Centrify Event IDs.

 

 

SIEM Integration

 
With the catalogued audit event file comes additional capabilities, allowing customers to use these audit events as input to their existing SIEM tools. And you can then provide alerting and notification from your monitoring tool-of-choice based on the specific event ID's that you want to query.
 
In a previous 4-part article, Centrify Product Manager, Satish Veerapuneni, wrote extensively about how Centrify integrates indirectly with SIEM tools (as mentioned previously) or directly with the following 3 SIEM tools:
 
  • Splunk
  • HP ArcSight
  • IBM QRadar
Taking the Splunk integration as one example, in order to view administrative events in the Splunk Enterprise console, you need to first install the following two Centrify apps:
 
SplunkApps.jpg

 

Once you install these two apps, you can then begin receiving audit events from within the Splunk console. For example, when a Centrify administrator creates a new Child Zone inside of Access Manager, we can follow the lifecycle and see the end reporting result below:

 

NewChildZone.jpg

 

SplunkConsole1.jpg

 

SplunkConsole2.jpg

 

 

Background

In a previous article titled "How to Use DirectControl to Facilitate Kerberos-based Oracle SSO on Unix and Linux", we discussed how the Centrify DirectControl agent can be leveraged to allow Active Directory users to authenticate to an Oracle database seemlessly and securely without having to enter their username and password. Unfortunately, allowing AD-based Single Sign-On for end users is only half of the battle for Oracle-related accounts.

 

By default, there are over 28 predefined accounts (administrative & non-administrative) and several, additional schema accounts created during an Oracle database installation. Only a few of these accounts are addressed during the Oracle installer and let you update the password; most of the others are automatically expired and locked. This leaves the Oracle DBA to manage those accounts and come up with a strategy for properly securing the passwords.

 

The Centrify Privilege Service (CPS) is an Enterprise access management and password service that can group databases and secure internal database accounts for both Oracle and SQL Server databases. In this article, we'll see how we can add an Oracle database to CPS, add accounts (managed & non-managed), and then create sets of databases in order to implement additional access control over these accounts.

 

Requirements

  • Oracle 11g or 12c Database software installed and functioning properly on a Centrify-supported Linux server (The Centrify Server Suite agent, DirectControl, doesn't need to be installed)
  • The latest instance of Centrify Privilege Service, deployed either as a cloud-integrated component to the Centrify Identity Service (CIS) or as a standalone service deployed on-premises. This article uses the CIS cloud-integrated deployment option.
  • The accounts you manage must be configured to include the CREATE SESSION privilege
  • Management of the password for the SYS account is not supported by the Centrify Privilege Service because it requires a physical password file.
  • You must install the ODP.NET client library on the same machine where the Centrify Connector is installed. You can download the Oracle ODP.NET managed driver (ODP.NET_Managed_ODAC12cR4.zip) from the Oracle downloads website or here. If you download and install the library after you install the Centrify Connector, you should restart the Connector before adding the database to CPS. If a newer version of the client library is available, keep in mind that only the baseline version (12.1.0.2.4) and the latest version available are supported.
  • Centrify Privilege Service can manage the account password for standalone Oracle server. However, the Centrify Privilege Service does not synchronize managed passwords across computers in a cluster at this time.

 

Step 1 - Decide which Oracle Accounts to Add to CPS

Typically, the SYSTEM administrative account is the first account that DBA's like to protect the password for; this is because it is used the most often. However, there are many additional accounts, both administrative and non-administrative, that may be in scope for your requirements.

 

A simple question that you can ask is, "what type of functionality will I need to enable as part of my Oracle database installation?". You can then select the associated administrative accounts and use those and the intiial accounts to add into CPS for management.

 

You will then need to decide which of those accounts that you would like CPS to manage. Having a "managed" account means that CPS will securely vault the password, set it to a random, secure string, and then rotate it whenever the password is checked back in or whenever it is forced to rotate.

 

Step 2 - Add an Oracle Database(s) to CPS

  • Authenticate to your CPS tenant as a user with the sysadmin administrative right
  • Select the Databases tab; then click Add Database to open the Add Database Wizard
  • Type a unique name to identify the database, select the type of database service you are adding, and specify the fully-qualified DNS host name or IP address, and click Next.

AddDatabase.jpg

 

 

NOTE: If the database type is Oracle, you must also specify a database service name and the accounts you add must be Oracle database accounts. Optionally, you can also type a longer description for the database. For example, you might want to make note of the applications the database supports or the physical location of the server, then click Next to continue.

 

  • Add a user name and password for an account used to access the database and specify whether the password for the account is managed by the privilege service, then click Next.
  • Select Verify Database Settings to test access to the database using the account information provided, then click Finish. If the database and account settings are successfully verified, click Close.

 

NOTE: If there’s an error, test network connectivity and verify that the user name and password you provided are valid for the database you are attempting to add. If verification fails, close the error message, deselect the Verify Database Settings option, then click Finish to add the database and close the Add Database Wizard. You can only deselect the Verify Database Settings option if the password for the account is unmanaged. If the password for an account is managed, the database account must be verified to ensure the correct password is stored by the privilege service.

 

Step 3 - Add the Database(s) to a CPS Set (optional)

If you would like to group databases together by environment or application, for example, then you might choose to create a CPS Set for the database(s). This would then allow you to apply specific policies to the CPS Set. For example, you might want to have your internal DBA's to have access to the Oracle accounts on Production databases while external consultants might only have access to the same accounts on non-Production databases. You could then decide to implement strong authentication controls for the external DBA consultants.

 

To create a new static Set, simply select the Sets tab next to Databases, name the Set, and then add the Database members to the Set. Once the Set is created and membership defined, you then select the Users or Groups of Users that you want to add Set and Member Permissions for.

 

Step 4 - Set the Permissions (& Additional Options) for Database Resources & Accounts

Once your database(s) and associated accounts are added to CPS, you will need to set permissions on both. You can also choose to enable Access Request/Workflow and set Password Checkout policies for the particular user accounts.

 

In the screenshot below, user dwirth has full access to the SYSTEM account for this database resource:

 

Account_Perms.jpg

 

Step 5 - Test the Password Checkout for an Oracle Account

Once you have verified that CPS can properly communicate to the Oracle database(s), the final step is to simply confirm that you can checkout the password for one of the Oracle accounts that you have added.

 

From the Resources tab, rt-click on the database resource, select Account Actions, and then choose to Checkout the password. If you have enabled Workflow for this database resource, then the "Request Checkout" option should be listed for users who initiate a password checkout session:

 

PW_CheckOut.jpg

 

NOTE: You can also initiate an account password checkout from the Accounts tab. Just choose Database Accounts as the seach criteria, rt-click on the account, and choose Checkout. If you have been given the proper account permission, you can also rotate the password.

 

NOTE: If you don't want CPS to manage a particular account when adding accounts to a database resource, then simply leave that box unchecked in the Add Database Wizard. While the password will stay statically defined to whatever you set it to, you can still use the Workflow and Policy controls to further secure the access to that account password.

 

Summary

As you've seen from this article, there are many pre-defined Oracle accounts that also need to be properly addressed in order to secure identities across your Oracle installations. Leaving these types of shared access account passwords unprotected will increase the chances that someone will eventually hijack the account password and use it for malicious intent.

 

Using your existing CPS tenant, whether it be deployed on-premises or integrated into CIS, you can quickly and efficiently secure the passwords for these accounts.

 

CIS Version 17.3 adds a new feature to specify which user name format is sent to a RADIUS server during MFA.

Works with DUO, SecurID, SecureAuth, etc. 

Read more...

One of the more anticipated features of the Centrify Identity Service 17.3 release is the ability to manage Windows 10 devices. This feature is currently in preview mode, but is available once enabled on your tenant. This post details the steps to enroll such a device into CIS. If you are interested in what administrators need to configure for Windows 10 mobile device management, please click here.

 

1. Under Settings, choose Connect to work or school.

Win10-1.png

 

2. Choose Connect

Win10-2.png

3. Enter your email address

Win10-3.png

 

4. This should locate your tenant in Centrify Identity Service. Enter your user name.

Win10-4.png

 

5. Enter your password

Win10-5.png

 

6. Choose an authentication method for multi-factor authentication

Win10-6.png

 

7. Respond to the challenge

Win10-7.png

 

8. You should see a success message, as below.

Win10-8.png

 

9. On the settings screen, you should see your work account similar to what is shown below

Win10-9.png

 

10. If you select the work account, you should see additional details similar to what is shown below

Win10-10.png

 

11. Log into your CIS tenant and select device tab. Your Windows 10 device is enrolled and should show here.

Win10-11.png

 

12. The Wipe Device and Unenroll Device actions should now be available.

Win10-12.png

 

So you're already managing user accounts in Active Directory - but what about those pesky system accounts you're still managing in /etc/passwd?  Wouldn't it be great to manage them with Centrify too?  In this article we'll demonstrate how to securely manage local accounts using a comination of Centrify Server Suite and Centrify Privilege Service.  

 

Read more...

Create a report listing all Resources in the Centrify Privilege Service

By Centrify Advisor IV on ‎03-27-2017 02:16 PM - last edited 3 weeks ago

Here's a quick report that can give you a list of resources in the Privilege Service. This is handy if you've run the Discovery tool and now want to print out your list of discovered resources. 

 

Read more...

User activity attribution even after they "sudo to root"

By Centrify Contributor II on ‎03-26-2017 10:53 AM - last edited 3 weeks ago

Centrify Server Suite 2017's new Advanced Monitoring functionality preserves "identity context" even after the user "sudo's to root".

 

The new “advanced monitoring” feature adds three new functionalities:

  • Generate audit trail events when specific programs are executed by any user.
  • Generate audit trail events when any file in the directories /etc, /var/centrifyda and /var/centrifydc is modified by a non-root user.
  • Get history of programs executed in an audited session, including programs that are executed by scripts.
Read more...

Configuring Centrify to use the Google Authenticator to satisfy MFA challenges is a good way to give users another authentication factor. The set up is easy for end users once all of the policies are configured from an Centrify Identity Platform Administrator.

Read more...

The Centrify Privileged Identity Management solution provides a set of controls for Google Compute Engine Linux VM Instances to support Enterprise integrated identity and access management functions. This solution enables organizations to consolidate identities, enforce cross-platform least privilege access and control shared accounts, while securing remote access and auditing all privileged sessions.

              

This guide will show how to setup and configure Active Directory based identity and access controls as well as privilege management for Linux VM Instances running on Google Cloud Platform. It will also show how to take over password management for local root accounts as well as to provide secure remote access to these Linux VM Instances.

Read more...

If you are already using the Centrify Identity Service for single sign-on, then your users can easily configure automatic login for the websites that they frequent. This is very beneficial for users that are accustomed to saving credentials into their browsers, since they do not have to store the credential in the Credentials Manager or Keychain.

Read more...

For customers that already use Symantec VIP for MFA and want to layer on the Symantec VIP MFA solution to the features that Centrify Server Suite provides, you can use this guide to add Symantec VIP MFA through PAM chaining. This allows you to leverage your existing investment in Symantec VIP until a time when you are ready to explore Centrify's fully integrated MFA Everywhere capability. 

Read more...

Showing results for 
Search instead for 
Do you mean 
Labels
Leaderboard

Community Control Panel