Showing posts with label unix. Show all posts
Showing posts with label unix. Show all posts

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.

Wednesday, June 8, 2016

Labs: Setting-up Step-up and MFA for Centrify Express for UNIX/Linux

Background

Note:  In this rare occasion I will discuss a capability related to Centrify Express.  This product is limited to a number of systems and Centrify has added additional capabilities that enhance the value of the solution. 

Last month, with the release of Centrify 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.  In addition, Centrify added MFA login support for Auto Zone.  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 on login. 

This quick 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: 
  • 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 Multi-factor at login?
    c) What users will have the rights to log in without multi-factor or for troubleshooting purposes?
  • IT/AD Infrastructure lead:   This SME will help setting up a Windows Server to act as the cloud connector
Technical Requirements
  • Active Directory
  • A supported Centrify Express OS with Centrify DirectControl 5.3.1
  • A Centrify Identity Service tenant  (you can sign-up for a trial here) with a Cloud Connector
    Cloud 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 Cloud Connector set up with the AD Bridge enabled.
To learn how to set up a cloud connector you can always review the Getting Started guide.
First, we will enable MFA using information from a user in AD (e-mail, mobile phone, phone), then we will walkt 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 Cloud Connector
Cloud connector configuration steps are outlined here. However, the steps are as follows:
  1. In Cloud Manager, navigate to Settings > Network > Cloud Connectors
  2. Click the "Add Cloud Cloud Connector"
    register cc.png
  3. Download the bits and run setup.  All you need is the cloud connector componetn.
  4. You have to authorize the Cloud Connector following the steps on the wizard.  Refer to the link below for a video detailed steps.
Configuring your Centrify Identity Service tenant for Server MFA
There are 4 tasks to configure MFA for Servers in the Cloud Manager 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 multifactor authentication.
    Cloud Manager > Roles > New Role > [Rights and Members]

    mfa role.png
  2. Authentication Profile
    Create an authentication profile that specifies the MFA methods to be used.
    Cloud Manager > 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).
    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
    Cloud Manager > 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 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)

After these changes, save your work and restart the centrifydc service.

Use adcdiag to check your work:

$  sudo /usr/share/centrifydc/bin/adcdiag
VERSION   : Verify that DirectControl version supports MFA               : Pass
JOINSTATE : Verify that DirectControl is in connected mode               : Pass
ZONECHK   : Verify that MFA is supported in the zone                     : Pass
SSHDCFG   : Verify that SSHD enables ChallengeResponseAuthentication     : Warning
          : Can not read sshd configuration file. Probably you are not
          : using Centrify openssh. SSH login for MFA users will fail
          : if option ChallengeResponseAuthentication is not set to
          : yes.
          : Please check and ensure ChallengeResponseAuthentication is
          : set to yes in sshd configuration file.
CDCCFG    : Verify that MFA options in centrifydc.conf are correct       : Pass
CLDINST   : Verify that trusted cloud instance is specified              : Pass
CNTRCFG   : Verify that cloud connectors are configured correctly        : Pass
CURCNTR   : Verify that DirectControl has selected a workable cloud
          : connector                                                    : Pass
CLOUDROLE : Verify that this machine has permissions to perform Centrify
          : cloud authentication                                         : Pass
AUTHPROF  : Verify that authentication profiles for Server Suite have
          : been specified.                                              : Pass
MFA checking passed with warnings. MFA still works on this server. We recommend 
checking the warnings before proceeding.

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

E-mail method
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

Monday, May 30, 2016

Centrify Suite 2016.1 Highlights

Last week Centrify made available the mid-year release (2016.1) that comes packed with new capabilities.

Given that the PCI DSS 3.2 focuses stresses multi-factor authentication Centrify is gearing-up to help organizations that are looking to align with it this fall both with their legacy solutions (e.g. RSA SecurID) and modern methods.

Multi-factor Authentication Extended
  • Centrify MFA with DirectAuthorize is now extended to HP-UX, AIX and Solaris  (this completes the UNIX/Linux ecosystem).
  • DirectAuthorize for Windows introduces MFA on Windows privilege elevation
  • Updated whitepaper RSA SecurID MFA integration that includes now server access and privilege elevation (instead of just PAM stacking).  QA'd with RSA 7.1 on AIX (5.3, 6.1, 7.1), HP-UX 11i v2/v3, RHEL (4.8, 5.8, 6.2), SUSE 11SP2, Solaris 11 & 10.
    Note that this is for non-GUI login and Centrify-enhanced sudo (dzdo)
  • OATH OTP (e.g. Google Authenticator, Yubico Authenticator, FreeOTP, Duo, etc.) is now usable via Centrify MFA with Identity Service.
  • Parameter-based MFA controls for supporting Centrify Auto Zone and Classic Zones.
  • The adcdiag command line tool was introduced to provide pre-flight checks for MFA setup.
  • Enhancements to PowerShell commands for provisioning of MFA fields.
