Overcoming the Identity or Infrastructure Duplication to Secure Linux Instances in Public Clouds

Background
Securing Linux instances in public (or private) clouds often requires the duplication of infrastructure (or additional overhead) just to be able to provide basic services like authentication.  Centrify just debuted a new client that leverages a capability called Identity Broker.  This allows users of Centrify privilege service to extend authenticaiton to Linux systems using Active Directory, LDAP, Google Directory and others without the need to implement extensions to AD or LDAP or any supporting infrastructure (like site-to-site VPNs).

The Challenges (AWS as an example)
In previous blog posts, we discussed the additional controls that can be implemented on top of Amazon's IAM and cryptography-based capabilities.  The model suggested the use of Active Directory and Centrify Server Suite.
Regardless of the solution, organizations need to find ways to extend this infrastructure by using these techniques:

• Re-creation of infrastructure (e.g. standing-up Active Directory or LDAP-like infrastructure)
• Network extension (e.g. treating the public cloud like a branch by implementing site-to-site VPNs)
• Capability duplication (e.g. implementing software and services in AWS)

In this article we'll discuss how organizations can leverage Centrify Privilege Service and the new Linux Agent (Identity Broker) to secure Linux instances and extend Enterprise Identity out to public clouds without the need of the additional overhead.

Centrify Privilege Service

Privilege Service is Centrify's answer to the traditional "password-driven" use cases (the industry refers as Shared Account Password Management, Privilege Session Management, etc);  however unlike other solutions, there are several capabilities areas that set it apart from the traditional "Password Vault"

• Flexible deployment:  Both as SaaS and On Premises  (in fact, it was designed as a SaaS solution first)
• Identity Sourcing and Federation built-in (includes Identity Service, this means support for AD, LDAP, Google and others  plus simplified SAML-based federation and 3K+ ready web and mobile apps)
• Policy, Workflow and MFA Engine:  Policies for time and geo-location, RBAC, step-up authentication and Multi-factor including Smartcard, plus a built-in access request system (+ServiceNow integration)
• Infrastructure Extensibility:  Privilege Service can be extended to any network using a Windows-based Centrify Connector via web protocols.

New Linux Agent
The new Linux agent takes advantage of a capability called "Identity Broker" this allows the bridging of identities known to Centrify Privilege Service;  this is done via the Centrify connector.  This means that the overhead of duplicating enterprise identity infrastructure or extending the enterprise to the public network can be avoided in this particular use case;  all that is required is to deploy a Centrify connector wherever you want to extend Password-related services and Linux authentication.  Let's show an illustration.

Company X needs to provide identity-based reporting and attestation of who has access to their public cloud EC2 instances in AWS;  their primary identity source is AD.  They could have used any model (independent forest, one-way trust + site2site VPN or RODC) to extend AD to AWS  or they could have deployed Amazon IAM roles and used SSH keys; but any of these models implied additional overhead.  With CPS and Identity Broker, all they did is this:

With this model, CompanyX not only can accomodate their corporate IT users, but external entities as well.  And as we discussed before, password, session and additional services are consolidated as well, both on premises and on any public cloud.  Plus

• No need to deploy "jumpboxes" to the private clouds (limits exposure)
• Shared account passwords for local accounts (Linux, Windows) or databases (like Amazon RDS) can be controlled
• Access Request provides the assurance of "documented approvals" to sensitive systems
• Deploy MFA or access only from the OnPrem network as additional controls.

Agent Architecture
The client architecture is using UNIX frameworks like Name Service Switch (Identity) and Pluggable Authentication Modules (Auth).  It also supports offline login as well as direct or proxy-based user/password or OAUTH-based enrollment codes (very useful for automation). This client implements the CLI tookit for setting, retrieving or deleting credentials under management.

Supported Platforms
Platforms supported in the initial release - more on the way

UNIX Identity
Following on the legacy of Server Suite, the new agent generates identity like DirectControl in workstation mode.
Login - user's short name (must use the fully-qualified name the first time)
UID - auto-generated based on the GUID
Primary group - auto-private (same as UID)
GECOS - the display name in Centrify Identity Service
Home/Shell - configurable in the Settings tab.

Since most public clouds don't need legacy identity (for services like NFS), this makes the client very lightweight.

Automation
There's an implied expectation of DevOps "friendliness" when a private or public cloud solution is implemented.  The new Linux agent leverages enrollment codes for this capability.

Centrify provides a sample AWS script that can be used with enrollment codes in the User Data field or with any other framework like OpsWorks (see attachment)

Identity Broker
Privilege Service can accomodate several identities, including:

Note that it can accommodate identities from Active Directories without any trust relationships.
These identities can be aggregated using Identity Service Roles:

 Roles, in turn can be assigned the AgentAuth privilege on a Linux Resource:

As you can see the model works like this:
Users or groups from Identity Sources are added to CIS Roles that are granted the AgentAuth right in CPS.

Basic Commands
Agent Operation

• cinfo – obtain information about the agent
• cenroll – enroll the identity platform and enable features
• cunenroll – leave the platform and optionally delete resource and any managed accounts
• cflush – flush the local cache

AAPM

• csetaccount – add a managed account for the resource
• cgetaccount – obtain a managed account’s password
• cdelaccount - delete a managed account's password

Centrify's Value Proposition - Part 3: Privileged User/Identity Management with Least Priviliege

In the third part of this series, we'll discuss how Centrify provides solutions for privileged user/identity management and maintains these principles:

a) Eliminates identity silos

b) Implements strong access controls without interfering with the user experience

c) Use what you have: infrastructure, processes, knowledge (less IT fragmentation)

d) Promotes operational efficiency

e) Provides strategic value, rather than tactical solutions

Organizations come to Centrify for privileged identity management or privileged user management because of combinations of the following challenges or circumstances:

