Using Centrify-enhanced sudo (dzdo) validator with ServiceNow requests

Background
Regulatory frameworks have evolved to require documented evidence of approval for development or infrastructure-related change control.  These activities usually require the exercise of elevated privileges.  Some examples of these requirements and guidelines can be found on PCI DSS, SANS Critical Security controls, ISO 27001 and others:
 

Centrify DirectAuthorize and DirectAudit provide end-to-end, role-based access controls for UNIX, Linux and Windows, in addition it provides mechanisms for validation and tracking of changes via ticketing or request systems.

Requirements
We've had customers that have two categories of requirements:

• Tracking activities related to a particular change control or approved request
  For example: We want to track all privileged activities related to a change control in my security operations dashboard.
  We covered this on this on the original dzdo validator article.  When privileges are elevated, entries in both syslog or DirectAuthorize get created automatically.
  Using Centrify-enhanced sudo:
  

  $ dzdo tail /var/log/messages
  Enter the change control ticket number:1255
  

  syslog:
  

  Nov  7 15:04:39 engcen6 dzcheck.sample[35173]: User "dwirth@centrify.vms" will run "/usr/bin/tail /var/log/messages" as "root" with ticket number "1255"
  

  DA Console:
  
• Implementing controls to prevent unauthorized changes
  For example:  We want to make sure that any privilege elevation is only allowed with an approved request.
  This lab covers a basic lab setup to implement this requirement.

Lab Diagram


What you'll need:

• Centrify Standard Edition and a Centrify Zone with some UNIX roles defined
• An AD-joined UNIX or Linux  system in the Centrify zone
  The system should be able to reach the ServiceNow instance directly, via proxy or via ServiceNow MIDServer.
• A DirectAuthorize role for UNIX
• A ServiceNow instance (Fuji release minimum) and a shared credential or token to query existing requests
  Make sure that the credential only has the minimal rights (e.g. read-only) for your requests.
• Optional:  Centrify Privilege Service (Saas or On-Prem) to vault the SN user's credential. 

Use Case

1. Privileged user obtains a change control manager approval via ServiceNow workflow request.
   The request has a change control window.  (date/time range)
2. During the request validity timeframe, the privileged user needs to perform activities (using Centrify-ehnanced sudo) and when the commands are issued, the SN request number has to be provided.
3. The dzdo.validator script uses the ServiceNow Perl API to validate if the request is approved or not.
   Additional validations can be added like user, time-range, etc;  these won't be covered for blog brevity.
4. If the request is a approved, the Centrify-enhanced sudo command is allowed to execute.  If not, the user is notified.

Implementation  Overview

1. Install the ServiceNow Perl API
2. Test ServiceNow Instance connectivity
3. Optional:  Protect the shared credential using Privilege Service
4. Modify one of the sample scripts to work with ServiceNow Requests
5. Modify the dzdo.validator script to call the ServiceNow Perl API script
6. Implement the dzdo.validator via parameter or GPO
7. Test your results

Install the ServiceNow Perl API
The full instructions and requirements are here: 
http://wiki.servicenow.com/index.php?title=Perl_API#gsc.tab=0

1. Make sure you have the appropriate Perl plugins  (e.g. CentOS 6.x):
   SOAP::Lite  (e.g. yum install perl-SOAP-Lite)
   Crypt::SSLeay (e.g. yum install perl-Crypt-SSLeay)
   IO::Socket::SSL ( e.g. yum install perl-IO-Socket-SSL)
   File::Basename
   MIME::Types (e.g. yum install perl-MIME-Types)
   MIME::Type
   MIME::Base64
2. Download the Servicenow Perl API  (link to 1.01 version) to your UNIX/Linux system
3. Unzip the file in a new folder and run the following commands:
   

   ## create a new folder, download and unzip
   $ mkdir SN
   $ cd SN
   $ wget http://wiki.servicenow.com/images/e/e5/ServiceNow-Perl-API.zip
   $ unzip ServiceNoW-Perl-API.zip
   ## compile the files  
   $ perl Makefile.PL
   $ make
   $ make test
   $ make install

   Follow the prompts, once you have all the ServiceNow Perl API libraries installed to use with your scripts.

Testing Connectivity with your ServiceNow Instance (Sample Script)

