Your Centrify Privilege Service (CPS) deployment could go a lot smoother with this checklist. This checklist is a high overview of the necesarry tasks to prepare, deploy, configure, and validate a CPS environment.

Read more...

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

Read more...

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

 

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

Read more...

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

Many federal IT departments are being told to provide 2-factor authentication not only for all logins, but also for all privilege elevations, including the launching of critical applications. Here’s how Centrify can help.

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

Want to know how to migrate your UNIX profiles from an existing AD Bridging solution or LDAP to Centrify Server Suite for UNIX/Linux?  These steps will who you how to leverage your existing unix profiles and migrate to Centrify from other centalized solutions with minimal impact to your environment and processes.

Read more...

Support has helped multiple customers who are trying to meet the challenges posed by the badlock vulnerability in samba while also learning about how to move to Centrify's new adbindproxy component.  This article is based on our recent experience helping customers migrate in hopes it will help other customers who are seeking similar guidance.

 

The following information applies to Red Hat Linux. If you are using a different operating system, please recognize that some of the commands may differ somewhat.

 

Let’s log into a Linux machine that is joined to a Centrify zone and has Centrify-enabled samba on it. Once logged in, let’s check the shares on the machine by running smbclient at the command prompt.

1.png

After verifying the correct shares are listed, let’s backup the samba configuration file:

 

dzdo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak

 

We’re now ready to uninstall the Centrify-enabled samba installation form the machine using the rpm command:

 

dzdo rpm –e CentrifyDC-samba   (This is case sensitive)

 

And then verify it was removed:

 

dzdo rpm –qa | grep –i Centrify

 

Ensure nothing for Centrify samba is listed. We’ll then want to remove any stock samba 3 installations. We will first search for them:

 

dzdo rpm –qa | grep samba

 

If any show up, we’ll then want to remove the packages with the yum command:

 

dzdo yum remove samba*

Enter a y to remove when prompted.

 

We’re now ready to install samba 4, again utilizing the yum command:

 

dzdo yum install samba4*

When prompted, enter a y to install.

 

We should then verify installation:

 

dzdo rpm –qa | grep samba

2.png

As long as the installation is listed, we are ready to move the backed up samba config file into place in order to utilize all of our previous samba settings:

 

dzdo cp /etc/samba/smb.conf.bak /etc/samba/smb.conf

 

 

You can check the date stamp to ensure the smb.conf file is the one we just copied into place.

If you’d like to verify the share files are still showing correctly, please run testparm at the command prompt. The shares should show.

3.png

We’re now ready to download and install Centrify’s adbindproxy. Please open a browser and navigate to www.centrify.com and then go to Support and then Download Center and use your Support Portal login to log into the site. Once logged in, please go to “Tools and Troubleshooting” and find “Integration with Samba”. It will then show a list of the different operating systems. Please select the TGZ button next to the line that matches your operating system and download the file.

4.png

4-1.png 

 

Once the download completes, please copy or move the file to the *nix machine. You can make a directory on the Linux machine where you’d like to untar the tgz file:

 

mkdir /tmp/adbindproxy

 

You can then navigate to the directory where the tgz file is located and untar it:

 

mv centrify-adbindproxy……..tgz /tmp/adbindproxy/

cd /etc/adbindproxy

tar –xvf centrify-adbindproxy…….tgz

5.png

We’ll then install adbindproxy with the rpm command:

 

dzdo rpm –Uvh centrify-adbindproxy…….rpm

6.png

After the installation is complete, we’ll want to run the configuration script for adbindproxy and we’ll mostly be taking the defaults in the script with a few exceptions:

 

dzdo /usr/share/centrifydc/bin/adbindproxy.pl

 

One of the prompts will ask if you want to join the machine to a zone, if it’s already joined, you can jess press enter. If you need to join it to a zone, you can enter the zone name here and press enter.

 

The next prompt you want to watch for is the one that says:

 

Please specify the stock samba winbind listen path(dir)if it is not in [/run/samba/winbindd]:

RHEL 6 often uses /var/run/samba/winbindd for its winbindd listen path so you’ll want to verify the winbindd path and change it here if necessary. If it uses the default path, you can just press enter.

 

You should just be able to take the defaults through the rest of the script but you may want to read them to verify they are correct before pressing enter.

After the script completes, the samba services, smbd, nmbd, winbindd and adbindd, will need to be restarted. Centrify has a built in command for restarting all four services so that they don’t have to be restarted one at a time. At the command prompt, please run:

 

dzdo service centrifydc-samba restart

 

You’ll be able to verify the services are starting OK at this point.

 

We’ll want to add this setting to chkconfig to ensure this command runs if the server is ever rebooted. We can do that by running the following command:

 

dzdo chkconfig --add centrifydc-samba

 

We then need to start this chkconfig process:

 

dzdo chkconfig centrifydc-samba

 

And then verify it started correctly for the run levels that are necessary:

 

dzdo chkconfig --list centrifydc-samba

 

We’re ready to verify the samba version installed:

 

smdb –V

7.png

We can also verify we see the Linux shares:

 

smbclient -L //localhost

8.png

And then connectivity to the shares:

 

smbclient //localhost/sharename

 

It will go to a prompt that looks like smb:\> where you can type in ls and the shares should be listed.

9.png

You may also want to go to a Windows machine and verify you can get to the shares from there. If you go to Windows Explorer and, in the address window, type in \\servername\sharename, you should see the contents of the share.

10.png

You’re all set. You are now running on stock samba with Centrify’s adbindproxy in place to help integrate samba with Centrify.

 

Centrify has some additional resources on this subject if you’re interested.

There’s a Samba Integration Guide that came with the adbindproxy download and can be found in the directory where we untarred the tgz file. You can also get this documentation from the Centrify website by going to:

 

https://docs.centrify.com/en/cs/suite2016/centrify-adbindproxy-guide.pdf

 

There is also a video that goes over the process step by step that you can view below.

 

  

There are also some knowledge-base articles that are helpful with this process. You can find them in the community section of the website. Links to these KBs are listed below.


Links:

https://centrify.force.com/support/Article/KB-6842-Overview-of-the-steps-to-upgrade-or-migrate-from-...

https://centrify.force.com/support/Article/KB-6834-Additional-configuration-steps-for-deploying-Adbi...

https://centrify.force.com/support/Article/KB-6731-Impact-of-Badlock-CVE-2016-0128-CVE-2016-2118-on-...

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:

  doc-approvals.png

 

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:
    DirectAudit Analyzer - dzdo.validator event.jpg
  • 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

dzdo-validator-lab.png 

 

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'=> $0})


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

ben-da.png

 

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.

ben-splunk.png

 

Improvements

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

  • Use OAth 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.

Background

Last month, with the release of Server Suite 2016.1, Centrify expanded on the MFA Everywhere strategy adding support for UNIX systems (AIX, HP-UX, Solaris) for Server Login and Privilege Elevation, on Microsoft Windows, MFA was added for Privilege Elevation and finally, MFA  at login for Auto Zone and Classic Zones.  This means that Centrify Express for UNIX/Linux customers can use the industry-recognized Centrify Identity Service tenants can implement MFA or step-up authentication when accessing systems. 

 

This article covers the steps to implement MFA as an additional control to access systems integrated to AD with Centrify Express for UNIX/Linux.  The information in this article can also be applied to Classic zones and Auto Zone (workstation mode).

For an in depth discussion on Centrify Server Suite MFA, you can read this lab entry.

For information on how to get started with Centrify Identity Service, visit the Getting Started page.

 

Planning

Potential Stakeholders

  • Centrify SMEs:  UNIX/Linux admins familiar with Centrify DirectControl (CLI tools and configuration)
  • Security Lead:  The security lead can answer questions like these:
    a) What servers require step-up authentication for login?
    b) What users will be challenged for Multifactor at login?
    c) What users will have the rights to log in without multifactor or for troubleshooting purposes?
  • IT/AD Infrastructure lead:   This SME will help setting up a Windows Server to act as the Centrify connector
  • PKI Lead (optional):  If using enterprise trust to issue certificate to be used for Integrated Windows Authentication (IWA/SPNEGO) over HTTPS.