OATH OTP support opens more possibilities with Google Authenticator or YubiKey
adcdiag should provide the same value to MFA implementations as adcheck does for AD joins.
Centrify auto zone other legacy modes get multi-factor at login and can be configured via GPOs


Microsoft AD, Kerberos, Certificates and Smart Card
  • AD Cross-forest authentication with alternate UPN is now supported
  • Support for Microsoft's  "Define host name-to-Kerberos host mapping" GPO
    Ref: https://support.microsoft.com/en-us/kb/947706 
  • Certificate Management and auto-enrollment now supports Elliptic Curve Algorithms.
  • Centrify Hierarchical Zones now support the sourcing of UNIX identity from pre-existing RFC2307 attributes.  This can simplify provisioning for organizations that use those fields.

UNIX/Linux Client and Utilities Enhancements
  • The NIS Proxy (adnisd) now has it's own watchdog process.
  • Enhanced argument checking for dzdo (Centrify-enhanced sudo)
  • New Events documented when MFA challenges fail or succeed
  • Centrify-enhanced OpenSSH is now based on OpenSSH 7.2p2
  • OpenSSL is based on 1.0.2g
  • Centrify LDAP Proxy now supports TLS 1.2
  • libcurl is based on 7.44.0
  • PuTTY is upgraded to version 0.64
  • A new command "adcdiag" has been added to troubleshoot MFA
  • A new command "adobjectrefresh" has been added to only refresh specific users or groups instead of the whole cache.
  • Parameter and utility enhancements to support Hortonworks Hadoop Ambari 2.1.2
adobjectrefresh will be a great addition for Centrify administrators
Added Platforms
  • AIX 7.2
  • Latest version of Amazon Linux AMI (x86, x86_64)
  • CentOS 7.2 (x86_64)
  • Debian Linux 7.10, 8.3, 8.4 (x86, x86_64)
  • Oracle Enterprise Linux 7.2 (x86_64)
  • Scientific Linux 7.2 (x86_64)
  • openSUSE 42.1 (x86_64)
  • SUSE 12 SP1 (x86_64)
  • Scientific Linux 7.2 (x86_64)
  • Ubuntu 16.04 LTS (x86, x86_64)
  • Windows 10 (App and network rights)

Removed Platforms
  • Debian Linux 6
  • Fedora 20
  • HPUX 11.11, 11.23
  • Oracle Solaris 9
  • Ubuntu 14.10
  • OS X 10.9
Windows Client Enhancements
  • MFA Challenge on Applications or Desktop launches
  • Audit Trail Events for MFA Challenges


Mac Platform Enhancements

  • Simplified setup
    There's no need to download DirectManage components.  Centrify has released a new "Mac Console" that contains the Centrify ADUC extension, GPOE and License Manager in a small (100 MB) bundle (contrast with 1.6GB for DirectManage).

Wednesday, May 4, 2016

[Labs] Centrify+AD+Yubikey - Implement Strong Authentication for UNIX/Linux using Smart Card

Background
This is the the second lab in the series around Strong Authentication.  In the previous lab we focused on StrongAuth for Windows access and privilege elevation with YubiKey.
We will be focusing on UNIX/Linux system access leveraging strong authentication to Windows (or Mac) systems via smart card or YubiKey.  Centrify Server suite allows definitions of roles that only allow non-password authentication to be enforced.   YubiKeys are full-fledged personal identity verification (PIV) cards that work very well with AD and Certificate Services.

The challenges
  • Recent advanced threats leverage the collection of passwords and poor security practices to exploit systems.
  • The variability (heterogeneity) of systems (Windows, UNIX, Linux, Macs) poses a big challenge for organizations
  • The proliferation of "best of breed" solutions promotes IT fragmentation and limits organizational flexibility.
  • The "jumpbox" or proxy approach combined with additional controls like workflow can help as long as connections are centralized, however many organizations are getting audit comments due to circunvention of these mechanisms.
  • Although there are different multifactor providers in the market and most of them provide Pluggable Authentication Modules for their solutions, the implementation requires a high-degree of expertise and translating the capability to hundreds or thousands of servers with heterogeneous OSs can be quite complex.