1. Create a new file with these contents
   

   # This script retrieves all the requests from your servicenow instance
   # it is used to test connectivity.
   #!/usr/bin/perl -w
   
   use ServiceNow;
   use ServiceNow::Configuration;
   
   # This example uses Centrify Privilege Service's AAPM capability
   # by checking-out the password from the vault at runtime, we eliminate
   # the need to use a cleartext password in this script.
   # uses cgetaccount to check out the password for your-SN-user for 3 mins.
   # Alternatively you can enable OAuth and use Tokens (recommended)
   
   $SN_PASSWD = `cgetaccount -s -t 3 your-SN-user`;
   
   my $CONFIG = ServiceNow::Configuration->new();
   
   $CONFIG->setSoapEndPoint("https://your-instance.service-now.com/");
   $CONFIG->setUserName("your-SN-user");
   $CONFIG->setUserPassword($SN_PASSWD);
   
   my $SN = ServiceNow->new($CONFIG);
   
   my @requests = $SN->queryRequestedItem();
   my $count = scalar(@requests);
   print "Number of requests=" . $count . "\n";
   foreach my $request (@requests) {
       print "Request number: $request->{'number'}\n";
       print "Requested by: $request->{'sys_created_by'}\n";
       print "Date Created: $request->{'sys_created_on'}\n";
       print "Approval Status: $request->{'approval'}\n";
       print "\n"
   

 2. To test the script, add the execution flag and run it

$ chmod +x checksn.sh
$ ./inc2.sh
Number of requests=34
Request number: RITM0000002
Requested by: fred.luddy
Date Created: 2016-05-02 18:15:39
Approval Status: requested

Request number: RITM0000004
Requested by: fred.luddy
Date Created: 2016-09-03 17:15:39
Approval Status: requested

Request number: RITM0000005
Requested by: fred.luddy
Date Created: 2016-05-22 19:15:43
Approval Status: requested
[output truncated]

Modify the Sample Script to work with Individual Ticket Numbers
To do this, you need to change the script to require arguments and check for usage.   The modified lines would look like this:

#!/usr/bin/perl -w

# You're checking for arguments here.  If there are no arguments
# show the usage and exit.  E.g.  checksn RTM00005

if (@ARGV)  {

# The previous program can go here.  Make sure you modify this line
# to look like this:

my @requests = $SN->queryRequestedItem({'number'=> $1})


}  else {
          print "USAGE:  checksn [ServiceNow Request ID]\n"
}
   

Note that there's no error logic for requests that are not found.  We're going to have to add this later.

Modify the dzdo.validator script to to use the ServiceNow Perl API script
 Centrify provides a sample dzdo validator script called dzcheck.sample.  This script exists under /usr/share/centrifydc/bin.
With the author's limited scripting knowledge we were able to modify it to work this way:

• Initialize the proper libraries and variables
• Retrieve the password for the ServiceNow user (your-user) and store it in SN_PASSWD
• Connect to ServiceNow instance
• Prompt the user for a Change Control number
• If the number is not found, log to syslog and the user will not be allowed to run the command
• If the number is found but the status is not approved, log to syslog and the user will not be allowed to run the command
• If the number is found and approved, log to syslog and allow the end user to run the command.

Note that additional error logic and checks can be added.

#!/bin/sh /usr/share/centrifydc/perl/run
# A modified demo for Centrify-enhanced sudo (dzdo) validator 
# Modified to work with ServiceNow Requests

use strict;

use lib "../perl";
use lib '/usr/share/centrifydc/perl';
use CentrifyDC::Logger;

use ServiceNow;
use ServiceNow::Configuration;
# Use privilege service to retrieve SN shared account password
# Alternatively, you can modify the script to use an OAuth token 
my $SN_PASSWD = `cgetaccount -s -t 3 your-user`;

my $dzdo_user=$ENV{DZDO_USER};
my $dzdo_command=$ENV{DZDO_COMMAND};
my $dzdo_runasuser=$ENV{DZDO_RUNASUSER};

my $CONFIG = ServiceNow::Configuration->new();

$CONFIG->setSoapEndPoint("https://your-instance.service-now.com/");
$CONFIG->setUserName("your-user");
$CONFIG->setUserPassword($SN_PASSWD);

my $SN = ServiceNow->new($CONFIG);
my $logger = CentrifyDC::Logger->new('dzcheck');

printf STDERR "Enter the change control ticket number: ";
my $user_input=<>;

my @requests = $SN->queryRequestedItem({'number' => $user_input});

# Check if request(s) exist, if not, exit (1)
if (scalar(@requests)==0)
{
  system "adsendaudittrailevent", "-t", "tkt_id", "-i", "$user_input";
  $logger->log('INFO', "Change control ticket number: %s", $user_input);
  $logger->log('INFO', "User \"%s\" will not be allowed to run \"%s\" as \"%s\" with ticket number (REASON:not found) \"%s\"", $dzdo_user, $dzdo_command, $dzdo_runasuser, $user_input);

  exit 1;
}

foreach my $request (@requests) {

my $req_status =  $request->{'approval'};

# Exit if request is not in approved status
if ($req_status ne "approved")
    {
     system "adsendaudittrailevent", "-t", "tkt_id", "-i", "$user_input";
     $logger->log('INFO', "Change control ticket number: %s", $user_input);
     $logger->log('INFO', "User \"%s\" will not be allowed to run \"%s\" as \"%s\" with ticket number (REASON:not approved) \"%s\"", $dzdo_user, $dzdo_command, $dzdo_runasuser, $user_input,$req_status);
  exit 2;
     }
}

# Run command and log if request is approved
system "adsendaudittrailevent", "-t", "tkt_id", "-i", "$user_input";
my $logger = CentrifyDC::Logger->new('dzcheck');

$logger->log('INFO', "Change control ticket number: %s", $user_input);
$logger->log('INFO', "User \"%s\" will run \"%s\" as \"%s\" with ticket number \"%s\"", $dzdo_user, $dzdo_command, $dzdo_runasuser, $user_input);

exit 0;

I've saved this script as dzcheck.snow in the same location.

Configure Centrify-enhanced sudo (dzdo) to use the ServiceNow Requests validator

1. Open the /etc/centrifydc/centrifydc.conf file for editing
2. Uncomment the dzdo.validator and set it to our scripts
   

   dzdo.validator: /usr/share/centrifydc/sbin/dzcheck.snow

3.  Perform and adreload (or restart the agent)

Testing
We'll use a modified version of the sample script to check the requests for validity first, then we'll try to flush the cache using dzdo.

1. Ticket does not exist  (ABC123)
   

   Request verification
   $ ./sncheck ABC123
   Request not found.

   $ dzdo adflush
   Enter the change control ticket number: ABC123
   Sorry, user dwirth is not allowed to execute '/usr/sbin/adflush' as root on engcen6.centrify.vms.
   
   # syslog contents
   Sep 20 18:00:52 engcen6 dzcheck.snow[35963]: Change control ticket number: ABC123
   Sep 20 18:00:52 engcen6 dzcheck.snow[35963]: User "dwirth@centrify.vms" will not be allowed to run "/usr/sbin/adflush" as "root" with ticket number (REASON:not found) "ABC123#012"
   Sep 20 18:00:52 engcen6 adclient[1526]: INFO  AUDIT_TRAIL|Centrify Suite|dzdo|1.0|1|dzdo denied|5|user=dwirth(type:ad,dwirth@CENTRIFY.VMS) pid=35961 utc=1474412452436 centrifyEventID=30001 status=DENIED service=dzdo command=/usr/sbin/adflush runas=root reason=Dzdo Validator checks failed. Do not permit to continue the privileged command.

2. Ticket is not approved (RITM0010022)
   

   Request verification:
   $ ./sncheck RITM0010022
   number of requests=1
   Request number: RITM0010022
   Requested by: robertson.pimentel@centrify.com
   Date Created: 2016-09-16 16:55:06
   Approval Status: requested

   
   

   $ dzdo adflush
   Enter the change control ticket number: RITM0010022
   Sorry, user dwirth is not allowed to execute '/usr/sbin/adflush' as root on engcen6.centrify.vms.
   
   # syslog content
   Sep 20 18:03:04 engcen6 dzcheck.snow[36011]: Change control ticket number: RITM0010022
   Sep 20 18:03:04 engcen6 dzcheck.snow[36011]: User "dwirth@centrify.vms" will not be allowed to run "/usr/sbin/adflush" as "root" with ticket number (REASON:not approved) "RITM0010022#012"
   Sep 20 18:03:04 engcen6 adclient[1526]: INFO  AUDIT_TRAIL|Centrify Suite|dzdo|1.0|1|dzdo denied|5|user=dwirth(type:ad,dwirth@CENTRIFY.VMS) pid=36009 utc=1474412584884 centrifyEventID=30001 status=DENIED service=dzdo command=/usr/sbin/adflush runas=root reason=Dzdo Validator checks failed. Do not permit to continue the privileged command

3. Ticket is approved (RITM001003)
   

   $ ./sncheck RITM0010003
   number of requests=1
   Request number: RITM0010003
   Requested by: diego.jimenez@centrify.com
   Date Created: 2016-09-11 14:57:57
   Approval Status: approved

   
   

   $ dzdo adflush
   Enter the change control ticket number: RITM0010003
   Demo Password:
   DNS cache flushed successfully.
   Authorization cache store flushed successfully.
   GC and DC caches expired successfully.
   The auditing service's name cache has been successfully flushed.
   The DirectAudit installation information cache has been successfully flushed.
   
   # syslog content
   Sep 20 18:06:22 engcen6 dzcheck.snow[36108]: Change control ticket number: RITM0010003
   Sep 20 18:06:22 engcen6 dzcheck.snow[36108]: User "dwirth@centrify.vms" will run "/usr/sbin/adflush" as "root" with ticket number "RITM0010003#012"
   Sep 20 18:06:22 engcen6 adclient[1526]: INFO  AUDIT_TRAIL|Centrify Suite|dzdo|1.0|0|dzdo granted|5|user=dwirth(type:ad,dwirth@CENTRIFY.VMS) pid=36106 utc=1474412782119 centrifyEventID=30000 status=GRANTED service=dzdo command=/usr/sbin/adflush runas=root role=UNIX Sysadmin/Global env=(none)

Benefits if you're using DirectAudit
If you have Enterprise Edition, DirectAudit's events will contain information about the Change Control and you can now search for all activity related to an individual change control number.


Benefits if you're using the Centrify Splunk App
The Splunk App will display reports on the reasons why the privilege elevation failed.  You can also add alerts based on this to identify any privileged user trying to fish.


Improvements
This is a lab blog post, therefore this is just a simple concept, but here are the improvements I'd make:

• Use OAuth tokens for ServiceNow instead of a shared credential
  http://wiki.servicenow.com/index.php?title=OAuth_Setup#gsc.tab=0
• Compare the date of execution with the change control date range (we only did simple checks)
• Provide better feedback to the user interactively
• Allow the user to create a request if it's not in the system and notify the approver (cli-driven workflow)

Quick Overview Video

 Notes:  ServiceNow, PCI DSS, SANS and ISO 27001 logos are registered trademarks of their respective owners.

Enabling Centrify Identity Service and Privilege Service for Smart Card Authentication

Background
Many governmental and commercial organizations have implemented smart cards as their preferred method for Multi-factor Authentication.  This post explains how to configure Centrify Identity Service (CIS) or Centrify Privilege Service (CPS) to provide authentication using Smart Cards.  This article provides the configuration steps to enable Smartcard (certificate)-based authentication for CIS or CPS.

How it works
Generally, cryptographic credentials (user certificates) are stored in the smart card (PIV or CAC card) and the system has a dedicated reader.   Upon successful authentication (credentials verified and PIN submitted) the operating system or application will use a standard protocol (like Kerberos) or a one-time-code to grant access to the system or application.

For example, Centrify Server Suite allows the user of Kerberos for SSO to applications like Secure Shell (SSH).  Our DirectAuthorize can enforce if the user is allowed to log in with a password or with Kerberos/GSSAPI only.

In the case of Identity Service and Privilege Service, we use a Centrify capability called Zero Sign-on (SZO).  SZO provides a one-time token to use for authentication if the Authentication Profile that applies to the user is configured for Certificate-based Authentication.  All the user needs to do is navigate to the CIS/CPS site, select the smart card certificate and PIN.

This setup provides strong authentication to access Apps or for Privileged Identity Management scenarios.

What you'll need:

1. An instance of Centrify Identity Service App+ or Privilege Service  (CPS can be SaaS or On-Prem)
2. Public Key Infrastructure Infrastructure  (Enterprise CA, Revocation Infrastructure, well-configured PKI clients) and understanding of how the subject name is being provisioned.
3. A copy of the Certificate Chain (or Root CA) for your PKI infrastructure.
4. A SmartCard or Yubikey configured for authentication into your environment.
   This post contains instructions to set up a lab. See "Lab - Base Setup"

Strong Disclaimer:  This is a PKI-related topic.  You should always be workign with your PKI SME with anything related to certificates, trust chains, revocations, etc.

Configuration Overview
The configuration depends on the deployment option of the service.

1. Configuring the Root CA in Identity Service App+ or Privilege Service
2. Configuring a Policy that allows for Integrated Windows Authentication
3. Testing the configuration
4. Appendix:  Configure Privilege Service On-Premises CNAME and Zero Sign-on SSL Certificate

Configuring the Root CA in Identity Service App+ or Privilege Service (SaaS)

1. Sign-in to Cloud Manager
2. Go to Settings > Authentication > Certificate Authorities
   Note:  If you can't see the Certificate Authorities option, you're not running the App+ edition or in the case of Privilege Service on-premises, you have to perform the activation steps (see below).
3. Press Add and complete the follwing information:
   
   Name:  descriptive name of the CA
   Extract login name from:  The options are
   a) Principal Name from Subject Alternate Name
   b) E-mail address field from Subject Alternate Name
   c) Username from Subject