•  Overall: They want to increase accountability and implement strong privileged user identity and access controls based on a common identity repository.
• They have Active Directory and multiple platforms, but primarily for UNIX, Linux and Windows
• They have a traditional (on-premise only) or hybrid (public/private cloud) enterprise
• They want to eliminate the use of shared credentials or persistent administrative accounts (root, administrator, “-a”, etc)
• Their existing solution does not provide flexibility on grouping systems based on a security governance model
• They might have chosen to implement a password-centric approach as their unique strategy and they’ve come to realize that their users are less productive (or supportive), that they’ve duplicated identity silos and that ultimately, their systems (the main goal) aren’t protected by it.
• On UNIX: They understand that using sudo/sudoers, although it’s mature may not be enough for high-risk, highly-regulated enterprises; they are tired of the complexities of managing a sudoers file and want more granularity and flexibility
• They want a higher-degree of control on how their users access systems (beyond just granting/denying access) cross platform.
• On Windows, they want to eliminate the problem of the Local Administrator, are conscious of the “pass the x” attacks and want to eliminate the “camping” issue with “-a” accounts.
• They need to provide separation of duties (operational rights vs governance rights)
• They need timely reporting of who has access to what system(s), what are their privileges, and what granted them access to do this.
• They don’t want to deviate from existing processes or realized that by implementing point solutions or “best of breed” they ended-up fragmenting their IT in the context of processes.
• They have regulatory requirements that they need to meet or exceed.  These may be SOx, PCI DSS, HIPAA, NERC, FERC, etc.
• They want to solve the Shared Account Password issue, but they want a solution that reflects the state of modern trends (they hybrid datacenter, IaaS, mobile-first, etc)
• They have high-security requirements like FIPS, solutions common-criteria certified, perhaps they rely heavily on Smart Cards.
• They want log aggregation that is simple to their native tools (ARCSight, LogLogic, Splunk, etc)
• They may need to go beyond the traditional security operations and provide session capture and replay from anywhere (remote or via console) because today they don't have that capability, are required to have it or simply, they might have gone the "jumpbox" route to realize that they are missing crucial sessions.
• They hate having to invest in multiple solutions to enforce the same basic security principles.  Each time they do, this may mean:
  - Evaluate a product
  - Invest or procure new hardware or software
  - Add additional infrastructure
  - Train or hire specialist
  - Maintain the solution down the road
  - Manage the vendor relationship

Here's a technical demonstration on how Centrify delivers this value:

The key differentiation areas are:

• AD Orientation - implemented in more of 90% of enterprises, users use a unique identity.
• Centrify Zones - unique patented way to create groups of systems in Active Directory
• Granularity of Access Controls - control HOW users log in to systems
• Granularity of Privileges - no need to know the privileged account password.
• Simple privilege elevation:  sudo-like tool in UNIX/Linux, shell and command line on Windows.
• No proprietary magic on how events are stored: no need to have a central system just to know who did what and when - need to rely on a central system to correlate who had a privileged account.
• Quick attestation and robust reporting - the data is in AD.
• Separates the operational tasks versus the governance tasks - to enforce SoD
• Works in multiple core platforms:  UNIX, Linux and Windows
• Protects your systems: Provides end-to-end enforcement of the rules as well as session capture and replay.

Finally, the end user experience is not affected, no identity silos are created  and your AD infrastructure, processes and technology are reused.  We propose that the "least access/least privilege" approach to Privileged Identity/Super User Privilege Management should be used at least in 80% of the use cases.

In the next post we're going to talk about the next 20%, this includes Shared Account Password Management, Proxied/Brokered/JumpBox initiated sessions (what gartner calls Privilege Session Management).

Centrify's Value Proposition - Part 2: The hybrid and heterogeneous enterprise

Organizations with traditional (on-premise) and  hybrid (private/public cloud) with Active Directory, come to Centrify because:

• They have diverse platforms (UNIX, Linux, Macs) in their enterprise (on-premise and in the cloud).
•  They are looking to Centralize the administration (or implement effective controls) for user access in those different platforms.  Their reasons may be due to security, regulation, operational efficiency or simply because they are reacting to an audit or other event.
•  They are also looking to leverage the secure authentication methods provided by Active Directory. 
•  They are looking to find a way to effectively manage UNIX identities by using Active Directory, but preferably, they don’t want any schema extensions to AD or software loaded in Domain Controllers.
• Some other organizations (and this is quite common on the Mac side) are looking for a more robust way to support AD integration and are also looking to use a common management framework (like Active Directory Group Policies) to enforce security policy or configuration management policies.
• Other organizations are looking to focus on their core competencies because perhaps they invested a lot of engineering cycles using open source software (like Samba/Winbind, RedHat’s SSSD, OpenLDAP with MIT Kerberos) and realized that the speed of requirements and diversity of platforms does not align with their goals.  (E.g. a Financial organization spending hundreds of man hours on “manual” identity and access controls rather than portfolio analysis).  These types of organizations are ready for a solution that “just works”
• Organizations want solutions that are friendly to private/public cloud scenarios; this means a toolset that promotes automation.
• The organization may have high-security requirements like smartcard authentication, FIPS encryption or common-criteria certified solutions
•  Finally, some organizations tried to wait as long as they can keeping the status quo; and a compelling event has made them change like:

• Change of leadership

•  A merger or an acquisition

•  A new technology (like BigData)

•  Acknowledgement that advanced persistent threats can’t be ignored

•  Another solution isn’t providing timely updates, proper support or their future is uncertain

• An audit or data-breach

•  Perhaps there’s an old infrastructure (e.g. NIS, LDAP) that found fresh blood that isn’t afraid of “touching the server, who knows what will break”  <= yes, this sadly happens.

Everything I outlined above is core of what some analysts call “Active Directory Bridging” but when you look at it is much more; it is the basis for implementing critical access controls and a management framework that is based on reuse of existing infrastructure and processes rather than point solutions.  It’s also the foundation of making sure users can do their work, without interrupting their flow.

Here’s a technical demonstration on how Centrify provides value:


 A very unique capability that is exclusive to Centrify is the zones technology.  Nobody else can do what Centrify does to group systems in a hierarchical way while consolidating UNIX identities for Users, Groups and NIS Maps.

Note that also, a large number of "born-in-the-cloud" organizations are coming to Centrify for Web Application SSO and Enterprise Mobility.  We will cover that in other entry.

In the next post, we'll focus on how Centrify builds on their AD bridging capabilities to provide Privileged User Management on UNIX, Linux and Windows and how it uses it's Identity Platform for secure access and shared account password management.

Labs: Securing Multi-protocol File Access (NFS/CIFS) on NAS (NetApp) Using Centrify and Windows Security Groups

Background

In the previous post, we discussed how to overcome identity limitations in NAS sharing scenarios.  In heterogeneous environments the main issue is about Identity - the filer is unable to consistently translate the Windows identity to a UNIX identity.  With Centrify Zones and the LDAP Proxy we solved the issue providing a unified identity consistently across Windows, Unix, Linux and Macs.

In Summary, here's what we accomplished:

The LDAP Proxy present's user information for the filer with consistency.  The UNIX information corresponds to what the AD user has in the Centrify Zone.

Now, we can let the NetApp filer do it's magic.  Let's look at a very simple example:

Testing Mixed Share Permissions

Set up the NetApp share

1. Create a new qtree
   qtree create /vol/vol0/mixed
2. Change the security model as mixed
   qtree security mixed