The opportunity
Although Centrify can accommodate the "jump box and shared account" model using Centrify Privilege Service, organizations should complement their security strategy with the least access model:
  • Users shall only access the systems they need to based on business need-to-know with strong authentication
  • Users shall be limited to the minimum privileges required for their functions:  this is accomplished by providing users roles with the rights that they need.
  • Rights shall be assigned and limited to the business function with a privilege elevation mechanism (e.g. sudo) that has the flexibility to provide strong authentication.
  • In sensitive systems, access and privilege elevation shall be supplemented with session capture and replay.
  • Active Directory and Centrify provide a stack that can secure systems and eliminates complexity across the different UNIX/Linux platforms
Lab Goals
  • Limit privileged users to a subset of UNIX/Linux systems based on their needs (AD and Centrify Zones enable this)
  • Require strong authentication for local or remote (SSH) access  (this is enabled by Centrify DirectAuthorize)
  • Require strong authentication on privilege elevation if needed (OTP, SMS, E-mail, phonefactor, etc)
  • Reproduce privileged sessions (session capture, transcription, replay).
What you'll need
  • Active Directory with Certificate Services
  • A domain joined member server with Centrify Server Suite 2016 (DirectControl) a
  • One or two UNIX/Linux systems with Centrify DirectControl and Centrify-Enhanced OpenSSH
    Because we will be relying on SSO, Centrify OpenSSH comes compiled with Centrify methods that simplify the process in simple and complex AD environments.
  • For SSO to work, the system has to be resolvable by name (shortname or FQDN) by the Kerberized clients.
  • SSH client that supports SSO; e.g. stock PuTTY (GSSAPI) or Centrify-enhanced (Kerberos)
  • Access to Centrify Standard Edition (evaluation or licensed)
  • Yubikey PIV Manager  (download link)
  • Yubikey 4, NANO or NEO
  • You need working knowledge of Active Directory and Centrify Zones
 Tip:  To set up a base configuration, you can build on the Microsoft Test Lab Guide or use the Announcement Post.

Scenario Description: 
We will use the Yubikey/Smart Card with the Certificate provisioned to the user in the base lab.  With Centrify Access Manager, we will create a role that allows her to access a system (locally and via SSH) and we will prove:
  • That the user can only log in to her Windows station with her Smart Card
  • That the user cannot sign-in to UNIX/Linux system locally or remotely (via SSH) with a password
  • That the user is only allowed to log in remotely via SSH to UNIX/Linux systems  via SSO (Kerberos or GSSAPI)
  • That these rights can be assigned to groups of systems, or groups of users in a temporary or permanent basis
  • Minimal to zero configuration at the system level.  Once the system is joined to AD, the security measures should just work.
Note:  We will not focus on privilege elevation.  We have covered this exhaustively, including with MFA/2FA in previous labs.
yubikey-nix-scenario.png

Centrify Setup
In this instance we are setting up a Web Admin role that contains the pre-defined "login-all" PAM right.  We are not breaking down the rights to prove that we can stop the user from logging in via console or via SSH with a password.
The privileged user assigned the role must have authenticated with her YubiKey or SmartCard to obtain a Kerberos TGT from Active Directory, subsequently, Centrify DirectAuthorize will be in charge of denying access to the user if they don't use SSO for access (via Kerberos or GSSAPI).  All we're going to need is a zone and a role.

To set up using PowerShell

Import-Module ActiveDirectory
Import-Module Centrify.DirectControl.PowerShell

$user = Get-ADUser -Identity Maggie.Simpson  # substitute for your test user
$cont = "cn=zones,ou=unix,dc=centrify,dc=vms"  # substitute for your container DN
$zone = New-CdmZone -Name "Yubikey-Demo" -Container $cont

$cmd1 = New-CdmCommandRight -Zone $zone -Name "Edit http config file" -Pattern "vi /etc/httpd/conf/httpd.conf" -Authentication none
$cmd2 = New-CdmCommandRight -Zone $zone -Name "Httpd service control" -Pattern "service httpd*" 
$cmd3 = Get-CdmPamRight -Zone $zone -Name "login-all"