4. Click Browse and select the location of the root ca certificate.
5. If you are confident that you have a highly-distributed (Internal & Internet facing) Certificate revocation infrastructure, check the "Enable Client Certificate Revocation Check" if you are not sure un-check the box for now.
   Note:  If you don't know what PKI certificate revocation is, it's time to find your in-house PKI expert and get him or her involved.  This is a serious topic.
6. Press Save

Configuring a Policy that allows for Integrated Windows Authentication

1. Sign-in to Cloud Manager
2. Go to Policies > [Select your Test Policy] > Expand User Security Policies > Login Authentication
3. Set the "Enable authentication policy controls" setting to Yes, if not selected.
4. Scroll down to "Other Settings" and make sure that the "Allow IWA connections..." is checked.  Then note the following:
   Note: Certificate-based authentication bypasses the login authentication rules set up for that profile.  The key settings are:
   
   The first setting "Use certificates for authentication..." is the main switch.  If you un-check this box, the users in scope for this policy won't be able to use smart cards for authentication.  This bypasses any controls set under "Login Authentication" in the preceding section.
   The second setting  "Set identity cookie..."  controls whether the cookie is set for the browser.   I would not set this flag if you expect users to access via non-managed systems.
   The third setting "Accept connections using certificate..." defines whether if users logging in with smart cards or certs are treated as "strongly-authenticated"
   
   Make your selections based on your desired security posture.