Technical Requirements

  • Active Directory
  • A supported Centrify Express OS with Centrify DirectControl 5.3.1 (2016.1) and up
  • A Centrify Identity Service tenant  (you can sign-up for a trial here) with a Centrify Connector
    Centrify Connectors run on 64-bit Windows Servers and require outbound HTTPS connectivity (can be behind a proxy)
  • A user with a supported MFA or step-up method (Phone Number, Mobile Number (for SMS), Centrify Mobile Authenticator for Push MFA, OATH OTP (Google Authenticator, FreeOTP, YubiKey, DUO, etc).
  • If using Centrify Mobile Authenticator or Google Authenticator  you'll need an iOS or Android device

 

Centrify Parameters for MFA on Auto Zone

Centrify Express joins Active Directory in workstation mode.  This allows for quick integration with AD for all users without worrying about UNIX identity.  UNIX login, UID, primary group, GECOS, home and Shell are generated by the Centrify client.  Configuration can be managed via parameters.   The parameters introduced for MFA are the following:

  • adclient.legacyzone.mfa.enabled: This parameter turns on MFA and it is set to false by default.
  • adclient.legacyzone.mfa.cloudurl: This is the Centrify Identity Service tenant URL that is configured to grant MFA to the system.
  • adclient.legacyzone.mfa.required.groups (or users):  These parameters specify which users (or members of the AD group) that will be challenged for multi-factor on login.
  • adclient.legacyzone.mfa.rescue.users: These are the users that can access the system in case no tunnel can be established with the MFA service.

Other relevant parameters:

  • adclient.cloud.connector:  This parameter can be used to specify a proxy server if in use.

 

Implementation

Scenario

We will get started with a Centrify Identity Service that has the Centrify Connector set up with the AD Bridge enabled.

To learn how to set up a Centrify connector you can always review the Getting Started guide.

First, we will enable MFA using information from a user in AD (e-mail, SMS, phone factor), then we will walk the user through the process of enrolling a mobile device (to enable Centrify Mobile Authenticator for push MFA) and we'll also use Google Authenticator for OATH OTP.

 

Configuring a Centrify Connector

Centrify connector configuration steps are outlined here. However, the steps are as follows:

  1. In Admin Portal, navigate to Settings > Network > Centrify Connectors
  2. Click the "Add Centrify Connector"
    register cc.png
  3. Download the bits and run setup.  All you need is the Centrify connector component.
  4. You have to authorize the Centrify Connector following the steps on the wizard.  Refer to the link below for a video detailed steps.

 

Retrieve the IWA Cert

Since Centrify Identity Platform 16.10, IWA happens over HTTPS.  This means that you must deploy a public, enterprise or tenant certificate.  The steps below explain how to use the IWA certificate provided with the connector.

  1. In Admin Portal > Settings > Network > Centrify Connectors > click the connector > IWA Service and click "Download your IWA root CA certificate"
    iwa.png
  2. Locate the file and try to open it with a text editor. If the text reads "--- begin certificate" you are dealing with a usable certificate.
    Save the file and transfer it to your target system (e.g. IWACert.crt)

 

Configuring your Centrify Identity Service tenant for Server MFA

There are 4 tasks to configure MFA for Servers in the Admin Portal side:

  1. Role Creation
    Create a role that has the "Server Login and Privilege Elevation" right and contains the computer accounts that will be requiring multi-factor authentication.
    Admin Portal > Roles > New Role > [Rights and Members]

    mfa role.png
  2. Authentication Profile
    Create an authentication profile that specifies the MFA methods to be used.
    Admin Portal > Settings > Authentication > Authentication Profiles
    authprof.png
    Notes:  It is important to make the distinction between step-up authentication and multi-factor authentication (sometimes used interchangeably).  In addition to the login password challenge, an e-mail link delivered to your inbox qualifies as step-up, but push MFA from a registered mobile device (something you have) is MFA.
    Note that I've left out password and user-defined security question.  Checking password will re-prompt the user for their AD password and the answer to a security question is just another secret that can be obtained by social-engineering.

  3. Set up an Authentication profile for Server Suite Authentication
    Admin Portal  > Settings > Authentication Profiles > Server Suite Authentication
    ssauth.png
    For Centrify Express, only the Access Profile applies.
  4. Verification of Methods
    Make sure your users have the step-up methods populated in AD:
    attrib.png
    If looking to provide Step-up via email, the user has to have a valid e-mail address.  For phone call, phone/mobile are required, for SMS mobile is required.

Configuring the UNIX/Linux System's PKI to use the tenant certificate

You need to make sure the ca-certificates package is installed in your system and that you append the certificate retrieved from the connector in the previous steps (IWACert.crt) to the ca-bundle file.

To check if the CA certificates bundle is installed

# On RHEL and derivatives 
$ sudo yum info ca-certificates
# If not installed
$ sudo yum install ca-certificates

To append the Centrify Connector IWA certificate to your existing CA bundle

$ sudo cat /home/user/IWACert.crt >> /etc/pki/tls/certs/ca-bundle.crt

Note:  This approach is recommended for a lab. Ideally you would have a public certificate or an Enterprise CA certificate deployed.  More info in this post.

 

Configure Centrify Express for MFA at login

 

This is a parameter-based configuration.  As defined above, you need at least 4 parameters in the /etc/centrifydc/centrifydc.conf file:

 

# set this one to true
adclient.legacyzone.mfa.enabled: true

# to require MFA, you can either use individual users or groups.
# groups are more efficient

adclient.legacyzone.mfa.required.groups: mfa-required
# all members of mfa-required AD group will be prompted
# rescue rights can be assigned for HA in case all CCs are down # or there's no redundant connectivity to the cloud service adclient.legacyzone.mfa.rescue.users: vip.user1, vip.user2 # vip users can access systems in case of comm failure
# The cloud URL is the key parameter to specify your tenant # note that no direct internet connectivity is required, the CC # will broker this. adclient.legacyzone.mfa.cloudurl: https://unique-id.my.centrify.com:443/ # Use the unique URL instead of the vanity URL if you expect
# any changes.
# There are other parameters (e.g. for a Proxy server)

Save your changes and run an adreload or simply restart the centrifydc service.

 

Use adcdiag to check your work:

$  sudo /usr/share/centrifydc/bin/adcdiag

In my case, I just need to make sure that ChallengeResponse is set, since I'm using stock SSH.

 $ grep Challenge /etc/ssh/sshd_config
ChallengeResponseAuthentication yes 

 

Verification

login as: lisa.simpson
Using keyboard-interactive authentication.
Password:
Using keyboard-interactive authentication.
[Available mechanisms]
 1 - Mobile Authenticator
 2 - Yubikey or OATH Token
 3 - Email... @rpdemo.net
 4 - SMS... XXX-2980
 5 - Phone Call... XXX-2980
 6 - Phone Call... XXX-4210
Please select a mechanism [1]:       

E-mail

emailmfa.png

 

 

Device enrollment for Push MFA with Centrify's Mobile Authenticator

Push MFA enhances the experience and provides more meaningful information.  This requires that the current policy allows the user to enroll an Android or iOS device. 

pushmfa.png

OATH OTP (Google Authenticator, FreeOTP, Yubico Authenticator, Duo and more)

OATH OTP opens more possibilities with this open standard.  Users are easy to onboard, and there are a variety of Authenticators that can be used.
oath-google.png

 

Enhancements

For those using Centrify Standard Edition with classic zones or workstation mode, you can use GPOs to manage the settings (or DevOps tools)
gpo- mfa.png

Centrify has also enhanced the documentation available for solutions like SecurID.  Check out the Documentation Center.

 

Video Playlist

Managing Local unix accounts (in /etc/passwd) in Server Suite 2016

By Centrify Advisor I on ‎03-29-2016 10:32 AM - last edited ‎03-30-2016 04:18 PM

The release of CSS2016 has brought a lot of cool new features many have been talking about on these forums.    One of the best features engineered into our product this release allows for unix administrators to manage local/system/service accounts through DirectManage Access Manager.

 

Let us level set for a moment.  Sure, Server Suite has always been able to provide authentication and authorization (sudo replacement with dzdo) from Active Directory down to the unix nodes.  But that type of AD bridging didn't work well for any accounts used by an application or process that wasn't compiled to read the PAM stack.  In other words, the unix account needed to exist in /etc/passwd in order for the application to work.  This added a level of unix administration to manage these accounts locally on every server, including uid/gid management, password management and potentially privilege management through sudoers.

 

Centrify Server Suite 2016 will now allow unix administrators to truly manage those local accounts through Access Manager.  Let me show you how this is accomplished.

 

You will need to have 2016 version of DirectControl Access Manager installed on a Windows target and you will need to upgrade your unix clients to the 2016 version to take advantage of this new feature.

 

When you open the Access Manager console and expand on the 'UNIX Data' tree, you will see a few new sections labelled 'Local Users' and 'Local Groups'.

 

Screen Shot 2016-03-29 at 10.02.39 AM.png

 

Right-Click 'Local Users' to 'Add User to Zone'

 

Screen Shot 2016-03-29 at 10.15.37 AM.png

 

Provide the Unix User name:

 

Screen Shot 2016-03-29 at 10.17.15 AM.png

 

Then fill in the Unix user profile:

 

Screen Shot 2016-03-29 at 11.32.06 AM.png

 

 

Two options at the bottom are also new.  First, local users that are 'Assign local listed role to make this user visible' option will be visible in Access Manager.

 

Second, the 'State' of the local account is import.  Here we see three options

 

Enable: If the user profile is complete, the local user will be

 

Screen Shot 2016-03-29 at 10.18.46 AM.png

 

Once you have completed the local user set, you can wait for replication and refresh on the unix server, or you can run 'adflush' to see your results:

 

Screen Shot 2016-03-29 at 11.09.01 AM.png

 

From here, you could consider adding privilege rights for the local unix account you just created through DirectAuthorize. You could also add AD account credentials by mapping the local unix account back to AD through the Users tab under UNIX Data.  The AD password could then be vaulted and accessible through our CPS tools.

 

Finally, if you consider managing these local unix accounts at the Zone level, you gain the ability to centrally manage the account, taking away the mundane and menial task of managing local unix accounts server by server.

During the process of coaching prospects, customers and new employees with Centrify Server Suite there's a lot of information in different places, including the documentation and the man pages. Our pubs team does a great job maintaining those documents.

 

Just recently, with the release of Suite 2016 Centrify published all the documents in a single zip file, that includes all the man pages for Centrify commands.  Over the years I've maintained my own cheat-sheet and I figured that many community users can benefit from it.  This was asked by one of our posters not so long ago.

 

Enjoy and I'll try to keep it relevant.

Read more...

A Better Way to Sudo – Part 1

By Centrify Contributor II ‎12-31-2015 10:30 AM

Part 1 - Using Sudoers to understand DirectAuthorize

In this first installment of the "A better way to sudo" series we’ll discuss the key gaps in “native” sudoers we hear from customers and why you should consider taking advantage of DirectAuthorize. Next, we’ll compare how how UNIX users interact in the UNIX environment through “dzdo” (Centrify’s enhanced implementation of sudo).  And then we'll use sudoers as a frame-of-reference to introduce the DirectAuthorize policy model.

Read more...

Walk-through of procedures for joining *NIX systems to a domain, using Centrify - part 2

By Centrify Contributor II on ‎12-31-2015 08:22 AM - last edited ‎01-04-2016 10:25 AM

In part 1 of this series, we've looked at the various methods available to join a system to Active Directory in one go. In the second and final instalment of the article series, the security implications are discussed, the available alternatives, and the additional benefits that these alternative join procedures bring to the table.

Read more...

Showing results for 
Search instead for 
Do you mean 
Labels
Leaderboard

Community Control Panel