[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

• Centrify Administrator's Guide for Linux and UNIX
• Centrify Identity Service Documentation
• Centrify Identity Service Getting Started Guide
• Useful tools:  Test Centrify Connection applet, adinfo --sysinfo cloud

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:

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:

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

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

Centrify for UNIX/Linux/Mac Command Line Cheat Sheet

AD-bridging commands ("ad" commands)
adcheck - check OS, network and AD readiness for Centrify DirectControl

To check the system with domain (e.g. corp.contoso.com)
$ adcheck corp.contoso.com
To only perform OS checks
$ adcheck --test os
To only perform network-related tests
$ adcheck --test net corp.contoso.com
To only perform AD-related tests
$ adcheck --test ad corp.contoso.com
To check the system with a service domain controller (e.g. dc1)
$ adcheck --servername dc1 corp.contoso.com
To check connectivity only with DCs within the site
$ adcheck --siteonly corp.contoso.com
To check only on 3 (or n) DCs in a large domain
$ adcheck --bigdommain 3 corp.contoso.com
To check trust relationships (e.g. with hq.fabrikam.com)
$ adcheck --xdomain corp.contoso.com
To skip NTP checking (if you are not doing sync with AD DCs)
$ adcheck --skip-ntp corp.contoso.com


adinfo:  provides information about the status of the agent

Looking-up Basic Information
To check the general status of the client
$ adinfo
To see the current domain controller the client is using
$ adinfo --server
To see the current domain the agent is joined to
$ adinfo --domain
To see the status (mode) of the agent (connected to ad or in offline mode)
$ adinfo --mode
To see the version of the installed client
$ adinfo --version
To see the corresponding Centrify Suite Version
$ adinfo --suite-version
To view Active Directory connectivity to the current domain
$ adinfo --test
To view the current Active Directory site
$ adinfo --site
To see the current joined Centrify zone
$ adinfo --zone
$ adinfo --zonedn  (in distinguishedName format)

Advanced/Troubleshooting Information
DNS
To check for the "joined-as" name (local host name and joined as name may be different)
$ adinfo --name
To check the status of the DNS cache and stats
$ adinfo --diag dns

Connectivity
To check connectivity with an AD domain
$ adinfo --test [domain.name]
To check network connectivity statistics
$ adinfo --sysinfo neststate
To test connectivity against a specific domain controller
$ adinfo --T --servername [domain.controller.name]

Active Directory
To see the current AD Global Catalog
$ adinfo --gc
To see the domain/forest map
$ adinfo --sysinfo domain
To see the status of the AD computer trust relationship
$ adinfo --sysinfo adagent

Testing a user's password
$ adinfo -A --user [username] 
# this will prompt you for a password, the output is:
Password for user "username" is correct/incorrect

Configuration
To parse the contents of the centrify.conf file
$ adinfo --config
To show the client's in memory configuration parameters
$ adinfo --sysinfo config

Kerberos
To view Kerberos information like supported encryption types, key version and registered SPNs
$ adinfo --computer
To view the updated Kerberos configuration in the local system
$ cat /etc/krb5.conf
To list the principals in the system's krb5.conf file
$ dzdo /usr/share/centrifydc/kerberos/bin/klist -kt /etc/krb5.keytab
To determine the encryption types of the system's cached ticket
$ dzdo /usr/share/centrifydc/kerberos/bin/klist -fe /etc/krb5.ccache

PKI
adcert - centrify Microsoft PKI client

To perform auto-enrollment of Computer PKI certificates (requires elegible template and communications)
Using the computer object to authenticate
$ dzdo /usr/share/centrifydc/sbin/adcert --enroll --machine
Using a user to authenticate
$ dzo /usr/share/centrifydc/sbin/adcert --enroll --user [ADusername]


Dynamic DNS
addns - a dynamic DNS client for AD DNS or RFC 2136-compliant servers

To renew DNS using machine credentials
$ sudo addns --update --machine
To renew DNS using user credentials
$ sudo addns --update --user [ADusername]
To renew DNS only on a specific interface (e.g. eth0)
$ sudo addns --update --machine --interface eth0

Querying Centrify-enabled AD Users and Groups
adquery: provides information about Active Directory users and groups that are UNIX-enabled by Centrify

To view all Centrify UNIX-enabled users
$ adquery user
will show all AD users in Express mode / Only authorized in Zone mode
To view all Centrify UNIX-enabled groups
$ adquery groupwill show all AD groups in Express mode / Only unix-enabled in Zone mode
To view a user's entry (UNIX passwd file style)
$ adquery user [username]
To view a group entry (UNIX group filestyle)
$ adquery group [groupname]
To view only the user or group's AD group memberships
$ adquery user [user] --adgroup
To view all information about a user or group  (including AD object attributes)
$ adquery user|group [user or group] -A
To view the distinguishedName a user or group
$ adquery user|group [user or group] --dn
To view all information and include password expiration, account lockout/enabled state
$ sudo adquery user [user] -A
To view information about a computer
$ adquery user [computername]$ -A
To get results from cache (instead of fetching from AD)
$ adquery user|group [options] --cache-first

Centrify Cache Commands
adflush - clears the Centrify cache in the local computer (dc, gc, credential & dns)

To flush the authorization cache
$ dzdo adflush --auth
To rebind and force a new DC selection
$ dzdo adflush --bindings
To flush the DNS cache
$ dzdo adflush --dns
To expire the information from domain controllers and global catalogs
$ dzdo adflush --expire
To force complete removal/expiration even when disconnected (use carefully)
$ dzdo adflush --force
To refresh the krb5.conf file
$ dzdo adflush --trusts
To clear the health history
$ dzdo adflush --health
To clear the cloud connectors (in MFA scenarios)
$ dzdo adflush --connectors


Group Policy-related Commands
adgpupdate - triggers the group policy refresh interval

To refresh the GPOs in the system
$ adgpupdate
To refresh only computer GPOs
$ adgpupdate --target Computer
To refresh only user GPOs
$ adgpupdate --target User

adgpresult - to view a RSOP (resultant set of policy) to the local system or user

To view the report for computer and user
$ adgpresult
To view the report for the computer
$ adgpresult --computer
To view the report for the current
$ adgpresult --user
To view the report for a particular user
$ dzdo adgpresult --user [user.name]

Joining Active Directory
adjoin - joins an Active Directory domain

To run adjoin successfully, you need
> to be root or sudo
> to have the credentials (or the keytab) of an AD user that can join computers to a container (NOT Domain Admin)
> to know the Distinguished Name (e.g. "ou=servers,ou=unix") of the container that you will place the system in AD
> to know the domain name you're joining
> to have a clear network path to the DC or DCs you're using (dns, global catalog, kerberos, ldap, cifs, ntp).

To join AD in workstation/express mode (AD user must be able to add computers to "ou=workstations,ou=unix")
$ sudo adjoin --workstation --container "ou=workstations,ou=unix" --user [AuthorizedADUser] --verbose [domain.name]
To join AD in Self-Service mode (AD/Centrify admin pre-created the machine ahead of time using AM or Centrify PS)
$ sudo adjoin --selfserve [domain.name]
To join AD in zone mode (e.g. Global zone)
$ sudo adjoin --zone Global --container "ou=servers,ou=unix" --user [AuthorizedADUser] --verbose [domain.name]
To join AD in zone mode and don't initialize (precache)
$ sudo adjoin --noinit --zone Global --container "ou=servers,ou=unix" --user [AuthorizedADUser] --verbose [domain.name]
To join AD and trust the Computer for Delegation (must know what you're doing - security implications)
$ sudo adjoin --trust Global --container "ou=servers,ou=unix" --user [AuthorizedADUser] --verbose [domain.name]
To join AD in workstation mode and specify a workstation license
$ sudo adjoin --licensetype "workstation"--workstation --container "ou=workstations,ou=unix" --user [AuthorizedADUser] --verbose [domain.name]
To use an specific domain controller to join (e.g. dc1.hq.fabrikam.com)
$ sudo adjoin --server dc1.hq.fabrikam.com Global --container "ou=servers,ou=unix" --user [AuthorizedADUser] --verbose [domain.name]
To join a Mac in Workstation mode and instruct Centrify to use the Apple algorighm to generate UID/GID scheme
$ sudo adjoin --enableAppleIDGenScheme --container "ou=macs,ou=unix" --user [AuthorizedADUser] --verbose [domain.name]
To join AD and provide a different "AD name" than the local system name (e.g. adserver vs. localhost)
$ sudo adjoin --name adserver --container "ou=servers,ou=unix" --user [AuthorizedADUser] --verbose [domain.name]
To join AD using keytab (kinit Authorized AD user keytab first, then run adjoin without the --user option)
$ env KRB5_CONFIG=[/path/to/krb5.conf] /usr/share/centrifydc/kerberos/bin/kinit -kt /path/to/keytab [principal]
$ sudo adjoin --zone Global --container "ou=servers,ou=unix" --verbose [domain.name]

Leaving Active Directory
adleave - leaves an Active Directory domain

To run adleave succesfully, you neeed:
> sudo or root
> for online leave, authorized AD user credentials

Leave the domain and disable the computer object (orphan object left behind)
$ dzdo adleave --user [Authorized ADUsername]
Leave the domain and remove computer object (frees license)
$ dzdo adleave --user [Authorized ADUsername] --remove
Offline/forced leave (no AD connectivity required, must clean-up in AD)
$ dzdo adleave --force

Privilege Elevation ("dz" commands)
dzinfo - displays information of the user's access controls

To view self access (all)
$ dzinfo
To view the properties of the role(s), including effectiveness
$ dzinfo --roles
To view how you can access the system (PAM rights)
$ dzinfo --pam
To view the commands you can run
$ dzinfo --commands
To view the computer roles that apply to the system (requires elevation)
$ dzinfo --computer-role
To view authorization information about about another user (requires elevation)
$ dzdo dzinfo [user.name]
To test a command against the role
$ dzinfo --test [path/to/binary] [options]

Centrify-enhanced sudo
dzdo - centrify-enhanced sudo. Uses Centrify zone data in AD for commands, otherwise identical to sudo.

To view version information (as of 2015, based on sudo 1.8.10p3)
$ dzdo -V
Use man sudo or man dzdo for more.

DirectAudit Commands ("da" commands)
dainfo - shows information about the status of the audit agent

To view the audit agent status
$ dainfo
To view status with verbose output
$ dainfo --diag  (or dadiag)
To view contents of the configuration file
$ dainfo --config
To view audited status of another user (must elevate)
$ dzdo dainfo --username lisa.simpson

dacontrol - controls the status/configuration of the directaudit client (requires elevation)

To set the installation (if not set by Group Policy)
$ dzdo dacontrol --installation [installation-name]
To check if the audit agent is enabled
$ dzdo dacontrol --query
To enable direct audit
$ dzdo dacontrol --enable
To disable direct audit
$ dzdo dacontrol --disable

What happens when adjoin is run succesfully?
This activates the DirectControl agent (adclient/CentrifyDC service).
1. Creates a computer object in AD and sets SPNs for http, host, nfs, cifs, afpserver
2. Establishes a secure communication channel between the system and Active Directory
3. A forest/domain/site map is created to locate the nearest DCs
4. The Kerberos environment (krb5.conf, krb5.keytab) are maintained by Centrify (configurable).  A backup is created.
5. Network time is synchronized with AD DCs (configurable)
6. The PAM (Pluggable Authentication Modules) are modified to include Centrify auth, account, password, session modules. A back-up of the previous configuration is made.
7. The NSS (Name Service Switch) providers for users and groups defaults to AD first, then other methods (e.g. files, ldap, etc).  A backup of the previous configuration is made.
Note: in the OS X platform, the PAM/NSS functions are channeled via the Directory Services Plugin API.
8. An Access Control Model is enforced depending on the zone mode:
- In zone mode:  Authorization (RBAC) follows zone rules (defaults to closed, only authorized users can access and enabled groups are visible)
- In express/workstation mode:  Only Authentication is facilitated.  The system is open for all AD users and all groups are visible.
9. Privilege Elevation:  Centrify-enhanced sudo (dzdo) becomes active based on the roles/rights defined.
10. User/Group identity (RFC2307) data in AD is stored within the Centrify zone, NOT with the user/group object.
11. The virtual registry is initialized and group policies are enforced.

What happens when adleave is run succesfully?
1. Online the --remove object:  The object in AD is removed from the container and from the zone (frees license)
2. Online the without --remove object:  The object in AD is marked as disabled.  Must be ovewritten to rejoin.
2. Offline:  The object in AD is left orphaned.  Cleanup must happen via any Centrify API (AM, PowerShell, adedit)
3. The UNIX environment is reset and rolled back (Kerberos, PAM, NSS)
4. The Centrify adclient (CentrifyDC) service is disabled.

Important Files and Folders
/usr/share/centrifydc/ 
/bin > contains user binaries, including centrify-enhanced openldap tools like ldapsearch
/sbin > contains system binaries, including adcert and centrify-enhanced OpenSSH
/samples > sample files for hadoop, adedit and local account management
Note: on OS X El Capitan, things changed to /usr/local/share/centrifydc


/etc/centrifydc
/centrifydc > config files for the DirectControl agent
/centrifyda > config files for the DirectAudit agent
/centrifycc > config files for the Privilege Service CLI Toolkit for AAPM
/openldap > config files for Centrify-enhanced OpenLDAP proxy if installed
/ssh > config files for Centrify-enhanced OpenSSH

/var/centrifydc
kset* files > dynamic information about the environment
reg > virtual registry, contains the computer and user hives  (user GPO disabled on Servers)

/var/centrify
net/certs > location of any Microsoft Certificate Authorithy auto-enrolled certs, keys and trust chain

[LABS] Testing the Local Account Management feature of Centrify Suite 2016

Background
There are several kinds of non-user accounts like local admin accounts (e.g. root, Administrator), application service accounts (e.g. oracle, Apache), network services (e.g. hdfs, yarn) or batch job/multi-tier apps (e.g. sftp, ssh, etc.)  The goal of Local Account management is to leverage the existing management infrastructure and framework (Active Directory, Centrify Zones, DirectMange/PowerShell/UNIX adedit) and the Centrify client (DirectControl) to provide an additional set of security controls. Centrify Suite 2016 provides the ability to:

• Control local UNIX user accounts (provision, disable, visibility or removal from /etc/passwd)
• Control local UNIX primary or secondary groups (provision, visibility control membership, or removal from /etc/group)
• Perform actions upon user creation/deletion, e.g. home directories, environment variables, password management/lifecycle.

We will provide the basic building blocks for you to evaluate this feature in your lab to explore the feasibility of it.
Like other posts, we'll use the Plan-Do-Check-Adjust model.

Planning
Use these planning steps for your test environment. We'veve added enough information that can be recycled towards production deployments.

Potential Stakeholders

• Centrify SME or Security Lead:  These users are entitled to perform management of zone operations inside Active Directory.
• Account Owners:  These are the subject matter experts that understand how the user or group accounts are used in the environment.  They can answer questions like these
  a) What local user (or group) accounts are required in a system or collection of systems?
  b) Should the account have a password?  should the password be managed?
  c) What are the group account members?
  d) Should the user or group account be visible to apps using name service (NSS)?