5. Press Save.

Testing your configuration

1.  Navigate to your Identity Service or Privilege Service URL
2. Depending if your browser is configured correctly, you'll see any of the following pop-ups will come up:
   
3. After selecting the Certificate on the Smart Card, you'll be prompted for the PIN:
   
4. Once you type-in the PIN, you'll be redirected to the appropriate portal (User | Cloud Manager | Privilege Manager).

Quick Setup Video


Appendix 1:  Enabling Certificate Authorities for Centrify Privilege Service (On-Premises)
Background:  Centrify Privilege Service can be deployed on premises on a Windows Server 2012 R2 system.  You need a CNAME record for the Zero Sign-On website and a x.509 certificate with that DNS name.

Pre-requisite tasks:
a) Set-up a DNS CNAME record to with the name hostname[zso].domain.name pointing to the hostname.domain.name.  E.g. if your system name is app1.corp.contoso.com, create a CNAME record to app1zso.corp.contoso.com and point it to the original host name.
b) You need an SSL Certificate with the DNSname for the SZO special host.

1. Log in to the server hosting Centrify Privilege Service
2. Open an Administrative PowerShell and navigate to %Programfiles%\Centrify\Centrify Identity Platform\Scripts
3. Run the setup_certauth.ps1 script.   The program will ask if the pre-requisites have been met.
   
4. Confirm and you'll be prompted to provide the x.509 (SSL) cert for the SZO site.
5. Once completed, you can return to Cloud Manager and perform the steps outlined above in the:  "Configuring the Root CA in Identity Service App+ or Privilege Service (SaaS)" section.

Other Resources and Related Topics
Documentation:  https://stage-docs.centrify.com/en/centrify/adminref/index.html?version=141#page/cloudhelp%2FCloud_Policy.13.html
Centrify's support for Derived Credentials: 
- Blog: https://www.centrify.com/products/identity-service/emm/derived-credentials/
- Docs:  https://docs.centrify.com/en/centrify/adminref/index.html?version=141#page/cloudhelp%2FderivedCreds.html

This article was originally written as a Centrify Tech Blog.

Basics: Centrify Zone Schema Types and Identity Sourcing - Part II

This article is a continuation an blog post I started last month about how Centrify supports multiple schemas to store UNIX information in Active Directory.  We also discussed the challenges with UNIX namespaces, the type of schemas supported by Centrify Server Suite and strategies for discovery leveraging PowerShell and other tools.


 In this part of the article we discuss strategies on how to source UNIX identity information into Centrify Zones in Active Directory.

Terminology

• Sourcing: extracting identity data and injecting from source to destination.  I don't mean synchronization.  This is meant to be a one-time thing.
• Provisioning:  Once identity migration happens, provisioning are the operational add/moves or changes.

Strategies
Centrify Standard Edition for UNIX implementations consist of analysis and design work to migrate (source) and operate (provision).  Organizational goals vary and must balance project and production needs. That's why a good design is based on a detail analysis of the organization's process.

Let's picture an organization with this makeup

In this case we have an organization that needs to maintain an old namespace because of legacy UNIX systems, however a big mistake that I see in many of our customers is not closing the project correctly.

In this scenario there should be a strategy like this:
For the migration

• Linux systems are going to be normalized and migrated, users keep their usernames and UID/GIDs if aligned with current username standards.  Duplicates will be taken care of.
• The AIX systems will be migrated to the Centrify DB2 Plugin that can take care of the existing challenges.  This is within a 3 month of Centrify operations.  A new child zone will be created for this purpose, during migration this will be overriden at this level. 
• The HP-UX systems will be retired with application attrition.  The vendor is out of business and management has given two years to find a replacement (most likely web-based).  This can be handled with a child zone or local overrides.
• Old NIS Maps:  The old nis maps will be maintained using the Centrify NIS proxy, but the application that relies on YP will be decommisioned in a year.  To compensate for the unencrypted traffic, Centrify DirectSecure will be implemented.

For operations

• Users will get a unix login name based on their AD username
• GIDs will be long integer numbers that are derived from the AD SID

Notice the clear end of the legacy operations.   Unfortunately, in the field this is not the reality;  many times organizations end-up carrying legacy problems for years.

Now let's talk about how to source and provision data for migrations and operations.

Sourcing Data Into Centrify Zones
Centrify zones can source data using different options.  Flexibility is the key here. Ultimately, a tool that uses the Centrify APIs is required to insert data into zones.  
The tools available are:

• With Centrify Access Manager (mmc snap-in)
  • Manually using the zone defaults
  • Manually using the import wizard
• Centrify DirectManage PowerShell
• Centrify adedit
• Centrify Zone Provisioning Agent
• Custom programs that use the Centrify DirectManage SDK

Using the Zone Defaults
Each zone can be configured to provide information from default values.  The options are:

• Login name:  defaults to the AD username (sAMAccountName) - it can be truncated.
• UID can be:
  • Not defined:  no value provided (requires manual intervention)
  • Auto-incremented:  this lends itself to collisions
  • Generated UID from SID: provides a unique 32-bit integer number generated using Centrify's algorithm
  • Use Apple UID Scheme:  provides a unique 32-bit integer generated using Apple's algorithm
  • RFC2307:  You need the 2016.1 version of AM to see this, but this option is quite useful to source existing RFC2307 data.