3. Export the newly created qtree
   exportfs -p rw /vol/vol0/mixed

Create a New AD Security Group for the Mixed Share Access

1. Open ADUC browse to an OU for groups
2. Select New > Group
3. Give it a name  (e.g. "Mixed-Share-Access")
4. Add a test user to the newly created share.

Publish the share in Windows

1. Open Computer Managemetnt
2. Connect to your NetApp filer
3. Navigate to System Tools > Shared folders
4. Follow the wizard to create your share
5. In the Share Permissions, remove Everyone and add your previously-created AD Group

Now you have:

• A CIFS share that is a shared folder protected by a Security Group in AD.  Access is governed by group membership and the permissions on the share.  NTFS permissions will be assigned at file/folder creation based on the user's identity.
• An NFS share that can be mounted from any Unix, Linux or Mac system;  UNIX file permissions will be assigned at folder/file creation based on the user's identity.  We'll leverage the NETGROUPS option with Centrify-exposed options to accomplish this.

Let's see this in action

Improvements

As outlined in the latter part of the video, there's definitely improvements that can be implemented:

• On the NetApp side, Kerberos can be implemented for additional security.  Remember that Centrify already provides "hands-off" Kerberos environment optimized for Microsoft's Kerberos.
• The AD Group used to control access can be UNIX-enabled, this opens the possibility of leveraging the group's UNIX identity as a group owner on the UNIX side.

Key benefits

• Process consolidation - now a single AD group can be leveraged to control access.
• Better Security - there's a better grasp on who has access to what.

Business Problems: Conquering the NAS multiprotocol (CIFS/NFS) file sharing in a mixed (Unix, Linux, Windows, Mac) environment using Centrify

Background

Network Attached Storage (NAS) is a key part of any enterprise today; they provide flexibility and an abstraction layer from an infrastructure perspective.  In the heterogeneous enterprise, the easy part is the infrastructure piece;  the hard part has to do with the diversity of platforms and the multiple file-sharing protocols in use.  This post and a series of labs will illustrate how leveraging Active Directory, Centrify Zones, the Centrify agent for UNIX, Linux & Mac and the Centrify LDAP Proxy we can ensure consistency with multi-protocol CIFS/NFS shares and enhance operational efficiency.

In previous posts, we have addressed how to to solve the consistency issue individually:

• Centrify and NFS Basics  (video lab)
• Centrify and Samba (CIFS) basics  (lab1, lab2)

This posts uses a NetApp filer as an example(*).  The concepts outlined here can be used on any NAS device that supports LDAP.  We will assume that you understand that the fundamental problem is how to solve the issue of identity across multiple platforms and how we accomplish that with the Centrify Agent and Active Directory (I highly recommend that you read the previous links).

The Issues (or variations of it)

• We have a NAS device, we integrated it with AD and it works great as long as the user is performing file operations on Windows.  However, we have to keep separate NFS shares.  We also have to manage permissions in multiple groups (Windows or UNIX) and that takes a lot of effort.
  Note, in my example with NetApp, the appliance does a great job at discovering LDAP servers:
  
  netapp1> Sat Jul  5 11:26:52 EST [netapp1:auth.ldap.trace.LDAPConnection.statusMsg:info]: AUTH: TraceLDAPServer- AD LDAP server address discovery for CORP.CONTOSO.COM complete. 2 unique addresses found.
  
  However, although it can resolve the AD portion, it is plain wrong about the Unix UID:
• We have a multi-protocol share (CIFS/NFS), everything is great on Windows, when the user wants to access their files over NFS he has to call to have the file/folder ownership taken care of
• We are tired of having to resolve file ownership issues.  Our organization is globally very diverse and each time we have a new visitor we spend significant amount of time helping them get access.
• We have a combination of Unix, Linux, Mac and Windows users and although we had it down in individual servers, when we moved to filers now we have all these new issues.
• I have a filer in my environment and we have Centrify as well, I know it can help but I don't now where to start.

Example of one of the issues

Let's look at an example.  In my environment with a domain-joined Netapp the appliance does a great job at discovering LDAP servers (this happened once I searched for one of my users):

netapp1> Sat Jul  5 11:26:52 EST [netapp1:auth.ldap.trace.LDAPConnection.statusMsg:info]: AUTH: TraceLDAPServer- AD LDAP server address discovery for CORP.CONTOSO.COM complete. 2 unique addresses found.

netapp1> wcc -s george.constanza

(NT - UNIX) account name(s):  (CORP\george.constanza - pcuser)

        ***************

        UNIX uid = 65534

        NT membership

                CORP\george.constanza

                CORP\UNIX-Model-Samba Users

                CORP\UNIX-Model-All Users

                CORP\UNIX-Model-dbaadmin

                CORP\Domain Users

                CORP\UNIX-Model-Sysadmins

                CORP\UNIX-Model-webadmin

                CORP\UNIX-Model-All UNIX Groups

                BUILTIN\Users

        User is also a member of Everyone, Network Users,

        Authenticated Users

        ***************

This is great from a Windows perspective, however, look at the Unix UID (65534), when you look at the options, this means that the user is being assigned a "nobody" user from a UNIX perspective.  We can further confirm this with this command:

netapp1> wcc -u george.constanza

no passwd entry for george.constanza

The way I have my system configured, although I can derive the user's identity leveraging the DCs, I can't see the user's Unix identity.  It is stored in the zone. See the output from a centrified system:

george@ubu1:/etc/centrifydc/openldap$ adquery user george.constanza -A

unixname:george

uid:1149240406

gid:1149240406

gecos:George Constanza

home:/home/george

shell:/bin/bash

auditLevel:AuditIfPossible

isAlwaysPermitLogin:false

dn:CN=George Constanza,OU=Staff,DC=corp,DC=contoso,DC=com

samAccountName:george.constanza

displayName:George Constanza

sid:S-1-5-21-2180375406-786980114-1643973036-1110

userPrincipalName:george.constanza@corp.contoso.com

canonicalName:corp.contoso.com/Staff/George Constanza

passwordHash:x

accountExpires:Never

passwordExpires:Wed Aug 13 11:28:48 2014

passwordWillExpire:39

nextPasswordChange:Thu Jul  3 11:28:48 2014

lastPasswordChange:Wed Jul  2 11:28:48 2014

accountLocked:false

accountDisabled:false

zoneEnabled:true

unixGroups:dbaadmin,george,webadmin