• Security Lead for Password Management:   This is the SME for a shared account password management solution.  They may know how to invoke any tools to manage the lifecycle for a shared account.

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+

Password Management (optional)

• If using Centrify Privilege Service (CPS), you need the CLI toolkit for your platform and a Cloud Connector that can reach your test systems.
• If using a 3rd party password manager, you need the tools and knowledge of the methods provided by the vendor
  In this example, we'll be using CPS.

Resources

• Centrify Administrator's Guide for Linux and UNIX
• Centrify Privilege Service - CLI Toolkit
• CLI tools and scripts:  admanagelocal, adflush, cjoin (CPS) cgetaccount (CPS)

How Local Account Management Works
The design and management is very similar to what you're used today with Centrify and UNIX-enabled AD users or Groups.

Information about the local user or group is stored in Active Directory.  The local users or groups are defined in the zone.  The scope of the local account is determined by where the identity is defined and the role that is assigned.  For example, if an account should exist and be enabled in all servers, then it's defined in the topmost zone and assigned a role with visibility at that level.  If it should only be visible to a group of systems (e.g. Database Servers) this can be done at the child zone or computer role level.  The management is exactly identical to UNIX-enabled AD users.
Once the changes are made in AD and the flush interval passes (or the adflush command is issued) the local account actions will be triggered.
There are additional CLI tools:

• admanagelocal:  to view existing managed local accounts or refresh the changes (or use adflush).
• handle_local_accts.sh:  this is a sample script provided to perform post-provisioning actions (e.g. home directory creation).  There are two versions of this script, one included with DirectControl, another one included with the CPS CLI Tools.

A Basic Lab Design
In my test environment I have:



1. An AD domain (centrify.vms) with a single domain controller (dc.centrify.vms)
2. A domain-joined server called "member" that has Access Manager installed (Suite 2016)
3. A Centrify zone called global with 2 computer roles:  App Servers and Web Servers
4. Two Linux servers (engubu1404 in the App Servers collection and engcen6 a Web Server)
5. Optional:  because I'll be testing the password lifecycle management, I have a CPS tenant and a cloud connector running on member.  CPS will provide the shared account password management functionality and workflow.

Use Cases

We are going to focus in several use cases:
Local UNIX Group Tests

• Provision a local group:
  - to all domain-joined systems
  - to a subset or individual system
• Manage group memberships
• Remove from /etc/group

Local UNIX UserTests

• Provision a local user
  - to all domain-joined systems
  - to a subset or individual system
  - have the password randomized and the home directory created
• Disable the user
• Remove from /etc/passwd

Local User and Password Management (optional*)

• Provision a local user and manually manage the account's password
• Provision a local user and automatically manage the account's password
• Retrieve the password for usage in break glass or scripting scenarios (admin or request via workflow)
  * These tests are optional given that they require a password manager that provides certain toolsets

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)