Import Wizard
The import wizard can process UNIX identity data from local files or a NIS directory.  The key is to arrive to a consolidated set of files and that the inconsistencies are understood.

Our professional services teams provide sets of of scripts to identity anomalies with user/group identities and once a consolidated /etc/passwd or /etc/group file has been identified, then the fun can begin:

Another benefit of the import wizard is that combined with the getent command, provides a fast way to onboard users and groups from 3rd parties.  This video should illustrate what I mean.

This topic has been covered as well in different entries:

• Migrating from /etc/users
• Migrating from /etc/group
• Cleanup with the adfixid & adrmlocal utilities by @tchariya

DirectManage PowerShell
Active Directory PowerShell Modules can be combined with DirectManage PowerShell for some interesting sourcing/provisioning options.  For example:  You can identity all users with posixAccount information (generally those that don't have the uidNumber populated).
If using a Centrify Standard or RFC2307 zone, you can use this information to provision data into the zone.

$zone = Get-CdmZone -Name RFC
$posixinfo = Get-ADUser -Filter * -Properties * | Where-Object {$_.uidnumber -ne $null} | Select-Object  UserPrincipalName, SamAccountName, name, uidNumber, gidNumber, unixHomeDirectory, loginShell 
Foreach ($user in $posixinfo)
{
New-CdmUserProfile -Zone $zone –User $user.UserPrincipalName -Login $user.SamAccountName  -Uid $user.uidNumber -PrimaryGroup $user.gidNumber –HomeDir $user.unixHomeDirectory –Gecos $user.name –Shell $user.loginShell
}

 Alternatively, if you're using an SFU zone and the information is normalized, you only need to update the msSFU30NisDomain attribute to the NIS domain set for the zone in the particular domain. 

$zone = Get-CdmZone -Name SFU30
$nisdomain = $zone.NisDomain
$posixinfo = Get-ADUser -Filter * -Properties * | Where-Object {$_.uidnumber -ne $null} | Select-Object  UserPrincipalName, SamAccountName, name, uidNumber, gidNumber, unixHomeDirectory, loginShell 
Foreach ($user in $posixinfo)
{
Set-ADUser -Identity $user.SamAccountName -Replace @{msSFU30NisDomain =$nisdomain}
}

Zone Provisioning Agent
ZPA is a utility provided for automatic provisioning.  It relies on AD Security groups as the "source" and based on group memberships the service will provision UNIX user or group identities.  ZPA options extend the options seen on the zone defaults.

ZPA can be viewed as a provisioning utility rather than a "sourcing" tool.

Centrify adedit
adedit is a TCL-based utility that can be used to modify Active Directory data and it powers many of the operations performed by the centrify's adclient.

Here's an excerpt for user provisioning:

>bind centrify.vms
>select_zone "cn=rfc,cn=zones,ou=unix,dc=centrify,dc=vms"
>new_zone_user wanda.web@centrify.vms
>set_zone_user_field uname wanda.web
>set_zone_user_field uid $userUID
>set_zone_user_field gid 0x8000000
>set_zone_user_field gecos "Wanda Web"
>set_zone_user_field home "%{/home}/%{user}"
>set_zone_user_field shell "%{shell}"
>show
Bindings:
        centrify.vms: dc.centrify.vms
Current zone:
        CN=RFC,CN=Zones,OU=UNIX,DC=centrify,DC=vms
Current nss zone user:
        wanda.web@centrify.vms:wanda.web:134217728:134217728:Wanda Web:%{/home}/%{user}:%{shell}:
Forests have valid license:
>save_zone_user

adedit is a deep topic.  Here's the documentation:  https://docs.centrify.com/en/css/suite2016/centrify-adedit-guide.pdf

Centrify DirectManage SDK

The directmanage SDK provides the ability for developers to write their own apps for sourcing or provisioning.  The best resource to find documentation and other resources is to leverage the Centrify Developers page.  The sample applications are in the Suite.  Access Manager, Zone Provisioning Agent and the migration wizards are all created using the SDK by Centrify developers

There are also customers making very innovative use of these resources.


Conclusion
The key to current customers and prospects is flexibility.  Regardless of where and how complex your organization's UNIX identity data is, Centrify offers the deepest options to seamlessly integrate to your existing Active Directory regardless of deployment.

[Labs] Using Identity Platform as a RADIUS Client to support MFA with OTP tokens (e.g. SecurID, etc)

Background

With the 16.8 monthly release of Centrify Identity Service and Privilege Service, Centrify is adding the ability for the Identity  Platform to act as a RADIUS client.  This will open the opportunity for CIS and CPS users to have authentication profiles for MFA products that support RADIUS (e.g. RSA, Symantec, CA, Vasco, etc).

This lab will allow you to set up a Linux server to act as your AD-integrated OTP+RADIUS server.  Then we'll configure CIS/CPS to act as a RADIUS client and support it as an additional MFA option.

Disclaimers

• This is a lab entry.  Production designs require planning for people, process and technology.
• RSA SecurID, Symantec VIP, Vasco, YubiKey, Google Authenticator, FreeRADIUS and CentOS are registered trademarks of their respective owners.

Lab Design
 The proposed lab looks as follows:

As you can see, we're using the following components:

• Identity Service or Privilege Service (can be the on-premises version of CPS too)
• Cloud connector:  enabled for AD Bridging and RADIUS client
• Centos 6.x System:  this system acts as
  • RADIUS Server > FreeRADIUS configured for PAM
  • Google Authenticator PAM Module > will provide OTP codes for enrolled users
  • Centrify DirectControl > Provides AD integration and NSS/PAM based identification/authentication
• Active Directory:  Provides infrastructure identity services (directory, authentication, policy)

Implementation
In this lab we will not cover the setup of an identity service instance and cloud connector.  Some resources:

• Getting Started with Centrify Identity Service (Microsite)
• Identity Service Support FAQ
• Centrify Support's YouTube Channel
• Identity Service Documentation

 What you'll need:

• A CentOS 6.x system configured in the same subnet as the Cloud Connector or with TCP 1812 connectivity.
• Working knowledge of Identity Service or Privilege Service
• Familiarity with Pluggable Authentication Modules (PAM)
• Basic DirectControl knowledge (install, join AD)
• An OATH OTP client (Google authenticator, Yubico authenticator, etc)

This lab starts assuming that you can log in to your Identity Service or Privilege Service instance with a user with the System Administrator right.


RADIUS+OTP Server Setup
Configuration Overview

1. Adding the EPEL repo to be able to install Google Authenticator
2. Install Google Authenticator
3. Install FreeRADIUS and related tools
4. Configure FreeRADIUS for PAM
5. Install Centrify DirectControl and join Active Directory
6. Enroll users for Google Authenticator OTP
7. Test your configuration with the command line
8. Configure Identity Service/Privilege Service as a RADIUS client

Adding the EPEL repo for Centos 6.x 

$ wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
$ sudo yum install epel-release-latest-6.noarch.rpm -y
[truncated]
Installed:
  epel-release.noarch 0:6-8

 Installing Google Authenticator

$ sudo yum install google-authenticator -y
[truncated]
Installed:
  google-authenticator.x86_64 0:0-0.3.20110830.hgd525a9bab875.el6

 Install FreeRADIUS and Tools

$ sudo yum install freeradius freeradius-utils -y
[truncated]
Installed:
  freeradius.x86_64 0:2.2.6-6.el6_7   freeradius-utils.x86_64 0:2.2.6-6.el6_7

Dependency Installed:
  perl-DBI.x86_64 0:1.609-4.el6

Configuring FreeRADIUS for PAM
a) User and Group for the Radius Daemon
To  allow the radiusd daemon to traverse the filesystem to read the Google Authenticator config files on each user's home directory, you have to change the user/group in the configuration file.  This may be undesirable in a production environment.
Edit the  /etc/raddb/radiusd.conf and find:

user = radiusd
group = radiusd

Change to

user = root
group = root

and save the file.

b) Enable PAM for the Default Site
Edit the  /etc/raddb/sites-enabled/default  and find:

        #  Pluggable Authentication Modules.
#       pam

uncomment the PAM module and save.

        pam

c) Configure Users for PAM
Edit the  and find

#DEFAULT        Group == "disabled", Auth-Type := Reject
#               Reply-Message = "Your account has been disabled."

uncomment and add the line as follows:

DEFAULT Group == "disabled", Auth-Type := Reject
                Reply-Message = "Your account has been disabled."
DEFAULT Auth-Type := PAM

 Tip:  To check your work so far

1. In one session window, run the radius daemon in verbose mode
   

   $ sudo radiusd -X
   [truncated]
   Ready to process requests.

   If there are any issues with the current configuration, you can verify it with the output.
2. Open another session and create a new user
   

   $ sudo useradd testing
   $ sudo passwd testing
   New password:
   BAD PASSWORD: it is based on a dictionary word
   Retype new password:
   passwd: all authentication tokens updated successfully.
   

   Now you have a user to test your RADIUS server via PAM.
3. In that same session, use the radtest utility with the client set for the localhost client.
   

    radtest testing Mysecret123! localhost 0  testing123       Sending Access-Request of id 204 to 127.0.0.1 port 1812
           User-Name = "testing"
           User-Password = "Secret123!"
           NAS-IP-Address = 192.168.81.34
           NAS-Port = 0
           Message-Authenticator = 0x00000000000000000000000000000000
   rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=204, length=20
   

   On the first window, you'll see the verbose output somewhat like this:
   

   rad_recv: Access-Request packet from host 127.0.0.1 port 53367, id=204, length=77
           User-Name = "testing"
           User-Password = "Mysecret123!"
           NAS-IP-Address = 192.168.81.34
           NAS-Port = 0
           Message-Authenticator = 0x8c11ad4b5c1dbd597764716d95d3d9e3
   # Executing section authorize from file /etc/raddb/sites-enabled/default
   [truncated]
   Sending Access-Accept of id 204 to 127.0.0.1 port 53367
   

   This verifies that things are set up correctly so far.  Cancel radiusd debug (CTRL+C)

Install Centrify DirectControl and Join AD
We'll use the Centrify Repo and join AD in Workstation mode.

$ sudo yum install CentrifyDC -y
[truncated]
Installed:
  CentrifyDC.x86_64 0:5.3.1-398
$ sudo adjoin -w -u [user.name] domain.name
user.name@DOMAIN.NAME's password:
Using domain controller: dc.centrify.vms writable=true
Join to domain:centrify.vms, zone:Auto Zone successful

Centrify DirectControl started.

At this point, if you want another sanity check, you can repeat the same debugging but with an AD user credential.

Configure the Radius PAM directives for Google Authenticator
Edit the /etc/pam.d/radiusd perform two modifications.
Add  this line on the top of the file auth required pam_google_authenticator.so and comment the auth module.
Here what we'll achieve is to provide the Google Authenticator code as our one-time password via RADIUS.  Other combinations of PAM modules can achieve a Password+Code. 
The final result should look like this:

#%PAM-1.0
auth       required     pam_google_authenticator.so

#auth       include     password-auth
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
session    include      password-auth

This configuration challenges for the OTP code only and ignores the password.

Enroll an AD user with Google Authenticator

1. Log in with a test AD user to your Linux system
2. Run the google authenticator setup (google-authenticator)
   

   Last login: Thu Aug  4 06:22:50 2016 from 192.168.81.11
   $ google-authenticator
   https://www.google.com/[truncated]  <= copy this URL and paste it on your browser
   Your new secret key is: ETIQLTKPBQV4TVLH
   Your verification code is 2647620
   Your emergency scratch codes are:
     08703664
   [truncated]
   

   Follow the prompts until you complete setup.
3. Paste the URL in a web browser and use your Authenticator QR Capture function to capture the code.
   Alternatively you can add the code manually.
4. Repeat this process for all your test users.

Verify RADIUS functionality with OTP

1. In a session, open Radiusd in verbose mode.  [sudo radiusd -X]
2. In another browser, test the authentication with the code from the OATH OTP authenticator.
   radtest [username] [oath otp code] localhost 0 [pharaphrase]
   In my environment it looks like this:
   