memberOf:corp.contoso.com/UNIX/Provisioning/UNIX-Model-All UNIX Groups,corp.contoso.com/UNIX/Provisioning/UNIX-Model-All Users,corp.contoso.com/UNIX/RBAC/UNIX-Model-Samba Users,corp.contoso.com/UNIX/RBAC/UNIX-Model-Sysadmins,corp.contoso.com/UNIX/UNIX Groups/UNIX-Model-dbaadmin,corp.contoso.com/UNIX/UNIX Groups/UNIX-Model-webadmin,corp.contoso.com/Users/Domain Users

Our goal is to make sure that our filer (or application) gets the correct Identity information for the purposes of proper file/folder ownership, access and permissions.

Who's affected

As you can see, the variety of problems outlines have multiple constituents:

• Security needs to make sure that users have access to what they need and to comply with policies
• IT (business) need to make sure that users can do their jobs
• IT (operations) wants to be efficient and make sure that an army of people is not needed
• The End User just wants to get their job done

As with all Business Problems, we'll use the Plan, Do, Check, Adjust methodology.

Planning

As discussed in previous posts, the key to this issue is Identity.  In this case, the NAS appliance needs to know not only the user's AD information, but the extended attributes (RFC2307) like unixname, UID, GID, Home, GECOS, Shell, etc., and unlike other approaches, Centrify stores this information in the zone.  This makes the solution more flexible because an AD principal can have multiple Unix identities.

Note:  If you've read this blog, you know that I've been very vocal about overrides (what enables multiple identities and roles).  Every process needs to have constraints; constraints make solutions simpler.  Having a normalized UNIX namespace is the goal and destination of any enterprise, even if Centrify allows you to put off this goal.  

Identity and Access Planning

1. Do the best you can to have a normalized namespace.  Leverage Centrify's ability to assign users a unique UID by generating it from the AD SID (using Centrify or Apple's Scheme).
2. Perform a migration if necessary (this post talks about strategies and Centrify tools for that purpose)
3. Leverage the power of hierarchical zones:  provision all identities at the top-most zone.  This will ensure that all pertinent systems will know the user's identities.
4. Continue to enforce the least-access principle:  Use the "listed" role to make users known to the systems (e.g. the LDAP proxies) and ensure that they can't sign-in to the systems.

Planning your LDAP Proxies

The Centrify LDAP proxy leverages the Centrify client (adclient) to present AD information to clientless devices or programs.  The benefits of leveraging the proxy are:

• It flattens AD for the application:  depending on the enterprise, AD can be complex.  There may be multiple forests, child domains, one-way, two-way trusts, etc.
• It leverages the agent's built-in capabilities:  optimal DC selection, site-awareness and offline cache.

Plan for high-availability:  the NAS (or application) is going to require redundancy, plan to deploy and configure multiple proxies.

Plan for confidentiality:  make sure that only authenticated connections over secure transports (TLS, SSL, etc) in case your appliance or application does not do it natively.

Plan for high-performance:  As always, have NSCD on the Centrified system, and plan for co-location near the appliance, application and be close to Global Catalog servers in complex environments.

Plan for your file-sharing use case

This section varies based on what you want to accomplish.  Planning for home directories is not the same as planning for a workgroup share.  

Implement (Do)

1. Unix-enable all your relevant users (you don't need to Unix-enable users that won't ever access via NFS).  You can do this manually, with ZPA or with your own IdM solution.   
2. Assign roles as required:  keep the least-access principle intact by leveraging the "listed" role.
3. Install the LDAP Proxy(es):
1. Copy the Centrify LDAP proxy binaries to the platfrom.
   e.g. for Ubuntu on 2014:  centrifydc-ldapproxy-5.1.3-deb5-x86_64.deb
2. Log in and install the package
   e.g. dpkg - i centrifydc-ldapproxy-5.1.3-deb5-x86_64.deb
   The LDAP proxy binary is on /usr/share/centrifydc/libexec
   The config files and schemas are in /etc/centrifydc/openldap
   The LDAP utilities (like ldapsearch)  are on /usr/share/centrifydc/bin
3. Modify the RFC 2307 map
1. Edit the /etc/centrifydc/openldap/rfc2307.map file
2. Add the following line (for NetApp compatibility):
   # Added for NetApp
   posixAccount.userPassword: _userPassword
4. For testing only, start slapd manually:
   dzdo /usr/share/centrifydc/libexec/slapd -f /etc/centrifydc/openldap/ldapproxy.slapd.conf -h ldap://ubu1.corp.contoso.com
5. Check that the proxy is running
   $ ps -ef | grep slapd
   root     23192     1  0 Jul04 ?        00:00:00 ./slapd -f /etc/centrifydc/openldap/ldapproxy.slapd.conf -h ldap://ubu1.corp.contoso.com
6. Verify that the proxy is responding to queries (e.g. check the Administrator account)
   $ /usr/share/centrifydc/bin/ldapsearch -h ubu1.corp.contoso.com-x -b "dc=corp,dc=contoso,dc=com" "(cn=Administrator)"
   # extended LDIF
   #
   # LDAPv3
   # base <dc=corp,dc=contoso,dc=com> with scope sub
   # filter: (cn=Administrator)
   # requesting: ALL
   # with pagedResults control: size=100
   ## Administrator, Users, corp.contoso.comdn: cn=Administrator,cn=Users,dc=corp,dc=contoso,dc=comaccountExpires: 0
   (output truncated***)
4. Configure your NAS appliance (e.g. on NetApp Ontap v 8.1.2)
1. Housekeeping:  Make sure that the name of the appliance is resolvable (add an A record for it) and that all Centrified systems, Windows Systems can resolve it.  The NetApp system should resolve all systems as well.  E.g.
   netapp1> ping ubu1
   ubu1.corp.contoso.com is alive
   netapp1> options dns
   dns.cache.enable             on
   dns.domainname               corp.contoso.com
   dns.enable                   on
   dns.update.enable            off
   dns.update.ttl               24h
2. Housekeeping:  Make sure that CIFS and NFS are licensed, enabled and the NetApp filer is joined to the domain.  (use the license command, the cifs setup command )
3. Verify that there's a computer object for the netapp device and that you can (as a Domain Admin) connect to it via Computer Management.  E.g. using ldapsearch:
   george@ubu1:/etc/centrifydc/openldap$ /usr/share/centrifydc/bin/ldapsearch -h
   ubu1.corp.contoso.com -x -b "dc=corp,dc=contoso,dc=com" "(cn=NETAPP1)"
   <truncated>
   # NETAPP1, Appliances, corp.contoso.com
   dn: cn=NETAPP1,ou=Appliances,dc=corp,dc=contoso,dc=com
   <truncated>
4. Optional:  Make sure that Domain Administrators are not mapped to root the NetApp filer:
   netapp1> options wafl.nt_admin_priv_map_to_root off
