Background

AWS WorkSpaces "allows customers to launch cloud-based desktops that allow end-users to access the documents, applic..." a cost effective way to manage these desktops is to use SimpleAD (an AWS-hosted Samba4-based directory that provides similar capabilities as Microsoft's Active Directory), this allows for centralized administration of users, policy enforcement, and Kerberos authentication.

 

Identity Assurance for Cloud-based Desktops

The goal of this article is to establish a lab to test MFA capabilities using Centrify technologies. 

As per the IAM model below, the first step is making sure that users accessing your AWS WorkSpaces are who they say they are, and with Centrify you can employ a variety of multi-factor or step-up methods.

 

model.png

 

With Centrify, organizations can secure Windows Systems by providing:

  • Access control using Centrify Zone technology
  • Strong Authentication with MFA at login, screen lockout or remote desktop
  • Privilege Elevation for application or administrative desktop

A complex requirement for some organizations is to run their own Active Directory Connector and RADIUS infrastructure (see details here) however, with the Centrify Agent for Windowsand the Endpoint capabilities of Identity Service, we can provide MFA at login and screen lockout while still using Simple AD.

 

In this lab, we'll use the Plan-Do-Check-Adjust methodology

 

Planning

Planning Topics

  • Define the Authentication Factors required for AWS WorkSpaces MFA
    These could be true 2FA (Push MFA, OATH OTP, RADIUS, etc), step-up (E-mail, Phone Factor, SMS) or Multi-Secret (security question);  this defines your authentication profiles.
  • Define the use cases that require MFA:
    • At login
    • At screen unlock  - will there be a grace period?  (e.g. do not require MFA if the screen is locked less than 10 minutes)
    • At privilege elevation (if the WorkSpace is being used as a management workstation)
  • Configure which users get challenged for MFA (e.g. will there be users excempt?)
  • Will offline passcodes codes be allowed (for requiring MFA if the WorkSpace can't connect to the Centrify service? What will be the behavior of the dialog box?
  • What is the Directory architecture?
    There are different approaches for AWS-hosted (Simple AD, Microsoft AD or even your own using EC2 instances)
    Expect this to be the most important planning topic
  • How many Centrify connectors and what services are required?

 What's required?

  • Knowledge of AWS concepts: VPCs, EC2 instaces, Security Groups, Directories and AWS WorkSpaces
  • Basic Knowledge of Centrify Identity or Privilege Service MFA
  • Identity Service or Privilege Service (SaaS) configured for MFA:
    • A Role with the Computer Login and Privilege Elevation (e.g. MFA Computers)
    • An authentication profile configured for Computer Login and Privilege Elevation
    • The AWS Workspace system has to trust the IWA root certificate for the tenant
    • A Centrify connector reachable by the AWS WorkSpace(s) VPC
  • AWS WorkSpace configured and running
    • A WorkSpaces Directory (Simple AD) and administrative credentials
      Note: any Active Directory or similar technology including Simple AD or any AWS or customer-managed Microsoft AD) will technically work as long as the communication requirements are met.
    • Your end-users must be populated in the directory with information for any MFA or step-up methods (e.g. telephone, mobile, e-mail, etc)
    • At least one Windows Server 2012 R2 and up EC2 instance in a security group that allows communication with the AWS WorkSpace Directory servers (HTTPS and TCP 8443 from the WorkSpaces systems outbound to the connector)
    • The connectors security group should have outbound HTTPS and Service Bus connectivity to the Centrify Identity or Privilege service instance.
  • Software Requirements:
    • Centrify Group Policy Extensions (available from the Server Suite installation bits)
    • Centrify Agent for Windows (tm) - available from the Server Suite installation files or the downloads section of the Admin portal for Identity Service or Privilege Service.  This post uses version 3.4.2.

In this lab, we'll run a Centrify Connector in a Windows Server joined to the AWS WorkSpaces directory, this EC2 instance is in a security group that allows IWA and AD communication with the directory service and members.  Alternatively, you could run the Centrify connector in a dedicated WorkSpace.

 

Implementation

Lab Overview

  1. Verify pre-requisites
  2. Launch an EC2 Windows Server instance, configure DNS and install Windows tools and features (RSAT-ADDS, GPMC)
  3. Join the system to the AWS WorkSpace directory and sign-in with an administrative user
  4. Create Structure in Active Directory (OUs, users)
  5. Install a Centrify connector the EC2 Instance and download the IWA Root Certificate
  6. Download and install the Centrify Windows Group Policy Extensions
  7. Configure PKI Trust and Centrify Agent Settings via Group Policy
  8. Launch an Amazon WorkSpace and download/install the WorkSpace client
  9. Configure the WorkSpace in the directory and authorize it for MFA
  10. Connect to the WorkSpace and Install  the Centrify Agent for Windows
  11. Test your configuration

 

Lab Diagram

aws-workspaces.png

Implementation

 

1. Verify Pre-Requisites

The most challenging part of this lab is to figure out the communication paths between the systems.  In this lab we are over-simplifying the process, but in a real deployment always use the minimum set of ports needed for functionality.

 

  • Communications between the AWS WorkSpace directory and your EC2 instances
    Go to AWS Console > Workspaces > Directories and expand your Directory, note the Directory ID and the IP Addresses (these are the IP addresses of your DCs and DNS servers)
    simplead1.JPG
    Go to AWS Console > EC2 > Instances > Security Group and select the Security Group designated for your EC2 Windows instances that will run the Centrify connector service (e.g. Connector group).
    simplead2.png
    Make sure that:
    - The connector group and the directory domain controllers can talk AD communications (DNS, Kerberos, LDAP, etc)
    - The members of the domain (including AWS WorkSpaces systems) and the connector  can talk over HTTPSgroup and TCP 8443.
    - The connector group has at least outbound HTTPS and Azure Service Bus connectivity with the Centrify Identity or Privilege Service tenant.

 

2. Launch an EC2 Windows Server instance, configure DNS and install Windows tools and features (RSAT-ADDS, GPMC)

  1. Log in to your EC2 console console.aws.amazon.com/ec2 and launch a current Windows Server instance in the security group designated for the connectors; this instance should have at least dual core processors and 8GB of RAM.  In addition it should have outbound internet connectivity  (direct or via proxy). 
  2. With the information collected about the AWS WorkSpace directory (the IP addresses of the directory servers), open the Network control panel (ncpa.cpl) and modify the TCP/IP properties of the network card.  In IPv4, add one of the IP addresses of the directory DCs as the primary and secondary DNS server entries for the EC2 Windows instance.
    ip-conn.JPG
    To verify connectivity, ping the domain, you should receive a response.  Note that this can be also accomplished with a VPC option set.
  3. Open an administrative PowerShell, and add the AD remote admin tools as well as GPMC.
    Install-WindowsFeature RSAT-ADDS, GPMC

3. Join the system to the AWS WorkSpace directory and sign-in with an administrative user

  1. Join Active Directory using the System Applet or PowerShell
  2. When prompted, provide administrative credentials to the AWS WorkSpaces directory.
  3. When prompted to reboot, select yes, and reconnect to your system
  4. Sign-in with a directory privileged user (e.g. administrator)
  5. Verify that you can open the domain administrative tools like Active Directory Users and Computers (dsa.msc) and GPMC.msc

4. Create Structure in Active Directory (OUs, Users)

Note:  These steps will be described at a high-level.

  1. Open ADUC (dsa.msc)
  2. Create 2 OUs, one for the WorkSpaces computers, the other for the test Users (e.g. Staff)
  3. In the Staff OU, create your test users.  Make sure you populate the information required for your MFA challenges (e.g. email and mobile number.  I created two users: Lisa and Diana.
    aduc.JPG
  4. Stay logged in as a domain administrator.

5. Install a Centrify connector the EC2 Instance and download the IWA Root Certificate
Note: for detailed steps to install a Centrify connector.  Check out this help article.

  1. Sign-in to your Centrify instance as a privileged user (e.g. https://example.my.centrify.com)
  2. Go to Admin Portal > Settings > Network and click Add Centrify Connector
  3. Click on 64 bit, this will start the Connector download.
  4. When downloaded, double-click and follow the wizard for setup (you don't need mobile tools), when finished the configuration wizard starts.
  5. Provide the Centrify tenant information and credentials, then follow the wizard (you don't need the activation or deleted items option).
  6. Verify that the Centrify applet displays a succesful connection.
    successful.JPG
  7. Go back to the Centrify Admin portal and under Settings > Network  >  Centrify iwaroot.pngConnector, press refresh on your browser.  You should see the newly-installed connector on the list, double click it and go to IWA Service, then click on the "Download IWA root CA Certificate" link, this will download the tenant's Integrated Windows Authentication certificate.  This is required for the client to communicate to the service.

6. Download and install the Centrify Agent and the  Centrify Windows Group Policy Extensions

  1. In the Centrify Identity or Privilege Service, go to the Admin Portal
  2. Click the administrator's name on the upper right corner and select Downloads and click Centrify Agents
  3. Download the Centrify Agent for Windows and the Centrify Windows Group Policy Extensions
  4. Double-click the Centrify Windows Group Policy Extensions and follow the wizard until the installation is complete.

7. Configure PKI Trust and Centrify Agent Settings via Group Policy

In this section, we'll distribute the IWA trust root certificate from the tenant using GPOs; we will import the GPO templates for the Centrify Agent for Windows.

 

  1. Open GPMC and expand your forest/domain
  2. Right click the WorkSpaces OU and select "Create a GPO in this domain and link it here" and give it a name
  3. Right-click the newly-created GPO and select Edit, this opens GP Editor.
  4. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities and right click the white space in the right pane, select Import
  5. In the Wizard, press next and then press browse to the location of the IWA Trust certificate from the previous section.  Once completed, you'll have the certificate for the tenant in this store.
    root-gpo.JPG
  6. Now, navigate to the Configuration > Policies > Centrify Settings
  7. Right-click Centrify Settings and select Add Remove Templates, then press Add
  8. Select centrify_windows_settings, press Open, then Press OK.
  9. Expand Centrify Settings > Windows Settings , you should have 2 sections:  Common and MFA Settings
  10. Expand MFA Settings and on the right side, double-click "Specify credential providers to exclude from the logon screen" and enable the policy.  In the box, add this string:  {003D4E42-9B59-4818-9352-17B3F5D4ACAF}, to the beginning of the list (note the comma separator at the end).  This will exclude the credential provider installed with AWS WorkSpaces.
    gpo-ex-cred.png
    Note: this step alters the connectivity behavior of the AWS WorkSpaces under that OU.  This means that the Windows Credential provider will be displayed after connecting to the WorkSpace.
  11. Leave GP Editor open, we'll return to it to make some tweaks.

8. Launch an Amazon WorkSpace and Download/Install the AWS WorkSpaces client

  1. Go to your AWS Console > WorkSpaces > WorkSpaces > Launch WorkSpaces
  2. Select a Directory:  pick the directory you are working with and press Next Step.
  3. Identity Users > select search for users (e.g. Lisa or Diana), check the box and Press Next Step
    lisa.JPG
  4. Select your bundle > pick your product (e.g. Windows 10 Standard)
  5. WorkSpaces configuration > pick the options as needed, press Next Step
  6. Review and launch > review and press Launch.  You may have to wait up to 20 minutes at this step.
  7. In the meantime, you can download and install the WorkSpaces client.  You can obtain them from here:  https://clients.amazonworkspaces.com/
  8. Follow the instructions to install the WorkSpaces client in your platform.
  9. When the WorkSpace is available, note the registration information and register with the AWS WorkSpaces client, before connecting, continue to the next section.

9. Configure the WorkSpace in the directory and authorize it for MFA

  1. Monitor the WorkSpaces until the system is listed as available.
  2. In your connector Windows system, open ADUC (dsa.msc)
  3. Go to the computers container, you should have a new system aside from the connector (e.g. IP-C0A8F12F)
  4. Move the computer object to the WorkSpaces OU.  (Note, this can be automated)
    This will ensure that the GPO will apply to the WorkSpace.
  5. Now, sign-in to Identity or Privilege Service > Admin Portal > Core Services > Roles > [select your role; e.g. MFA Computers] > Members > Add > Check computers and search for the system name, when you find it check it and press Add, then Save.
    mfa-comp.JPG
    Now the system is authorized to do MFA requests.  The next step is to connect to our WorkSpace, and install the Centrify Agent for Windows.

 

10. Connect to the WorkSpace, Refresh GPOs, Restart and Install  the Centrify Agent for Windows

  1. Connect to your WorkSpace
  2. Since the Credential Provider is disabled, you may have to re-auth after connecting.
  3. Open a command window and type gpupdate /force, then reboot the system. 
  4. After reboot, reconnect to the system and log in as the test user
  5. Browse to the location of the installation bits for the Centrify Agent for Windows and shift+right click > Run as a different user > log in with a domain privileged user
    Welcome page > press Next
    EULA page > check the box and press Next
    Destination Folder > press Next
    Ready to install > press Install
    Completed page > press finish.  This will start the configuration wizard.
    Note:  the configuration steps below can be set via Group Policy.
  6. Press Add Service, at this point, depending on the information in AD, the services are visible
  7. Select 'Centrify Identity Services Platform'  and Press OK
    id-serv.JPG
  8. Select your tenant instance
    selinst.png
  9. Multi-factor authentication on Windows login > Enable > Press Add > select your test users (e.g. diana, lisa), press Next
    mfa-set.JPG
  10. The platform will attempt to enroll the system.  If the IWA Root Certificate for the Centrify tenant was installed succesfully via GPO refresh, this should be fine; if not, an error indicating this will be displayed.  You can, alternatively import the IWA root certificate manually into the trusted root certification authorities for the system.
  11. The installation will prompt to reboot.  Reconnect to start testing.

 

Checking Functionality (Testing)

Here's a quick test matrix:

  • Verify MFA at login
  • Verify MFA at screen unlock
    success.png
  • Verify no MFA challenge if screen unlock is under defined grace period
  • Verify MFA with offline code if connector(s) are not available

 

Adjusting (Improvements)

Here are the potential improvements for this setup:

  • Add additional Centrify Connectors for High-Availability
  • Use WorkSpaces Application Manager to deploy Centrify Agent for Windows (tm) automatically
  • Use Group Policy to define which users are required multifactor
  • Use Group Policy to define if MFA will be required during Windows unlock.

 

Video Playlist

 Other Resources

 

 

Background

 

This technical blog post [with Video] serves as a follow-up to a previous lab "Integrating ServiceNow Approvals to Centrify-enhanced sudo using the dzdo validator."

Read more...

This article is the first of a multipart series. Part I will cover the following:

  • The effect the current threat landscape is having on the business
  • Why access control is not enough
  • The benefit provided by active log monitoring solutions
  • How SIEMs help.
Read more...

We heard from some customers that would like to use AD credentials to authenticate to IBM Sterling Connect:Direct. IBM Sterling Connect:Direct provides security-rich, point-to-point file transfers to lessen dependency on unreliable File Transfer Protocol (FTP) transfers.

 

Continue reading...

Read more...

What will you do if someone checks out the root password and then creates SSH keys so that they can go around your password vault anytime they want?

Read more...

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

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 

Getting Kerberos Tickets For Your Second AD Account On Your Smart Card

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 UNIX, Linux systems running in AWS.

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

 

About Centrify Audit Events

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

 

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

 

Pre-Requisites

For this lab, you'll need:

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

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

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

 

Implementation Overview

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

 

Set-up your AWS Linux Instances for CloudWatch Logs

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

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

 

Verify Centrify Audit Trail events in the CloudWatch log group

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

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

 

Identify Access and Privilege-related Metrics provided by Centrify

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

 

Example 

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

 

Access Control

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

pamev.png

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

 

Privilege Elevation

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

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

 

Create the Filters and Assign a Metric

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

Create a Dashboard

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

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

 

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

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

 

Below is a simple dashboard that includes the metrics above.

 

dash.png

Create an Alarm

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

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

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

Trigger the alarm

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

Conclusion

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

 

Related Articles

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

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

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

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

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

Background

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

 

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

 

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

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

This way, while the system is running:

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

Pre-flight Checklist

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

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

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

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

statepoint5.png

 

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

 

Supported Platforms

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

Configuration Overview

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

 

Copy your Kerberos keytab to your S3 bucket

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

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

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

Now you have a Policy.
policy-1.PNG

 

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

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

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

Create and configure Chef 12 OpsWorks custom stack

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

 

Create a Stack 

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

Add a Layer

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

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

Adding instances to your stack  

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

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

 

Troubleshooting and Debugging

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

issue.png 

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

 

Known Errors

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

 

Verifying Success - Provisioning

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

The OpsWorks console shows the system online.

lisa.png

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

success2.png

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

reportcdc.png

 

Verifying Success - Deprovisioning

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


gone1.PNG

 

Conclusion

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

 

Related Articles

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

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

Background

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

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

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

 

What you'll need:

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

Create an AD User

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

 

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

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

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

 

Delegate Permissions

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

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

 

Let's illustrate the steps using this OU structure

oustruc.png

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

 

To delegate the computer object in the target OU 

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

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

 

To delegate at the Centrify Zone level

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

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

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

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

 

Optional:  To delegate for Computer Roles 

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

 

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

 

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

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

 

Create the Keytab File

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

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

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

 

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

 

Here's a simple way of constructing an adkeytab command

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

Here's the command

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

Here's a sample output:

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

Verify the keytab is correct.  List the principals

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

 Testing your Keytab for Join/Removal Operations

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

 

Authenticating using the key table file

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

 

Testing adjoin and adleave operations

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

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

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

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

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


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

 

What next?

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

Related Articles

 

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

 

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

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

 

Levels

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

 

Basic AWS Setup

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

  1. Sign Up for AWS

  2. Create an IAM User (optional)

  3. Create a Key Pair

  4. Create a Virtual Private Cloud (VPC)

  5. Create a Security Group

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

 

Planning to modify your Security Rules

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

Create an S3 Bucket

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

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

 

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

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

 

Active Directory in AWS

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

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

 

multi.png

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

 

1. Setting-up Active Directory in AWS

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

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

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

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

 

2. Configuring Microsoft DNS with a  Forwarder

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

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

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

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

 

Using an Amazon-hosted option

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

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

 

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

 

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

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

 

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

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

  3. Select Create DHCP Options Sets.

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

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

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

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

 

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

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

 

Centrify Standard Edition Lab Setup - Member Server

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

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

Add Windows Features

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

 

Install Centrify Standard Edition Tools

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

 Initialize Centrify Standard Edition

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

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

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

 

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

 

Sanity Check # 3

At this point, you should:

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

 

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

Users, Groups and Roles

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

Groups

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

Sample User Creation Script

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

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

script0.png

Create and Configure a Centrify Zone

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

 

Zone Creation and User UNIX-enablement

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

 This script creates the AWS zone and enables our users 

script1.png 
UNIX and Windows Admin Roles + Assignments

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

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

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

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

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

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

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

script2.pngscript3.png

 

 

Install Centrify DirectControl and run adcheck

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

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

 

Modify default AWS EC2 SSH Server Settings

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

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

Join your EC2 Linux instance to Active Directory Manually

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

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


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

 

Verify your UNIX Access and Privilege model

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

     Now you can logout Lisa.

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

Join your EC2 Windows member to the Centrify Zone

Grant your test users remote desktop access

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

Install the Centrify Agent for Windows

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

Verify your Windows Access and Privilege model

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

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

 

 

Sanity Check # 4 

At this point you should have

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

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

 

statepoint5.png

 

Privilege Service Lab Setup - Centrify Tenant and Connector 

Obtain a Privilege Service Tenant

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

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

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

 

Sanity Check # 5
At this point, you should:

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

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

 state-with-bucket.png

 

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

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

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

How Centrify Extends Audit Trail Events

By Centrify on ‎03-28-2017 09:52 PM

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

 

 

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

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

Using Centrify Server Suite to prevent the use of SSH keys

Read more...

This week we've made available our new version of Centrify Server Suite 2017 and like any new release it's packed with new capabilities, features and bug fixes.  This post will allow you to explore what's new in this release and what are the some key planning considerations for successful deployment.

 

What's new on Server Suite 2017

Kerberosfast.png

  • Kerberos Library Upgrade: In this release, Kerberos libraries have been upgraded to MIT  5-1.14.1.
  • Flexible Authentication Secure Tunneling (FAST):  Also known as Kerberos armoring, secures pre-authentication traffic and protects KDCs from error spoofing.
  • This upgrade allows support for Smart Cards using AES-256 encryption.  Centrify has tested with Oberthur ID One 128 v5.5 Dual SHA256 and G&D FIPS 201 SCE 3.2 SHA256 Cards.

Flexible open-source packaging

  • cdc-dep.pngCentrify DirectControl has leveraged OSS packages (OpenLDAP, cURL and OpenSSL); in versions prior to 2017 updating these packages required a re-spin of the whole suite (in all supported platforms)
  • Starting with CSS 2017 (DirectControl 5.4) the packages for cURL, OpenSSL and OpenLDAP are independent and can be separately updated, this will allow for faster response to any CVEs that apply to those components.

Security

  • Implemented transaction control for LRPC2, this provides security improvements over heavy load.  Requires that both DirectControl and DirectAudit are upgraded.
  • MFA: Since Centrify Identity Service version 16.10 the IWA negotiations happen over SSL. This means that either Enterprise CA, Public CA or IWA root certificate trust must be established for Centrify Multi-factor Authentication to be successful.

Centrify Report Services

  • New Operation Mode (zone mode):  The first release of report services works in "domain mode" this means that the "Replicating Directory Changes" delegation was required.  Now in this mode, only delegations at the zones container is needed, keeping the scope of the information sent to report services only to Centrify data.
    reports - modes.png
  • Report options:  include the ability not to generate charts as well as reports for local users.
    lisa-attestation.png

Centrify-enhanced OpenSSH

  • SSHv1 is no longer supported.
  • AIX:  The LAM version of Centrify-enhanced OpenSSH is no longer shipped.  This is because supported versions of AIX ship with PAM enabled.

Introducing Centrify Licensing Service

  • Customers are asking to provide more efficient and proactive licence capacity and usage and many are asking for elastic licensing to support public cloud workloads.
  • Centrify Licensing Service (v1) targets perpetual licensing and provides mechanisms for streamlined capacity, inventory and notification.
    cls - main.png
  • CLS requires a highly-available Windows server that runs the licensing service (this does not have to be a dedicated server)

LDAP Proxy performance enhancements

  • The LDAP Proxy now implements new caching mechanisms (at the server auth and client) that can result in performance increases.

Centrify Agent for Windows

  • MFA:  Supported at login (console, RDP, screensaver unlock) in two modes:  zone mode and zoneless mode.  Zoneless mode requires a Centrify Identity Service device license.
    zoneless.png
  • Support for both MFA at login and with privilege elevation (desktop, applications) is exclusive to zone mode (requires Standard Edition license)
    mfa -zoned.png
  • Just like UNIX/Linux MFA, requires IWA over SSL, this means that Enterprise, Public or IWA root cert trust must be planned and implemented.
  • Application Manager:  This application can be assigned to a role to allow Add/remove of Windows programs
    app-mgr.png
  • Feature Manager:  This application can be assigned to a role to allow for Windows feature management
    feature-mgr.png

DirectAudit Enhancements

  • Compiled with libaudit support (system call monitoring at the Kernel level) on RHEL and derivatives (more platforms coming in the next releases)
  • DirectAudit is now able to monitor file changes on /etc/, /var/centrifydc and /var/centrifyda
    filemon-rep.PNG
  • DirectAudit is now able to audit commands run inside scripts
  • DirectAudit is now able to monitor for specific command executions.

 

Platform Support

Platforms Added

  • Amazon Linux AMI
  • CentOS 6.8 (x86, x86_64)
  • CentOS 7.3 (x86_64)
  • Debian Linux 7.1, 8.5-8.7 (x86, x86_64)
  • Fedora 24, 25 (x86, x86_64)
  • Mac 10.12 (x86_64)
  • Oracle Linux 6.8 (x86, x86_64)
  • Oracle Linux 7.3 (x86_64)
  • Red Hat Enterprise Linux 6.8 (x86, x86_64)
  • Red Hat Enterprise Linux 7.1, 7.2, 7.3 (ppc64le)
  • Red Hat Enterprise Linux 7.2 (zLinux) on Standard Edition
  • Red Hat Enterprise Linux 7.3 (x86_64)
  • Red Hat Enterprise Linux 7.3 (ppc64)
  • SUSE 12 (ppc64le)
  • Ubuntu 16.10 (x86, x86_64)

 Platforms Removed

  • Fedora 21
  • Mac 10.9
  • OpenSUSE 13.1
  • SUSE Linux Enterprise 10.x
  • Ubuntu 15.04, 15.10

Component Version Upgrades

  • Centrify-enhanced OpenSSH is now based on OpenSSH 7.3p1
  • Centrify-enhanced sudo (dzdo) is now based on sudo 1.8.17p1
  • Centrify-curl is based on libcurl version  7.51.0
  • Centrify-openssl is upgraded to version  1.0.2j
  • Centrify PuTTY is upgraded to version  0.67

 

Planning tips for Server Suite 2017

  1. As recommended, read the release notes and upgrade guide.
  2. Even if you don't plan to update your clients right away, you can upgrade your consoles and group policy templates. 
  3. This is a major release and all components must be upgraded: DirectControl, DirectAudit (agents/collectors/database), this is because:
    • Kerberos upgrade
    • New LRPC2 transaction protocol
    • New Open-source packaging
    • OpenSSL upgrade
  4. Plan for Centrify Licensing Service - have the service installed on one or two highly-available windows servers.  Have your technical and procurement leads in the notification lists and designate a thresold to get proactively sent deployment reports.
  5. Due to the new DirectControl packaging, plan to update your DevOps recipes/cookbooks (Chef, Puppet, Ansible, etc)
    Tip:  adjoin has a new option “-F/--forceDeleteObj” to clean up the existing computer object and extension object in Active Directory before performing the adjoin operation.
  6. If you're using Centrify-enhanced OpenSSH on AIX platforms, plan phase out unsupported versions or to migrate and test existing PAM support; this is because we no longer ship a LAM version.
  7. SmartCard: RC4 and DES are no longer supported;  this means you have to plan to upgrade to AES-128 or AES-256 to ensure compatibility.
  8. Leverage the Centrify Repo for quick updates on RPM, APT or Zypper-compatible distributions.
  9. The new capabilities of DirectAudit (config file monitoring, monitored execution, etc) are not turned on by default.  You have to turn on the event.execution.monitor and event.monitor.commands parameters in the /etc/centrifyda/centrifyda.conf file.  Make sure you do a baseline analysis first.
  10. Hybrid-cloud support:  remember that you can use Server Suite in your AWS, Azure or GCP deployments and that Centrify provides unique support for complex AD scenarior like one-way trusts, RODC and now Kerberos Armoring.

 

Conclusion - It's all about value

  • With each release of Server Suite, Centrify adds more new capabilities that ensure alighment with security practices and regulations and operational efficiency.
  • You have to learn to spot issues with your current deployment like:
    • Challenging management due to a large number of zones:   this may mean that your implementation is following outdated practices.  Back in 2010 Centrify introduced Hierarchical zones, this allows for better administration, privilege management and a reduced number of zones.
    • Not leveraging privilege management:  Authentication was the problem 10 years ago. Now you're faced with multi-platform attestation, conformance with MFA requirements, etc.  These are all parts of the product that you own.
    • Not getting the proper "insight":  Centrify Report Services and the integrations with Splunk, ARCSight and QRadar are the best ways to understand what's happenning in your Centrify deployment today.
      Check out this article series to see the insights you should be getting: http://community.centrify.com/t5/TechBlog/Security-Corner-Reviewing-your-Access-and-Privilege-Manag...
      dwirth-unix.png
    • Cognitive gaps:  If you or your team feel that have inherited a Centrify deployment and don't have the proper training, let your reps know and they'll take care of that.
  • For an article discussing what do if you inherited a Centrify infrastructure, go here:  http://community.centrify.com/t5/TechBlog/10-Tips-I-Inherited-a-Centrify-Server-Suite-Deployment-Wha...

Expect some in-depth articles on some of the newest features of this release.

 

Resources

Security Kaizen - Part II:  System, Roles and Groups + Anomalies

Part I | Part II | Part III | Part IV

In the previous article of this series, we discussed the application of continuous improvement process (CIP) to security practices in the context of access control and privilege management.

 

We defined that the  goal is to implement the least access and least privilege principles across the board and that we start by collecting metrics like the number of users with system access, privileges, etc.  The idea is to Identity-Plan-Implement and Review.  For example:  If after reviewing the roles assigned to a user, we realize that this was a one-time request that was implemented permanently, we can eliminate the role assignment and have a process to review (perhaps every 30 days);  an improvement over this could be an automatic email sent to the user to extend the access instead of removing it.

 

We also introduced the concept of dimensions.  In the past article we focused on the user view,  in this article we discuss other dimensions.

 

System View

Total Centrify-managed systems vs Domain-joined systems

To identify Centrify-managed systems, first you need to identify the existing zones in your environment.

Get-CdmZone | Select Name, Domain, DistinguishedName, Schema 

Once you have identified the zones, you can enumerate the number of systems under all active zones.  An improvement point is to ask: "Why are these zones in existence if no systems are currently being managed?"

Another point of concern is if a large number of classic zones are encountered.  Centrify best practices since 2010 favor hierarchical zones over classic zones. 

 

The goal in this measurement is to understand which systems are under Centrify management and aren't.  For example, you can use these commandlets:

Get-CdmManagedComputer -Zone (Get-CdmZone -Name Global) | Measure
Get-ADComputer -Filter *  | Measure

to count the Centrified systems and all AD-joined systems.  This will give you a ratio of the % of systems that are managed by Centrify.  For example, in my test system I have 12 total systems with 5 managed by Centrify.

 

This is important because you need an alternative strategy for assessing who has access and privileges on those systems OR you can ask "Why haven't these systems been set up under Centrify management?"

 

Computers that grant more access and computers subject to more assignments

comp-roles.png

These metrics allow you to identify the systems that have the less stringent access controls; in addition, you can identify the systems that are subject to more role assignments.   Reviewing the data classification of the apps on these systems is advisable since the more access exists, the more possibilities of users saving privileged data.

 

Logins by System

This system view complements the "logins by user" metric discussed in the previous article.  This one has an interesting twist.  Note that I said I have 5 Centrified systems, however, I seem to be only getting data for 2 systems.  This is an indication that perhaps there is a misconfiguration; in my case I only have the Splunk forwarder installed in two of my demo VMs.  Note that in the case of hybrid cloud, because systems are treated as cattle, you may not notice users logging in at all.

logins-by-system.png

 

 

Computers subject to more privileges

comp-most-priv.png

This is the privilege view of systems.  Notice that my Ubuntu system grants more privileges than the rest; if this was a PCI or SOx system, you want to dig deeper to find out why.

 

Privileged Access with most computers in scope

priv-access-most-comp.png

This metric allows you to identify what rights are more prevalent in the computer population.  The more common the right is, the more prevalent it will be; expect login rights (e.g. ssh, sshd or login-all) to be more prevalent.  If you see something like "run as root"  or  "Administrative Desktop" as a prevalent command, this may be part of a sysadmin role.

 

Privilege Activities by Type

Often you may need to look at a system and find out exactly what the privileges activities are most common.  This complements the user view (e.g. most used privileged commands)

priv-act-by-type.png

 

Group and Role views

Before moving into groups and roles, let's add some context.  In Centrify DirectAuthorize, the best practice is to assign roles to AD security groups;  however AD security groups constitute what are called "Computer Roles" - these are nothing more than "Teams of Servers";  these constructs allow a system to belong to different types (e.g. a web server and a database server) which may be subject to roles assigned to different populations (e.g. web admins and DBAs respectively).

 

Roles with Most Access

These are the roles that have the broadest scope in a Centrify deployment.  Note that design principles suggest that Zone-level and computer-level role assignments should be used sparingly.

roles-wmost-access.png

 

AD Groups with Most Members

Depending on the deployment mode of Report Services (domain or zone) you can get information about all or only the zone-relevant groups.  In this case, this graph indicates the membership numbers of groups that grant privileges in a Centrify deployment.

groups-most-members.png

AD Group Attestation - Access

access-group.png

The picture above provides information about an AD group that is used in a Centrify deployment.  Note that it also highlights if the group has any nested groups and includes a detail of the systems it grants access to.

 

AD Groups with Most Privileged Access

 The common practice is to provide both access and privileges within the same group; therefore this report should be very familiar to the access report;  however there are exceptions, especially when using selective auditing.

access-group.png

 

AD Group/Role Attestation

This report shows the relationship between the AD group, the systems in scope and the rights defined in the system.

rights-report-group.png

This is a great report to generate if you need to answer these questions:

  • What privileges does the "Apache Web Admin" group provides?
  • What role(s) are associated with it?
  • What is the scope of the role assignment?
  • What is the definition of the role (commands) that it provides?

 

Anomalies

Ideally anomalies are subject to security operation actions, however, as part of your overview of the access model, it's not uncommon to collect metrics of the kinds below, some of them are self-explanatory;  the others we'll provide some color.

 

Failed Logins by reason

failed-logins-reason.png

Users with Multiple Login Failures

users-mult-login-fail.png

Failed Logins over Time

failed-logins-overtime.png

Any spike on failed logins could indicate attemps at lateral movement, or a service account with an outdated password.

 

 Denied Privileged Activities over Time

denied-overtime.png

A spike on these could indicate a compromised account with attempts to perform privilege elevation.  MFA can help mitigate this risk.

 

Centrify Software Operations

Because a system that is not under management is easier to compromise, there are several operational activities that we should track:

Leave Activities

leave-activities.png

When a system is not in AD, you lose access control and the Centrify audit trail log.

 

DirectAudit Agent Service Stoppages

audit-stop.png

Privileged users can stop the session-capture client (DirectAudit), not without audit trail recording it.  Since most systems subject to this capability most likely are highly-sensitive, all anomalies should be investigated to make sure there's no collusion.

 

Resources

[How to] create and publish a new username/password app for Cloudera Manager.

Read more...

In part 1 of this series, we described how to configure DB2 Express-C on Linux and how to configure the Centrify DB2 Plugin.  In this article we will focus on testing the installation and an example of how to troubleshoot if things aren't working as expected.

 

Read more...

Validating Centrify Zone Delegations

By Centrify Contributor II on ‎01-06-2017 07:06 AM

One of the major strengths of Centrify Server Suite, is that all UNIX identity and authorization data is stored as Active Directory objects in Centrify Zones. As a consequence, delegation tasks of zone management, are stored in Discretionary Access Control Lists (DACLs) on Centrify Zone objects in Active Directory.

 

The Zone delegations can be implemented using PowerShell (for example, using the Set-CdmDelegation PowerShell CMDlet, which is included with the Centrify.DirectControl.PowerShell module), or by using the 'Delegate Zone Control' context menu option in the Centrify DirectManage Access Manager console. Either method will provide you with the ability to chose from a list of a granular zone delegation tasks, that can be delegated to an Active Directory user or security group.

 

 

List of zone delegations in Access ManagerList of zone delegations in Access Manager

Applying zone delegations using the Centrify PowerShell CMDletApplying zone delegations using the Centrify PowerShell CMDlet 

As part of an engagement, Centrify Professional Services can aid you to conceive a delegation model using a RACI matrix, and implement the resultant zone delegations. This allows for implementing least privilege, where (for example) the service account for the zone provisioning agent can only add/remove UNIX profiles to/from a zone, but nothing more than that. If the ZPA service account gets compromised, it cannot be (ab)used to modify UNIX authorizations.

 

A returning question from customers during these engagements is: How can we validate that the delegations that have been implemented, are actually in place?

 

 

 

This article details the methods available to implement zone delegations, and how zone delegations can be validated.

Read more...

Customer are seeing great value from Centrify's Server Suite DirectAudit's session capture and replay capabilities.  We hear the benefits from customers all the time.  Examples of how DirectAudit allowed them to quickly uncover what malicious users did or mistakes honest users made that caused systems and applications to go down.  Like in the human world, having a security camera at the system level, with the ability to search and replay is the best way to determine what is happening or has occurred.  

 

The Problem:

 

Customers who implement DirectAudit should implement a rentention policy and purge audited sessions after a period of time.  Doing so allows the Audit Store(s) to remain small which delivers better performance.  Their are multiple ways to implement a data retention policy for DirectAudit, including rotating databases every so often as described on page 9 of the Database Management guide.  Another option not as well know, and the focus of this article, is that data can be purged after a certain amount of time.  For example, delete sessions older than 90 days.  

 

The Solution:

 

Centrify provides a tool called PurgeSessions documented in Knowledge Base article KB-3394.  PurgeSessions can be scheduled to run using the Windows scheduler every 2 weeks to delete sessions older than the retention policy.  

Read more...

Customers with NetApp ONTAP filers are looking to provide consistent level of access across multi-protocol CIFS and NFS shares.  To do this, the filers need to obtain Active Directory users and the UNIX identity of those users to provide the unified level of access required.  Customers with Centrify deployed can very easily accomplish this.  The following guide will show you how to integrate NetApp onTap filers with Centrify.  

Read more...

If you're an existing Centrify customer, you may have seen recent news about the capability to support Multifactor Authentication at Windows Login. This article explains how to set this feature up in your Centrify Server Suite and Centrify Identity Service environment. 

Read more...

Find out how to recover administrator access to an existing DirectAudit Installation by granting an AD User administrator privileges at the Database level. 

Read more...

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

 

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

 

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

 

plaform.png

 

Leverage your Identity and Access Management to secure your AWS IaaS

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

aws.png 

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

Here are a few Tech Blogs that cover this topic:

 gears.png

 

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

 

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

 

AWS and the Identity Challenge

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

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

 

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

 

Exciting New Alternatives to Secure Extend your Enterprise Identity to AWS

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

 

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

methods.PNG

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

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

 

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

 

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

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

 

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

 

Here's a quick demo

 

 

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

 

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

 

 agent.png

 

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

In the course of helping customers migrate to Centrify Adbindproxy, Support has identified some instances where the scale of Samba environments impact the effectiveness of the new adbindproxy component.  This blog will summarize a recent issue and workaround which may help other customers facing a similar situation.

 

Centrify supports another way of implementing stock Samba4 with Centrify that does not use adbindd, but uses NSS instead.  Access control is then based on NSS users and groups with winbind instead of using adbindd (Active Directory).


Background:

In one customer's environment, they were using Samba to share directories to a large number of end users whom were moving and accessing lots of large media files to and from those shares.

Read more...

The Centrify Community has some great resources when it comes to IBM DB2 integration with Active Directory using Centrify. But, have you ever wanted to quickly set up DB2 in a test environment to play with these integrations? By following this article, you can!

Read more...

Showing results for 
Search instead for 
Do you mean 
Labels
Leaderboard

Community Control Panel