$role = New-CdmRole -Zone $zone -Name "UNIX Webadmin - StrongAuth" -UnixSysRights ssologin, nondzsh, visible

Add-CdmCommandRight -Right $cmd1 –Role $role 
Add-CdmCommandRight -Right $cmd2 –Role $role 
Add-CdmPamRight  -Right $cmd3 –Role $role 

New-CdmUserProfile -Zone $zone –User $user –login $user.SamAccountName -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
New-CdmRoleAssignment -Zone $zone -Role $role -TrusteeType ADUser -ADTrustee $user | Out-Null


To perform the steps for the script above manually
Create, Configure and Assign the Demo role
 In Access Manager > Open they Yubikey-Demo zone > Authorization > Right Click Role Definitions > Select Add Role
  1. Name:  UNIX WebAdmin - StrongAuth
    System Rights:
    - Non-password (SSO) login is allowed  (checked)
    - Login with non-Restricted shell (checked)
    Access Manager - role Strong Auth.png
  2. Create two UNIX commands.  
    Since this will be our "Web Admin" we'll allow the role to manipulate the httpd daemon and edit the config file for the Apache server.  The commands are:
    Glob expression vi /etc/httpd/conf/httpd.conf from the standard user path /usr/bin no reauthentication required.
    Glob expression service httpd* from the standard user system path /usr/sbin no reauthentication required.
    Access Manager - role command.png
  3. Add the rights to the role.  Right click the "UNIX WebAdmin - StrongAuth"  role and select "Add Right"
    Access Manager - role command.png
  4. The role is ready to be assigned.  Now press OK and right-click the Authorization > Role Assignments > Select Assign Role
  5. Press the Add AD account > type the name of your test user, select it and press OK.
    Access Manager - assigned.png
    Note: This is a permanent direct assignment to a user principal at the zone level.  This is not the best practice, typically you grant role assignments temporarily (for attestation), in a subset of systems and to AD groups for better administration.
 Install DirectControl and join the system to the Centrify Zone
  1. Use your preferred software distribution method to copy the Centrify software
    In my case I already have a local repo for RHEL and derivatives.  (Read how to set up here)
  2. Log in to your UNIX/Linux system and use your favorite package manager to install Centrify DirectControl and Centrify-enhanced OpenSSH

    $ sudo yum install CentrifyDC CentrifyDC-openssh
    [truncated]
    Installed:
      CentrifyDC.x86_64 0:5.3.0-213   CentrifyDC-openssh.x86_64 0:7.1p1-5.3.0.208
    Complete!
    
    
  3. Now Join the Centrify zone and you'll be ready for testing.  Use the adjoin command and an authorized user:

    $ sudo adjoin -z Yubikey-Demo -c "ou=servers,ou=unix" -u dwirth centrify.vms
    [sudo] password for centrifying:
    dwirth@CENTRIFY.VMS's password:
    Using domain controller: dc.centrify.vms writable=true
    Join to domain:centrify.vms, zone:Yubikey-Demo successful
    
    Centrify DirectControl started.
    [truncated]
    
    
  4. If your system was not resolvable by Windows DNS, you can use the addns command to register automatically with dynamic updates (if your DNS zone allows):
    $ sudo /usr/sbin/addns --update --machine
    Updating both HOST and PTR record for: centos67.centrify.vms
    Deleting old reverse lookup records for centos67.centrify.vms on 192.168.81.10.
    No old reverse records deleted because no host records found for centos67.centrify.vms on 192.168.81.10.
    
    
  5. Verify that your users are correctly UNIX-enabled and with the expected rights (use adquery user and dzinfo)
    $ adquery user maggie.simpson
    maggie.simpson:x:1040191002:1040191002:Maggie Simpson:/home/maggie.simpson:/bin/bash
    
    $ sudo  dzinfo maggie.simpson --roles
    User: maggie.simpson
    Forced into restricted environment: No
    Centrify Cloud Authentication: Supported
    
      Role Name        Avail Restricted Env
      ---------------  ----- --------------
      UNIX Webadmin -  Yes   None
      StrongAuth/Yubi
      key-Demo
    
        Effective rights:
            Non password login
            Allow normal shell
            Visible
    
        Centrify Cloud Authentication:
            Not Required
    
        Audit level:
            AuditIfPossible
    
        Always permit login:
            false
    

    All set on the Centrify side.
Configure your Test user for Smart Card Authentication
  1. In ADUC, find and double-click the test user.
  2. Account Tab > Account Options > Check the box for "Smart Card is required for interactive logon"
    yubikey-win-user-sm.png
  3. Press OK. You are ready to start testing.