5. Configure NetApp to use the LDAP Proxy (Example corp.contoso.com;  ubu1)
1. Set up the LDAP base container
   netapp1> options ldap.base dc=corp,dc=contoso,dc=com
2. Set up the LDAP server(s) to be used by the NetApp appliance
   netapp1> options ldap.servers ubu1.corp.contoso.com
3. Set up the name of the Active Directory Domain
   netapp1> options ldap.ADdomain corp.contoso.com
4. Map the userPassword attribute to avoid null results
   netapp1> options ldap.nssmap.attribute.userPassword cn
5. Enable LDAP
   netapp1> options ldap.enable on
6. Modify the /etc/nsswitch.conf to make LDAP the first source for user, group and shadow entries.
   netapp1> wrfile /etc/nsswitch.conf
   hosts:  files  dns
   passwd:  ldap files
   group: ldap files
   netgroup:  files nis
   shadow:  files nis
7. Verify the results
1. Query and note the UID from Windows
   wcc -s jerry.seinfeld 
2. Query and note the UID from UNIX
   wcc -u jerry.seinfeld
3. Advanced query using NSS
   priv set diag
   getXXbyYY getpwbyname_r jerry.seinfeld
   
   Compare the results with the zone information.  At this point it should match the UNIX identity on Access Manager

Check the Results

To verify the results, use a multi-protocol (CIFS/NFS) share and make sure that the identity information is consistent.

1. From a Windows system in the target domain, map or browse to the share via CIFS.  Create a file.
2. From a Unix/Linux or Mac system, mount the share as an NFS mount and issue the ls -la and ls -lan.  Compare the results from before.

Adjustments to the Implementation

Adjustments are based on your existing environment, however, based on ours here are some key modifications:

• There's only one LDAP proxy, we need several for high-availability
• The LDAP Proxy is accepting anonymous connections, we need to make sure that only authenticated connections are accepted.
• Ideally we would use Secure LDAP or implement TLS or IPSec for additional confidentiality controls.
• Operations needs to monitor the health and status of the LDAP Proxies

Lab Videos

What you'll need to follow along:

• Active Directory
• Centrify Standard Edition
• A Centrify zone
• Client for Unix, Linux or Mac
• Centrify's LDAP Proxy
• A Multi-protocol filer (we'll use NetApp's  ONTAP Simulator)

Installing, Configuring and Testing the Centrify LDAP Proxy

Configuring the NetApp appliance to use the Centrify LDAP Proxy


Verifying the NetApp CIFS/NFS share provides consistent identities

Labs: Mac OS X AD Integration with Centrify Suite 2014

Centrify Suite 2014 Mac Integration Playlist

This playlist (47 minutes total) covers the requirements for the Mac OS Scenario outlined in the previous post.

http://centrifying.blogspot.com/2014/04/enter-mac-extending-2014-evaluation.html

Enjoy!

R.P

Basics: The Centrify Agent Cache

Background

In a previous post we described the Centrify agent (adclient) and we mentioned that the cache exists for two objectives:  performance and offline access (availability control in case AD is not accessible). Understanding the cache allows any system administrator to be more effective at using the solution.   The client caches DNS, object and authorization information.

The NSCD service

NCSD stands for name server cache daemon.  It is the best method to retrieve cached information since it's implemented and optimized for each version of UNIX/Linux.  As a basic computer science principle, retrieving items from memory is always preferable than retrieving from permanent storage. The rule of thumb is to always implement NSCD in your systems.  This is a very important design consideration.

The best thing you can do to improve performance of any application that uses Name Server Switch is to implement NSCD.  This applies to Centrify for Unix/Linux.

The Object cache

This cache stores the UNIX-enabled users and managed groups that belong to the client's zone. It's implemented as a database that is stored in the /var/centrifydc folder.  It is used so the client does not have to go to Active Directory for each query and provides support for offline access.

Object expiration and refresh intervals

When objects are retrieved they are tagged with a time-stamp and some of the AD information is retrieved (mainly the update sequence number), while the refresh interval is current, the object will be returned "as is" (no queries to AD are made), if the refresh interval expires, then the object's USN is compared to 

the one in the cache, only if the numbers are different the object will be refreshed, otherwise the time-stamp

is renewed.

The notable exception to this logic is when an end-user attempts to log in; at this point (among other things)
the validity of the account is checked (e.g. is the account disabled, locked, expired, allowed to log in at the time, etc) those checks are performed in real time.
Although there are more parameters to fine-tune the cache, the adclient.cache.expires interval governs when objects are expired. Traditionally, by default is set to 1 hour.

The Authorization Cache

This cache is used for the purposes of authorization (roles, rights etc) and it's separate from the object cache.
It uses the AD azman schema and Centrify algorithms to determine if there are changes to the group memberships (or principals) that have roles and rights tied to them. It uses the USN and the adclient.azman.refresh.interval (set to 30 minutes by default).

Depending on the complexity of the AD infrastructure, the operation can be expensive (in terms of LDAP queries) this is because corporate domains are complex and in certain scenarios it's possible that groups are merged.  Since the memberships are fully enumerated, this is something to think about.

How the Authorization Cache affects the User's ability to log in

Notice that before we have mentioned that for a user to log in they require two things: A UNIX identity, and a role that allows them to log-in. One component relates to identification, the other relates to authorization.
This means that it's possible to have a proper login, UID, GID, etc; but still be unknown to a system because the user does not have a role assigned or the role that is assigned doesn't have a PAM login right.

Note that users can be "listed" in a system.
There are other types of cache, but the two most relevant are the Object and Authorization caches.

What does this all mean?

It means that there's a fine balance to be understood in order to provide performance and high-availability. It also means that there are planning implications to the workings of the agent.  Questions like:

• What is this system used for?
  Very different settings for a shared developer's system than a slave node in a number-crunching system.
• What are the current provisioning/de-provisioning SLAs?
  This opens a great question.  The SLA dictates a lot of settings.  For example in a scheme in which users are provisioned using an IdM solution from an HR system, and there are workflows involved to approve access to UNIX/Linux systems, all components have to be accounted for, Including Active Directory replication intervals.

Adfush described

Adflush is a command line utility that allows system administrators to manipulate the cache.  It shouldn't be used without understanding how the cache works.  

usage: adflush [options]

options:

  -f, --force             flush cache even adclient is in disconnected mode

  -a, --auth               flush cached authorization data

  -d, --dns                flush the adclient dns cache and DC locator cache

  -e, --expire             expire everything in the DC and GC object cache

  -o, --objects            flush only the DC and GC object cache

  -t, --trusts             rediscover the trusted domains

  -b, --bindings           force refresh binding

  -v, --version            print version information

  -V, --verbose            print debugging information

  -h, --help               print this help information and exit.