Although these steps should be straightforward to you, they are documented here:


General Test Cadence
There's a simple methodology to these tests:

1. Perform the change or update (e.g. create the local user/group, make visible, remove, change membership, etc)
2. Open a session to a system in scope of the previous change
3. Run getent (passwd or group) [target user or group]  > these result should not yield the results
4. Run adflush or 'admanagelocal --reload' (with sudo or dzdo) > this step causes the flush interval to expire and the changes in the zone to be committed by DirectControl
5. Run getent (passwd or group) [target user or group]  > these result should yield the results expected.

For example, if you create a new UNIX group called my-group (GID 3232) in all systems, after an adflush all systems should produce the same result.  If you do this in an individual system (or group of systems.

Differences between Group and User tests
a) Local Users follow the same rules as UNIX-enabled AD users 
Local users must have an identity and a role assigned to be visible in a system.  This allows for you to scope the visibility to the zone (all), child-zone (subset), computer role (subset) or individual system.  This differs from Groups that can be enabled at the zone, child-zone or individual system.

You can even time-bound the visibility of the role assigned to a local user.
b)Users must belong to at least a singe existing primary group

Otherwise, the provisioning won't work.
c) Post-provisoning actions must be defined via parameter or GPO
Provisioning users does not mean that home directories, environment variables or the password lifecycle will be handled by the Centrify agent; those actions are customizable.  Centrify provides a parameter called adclient.local.account.notification.cli; it can be used with a provided script /usr/share/centrifydc/samples/localaccmgmt/handle_local_accts.sh to perform these actions.