Test Plan:
  1. Try to access the system with any other AD user than test user - expected result:  Access Denied
    This is because users need to be explicitly be granted access a UNIX identity and a Centrify role in the zone for the computer.
    login as: dwirth
    -----------------------------------------------------------------
    CENTRIFY DEMO -
    -----------------------------------------------------------------
    WARNING: This is a PRIVATE system exclusively for Centrify demos
    Your actions will be monitored and recorded.
    -----------------------------------------------------------------
    Using keyboard-interactive authentication.
    Password:
    Access denied
    Using keyboard-interactive authentication.

  2. Try to access the system with your test user (Maggie) with her password (Console or SSH) - expected result:  Access Denied
    This is because the test user was defined with "Smart card required for interactive logon"
    login as: maggie.simpson
    -----------------------------------------------------------------
    CENTRIFY DEMO -
    -----------------------------------------------------------------
    WARNING: This is a PRIVATE system exclusively for Centrify demos
    Your actions will be monitored and recorded.
    -----------------------------------------------------------------
    Using keyboard-interactive authentication.
    Demo Password:
    Using keyboard-interactive authentication.
    Account cannot be accessed at this time.
    Please contact your system administrator.
    
    
  3. Log in to Windows system (you are forced to smartcard login) - Launch PuTTY (configured for SSO)
    Expected result:  Access Granted
    Yubikey UnIX - success.png
 Video

Other Considerations:
  • When forcing strong authentication, you must have a plan for other shared non-human accounts.  This is where Centrify Privilege Service shines.
  • Don't underestimate the need for good process around the lifecycle of PKI and smart cards.  PKI is serious business.

Thursday, April 7, 2016

Using Centrify+Microsoft PKI+Yubikeys to enforce Strong Authentication for UNIX/Linux/Windows Elevation and more....

Announcing a new series!!!

I'll be focusing on Strong Authentication using Smart Card.  Recently got a hold of some Yubikeys. Yubikeys make the process of implementing strong authentication much easier.

Historically Centrify has supported PKI authentication for years and you'll be able to see how easy this is to set up.

The first scenario focuses on Servers:

css-yubi-scenario.png
Strong Authentication (PKI)
  • Leverage what you have:  Active Directory, Microsoft CA, Group Policies
  • Enforcing Smart Card access to UNIX/Linux/Mac systems  (Windows systems support this natively)
  • Use DirectAuthorize roles to limit access to strongly authenticated sessions
Strong Authentication for Windows Privilege Elevation
  • Applications
  • Desktops
We already covered Access and Privilege Elevation For UNIX/Linux using Centrify MFA here:

css-yubi-scenario2.png
Strong Authentication (Smartcard/Yubikey) & OATH OTP access
  • IdP Portal Access
  • OnPrem or SaaS Application Access
  • Privilege Portal Access
  • Privilege Password Manager  (Shared Account Password Manager)
  • Privilege Session Manager (Jump Box)
Here's a quick overview/demo
Stay tuned!

Wednesday, February 3, 2016

[LABS] Testing MFA for Servers (Step-up Authentication) feature of Centrify Suite 2016

Background

Step-up authentication can provide additional security controls to prevent unauthorized access to systems or controlled privileged elevation.  Server Suite 2016 uses the established step-up authentication methods of Centrify Identity Service (Token via Centrify Mobile Authenticator, SMS, Phone factor, E-Mail and User-defined security question); the key differentiators are the combination of Role-Based Access Control (RBAC) with step-up authentication and context awareness (time/access/privilege).

To complete this lab you need:
  • Familiarity with Centrify Server Suite consoles:  Access Manager
  • Familiarity with Centrify RBAC concepts:  hierarchical zones, role definitions, role assignments
  • Familiarity with Active Directory and tools:  AD users, security groups, Active Directory Users and Comuters
  • Familiarity with TCP/IP:  ports, protocols
You don't need to be familiar with Centrify Identity Service.  We will outline the set-up steps for this configuration.

Planning

Potential Stakeholders
  • Centrify SME:  These users are entitled to perform management of zone operations inside Active Directory.
  • Security Lead:  The security lead can answer questions like these:
    a) What servers require step-up authentication for login?
    b) What privileged actions require step-up authentication?
    c) What servers require step-up authentication based on day/time?
  • IT/AD Infrastructure lead:   This SME will help setting up a Windows Server to act as the cloud connector