The type of adflush can have implications from slowing things down a bit, to consuming resources to actually eliminating the ability to log-in offline.  This is important to know for roaming users of Macintosh platforms.  A user that runs a forced adflush while at home will have to wait to get back to the office to log in!!!

Lab # 7: Installing the Centrify agent and joining Active Directory

In this lab

• We will install the Centrify agent in CEN1 using RPM and join Active Directory manually
• We will install the Centrify agent in SUSE1 using install.sh in interactive mode and join Active Directory manually
• We will install the Centrify agent and join Active Directory on SOL1 using install.sh in unattended mode.
• We will use some of the tools and CLI commands including with the base agent.

 Install Centrify on CEN1 using RPM

1. Log in to CLIENT1 with Jessie Matthews (UNIX administrator) account.
2. Open PuTTY and connect to CEN1
3. Go to the /temp folder (or where you copied the Centrify agent files)
4. Decompress the tarball (elevate if necessary)
   tar xzvf centrify-suite-2013.3-rhel3-x86_64.tgz
5. Use RPM to install the base agent centrifydc-5.1.2-rhel3-x86_64.rpm
   rpm - Uvh centrifydc-5.1.2-rhel3-x86_64.rpm
6. To verify that Centrify is installed, run the adinfo command.  Notice the output
   $ adinfo
   not joined any domain
   Licensed Features: Enabled
   The last line means that the agent can see a valid license in AD.

Join CEN1 to Active Directory

Information
Domain to join:  corp.contoso.com
Place to put the computer account:  "OU=Servers,OU=UNIX"
Zone to join:  HQ
User account that can join systems to the target container:  jessie.matthews
Desirable command output:  verbose