d) Don't fall in the poor habits
Always prefer computer roles (users) and child zones (users, groups) instead of computer overrides.

Local Group Testing Video

Local User Testing Video (without actions)


Testing local user provisioning plus actions
Using the provided handle_local_accts.sh to enable provisioning actions
In order to allow for actions to be performed upon user provisioning (or de-provisioning), Centrify provides a sample script called handle_local_accts.sh that will perform actions like assign a random password, create home directories, etc.  To enable this script:

1. Enable the adclient.local.account.notification.cli parameter (set for none)
   

   $ dzdo vi /etc/centrifydc/centrifydc.conf
   # search for adclient.local.account.notification.cli
   # enable the parameter by removing the pound and
   # set it to the path of the sample file
   adclient.local.account.notification.cli /usr/share/centrifydc/samples/localacctmgmt/handle_local_accts.sh
   

2. Run adreload (as root or with sudo/dzdo) and restart your testing.
   For example, to verify that a home directory was created after enabling a local account, you can use the following sequence:
   

   # use access manager to enable the account (e.g. james-foo)
   $ dzdo /usr/share/centrifydc/bin/admanagelocal --reload
   $ getent passwd managed-all
   # this should confirm that the user is enabled
   $ ls -l /home
   # there should be an entry for the recently-created account

Testing local user provisioning plus password management
Using CPS to manage the password lifecycle of a Centrify-provisioned local user account
This test can be performed with any password manager that provides UNIX/Linux-based CLI utilities.  The idea is that upon local account creation, the password manager is notified of the account creation, the password is randomized, changed and managed by the solution.   This example uses Centrify Privilege Service to illustrate the use case.

To set up this test, you need to have a CPS tenant with a Cloud Connector that can reach your systems and a Linux system with the CLI Toolkit.

