Tuesday, August 16, 2016

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
sourcing2.png
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.
z-defaults.png

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.
imp-wizard.png
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:
ps-scripts.png
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:
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-options.png
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
visual.PNG
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:radius-lab.png

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:
 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:
    verify-radius.png
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.
cis-radius-setup.png

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" 

cis-cc-radius.png
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.
cis-cc-authprofile.png

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.
cis-cc-authprofile.png

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)
    verifiy-radius2.png
    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

Sunday, August 7, 2016

[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.
lp-mac.png

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:
    lp-mac2.png
  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)
    lp-mac3.png
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