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

Announcing a new series!!!

 

I recently got some YubiKeys from HQ (thanks @Peter) and since they provide all-in-one smart card (PIV) and OTP (OATH) capabilities plus they work great with Centrify products. 

 

Here are the series links:

Part 1: Securing Windows Server Access and Privilege Escalation with Centrify, Active Directory and ...

Part 2: Securing local and remote access to UNIX/Linux with Centrify, Active Directory and YubiKey

Part 3: Using SmartCard (or YubiKey) to secure Apps, Shared Secrets an Sessions with CIS and CPS

 

 

About the Series

This new series showcases our  MFA Everywhere initiative and we'll be posting a series of HOWTO labs to cover several scenarios:

css-yubi-scenario.png

Strong Authentication (PKI) Smart Card / Yubikey

  • Leverage what you have:  Active Directory, Microsoft CA, Group Policies
  • Enforcing Smart Card access to UNIX/Linux/Mac systems  (Windows systems support this natively)
  • Use DirectAuthorize roles to limit access to strongly authenticated sessions

Strong Authentication for Windows Privilege Elevation

  • Applications
  • Desktops

We already covered Access and Privilege Elevation For UNIX/Linux using Centrify MFA here:  http://community.centrify.com/t5/Community-Tech-Blog/LABS-Setting-up-the-MFA-for-Servers-feature-of-...

 

css-yubi-scenario2.png

Strong Authentication (Smartcard/Yubikey) & OATH OTP access

  • IdP Portal Access
  • OnPrem or SaaS Application Access
  • Privilege Portal Access
  • Privilege Password Manager  (Shared Account Password Manager)
  • Privilege Session Manager (Jump Box)

 Here's a quick overview/demo

 

Lab - Base Setup

The base setup is the pre-requisite for all the Yubikey/SmartCard related labs.

 

What you'll need

  • Active Directory with Certificate Services
  • A domain joined member server with Centrify Server Suite 2016
    • .NET 3.x features enabled
    • Feature RSAT:  Active Directory, Group Policy Management and Certificate Services tools
  • One or two UNIX/Linux systems with Centrify Standard Edition 2016  (5.3+)  (if testing UNIX/Linux)
  • Access to Centrify Standard Edition installation files (evaluation or licensed)
  • Yubikey PIV Manager  (download link)
  • Yubikey 4, NANO or NEO
  • You need working knowledge of Active Directory and Centrify Zones

 Tip:  To set up a base configuration, you can build on the Microsoft Test Lab Guide.

 

Create Test Users and AD Group

On the member server

  1. Open Active Directory Users and Computers and navigate to your desired OU
  2. Right click and select New > User  and follow the wizard until the user is created.
  3. Right click the newly-created user and select properties.  In the general tab, update the Email to match the user principal name.
    e.g. user@corp.contoso.com and press OK.
  4. Right click the OU and select New > Group and make it a Global/Security group.  Call it "Smart Card Users"
  5. Right click the Group, select properties, go to the Members tab, press Add and add the user created in step 2.
  6. On the member server, grant the group or user the ability to log on remotely. 
    Computer > Properties > Remote Settings > Remote Desktop > Select Users  > Add > [select user or group] press OK twice.

Certificate Services

Modify the Smart Card User template

  1. Open the Certification Authority console  (Start > Search > Certification Authority)
    If you get an error, retarget the console to the appropriate server (e.g. DC1)
  2. On the left pane, right click "Certificate Templates" and select Manage.  This will open the Certificate Templates console.
  3. In the template list, right-click the SmartCard User template and select "Duplicate Template"
  4. In the General tab, give the template a descriptive name.  I used "Smart card User V2"  (this is the display name, the actual template name is SmartcardUserV2)
  5. Click on the Security tab, press Add, select the newly-created Smart Card Users group, check the Enroll and Autoenroll boxes, then press OK and close the Certificate Templates console.

Publish the Newly-Created Template

  1. In the Certification Authorities console, on the left pane, right click "Certificate Templates" and select New > Certificate Template to Issue
  2. Select the newly-created version of the Smart Card User template  (e.g. Smart Card User v2) and press OK.

Provision the Smart Card User Certificate into your Yubikey

  1. Log on to your member system with the test user.
  2. Open the Yubikey PIV manager tool with the Test User  (shift+right click > run as different user)
  3. If you're using a VM, connect the Yubikey to your virtual machine.
    Note:  If you're using VMWare, you need to add the parameter below for the Yubikey to be available to your VM.
    usb.generic.allowHID = "TRUE"
    This step is performed by editing the .vmx file and editing it with your current text editor while the VM is off.
  4. Initialize the Yubikey if brand new.  Do not forget the PIN.
    yubikey-win-init.png
  5. In Yubikey PIV manager, press Certificates > Generate New Key and make sure you type the Certificate Template name (not the display name) and press OK.
  6. Type the PIN when challenged, and select your existing CA.  In my case I use the non HTTP link and press OK
    yubikey-enroll-cert.pngyubikey-enroll-cert2.png
    yubikey-enroll-cert3.png
  7. To test the smart card authentication, either lock your screen or logoff.  If you can unlock or login successfully, you should be ready for the next steps.
    yubikey-cert-test.png

 

Lab Verification Video

This article describes the steps to install, configure and test the local UNIX user and group management feature included with Centrify Suite 2016.  You will find this article useful if you're looking to accomplish the following goals:

  • Control local UNIX user accounts (provision, disable, visibility or removal from /etc/passwd)
  • Control local UNIX primary or secondary groups (provision, control membership, or removal from /etc/group)
  • Use a single management framework (DirectManage GUI, PowerShell, UNIX adedit)
  • Leverage Centrify Zones, Child Zones or Computer Roles stored in Active Directory
  • Perform actions upon user creation/deletion, e.g. home directories, environment variables, password management/lifecycle.

Disclaimer:  This post is not a best practice, it's simply to aid you to study and test the feature before your consider it for production scenarios.

Read more...

In the original article about orchestration basics, we set up a basic implementation of YellowDog Updater Modified (YUM) for RHEL and derivatives (CentOS, Scientific, Oracle Linux, etc) in different architectures

(Intel, Power, zLinux).

 

In this second article of the series we discuss how we can use a simple (non-idempotent) Chef recipe to deploy, and join a node to Active Directory with Centrify DirectControl.

Read more...

Showing results for 
Search instead for 
Do you mean 
Labels
Leaderboard

Community Control Panel