1. Create a CPS role for the systems that will be used for testing and assign the Privileged Management right
   
   You can also use an AD group and add your computer objects and use it to nest it into the CPS role.
2. Now you can download and copy the CLI toolkit to your test system.
   
   You can add the bits to your repository or copy the installation files manually.
3. Install the CLI toolkit and add the system as a CPS resource (e.g. in my engcen7 RHEL system)
   

   # install the CPS CLI toolkit bits
   $ dzdo yum install centrifycc-rhel6-x86_64.rpm
   # add the system as a CPS resource
   $ dzdo cjoin -k -n engcen7 -a engcen7.centrify.vms
   # The command joins a system using Kerberos, names it engcen7 and gives it the 
   # hostname/ip of engcen7.centrify.vms (FQDN instead of address).  
   # You can verify the status using the cinfo command.

4. Switch the provisioning handler.  The CPS CLI toolkit includes another version of the handler.
   

   $ dzdo vi /etc/centrifydc/centrifydc.conf  # modify the parameter below
   adclient.local.account.notification.cli /usr/share/centrifycc/samples/localacctmgmt/handle_local_accts.sh
   

5. Run adreload (e.g. dzdo/sudo adreload)
6. Now you can add a new local account using access manager (e.g. managed-all)
7. First, verify that the home directory has been created, and then verify in the CPS accounts page that the account exists under the server.
   
8. You can also use the cgetaccount command to check-out the password for temporary use directly from the CLI.
   
   This is not really a practical example, most likely you'd assign the value of the password to a variable and use it on a script.

Provisioning local account with actions (random password/home directory) video

Provisioning local account with password lifecycle management (requires CPS or Password Manager)


This last video provides an example of Server Suite and Privilege Service working together:

1. We review the set up in the Centrify Privilege Service (connector, managed system role)
2. We verify the CLI toolkit in the target systems
3. We join the system as a resource in CPS (using cjoin)
4. We enable the adclient.local.account.notification.cli parameter to use the handle_local_accts.sh provided with CPS and reload the configuration
5. We enable our test account in Access Manager
6. We verify that the account exists in /etc/passwd and that home directory has been created
7. We verify that the acccount exists under the CPS server resource
8. We check-out the password via CPS Web GUI and UNIX CLI (with cgetaccount)
9. We perform an assisted SSH session with the account via CPS console.

Adjustments
There are several improvements to be made, for example:

• Customize the handler script to be suited to your environment
• Use your existing password manager to manage the lifecycle
• Upon deprovisioning, the home folder can be gzipped+tar and removed

[LABS] Testing the Centrify Reports Feature of Centrify Suite 2016

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

• Increase the speed of Access and Privilege related reports
• Provide information to your Security or Audit counterparts for Access or Attestation purposes
• Automate Attestation report generation and delivery
• Provide a data source for custom report generation.

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

What is the Centrify Reports feature designed for?
It's designed to overcome the limitations of existing report generation via LDAP (speed), provide flexibility (SSRS or Bring your Own Reporting), and increase productivity (automate report generation and distribution).

Can you describe an example?
The typical scenario is that depending on your risk or regulatory profile you need to provide user entitlements (who has access to a server or collection of servers in a Centrify zone and  what can they do with Privilege using DirectAuthorize).  For example:

• Who has access to UNIX/Linux or Windows Server? What privileges do they have (dzdo/dzwin)? What AD object grants access?
• Who can access this collection of systems? What privileges do they have (dzdo/dzwin)?

These entitlement reports, are used typically in attestation exercises.  Attestation may be done manually (you get together an ratify that these are the proper people that should have accesss) or automatically using a Security Governance tool (at that point, a feed is inserted to the tool)..  As always, we'll be using the Plan-Do-Check-Adjust methodology.  In the labs, the goal is to test the features to be able to produce an viability assessment of the feature.

Planning
Use these planning steps for your test environment. We'veve added enough information that can be recycled towards production deployments.

Basic Requirements

• Obtain access and privileges reports in a timely fashion (for example, delivered daily, weekly, monthly or quarterly)
• Minimize impact to Active Directory domain controllers
• Automate delivery (e.g. email or shared folder)
• Allow reports consumers to customize reports based on their needs

Potential Stakeholders