Technical Requirements
Active Directory and Centrify
  • A licensed or evaluation copy of Centrify Suite 2016
  • An Active Directory test or production environment with Centrify a Centrify Hierarchical zone
  • A UNIX/Linux system with Centrify DirectControl 5.3+
  • A Centrify Identity Service tenant with at least one Cloud Connector acting as an Active Directory bridge
  • For step-up methods (user-defined security question can be used if none below are available):
    a) an iOS or Android device for token testing (optional)
    b) a mobile phone to test SMS
    c) an e-mail account
    d) a phone line for phone factor
Software as a Service (Cloud) - Quick Security/Assurance FAQ
  1. What is Centrify Identity Service (CIS)?
    CIS is an Identity as a Service (IDaaS) that provides Identity, Single Sign-On, Mobility Management, Policy and Multifactor Authentication among other capabilities. The service is "connector-based";  this means that there's a server running on premises that communicates with the service.  This is a very common architecture used by solutions like ServiceNOW or Office365.
  2. Why is a SaaS solution required to provide multi-factor authentication?
    The answer boils down to time-to-production, cost and efficiencies of a software as a service solution versus the overhead of an on-premises alternative.  Centrify is re-using their existing Identity Platform and extending it to Server Suite.
  3. What are the mechanisms that Centrify implements to provide assurance for confidentiality?
    Each tenant gets their own key and PKI Certificate Authority, this provides the assurance that:
    a) only the tenant owner can decrypt traffic that has been encrypted at rest or in transit
    b) the cloud connector will repudiate connections from any other source
    c) an additional layer of encryption is provided in addition to SSL
    The cloud service and the cloud connector must be authorized by two parties:  the tenant admin and an AD admin.
  4. What are the mechanisms that Centrify implements to provide high-availability?
    a) CIS runs on top of Microsoft Azure.  Azure provides hardware, datacenter, nearby datacenter and geographical datacenter redundancies.
    b) Centrify implements mechanisms that guarantee that upgrades don't cause downtime
    c) Cloud Connectors are constantly monitored for health and failover is automatic
    d) In the context of Server MFA, the tokens and SMS contain a code that can be used asynchronously
    e) In the context of Server MFA, roles with rescue rights are available;  this allows the bypassing of MFA in case of a disaster.
  5. Are the Cloud Connector public facing or in the DMZ?
    No.  Cloud connectors aren't required to be public facing or in your DMZ; they can be inside your private network and even can work behind a proxy server.  The cloud connectors will establish an outbound HTTPS connection.  The documentation explains target sources and destinations.
  6. Is outbound Internet access required for systems that use the MFA for servers feature?
    No.  The systems only need to talk to the on-premise cloud connector in a mutually authenticated, encrypted and configurable port, in turn the cloud connector validates if the systems are authorized for MFA and acts as a broker with our Identity Platform.
  7. What other assurance mechanisms are provided by Centrify for their Cloud Solutions?
    Certifications:  SOCII, SafeHarbor, TrustE.  Centrify is working on FedRAMP certification attainment.
  8. Where can I find more information?
    For more information:  http://www.centrify.com/support/centrify-trust/trust/
Resources


How MFA for Servers Works

Components:
Active Directory
  • Centrify Zones contain:
    - Identity data in the form of UNIX RFC2307 fields for provisioned users and groups
    - Authorization (DirectAuthorize) information:  definitions of roles and attributes, rights (commands) and role assignments.
    - Information about the Centrify Identity Service tenant if there's a registered cloud connector in AD
  • Roles can have two MFA-relevant attributes:  "require multifactor authentication" and "rescue rights";  if the first one is checked, users will be prompted to provide step-up authentication to access the system;  if the second one is checked (just like with DirectAudit) all the additional security controls will be bypassed.
  • UNIX commands that have the "require multifactor authentication"  this will prompt the user to provide their password and a step-up authentication method on privilege elevation.
  • Test AD users:  The test AD users need to be UNIX-enabled and have populated attributes like email, telephone or mobile number if email, phone factor or SMS will be requested.
Centrify Server Suite
  • These are DirectControl agents 5.3+ joined to a hierarchical zone.  These systems don't need outbound connectivity to the internet.
  • The AD computer objects need to be authorized to talk to the cloud service (via role) and they should be allowed to communicate to the cloud connector using HTTPS in the web service port (8080 is the default). 