1. Type the following command (requires elevation if you're not root):
   sudo adjoin -z HQ -c "OU=Servers,OU=UNIX" -V -u jessie.matthews corp.contoso.com
2. Type the sudo and Jessie's AD password when prompted.
3. To verify that the computer has joined successfully, type the adinfo command:
   [centrifying@cen1 temp]$ adinfo
   Local host name:   cen1
   Joined to domain:  corp.contoso.com
   Joined as:         cen1.corp.contoso.com
   Pre-win2K name:    cen1
   Current DC:        dc1.corp.contoso.com
   Preferred site:    CorpHQ
   Zone:              corp.contoso.com/UNIX/Zones/HQ
   CentrifyDC mode:   connected
   Licensed Features: Enabled
4. Exit the PuTTY session.

Install Centrify on SUSE1 using install.sh

1. Open PuTTY and connect to SUSE1
2. Go to the /temp folder (or where you copied the Centrify agent files)
3. Decompress the tarball (elevate if necessary)
   tar xvfz centrify-suite-2013.3-suse9-x86_64.tgz
4. Use the install.sh and in interactive mode, select a custom installation and accept the DirectControl Agent, select N for the rest of the options.
   How do you want to proceed? (E|S|X|C|Q) [E]:C
   Install the Centrify DirectControl 5.1.2 package? (Q|Y|N) [Y]:Y
5. When presented with the confirmation option, select Y.
   You chose Centrify Suite Custom Edition and entered the following:
       Install CentrifyDC 5.1.2 package: Y
       Install CentrifyDC-nis 5.1.2 package: N
       Install CentrifyDC-openssh 5.1.2 package: N
       Install CentrifyDC-ldapproxy 5.1.2 package: N
       Install CentrifyDA 3.1.1 package: N
       Express authentication mode      : N
       Run adcheck                      : N
       Join an Active Directory domain  : N

If this information is correct and you want to proceed, type "Y".
To change any information, type "N" and enter new information.
Do you want to continue (Y) or re-enter information? (Q|Y|N) [Y]:Y

To join SUSE1 to AD, follow the instructions outlined for CEN1.  Keep in mind that the adjoin command is in /usr/sbin in case you don't have it in your path.

Install the Agent and Join AD on SOL1 using an unattended installation

1. Open PuTTY and connect to SOL1
2. Go to the /temp folder (or where you copied the Centrify agent files)
   You may need to su to root or use Solaris roles to perform the following tasks.
3. Run tar to decompress the tarball
   tar xvf  centrify-suite-2013.3-sol9-x86.tar
4. Edit the following lines in the  centrifydc-install.cfg file.  Uncomment lines if necessary.
   ADJOIN="Y"
   DOMAIN="corp.contoso.com"
   USERID=jessie.matthews
   PASSWD=Jessie's or your user's password
   CONTAINER="OU=Servers,OU=UNIX"
   ZONE=HQ
   Comment the following line (add a # in front of it)
   #CentrifyDC_openssh=
   This is to stop Centrify OpenSSH from being installed with the base package.
5. Save the file.
6. Run install.sh in non-interactive mode
   ./install.sh -n

At this point the script will run adcheck and read the unattended file.  Some output:
Joining the Active Directory domain corp.contoso.com ...
Using domain controller: dc1.corp.contoso.com writable=true
Join to domain:corp.contoso.com, zone:HQ successful
Centrify DirectControl started.
Initializing cache
.
You have successfully joined the Active Directory domain: corp.contoso.com
in the Centrify DirectControl zone: CN=HQ,OU=Zones,OU=UNIX,DC=corp,DC=contoso,DC=com

Verify the objects in Active Directory

Open ADUC and expand the corp.contoso.com domain, expand UNIX, then Expand Servers.

1. Verify that the two new computer objects are present  (refresh if necessary)
   
2. Right-click the CEN1 computer object, select Properties and go to the Operating System tab.
   

Notice that the OS type and version exhibit the proper version.

Add each system to their corresponding computer group

1. Open Access Manager and Navigate to the Zones/HQ/Authorization/Computer Roles node
2. Expand Database Servers, right click Members and select Add Computer
3. In the find box, type cen1;  click on cen1 from the results box and press OK.
4. Expand Web Servers, right click Members and select Add Computer
5. In the find box, type suse1;  click on suse1 from the results box and press OK

Now all the systems are joined in to AD and properly categorized, we are ready to start working with users and accessing systems.

Appendix

Installing Using a YUM Repository
http://centrifying.blogspot.com/2015/11/setting-up-simple-yum-repository-to.html
Installing Using a Simple Chef recipe
http://centrifying.blogspot.com/2015/11/deploy-centrify-and-join-active.html
Tools: Install.sh
http://centrifying.blogspot.com/2015/10/utilities-installsh.html

Basics: Installing the Agent, Joining Active Directory and About Computer Accounts

Installing the Agent - Multiple Avenues

Centrify provides multiple ways for system administrators to install and deploy the Centrify agent.  The agent (adclient) is supported in a variety of systems; the rule of thumb is this:  any commercial system that uses PAM and NSS is likely to be supported.  A great resource is this page.
The installation options are:

• Native packages:  Centrify includes native packages for each platform (rpm, deb, etc.)
  The benefit of native packages is that it allows the use of existing package management and software distribution, repositories or configuration management platforms. Here's an example with YUM.
• The installation script (install.sh):  This is an orchestrator that will install the software based on an interactive menu or an answer file.
  The benefit of install.sh is that it allows for easy manual setup and the integration of scripting.
• DevOps tools like Chef, Puppet, Satellite or Ansible:
  - Example with Chef
  - Example with Puppet
• Deployment Manager:  This is a free tool included with the suite designed to aid in deployments for very small environments.  It's not a substitute for a software distribution or configuration management solution.
  Moderation Note:  Deployment Manager is not covered in this blog.

When the Centrify agent is installed, the binaries are in place, but there are no changes to the system until it is joined to Active Directory.

Joining Active Directory on Windows - Basics

When a Windows computer joins Active Directory (at a very high level) these operations are performed:

1. The user account performing the join operation is checked for the right authorization
2. AD is checked for any duplicate computer account names
3. A computer object is created for the computer account
4. A secret is shared between Active Directory and the Computer
   This shared secret allows for encrypted communications (secure channel), Kerberos ticket processing, etc.
5. Domain Users (and any trusted domains) become users for the computer
6. Domain Administrators can perform administrative duties in the computer
7. Targeted Group Policies are set to be processed
   Note:  to really find out what happens when you join a Windows computer, just read the NETSETUP.LOG file under the system folder  (or %systemroot%)\debug folder.

In general there are 3 major pre-requisites to perform a join in Windows:

• The system needs to be able to resolve the name of the domain (proper DNS configuration)
• The system needs to be able to establish communications correctly
• The user account performing the join is authorized for the operation in the target container

The process is very similar with the Centrify agent, step 5 being the most notable exception.  In standard edition in zone mode, only Unix-enabled users with the proper rights can log in to the AD-joined UNIX/Linux system (centrified system).

Joining UNIX/Linux (and Mac) systems to Active Directory - Basics

 

adcheck - the Quality Assurance tool

adcheck is a tool included with the package that is used to assess the readiness of the system to join AD.  The general syntax is:  ./adcheck-platform domain
E.g. for RedHat 64 bit:   ./adcheck-rhel3-x86_64 corp.contoso.com
It's also a great tool to troubleshoot connectivity issues.   It will check

OSCHK    : Verify that the system is supported by that version of the package.
PATCH    : If there's any pre-requisite OS patches (great for AIX, HPUX and Solaris)
PERL     :  Perl is required to perform the installation tasks and to process group policies.
SAMBA    : If the system is running it, will warn to use Centrify-enhanced Samba for proper UID/GID assignments
SPACECHK : Check if there is enough disk space in /var /usr /tmp
HOSTNAME : Verifies if the hostname is acceptable (localhost and some others aren't allowed)
NSHOSTS  :  Verifies the configuration of this entry in the /etc/nsswitch.conf
DNSPROBE : Will try to communicate the DNS servers.  Will warn if there's only one entry.
DNSCHECK : Same as above.
WHATSSH  : Verifies that the SSH version has been tested and there's no issues.  It will warn to use Centrify-enhanced SSH if you will use Kerberos authentication.  Stock SSH will be fine.
SSH      : Checks the SSH configuration
DOMNAME  : Will check for the domain name, it will warn if it's a .local domain.
ADDC, ADDNS, ADPORT, GCPOR, DCUP, SITEUP: It will perform a series of checks:
- SRV records for the domain
- DNS communications
- Will verify that the proper communication ports are open for each DC and Global Catalog
- Will check for domain controllers in the AD Site.
DNSSYM   :  It will check the consistency of the DNS configuration.
ADSITE, GSITE:  It will check that the subnet is within an AD Site and that the correct site is selected.
TIME     : It will check that the clock between AD and the local time source is not skewed more than 5 minutes (Kerberos requirement)
ADSYNC   : It will check that the domain controllers are in the same page.
Typically, the most common issues are around DNS configuration, Communications, DNS symmetry and clock skews. Solve all the issues before moving forward. Warnings can be typically ignored but should be addressed depending on the situation.  After that, you can move on to join the system

adjoin - to Join Active Directory Domains

With Centrify, computers can be joined with:

• install.sh in interactive or unattended (quiet) mode
• the adjoin command
• with Deployment Manager

All these methods ultimately use the adjoin command.

Joining a system is a privileged operation, so it has to be performed as root or elevating with sudo.

Adjoin Syntax

usage: adjoin [options] domain

options:
  -u, --user user[@domain] user name

  -p, --password pw        user password, prompts if absent

  -c, --container dn       subtree to create below or move to.

                           LDAP is used to create computer object,

                           if computer object does not exist.

  -n, --name comp          computer account name
  -N, --prewin2k name      pre-windows 2000 computer account name
                           must be 19 characters or less
  -D, --dnsname name       optional parameter to override the
                           dNSHostName attribute in the computer object
  -f, --force              overwrite existing joined computer
  -a, --alias alias        add an alias computer account name
  -C, --noconf             do not update PAM or NSS config
  -z, --zone zone          zone to join
  -s, --server ds          domain server for join operations
  -Z, --zoneserver ds      domain server for zone operations
                           useful if zone is in another domain
  -g, --gc ds              domain server for global catalog searches
  -U, --upn upn            user principal name for the account
  -T, --trust              trust computer for delegation, requires
                           administrator permission
  -k, --des                use DES key only
  -P, --precreate          precreate computer and extension object
  -m, --compat             make computer and extension object
                           compatible with DirectControl 2.x.
  -S, --selfserve          use reset computer account credentials to perform
                           a self-service join
  -w, --workstation        join computer to Auto Zone
  -l, --ldap               use LDAP method to create the computer object
  -x, --extramap mapname   add named nss map to nss configuration. Can be repeated
  -i, --noinit             skip cache preload
  -A, --attempt            attempt to grant authenticated users read permissions to PSO objects so that the computer account can read fine grain password security policies in the current domain.
Note that the administrator(s) may also need to grant authenticated users read permissions to PSO objects in trusted domains and forests as well for more accurate password expiration times for cross domain and cross forests users.
  -v, --version            print version information
  -V, --verbose            print debug information for each operation
  -h, --help               print this help information and exit.

Example:  To join the corp.contoso.com domain in the HQ zone, place the computer account in the Servers OU under the top level UNIX OU in verbose mode with Jesse's AD account, the adjoin command is:
adjoin -z HQ -c "OU=Servers,OU=UNIX" -V -u jessie.matthews corp.contoso.com

What happens in a system when you join Active Directory?

Several things happen:

Type	On	File location
Kerberos configuration file	Most platforms	/etc/krb5.conf
	Solaris	/etc/krb5/krb5.conf
Kerberos keytab file	Most platforms	/etc/krb5.keytab
	Solaris	/etc/krb5/krb5.keytab
NSS configuration file	Most platforms	/etc/nsswitch.conf
PAM configuration file	Red Hat Linux	/etc/pam.d/system-auth
	All other Linux	/etc/pam.d/*
	HPUX, Solaris	/etc/pam.conf
LAM configuration file	AIX	/usr/lib/security/methods.cfg
Login control files	AIX	/etc/security/user

The previous configuration is saved to be restored if the system leaves the domain.
(*) Note that these changes only apply to the centrifydc (adclient) program.  If you also install Centrify-enhanced OpenSSH, other modifications pertaining to the SSH server are made.

Sample entries in /etc/nsswitch.conf file after a system is joined to AD:
passwd:   centrifydc    nis   files
shadow:   centrifydc    nis   files
group:    centrifydc    nis   files

What does this mean?
Name Server Switch is a UNIX facility that allows for network-based services, including directory services.  As a consequence:

a) Any NSS-enabled program will check for the user or group in AD (centrifydc), an existing NIS domain, and then in the local /etc/passwd or /etc/group files. 
b) Users from local files, NIS or LDAP can coexist happily, also migrations are easier because they can be done in a phased-approach.
c) This also means that local users, service accounts and super user accounts are available and can be managed locally.
d) Hands-off approach:  any NSS (or PAM, or Kerberos-related) file does not need to be touched.  Centrify makes it work out of the box.  This includes if there's any changes in Active Directory.

Entries in the /etc/pam.d/system-auth

# lines inserted by Centrify Direct Control (CentrifyDC 5.1.0-494)

auth       sufficient     pam_centrifydc.so
auth       requisite      pam_centrifydc.so deny
account    sufficient     pam_centrifydc.so
account    requisite      pam_centrifydc.so deny
session    required       pam_centrifydc.so homedir
password   sufficient     pam_centrifydc.so try_first_pass
password   requisite      pam_centrifydc.so deny

What does this mean?
PAM is a framework to allow program to leverage authentication services.  Therefore, any PAM-enabled program will perform the account, password, session and authorization checks using Centrify's shared libraries in addition to the existing system methods.  For example, if a UNIX-enabled AD user issues the passwd command, since this command is PAM-enabled, the password module will be invoked to enforce things like length, complexity, expiration, etc. in AD  (defined in Group Policy).
At this point you define policy once (in AD) and it will be enforced in the Centrified UNIX/Linux system in addition to Windows.  More process and policy reuse!

The opposite of joining a domain is leaving the domain, and since Centrify's tools are very consistent the command is adleave.

How do I know if a system is joined to AD?
Use the adinfo command.
If the system has the Centrify binaries but is not joined to a domain, the output is
No joined to any domain
Licensed Features: Enabled

If the system has the Centrify binaries and is joined to a domain, the output is
Local host name:   suse1
Joined to domain:  corp.contoso.com
Joined as:         suse1.corp.contoso.com
Pre-win2K name:    suse1
Current DC:        dc1.corp.contoso.com
Preferred site:    HQSite
Zone:              corp.contoso.com/UNIX/Zones/HQ
CentrifyDC mode:   connected
Licensed Features: Enabled

Notice that the output of adinfo is very helpful to understand what is going on in your system and the agent.  You can tell how the system was joined, to what domain, what domain controller the agent is talking to, and if there's communications to AD.

About Computer Accounts

In Active Directory, computer accounts (just like user accounts) have passwords too, and by default they change automatically every 30 days, this applies to AD-joined systems using Centrify.
Computer accounts can belong to AD Groups.  In fact, Centrify Computer Roles (the collections of systems) are all contained within a previously created AD group.  E.g. in our lab, we have a UNIX Database Servers group, to hold the computer accounts of Database Servers.

Process and knowledge reuse

All the processes outlined by Microsoft (add, remove, move, pre-create, disabling, renaming, etc.) can be performed with centrified systems.  http://support.microsoft.com/kb/320187 
These operations affect provisioning processes, operations and even group policy processing.  Most likely, any major organization has processes in place for Windows computer accounts and they can be leveraged for the UNIX/Linux  (or Mac) systems.

Update 1  (March 2015)

This update is based on feedback, the original post has been left intact, typos and all.

Should I install Centrify-enhanced OpenSSH?
Short answer:  No
Why would you need Centrify OpenSSH?

• If you have a version of SSH Server that is not compiled/configured for PAM support.
  Older box UNIXes used not to be ready out of the box (e.g. old HPUX, AIX, Solaris)
• If you want granular PAM access controls to be set up automatically for you.
  For example, if you wanted to set up an account to be able to only scp a file, but not login. Centrify-enhanced OpenSSH has all those settings done for you.
• If you want optimized Kerberos or GSSAPI support on SSH
  This version of OpenSSH is compiled to use the Centrify AD shared objects and MIT Kerberos tools.  This means that in scenarios with complex AD infrastructures (one-way trusts, etc) you don't have to worry about SSO working.
• Smartcard Environments
  Somewhat related to the previous bullet.  In some environments, interactive sign-on is with Smartcard, then the rest is via Kerberos.

Basically the answer is No, but choosing Yes, helps in many advanced scenarios.

Should the system be restarted after Centrify installation and AD join?

The answer really depends.  Most of the time the answer is no, but the determining factor is have long-running daemons (e.g. like DB2 on UNIX, or X-Window, etc), then a restart is in order.  This is because unlike dynamic daemons (like sshd) these programs only read the PAM configuration at start-up.

A note of warning

My advice is that you reboot the system PRIOR to installing any new program.  This is because most of the pride of UNIX, Linux and post 2008 windows admins is uptime, but the longer the system is up, the more possibility that changes may have been made while the system was running.  Services may have been altered, environment variables modified but not committed, etc.  

If the system restarts, and something is not right, the logical conclusion will be to blame it to the last program that was installed. This leads to flawed troubleshooting and possibly introducing additional issues.  So, prior to a major change, have the system(s) rebooted and working again for a week, then the next window the programs or upgrades can be performed and any failures can be attributed to the recent event with accuracy.