• Active Directory Administrator:  To request and set up the account used to replicate AD Group and Centrify zone data to SQL Server.
• IT Infrastructure:  You can set up different distribution methods like file or web server and email.  The infrastructure SME will allocate shares, permission, SMTP relays or web servers.
• Security or Audit Analysts:  These are the consumers of this data.  They provide input on report data/distribution, etc.
• Database (SQL Server) Administrator (optional):  To work to set up a database instance (most likely in production);  if in a test lab, the Centrify bits include SQL Express.
• Reports SME (optional):  Depending on the size of your organization, you may have report developers that can customize the reports based on your security or audit needs.

Technical Requirements
Active Directory and Centrify

• A licensed or evaluation copy of Centrify Suite 2016
• An Active Directory test or production environment with Centrify hierarchical zone data (HZ Zones have RBAC)
• A domain-joined Windows server, ideally 2008 and up
• An Active Directory Service account (or two depending on your setup)
  An account needs the "Replicate changes" right in AD (to be able to read AD data and copy it to SQL)
  An account needs the "logon as a service" right in the system that runs the synchronization
• A Windows administrator or local admin rights to install programs in the test server.

SQL Server

• Versions validated: 2008, 2008R2, 2012, 2014;  Standard, Enterprise or Express (included with Centrify Suite 2016)
  Note:  with SQL Express, you have limitations on scale and capabilities.  E.g. can't do file/email subscriptions.
• If you need to test custom reports, email delivery, scheduling, etc; you'll need a Standard or Enterprise version of SQL
• If you want to test the Centrify-provided reports, you need to deploy SSRS
• If you want to test with a custom tool (e.g. Tableau) you'll need that software.

A Windows Server 2008 and up to install the Centrify Reports Service.  Depending on your deployment model, this may be the same machine as SQL or if it's a production design adhere to your organizational best practices.

Resources

• Centrify Administrator's Guide for Reports
• SQL Server Documentation (or leverage your DBA)
• Social: 
  What rights does “Replicating Directory Changes” actually grant in Active Directory?Please explain: "Replication Synchronization" permission in Active Directory
  Note: depending on the experience of your AD team, they'll know what the rights are used for; this is not unorthodox because it's a common practice when setting Sharepoint, FIM, Office365 DirSync or other services, however as we know you may get push-back based on lack of cognitive knowledge.

Design
Your design is going to be dictated by the capabilities that you with to test and your requirements.  Examples:

• If reports delivered via file-share or email are required and you'll use SSRS, then you need SQL server standard or enterprise.
• If you have your own reporting tool, SSRS is not needed, all you need is connectivity between your tool and the SQL server database instance that was used to sync the AD data that contains the Centrify access control data.

Here are some suggested(*) deployment models:

Note that the common denominators are AD, Centrify Hierarchical zone data and the service account required to sync AD data to SQL server.
(*) Remember that this is a "labs" post and this is a new feature.  Although I have input from beta testers, the true best practices come from our professional services organization.

How frequently should access and privilege data be synchronized between AD and SQL Server?
The answer to this question depends on the attestation requirement.  Examples:

• Some organizations do quarterly user access/privilege attestation exercises.  Perhaps synchronizing every quarter is fine in this organizations.
• Some organizations practice just-in time privileges (e.g. nobody has privileges or knows privilege account passwords) and they need reports daily to make sure there are nobody has any sticky privileges.  Daily reports that get delivered to a security analyst are required in this case, so a daily sync is in order.

The key here is that attestation has a component of comparing the access/privilege data from one time period to another and you have to plan your synchronization based on that.  Technically,  after the first sync or a rebuild, only the delta changes are requested from AD, this ensures that these operations don't negatively impact your Domain Controllers.  In a complex environment, your AD lead should understand that proximity to a Global Catalog will be an important design consideration.

Implementation
Download Suite 2016 from the Customer Support Portal and unzip the bits in an accessible folder on the domain-joined server.

Set up the AD Service Account
This step may be done for you by a Windows administrator.

1. Open Active Directory Users and Computers and navigate where you want the account to be created (OU or container)
2. Right-click the OU, New User and in the form type the First Name, Last Name and User logon name (e.g. centrify-reports) and press next
   
3. Set up a password for the account, depending on your practices, you may set the account's password to never expire, press next and then finish.

Delegate the Rights to Replicate Directory Changes from AD
In my example, I'm delegating at the top level of the domain, depending on the location of your users/groups, this may change.  This step may be done for you by a Windows administrator.