You have verified functionality.

Set up the Cloud Connector as a RADIUS Client
On the FreeRADIUS Server you have to set up the connector as a client.

1. If you haven't done so, close the radiusd debugger.
2. Edit the following file  /etc/raddb/clients.conf go to the end and add:
   

   client member2.centrify.vms {
           secret          = [Insert Complex String Here]
           shortname       = [Friendly Name]
   }
   

   Notes:
   - You can use the IP address or FQDN of your RADIUS-enabled connector
   - You must choose a decent complex string as your secret and save it for the next section.
3. Save the file.

Note:  In some Linux systems/versions you may need to set SELinux to permissive.  This is to allow radiusd to interact with PAM.

Centrify Identity Service or Privilege Service Setup
Overview

1. Configure the RADIUS Server
2. Configure Connector for RADIUS
3. Enable RADIUS in your Policy
4. Enable 3rd Party RADIUS in your Authentication Profile(s)
5. Verify Functionality
6. Modify RADIUS service startup

To configure the RADIUS Server
Go to Cloud Manager > Settings > Authentication > Radius Connections > Servers Tab and press Add
Name: A descriptive name (e.g. SecurID PIN+Code)
Description: Optional
Server IP Address:  The IP address of your server
Port:  Change if not default (1812)
Server Secret:  Must match the secret you set up in the previous step.


Configuring a Connector for RADIUS
You need at least one connector enabled for RADIUS that can reach the RADIUS server.
Go to Cloud Manager > Settings > Network > Cloud Connectors > [connector] > RADIUS > and Check
"Enable connections to external RADIUS servers" 

Also make sure that the RADIUS Client service is enabled.

Enable RADIUS in your User Authentication Policy
Go to Cloud Manager > Policies > [click on the policy that applies to the user(s)] > Expand User Security Policies and Click RADIUS.  Set "Allow 3rd Party RADIUS" to Yes and Save.


Enable 3rd Party RADIUS in any corresponding Authentication Profiles
Cloud Manager > Settings> Authentication Profiles > [click profile that you want to enable] and check
"3rd Party RADIUS Authentication" and press OK.  Repeat with other profiles if needed.


Verify Functionality

1. Launch radiusd in debug mode (sudo radiusd -X) on your Linux system.
2. Trigger a Step-up protected event in CIS/CPS  (private login, secure access, password checkout)
   
   Monitor the debug log for any errors.  If everything goes as expected, keep testing with other users.

Tidy-up:  Set up the Radius Service for Automatic Startup

$ sudo chkconfig radiusd on
$ sudo service radiusd start

Quick Video

[Quick Tip] Using Centrify GPOs to allow OSX users to control print queues

Background

OS X users without administrative rights get challenged each time they need to stop/resume print queues.  Organizations looking to implement the least privilege management security model may need to provide ways for users to be "print operators" on a Mac, without granting full administrative rights.  The "Printers and Scanners" system preference does not provide granular entitlements.

This issue may cause many calls to the helpdesk

This post covers a way to overcome this issue using AD security groups and the "Map zone groups to local groups" Centrify GPO.

The idea is that you map an AD security group to the _lpadmin and _lpoperator local groups of the system.


What you'll need:

1. An AD Security Group and the ability to control memberships.
2. The ability to modify GPOs that apply to your Macs using the Centrify templates and GPMC/GP Editor.

Step-by-step
Create and populate an AD group

1. Use ADUC, PowerShell, request system or any tool of record to request an AD group.  Give it a descriptive name like "mac-print-admins"
2. Populate the group with the AD users that will be allowed to manipulate queues.

Edit the "Map zone groups to local group" GPO

1. Open GPMC and browse to the GPO that applies to your Mac.  Right click and select edit.
2. In GP Editor, browse to Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Accounts and double-click the Map zone groups to local group GPO.
3. Press add and and in local group type _lpadmin, then browse for the AD group created in the previous step.  (e.g. mac-print-admins).
4. Repeat same process on step 3 with the local group _lpoperator.  At the end, the GPO looks like this:
   
5. Press OK and close GP Editor and GPMC.

Refresh the GPOs on the Mac and verify your results

1. Log on to the Mac as a non-admin user that is a member of the AD group created in the first section.
2. Open a Terminal.
3. First, refresh the group policies by running the adgpupdate command.  (adgpupdate -T computer)
4. Now verify that the GPO is effective by running adgpresult  (adgpresult | grep _lp)
   

Your user should not be challenged moving forward to pause/resume print queues, plus the user does not have admin rights, therefore you're aligned with the least access principle.

Quick verification video

Basics: Centrify Zone Schema Types and Identity Sourcing - Part I

A common category of questions we get from Centrify prospects and customers is around UNIX identity storage and options for sourcing.  The most frequent is:  How do we get UNIX identity data to your solution?

I typically tend to answer:  Where does your UNIX identity data resides?
The answer to this question varies.  I've heard all kinds of responses, including silence or arguments between team members.  Ultimately it boils down to two categories:

Rationalized(*)

Not Rationalized

There is a naming convention established and the convention is enforced A directory may or may not be in place  (e.g. LDAP, NIS, etc) Every user has a unique login, UID and Primary Group Every UNIX group is defined with the same unix-name and GID, has the same meaning and group members There is typically a unified strategy for multi-protocol filers There is a unified (or centralized) sudoers files