Centrify Identity Service
  • MFA Computers Role:  This role contains the systems authorized to request MFA.  This can be individual computers or AD groups that contain the AD computer objects.  They must have the Server Login and Privilege elevation right.
  • Server Authentication and Privilege Elevation Authentication Profiles:  You can define what step-up methods are available and even if there's additional mechanisms to be used.
  • Policy:  A policy that applies to the MFA Computers role needs to be implemented.  This method should allow for Integrated Windows Authentication via Kerberos for machine-to-machine authentication
Cloud Connector
  • This is a Windows system that runs the adproxy service.  The cloud connector only requires an outbound HTTPS connection to talk to the Centrify Identity Service tenant. 
  • Web Service: The cloud connector authenticates authorized agents using Integrated Windows Authentication (SPNEGO)
 The illustration below provides an oversimplified set of steps:
MFA - concept.PNG
Note that in case of AD connectivity failure, the centrify agent will use the AD methods (sites/services, offline cache) and it also caches the authorization data.

A Basic Lab Design

In my test environment I have:
MFA - my lab.png
Description
  1. A Centrify Identity Service tenant App Edition (or 30-day trial)
  2. An Active Directory domain (centrify.vms) with a single domain controller (dc.centrify.vms)
  3. A domain-joined server called "member" that has Access Manager installed (Suite 2016 commercial or evaluation)
    Member will also be running the Centrify Cloud Connectors
  4. A Centrify zone called global with 2 computer roles:  App Servers and Web Servers
  5. Two Linux servers.  The names may be slightly different given that I have labs in different stages.
  6. A mobile device with a phone line running iOS or Android.

Test Cases

Test Name
What you need
Comments
Step-up on Privilege Elevation
You need a UNIX command with the “Require Multi-factor authentication” flag set.

Ideally you will start with privilege elevation, that way you can do troubleshooting if needed.
 Test with two users with the same role, one with password, the other one with password and MFA required.
Step-up on Server Access Elevation
You need a role with the “Require Multifactor Authentication” flag set.
If using SSH for testing, be mindful of SSH timeouts.  You can extend timeouts for your testing or enroll a device so you have push MFA.
Time Context-aware privilege elevation
You’ll need two roles, one without MFA time-bound for business hours, the other one with MFA for after hours
This is an excellent use case because reflects a real-world scenario.  A variation of this test case can be No MFA on QA/Dev and MFA on Prod systems.  You can leverage Computer roles for this.
Privilege Elevation without AD connectivity
This test relies in the agent’s caching capabilities.
This is a disaster recovery use case.
Privilege Elevation with out-of-band method
You need an enrolled mobile device to access the mobile authenticator (or you can type the code delivered with an SMS)
In cases in which you can’t receive a phone call or SMS, you need the code to provide step-up auth (e.g. like token based solutions)
Disaster Scenario.  There are no cloud connectors, the CCs can’t talk to the Centrify Service or MS Azure/Centrify Service is down
You’ll need a role with the “Rescue Rights” checkbox set.
This should be familiar to DirectAudit testers;  Rescue rights are granted to overcome an issue with the Centrify functionality (Audit or MFA)


Implementation

Download and Install the Centrify Suite 2016 bits
  1. Download the Standard Edition 2016 Consoles
  2. Download the Centrify client bits for your platform
  3. Install Access Manager
  4. Install or upgrade your agents  (e.g. install.sh, rpm or yum, apt or dpkg, etc)
  5. Join a zone (use adjoin)
I will recycle the pre-requisites video for the local account management since the steps are identical:

Obtain and Configure a Centrify Identity Service Tenant
  1. To obtain your Tenant
    Follow the steps here:  http://www.centrify.com/free-trial/identity-service-form/
    Follow the steps until you activate your tenant and log in with the cloud admin account for the tenant.  You have to secure those credentials.
  2. Set up a Cloud Connector (Settings > Cloud Connectors)
    You can see steps here (download-install-configure-authorize).  Other than the "next-next" steps here what needs to be understood is what is the Cloud Connector doing.  The Centrify cloud connector service runs on Windows and provides AD bridging.
    a) The CC talks to the cloud service on behalf of your servers; uses PKI for trust and non-repudiation.
    b) The CC makes outbound connections  over HTTPS that are double-encrypted (SSL + tenant key)
    c) it has to be authorized to read objects from the AD domain by a privileged AD administrator
    d) The CC needs to authenticate the systems (or group of systems) that will use step-up using SPNEGO over 8080 (default)
    Note that if your're working in an isolated lab, this port has to be open between your Linux systems and the CC.
    e) The CC will provide information to the cloud service about email, phone numbers, etc so the user can get the step-up challenge
    f) For MFA testing, you can disable all other capabilities of the CC (like LDAP bridging and App gateway) to keep configuration to a minimum.
    cloud - cc service properties.PNGcloud - cc service dis.PNG
  3. Configure Authentication Profiles (Cloud Manager > Settings > Authentication Profiles)
    You need to set up authentication profiles for both Server Access and Privilege elevation.  For this go to .  Here's what I set up for Server Access:
    cloud - authprof.PNG
    What to use for Step-up:  You'll need to use your security savvy here.  The goal is to provide an additional control in case of password compromise.  You would not use email in this case because in an Exchange scenario, the password is the same for the AD user so if a threat agent compromised the user's password, they likely have access to his email.  The best course of action is something the user has like a token or his phone.  That's why I only checked those options.
  4. Set the Server Suite Authentication Profiles (Cloud Manager > Settings > Server Suite Authentication)
    Set the APs for Server Access and Privilege Elevation
    cloud - CSS authpro.PNG
  5. Create a Role that Contains your Linux Systems (Cloud Manager > Roles)
    In my case, I created an "MFA Computers" cloud role and as members I added an "MFA Computers" AD group that in turn contains my Linux systems.  This simplifies administration because if I want more Linux systems enforcing MFA, all I need to do is upgrade them to 5.3 and add them to that AD group.
    cloud - role mfa computers.png
  6. Policy Applied to MFA Computer with IWA  (Cloud Manager > Policies)
    We need to verify that Integrated Windows Authentication is allowed for the User Policy that applies to this role.  This will allow the servers to use Kerberos to authenticate to the web service on the cloud connector.  This is under Policy (e.g. Default Policy) > User Security Policies > Login Authentication
    cloud - policy iwa fma.PNG
    Ideally, to isolate MFA testing, you will create a new Policy that applies just to the MFA computers role and you stack it higher than your deny-all policy.
    cloud - policy iwa applied.PNG
Configure Access Manager for Centrify Identity Service Tenant
  1. Open Access Manager and open your Zone. 
  2. Right-click the zone and select properties, click on the Cloud tab and click Browse
    There is now a selectable cloud instance.  This is because of the cloud connector registration.
  3. Select and press OK twice.  Now you can test end-to-end connectivity using the Test Cloud Connection tool
    access manager - cloud testing.PNG
    You have to right-click the "DirectManage Access Manager" node to expose the tool.
Verify that your Centrified Linux system is Cloud Connector-aware
You need to refresh the cache and restart the agent to reflect the AD group membership that will allow the system to interact with the cloud connector.
  1. Sign in to your system (with a user that can elevate)
  2. Run adflush --force
  3. Restart the CentrifyDC service (service centrifydc restart)
  4. Run the 'adinfo --sysinfo' cloud command to verify cloud connector awareness.

$ adflush --force
DNS cache flushed successfully.
Authorization cache store flushed successfully.
GC and DC caches flushed successfully.
$ service centrifydc restart
Stopping Centrify DirectControl:                           [  OK  ]
Starting Centrify DirectControl:                           [  OK  ]
adclient state is: connected
$ adinfo --sysinfo cloud
System Diagnostic
==============Cloud/Connectors info============
Cloud instances:
   Cloud in connection: https://aaj0736.my.centrify.com:443/
   Cloud: https://aaj0736.my.centrify.com:443/
Cloud connectors:
   Current used connector: member.centrify.vms
   Cloud connectors in current site:
      Cloud connector: member.centrify.vms
        Cloud URL: https://aaj0736.my.centrify.com:443/
        Connector Site: Demo-Network
        Proxy FQDN: member.centrify.vms
        Tenant ID: AAJ0736
        Connector port: 8080
        Connector IWA HTTP port: 80
        Connector IWA HTTPS port: -
   Cloud connectors in other site:
   Cloud connectors discarded:
   Cloud connectors in current site and unused:
   Cloud connectors in other site and unused:
   Cloud connectors invalid:
==============Cloud auth token info============
CloudAuth tokens maximum: 10
Current count: 0
Current timestamp: 1454536466
Occupied tokens:

You're all set and ready to test.

Video Playlist