1. In Active Directory Users and Computers, right click the domain (e.g. corp.contoso.com) and select "Delegate Control" and press next on the first wizard page
2. Users or Groups:  Press the add button and find the newly created account, then press OK and press next.
3. Tasks to Delegate: Select "Create a custom task to delegate" and press next
4. Active Directory Object Type:  Keep the default radio button and press next
5. Permissions:  In permissions, scroll down and check the "Replicating Directory Changes" permission and press next and finish.
   

Delegate the Rights for the Account to run as a Service
In my example, I'm using AD Group Policy to grant my user the right to run as a service in that system.  The system is in an OU called Servers.  This step may be done for you by a Windows administrator.

1. Open the Group Policy Management tool and navigate to the OU that corresponds to the server, create or modify a GPO in and link it to that OU, right click it and select Edit (launches the group policy management editor).
   Alternatively, you would do this the Local Security Policy for the system.
2. Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment and find the GPO named "Log on as a Service" and double-click it.
3. If not checked, check the "define these policy settings" and press the Add User or Group, click browse and make sure that the "From this location" has the AD domain selected otherwise click Locations and select it. 
4. Type the name of the service account and press check names.  Press OK three times.
   
5. Now you can close GPME and GPMC.

Installation of Report Services
You need administrative rights to install and configure this software.  This may have been granted to you or you're assisted by a Windows administrator.

1. Using Windows Explorer, find the unzipped Centrify 2016 folder and navigate to DirectManage > Report Services and either the MSI or EXE file in that folder (it's the same)
2. EULA Page:  Accept and press next
3. Destination Folder:  Select the proper destination or leave as default and press next and press install.
4. In the final page, leave the Config Wizard box checked.

The Report Services installation package installs 3 key apps:

• Configuration Wizard,
• Report Services Control Panel, and
• Report Services launcher.

Now you have two options for configuration, with SQL Express (included) or with SQL Standard or Enterprise

Configuration for SQL Express or Standard/Enterprise

1. Launch the centrify Report Services Configuration Wizard and press next in the welcome page.  The next steps depend on your setup:
2. If using SQL Express:
   SQL Server Page:  Select the "Install SQL Server Express instance on this computer" and use the default name (REPORTS) or change the name and press next.
   SQL Server Package:  press next or specify an alternative set of bits (must know what you're doing), press next.
3. If using SQL Standard or Enterprise:
   In this step, you're either authorized at the SQL server level login (integrated or mixed) or assisted by your SQL DBA
   SQL Server Page:  Select the "Use an existing instance" and browse to the instance to be used; press next and give it some time to connect.
4. Deploy Centrify Reports (optional):  You can choose to deploy the Centrify attestation reports to the SQL Server Reporting Services website.  This is only optional if you plan to use another reporting tool, press next.
   Note that you may need to run the Reporting Services Configuration Manager applet to determine these URLs.
5. Monitored Domains:  Defaults to the local domain, add any additional (you must have had delegated the account permissions and the proper AD trust direction has to be in place), press next.
6. Sync Schedule:  Select an appropriate frequency based on your reports needs, press next
7. Report Services:  Select "use account" and browse for the AD service account set up.  Type in the password and press next.
   At this point, the wizard will check if the account has the proper permissions in the monitored domains.  If you did not get the correct delegations, this will fail.
8. Press close and then next.
   At this point the installer will perform an assisted installation of SQL Server Express.
9. Once completed, you'll get to the configuration completed page and the check box to do an initial sync will be selected.  When you press finish, the service will do the initial sync.  From that point on, all will be delta synchronizations.

Verification (Check)
The verification steps vary depending on the features you've deployed. However, a key step is to verify that AD roles and rights and principal data is being sent to SQL server in the interval that is set.  For this you can use the Report Service Control Panel.

If you chose to deploy the SSRS reports, you should be able to use the Report Services shortcut and access the sharepoint-based report services.  This grants access to subscriptions, report builder, etc (if you're not running Express).

Here are some verification videos: 

Adjustments
There are may adjustments to be made to this configuration.  Some may or may not be related to Centrify technologies:

• Set up a file share subscription
• Set up a SMTP distribution email
• Use a custom tool for reporting
• Programmatically retrieve reports data

The good news is that all the building blocks already are in place.  Future entries can cover these topics.