The naming convention is spotty or non-existent A directory may or may not be in place  (e.g. LDAP, NIS, etc), but there are pockets of "other stuff" Users may have different naming for login or different UIDs  (e.g. jdoe (501:501) vs john.doe (10001:1) Groups may have different unix-names, different GID numbers, members or meaning. Centralized sudoers files may or may not exist or contain outdated information.

^(*)Note: "Fully-rationalized" is typically an aspiration.  Organizations may have historical or legacy reasons as of why they may keep older systems that do not conform to the standards (and yes, Centrify has you covered).

Other questions that follow are:  Will you be using the SFU or RFC2307 fields? What are these zones that you speak of and what are the AD implications?  Can you make use of my existing UNIX information?  How painful (or painless) will the process be?

The answer to the last question varies between organizations.  Some organizations believe the process will be cumbersome and choose to continue with the status-quo (after all, their problems are well documented); others make the painful decision to not get help or training (a decision that really baffles me).

This article explores the different schemas used by Centrify Zones and provides an overview of sourcing options. The topic is very relevant due to the following facts:

• Microsoft's deprecation of Identity Management for UNIX and Services for NIS
  https://blogs.technet.microsoft.com/activedirectoryua/2016/02/09/identity-management-for-unix-idmu-is-deprecated-in-windows-server/
• Limitations of current OS-native alternatives and less investment from alternative 3rd. parties.

Having a solution that provides flexibility, especially in such an important capability that is the foundation to secure critical systems is key for large enterprises.  Let's get started.

Basics

• UNIX identity data consists of login, UID, GID, Home Directory, Shell and GECOS.
• Centrify Zones leverage Active Directory to provide Identity Management for UNIX, Linux and Macs and Role-Based Access Control + Privilege Management for UNIX, Linux and Windows.

UNIX identity may reside on:

• Local /etc/passwd and /etc/group files on each individual system (could be the same for /etc/sudoers)
• Network-based passwd and group files on LDAP or legacy NIS directories (same for /etc/sudoers)
• In Active Directory in the msSFU30 fields (pre-Windows 2003R2) or the RFC2307bis (after Windows 2003R2) and are attributes of the posixAccount class.
• In other LDAP-like directories that rely on synchronization (e.g. Oracle, Red Hat, Apple or other third party software, etc)

Centrify Data Storage: Zones
Identity data is inside the Centrify Zone.  A Zone is a set of AD objects that consolidate identity and privilege information.  Centrify identity data is stored on a serviceConnectionPoint linked to the user or group object.  This chalk-talk covers this information in detail.

Benefits:

• Provides the ability to limit the visibility (and access) of users/groups in different contexts.
• A user (or group) may have different identities in different contexts (especially useful in M&A activities or consolidations)
• Provides the capability to group systems (teams of servers) using different options
• Its structure is hierarchical, provides inheritance and object reuse
• Aligns organizations with the principle of separation of duties
• Multi-platform (allows the grouping of UNIX, Linux, Windows and Mac systems)
• Highly-scalable (overcomes the limitations of other schemes like Auto Zone)
• Provides support for different schemas (SFU, RFC2307) and UID/GID Schemes

Types of Zones and Schemas
Zones can be Classic or Hierarchical.  Because Classic zones are no longer the best practice, they exist for backwards compatibility.  In the rest of this article, a Centrify Zone is always considered to be a hierarchical zone.

Centrify Standard Schema: UNIX attributes are stored in the keywords multi-valued attribute of the user or group's serviceConnectionPoint


The standard schema was very useful, especially in old Windows 2000 deployments.
Here's how to create a Standard zone using Centrify DirectManage PowerShell:

$cont = "cn=zones,ou=UNIX,dc=centrify,dc=vms"  #substitute with your container DN
New-CdmZone -Name Standard -Container $cont -Schema standard -Type hierarchical

SFU Schema: UNIX attributes are stored with the user or group object and the msSFU30NisDomain is populated based on the zone's NIS domain setting.

Using the SFU schema allows the automatic sourcing for all users that have the RFC2307 UNIX fields populated along with the the msSFU30NISDomain attribute.  The drawback is that you must have rationalized your environment and overrides won't be possible (more about overrides below).

PowerShell:

$cont = "cn=zones,ou=UNIX,dc=centrify,dc=vms" # substitute for your container DN
New-CdmZone -Name SFU30 -Container $cont -Schema sfu -NisDomain SFUX -SfuDomain centrify.vms -Type hierarchical

When planning to use SFU as a schema, you are bound by the limitations of having the data with the AD object, most notably UNIX names.  You cannot have identity overrides (for example, changing the UNIX name of a group).  This is illustrated below:


RFC2307-compatible schema:  UNIX attributes are stored with the serviceConnectionPoint that defines the user or group.


PowerShell:

$cont = "cn=zones,ou=UNIX,dc=centrify,dc=vms" # substitute for your container DN
New-CdmZone -Name RFC -Container $cont -Schema rfc -Type hierarchical

Tips on Discovering UNIX Data
Due to the fragmented nature of heterogeneous environments (and the fact that they've been around for a long time), information seems to be all-over the place, but here are many tips.

• UNIX Identity data in files (/etc/passwd or /etc/group) may have different inconsistencies like:
  • unix users with more than one UID
  • unix users with more than one GID
  • unix users with multiple unix names
  • unix users with different shell or home directories  (e.g. /home/user vs. /exports/home/user)
  • unix groups with more than one GID
  • GIDs with different group names
  • unix groups with different group memberships
  • sudoers files with non-existing groups, aliases or unix names

Identifying this information can help with the identity rationalization process.

• UNIX Identity data in Active Directory
  • Different schemas (SFU vs RFC2307)
  • Multi-domain forests with inconsistent NIS domain data
  • AD data that is no longer relevant

PowerShell Discovery Query (RFC2307)

Get-ADUser -Filter * -Properties * | Where-Object {$_.uidnumber -ne $null} 
| Select-Object  UserPrincipalName, SamAccountName, name, uidNumber, 
gidNumber, unixHomeDirectory, loginShell | Format-Table

Conclusion for Part I:
Part of the reason why Centrify has been successful is the flexibility of our toolset, the experience of our Professional Services organization, our willingness to listen to our customers and the consistent investment on the product. 

The benefits of having a unified namespace while using a common infrastructure are critical for security, functionality and productivity.  In the field we still see many organizations struggling with this core concept.  With Centrify enterprises are covered not only on a family of Linux systems, but in critical UNIX systems that run AIX, HP-UX, Solaris, OS X and other commercial Linux distributions.

In part 2, we'll discuss some options on how to source data into Centrify zones using multiple toolsets.

Centrify also named a leader in the Privilege Identity Management by Forrester

Following last month's Gartner IDaaS MQ, Centrify has also been named a leader in the 2016 Forrester Wave for Privilege Identity Management (PIM).

This makes Centrify the only vendor with leadership on both capability categories.  Most of the content of this blog is around tips for PIM for my prospects and customers.  We'll continue to post based on your inquiries and questions.