Business Problem # 2: Network Shares, Granular Privileges, Security, Availability, Secondary Groups and Usability Enhancements

Background

After conquering Business Problem #1, there are some other challenges related to network shares, privilege management and other usability requests.


Network Shares

• End-users are calling in with issues accessing their files over the network (permissions issues) in NFS and Samba shares
• Some of these shares are hosted in non-centrified systems and appliances that are closed boxes.

Granular Privileges

• Database users are requesting the ability to run certain utilities with in the context of certain privileged local accounts.
• Web Administrators are requesting the ability to perform certain operations with the Apache server.
• Offshore operations:  The company has outsourced some functions (backup operations) to an external group.  They need to perform backups in late hours of the night.

Security Enhancements

• Access reports are produced with more efficiency, however, the Security department would like to be able to generate them on their own without the assistance of the UNIX administrators.
• Passwords stored in script utilities:  there is an initiative, now that there are better tools, to eliminate the practice of using service accounts and embedded passwords in scripts or with reversible encryption.

Enhanced Availability

• Since the number of servers is increasing, especially in remote sites, there's a need to make sure that a limited set of trusted administrators can access the systems in the event of an outage, even if they have not signed into the system before.

Usability Enhancements

• Certain users are requesting that since the identities are consolidated in AD and the OpenSSH versions deployed support the Generic Security Services Application Program Interface (GSSAPI) if it's possible to get silent sign-on to UNIX/Linux servers using SSH.

Secondary UNIX groups

• Secondary UNIX groups are still used for different purposes.  Although they are not used anymore for access or privileges with sudo, they are still used for various applications.  There's an interest in streamlining this process and make it as automatic as possible.

Stakeholder Concerns

UNIX/Linux Admin	-          We should be able to maintain the auto mount maps to NFS shares. -          The process of provisioning Secondary groups should be aligned with the existing process of user provisioning.
Security Analyst	-          Additional rights can be granted to Database and Web users as long as privilege accounts are not shared. -     The offline mechanism for trusted administrators in remote servers, should not store passwords in the clear;  this would conflict with another initiative.
IT Manager	-          Users are allowed to leverage SSO, as long as it doesn't affect the deployment schedule or require additional components.
NetApp filer administrator	-          The filer is a closed system.  Any solution should use the facilities exposed by the appliance.

Planning Activities 

Network Shares  (UNIX Admins, Appliance  admins)
During the initial rollout, some identities were overridden at the system level, this means that when users log into those systems there is inconsistencies with their identities.  These systems need to be converted.
In addition, there are stand-alone servers running Samba and NFS that need to be aligned with the new solution.
Finally, there's NetApp filer that needs to be integrated to the system, leveraging Centrify tools.

Additional Privileges  (all)
After working together with the Security Analyst, Web and Database Managers, the UNIX administrator decide to extend the privileged rights for the Database users (DBAs) and Web Administrators.

• DBAs: 
• Will continue to access only database systems via SSH
• Will be able to elevate to the db2inst account
• Will be able to run the db2 commands as the db2inst account
• Web Admins can
• Will continue to access only web systems via SSH
• Will be able to edit the files in the /etc/httpd/conf
• Will be able to control the status of the httpd service
  Controls should be implemented to limit abuse.
• Offshore Operators
• Will have SSH access to Utility Servers
• Will be able to run the tar command to perform home directory backups
• The privileges will be limited from 10 PM - 6 AM

Security Enhancements (UNIX admin, Windows Admin, Security Analyst)

Reporting for Security Analysts

Since the reporting facility of Access Manager is an MMC snap-in, the Windows administrator states that it would not be a problem to allow read-only access to the Security Admins.

Improving Script/Service Account Security

As part of the initiative to have better security, the UNIX administrator will explore options to eliminate the practice of knowing service account passwords and the possibilities to improve the security of scripts that leverage those accounts.

Usability (UNIX Admin, Security Analyst)

There should not be any issues because both versions of SSH Server and client support GSSAPI.  No additional components are required.

Business Problems: State of Business Problem # 1

Background

In the description of business problem # 1, we outlined that Contoso was looking to accomplish the following goals:

• Eliminate the usage of shared privileged accounts 

• Make sure people are uniquely identified (PCI 8.1) 

• End users will authenticate to Unix systems with their AD credentials 

• Make sure that when accounts are enabled/disabled/constrained in their Active Directory, the same is expanded to Unix and Linux systems 

• The security policy for passwords needs to be uniform across platforms (Windows, UNIX, Linux) 

• User passwords can be changed from Windows/Unix/Linux without synchronization.

Eliminate the usage of shared privileged accounts 

Shared privileged account use has been limited by using Centrify-enhanced sudo (dzdo).  Although our UNIX admin can still do things like "dzdo su -" the technical controls are in place.  All that is required is the detective controls to complement this capability.  We will fine-tune the privilege management later.

Make sure people are uniquely identified (as in PCI DSS 8.1)

Users are uniquely identified in Active Directory.  Each user has a unique User Principal Name (UPN) and sAMAccountName.  In a more complex scenario, this can also be associated to an EmployeeID.  Notice that in the context of the UNIX identity, Centrify offers the flexibility of Identity Overrides.

End users will authenticate to UNIX systems with their AD Credentials

Users can authenticate with their AD UPN, with their login name or any overridden login name at the zone, child zone or system levels.  The authentication uses Kerberos, therefore there's the benefits of encryption, ticketing system (no passwords don't travel on the wire) and high-availability.

Make sure that when accounts are enabled/disabled/constrained in AD, the same behavior is experienced in UNIX/Linux

First off, by default, All AD users don't have access to the UNIX/Linux systems joined to the domain via Centrify.  They need a UNIX identity and a role that allows them to log in.  Least access is enforced by default. Centrify users PAM, and the account module in the PAM stack will check:
- if the account is enabled, disabled or expired
- if the account is allowed to log in at the time  (at the AD account and Role level)
- if the account is allowed to log in from that workstation (at the AD account and Role level)

The security policy for passwords needs to be uniform across platforms (Windows, UNIX, Linux, Macs)

This has been accomplished by way of consolidating the accounts identity in AD and by using the Centrify Agent's group policy capability and it's ability to perform these transactions using Kerberos.

Your AD password will expire in 26 days  <= this is also from GPO
Last login: Wed Jan  8 16:26:59 2014 from client1.corp.contoso.com
jmatthews@suse1:~> passwd
Changing password for jmatthews.
Changing password for jmatthews
(current) AD  password:
Enter new AD password:  <non-compliant password>
Confirm new AD password: <non-compliant password>
The password change operation failed due to a policy restriction set by the Active Directory administrator. This may be due to the new password length, lack of complexity or a minimum age for the current password.

External Benefits

• The processes of  provisioning (and deprovisioning) of UNIX identities as well as Role Assignments  can be consolidated manually, programmatically or with an Identity Management solution.  These are efficiencies.
• Any existing self-service (or assisted) password reset process has been flattened (there's no deviations for UNIX/Linux accounts), this is because the identity is unique.
• As a by-product of joining the systems into AD, there's higher visibility to these assets via AD (this means that tools like System Center can be used to account for these assets) and more security visibility - successful and failed login attempts to UNIX systems are viewable in the Security log of the Domain Controllers.
• The infrastructure is reused, the knowledge is reused, the processes are reused.

Individual Stakeholder Concerns 

(comments in RED)

UNIX/Linux Admin	-          It’s becoming very hard to keep track and maintain local accounts. This concern has been addressed and there's mechanisms to continue to conserve local identities if necessary.  The recommendation or end state should be a normalized namespace. -          We have some old NIS servers and maps that need to go away (legacy) We have yet to address this.  Future postings. -          Each time there’s I need to scramble to make information available to auditors The fact that we have implemented RBAC and that the information is stored in AD, makes the use of the  "Show Effective User Rights" and Reporting facilities of Access Manager a great tool to produce this information. -          The root, oracle and other service accounts are shared; it’s hard to establish who did what. UNIX-enabled AD users can use Centrify-enhanced sudo to perform privilege actions as these accounts without knowing the password, accountability is increased because users perform functions as themselves and these actions are written in the system log.  More on this on the Privilege Management topics. -     Ideally, any service accounts are managed within the UNIX system and not provisioned in the directory Service accounts can remain locally, and by way of using PAM, this is not an issue to coexist with Centrify. -     I am concerned that if AD (or the network) is not available, it will be impossible to log in to servers. Centrify implements several high-availability scenarios:  first, it's AD sites aware, which means that it's smart enough to pick another domain controller in case the current one is not available.  If no network or AD is available, Centrify has the offline cache to rely on. -     I am concerned of not being able to perform functions to do my job (superuser) or that it will be hard to elevate to get rights The Centrify agent implements privilege management modules that allow accounts to run with privileges.
Security Analyst	-          We will start processing credit card data soon, therefore I need to make sure that privileged accounts are not shared -          We need to make sure that everyone has a unique identity -          We need to carry over the security policy defined on Windows to UNIX (password policy:  length, complexity and expiration) See above. All objectives have been met.
IT Manager	-          Our workflow for provisioning and password resets is very complex.  When somebody needs a UNIX account for our systems, more teams need to be involved. -          We have to be ready to process credit card data -          We have an Identity Management System (FIM) and we would love to leverage some of the existing processes       The initial PCI requirements 8.1 and 7 are covered. Since identities have been consolidated in AD, the provisioning, deprovisioning, self-service or assisted password reset, privilege management processes can be integrated easily to any tool, by just adding (or removing) users from Active Directory Security groups.  Automatic Provisioning with ZPA was demonstrated in this post and video.
Windows Administrator	-          Whatever solution is coming in should not require schema extensions to AD and no Software in domain controllers. In the preparation lab and the installation lab we did not require any schema extensions and we didn't even go into the DC. -          We should be able to keep the same organization and naming conventions that we use in the directory today. In the preparation lab, we proved that UOs and Groups can be leveraged to establish a storage and governance model in AD, same model works for Group Policy processing.

Basics: Using Group Policy on UNIX/Linux and Mac OS X Systems with Centrify

Background

As per Wikipedia: "Group Policy provides the centralized management and configuration of operating systems, applications, and users' settings in an Active Directory environment"  but what does this mean:

• For the IT Administrator:  It allows the enforcement and management of computer and user settings to be much easier.  It's also easier to achieve standardization from a central administrative place.
• For Security:  It allows for security policy definition in a single place, with enforcement in multiple endpoints.
• For End-Users:  It means that the two parties above can control my experience.  :-)  All joking aside, group policies can make the user's experience more consistent.
• For IT Management:  Group Policies promote better compliance, more standardization and operational efficiency.

Centrify provides Group Policy objects for the UNIX/Linux (including GNOME), Mac OS X and in the user suite for iOS, Android, etc.

How does group policy work?

In a Windows network, client reads a special share in the SYSVOL share of a domain controller and based on the scope (Site, Domain, OU), the processing rules and security settings they may or may not be processed.  They can change computer settings (upon reboot) or user settings (upon login) or after the gpupdate command is issued.

But UNIX/Linux systems are not Group Policy capable?  Yes, this is true.  Unless the system has been Centrified.  The section below explains how Centrify can process group policies.

Note:  Group Policy processing is available on the licensed versions of Centrify for UNIX, Linux and Mac OS X, with the exception of the Password and Kerberos policy that can be enforced in the Express (community) version.  This blog does not cover Centrify Express, but the reason why this is possible is due to the shared objects that comprise the Account PAM module provided by Centrify.

How does Centrify enable Group Policy for UNIX/Linux and Mac Systems?

There are several components that allow group policies to be processed in UNIX systems.

On the Windows side:  Group Policy templates and definitions (.adm and .xml) files provided with the Centrify Suite. A trusted administrator links and configures the GPOs, which in turn are copied in the SYSVOL share of the domain controller (and replicated in the domain).

On the UNIX/Linux/Mac OS X system side:  The Centrify agent (adclient), mapping files, the mapper process, a virtual directory and config files.

The simplified process works like this:

1. At the group policy refresh interval or when the adgpupdate command is issued, adclient reads the SYSVOL share of the current domain controller.
2. The client determines which group policies apply according GP processing rules.
3. The group policies are interpreted and implemented by the mappers process
4. The corresponding changes are made to the configuration files in the system.

For example, the Windows logon banner, specified in the "Interactive logon: Message text for users attempting to log on" GPO under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options is mapped to the text in the  /etc/issue file in the UNIX/Linux system.

Other very important GPOs are verified by the PAM Password Module, like these options on the "Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy" Section:  

Enforce password history

• Maximum password age
• Minimum password age
• Minimum password length
• Password must meet complexity requirements

Process Reuse:  This means that all the password policies can be reused in the UNIX, Linux and Mac OS X systems that are joined via Centrify commercial editions!!!

Video Chalk-talk

For a deeper dive on group policies provided for Mac OS X by Centrify, take a look at this chalktalk:

Documentation

• Understanding OS X Group Policies (public since December 2016)
• Centrify 2016 Group Policy Guide  (Centrify Customers)

Group Policy-related Centrify Utilities

adgpupdate

The adgpupdate command is the equivalent to the gpupdate command in Windows.  What it does is described above.  

usage: adgpupdate [options]

options:

  -T, --target <Computer | User>

                     Only refresh the computer or user policy (default both).

  -V, --verbose      Print debugging diagnostics to stderr.

  -v, --version      Print version information.

  -h, --help         Print this help text.

Sample output:

$ adgpupdate -V

session opened

Refreshing Computer Policy...

Success

Refreshing User Policy...

User Policy disabled on this machine.

To view the settings processed by group policy, inspect the gp.report file under /var/centrifydc/reg/machine  (and /user if the system is a Mac or if it was enabled for GNOME policies)

adgpresult

In the 2015 version of the Centrify DirectControl agent (5.2.2), the adgpresult command has been introduced.  This command works just like the Windows gpresult tool.  It shows all the group policies processed locally by the agent in a very neat output.

$ adgpresult --help
usage: adgpresult [options]
    e.g. adgpresult -a
    or adgpresult -m -u uname1 -u uname2 ...
options:
    -a, --all           Dump both gp settings for machine and current user.
                        Default option if no option is given.
    -m, --machine       Dump the machine's gp settings.
    -u, --user <name>   Dump the specified user's gp settings.
    -h, --help          Print this help information and exit.

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.

Business Problem # 1: UNIX Authentication and Identity Management

Background

Our fictitious company (Contoso):

• Their core competencies are not in Technology  (unlike a Google or Apple)
  This means that they can't profit or showcase what they develop in house.
• They have limited staff and are cost conscious
• They value operational efficiency
• They have agreed to maximize their investment in Active Directory:  People, Process, Technology.

Problem # 1:  Authentication and UNIX Identity Management

Contoso is looking to start processing credit card information, and based on PCI, in the first phase they need to start enforcing certain rules like:

• Eliminate the usage of shared privileged accounts
• Make sure people are uniquely identified (PCI 8.1)
• End users will authenticate to Unix systems with their AD credentials
• Make sure that when accounts are enabled/disabled/constrained in their Active Directory, the same is expanded to Unix and Linux systems
• The security policy for passwords needs to be uniform across platforms (Windows, UNIX, Linux)
• User passwords can be changed from Windows/Unix/Linux without synchronization.

UNIX/Linux Admin	-          It’s becoming very hard to keep track and maintain local accounts. -          We have some old NIS servers and maps that need to go away (legacy) -          Each time there’s I need to scramble to make information available to auditors -          The root, oracle and other service accounts are shared; it’s hard to establish who did what. -     Ideally, any service accounts are managed within the UNIX system and not provisioned in the directory -     I am concerned that if AD (or the network) is not available, it will be impossible to log in to servers. -     I am concerned of not being able to perform functions to do my job (superuser) or that it will be hard to elevate to get rights
Security Analyst	-          We will start processing credit card data soon, therefore I need to make sure that privileged accounts are not shared -          We need to make sure that everyone has a unique identity -          We need to carry over the security policy defined on Windows to UNIX (password policy:  length, complexity and expiration)
IT Manager	-          Our workflow for provisioning and password resets is very complex.  When somebody needs a UNIX account for our systems, more teams need to be involved. -          We have to be ready to process credit card data -          We have an Identity Management System (FIM) and we would love to leverage some of the existing processes
Windows Administrator	-          Whatever solution is coming in should not require schema extensions to AD and no Software in domain controllers. -          We should be able to keep the same organization and naming conventions that we use in the directory today.

Planning Activities (stakeholders)
These are the planning activities to address this problem with the corresponding stakeholders.  This can be the biggest challenge, especially when the status quo is to work in a fragmented and independent way.  Decisions need to be made, compromises will have to be reached, etc.  All projects have a cognitive, cooperation and coordination aspect.  Assuming our stakeholders find the right balance, an initial set of activities include:

Access Governance  (all)
After working together with the Security Analyst, the UNIX administrator decides that although the tool provides the flexibility of granular access and privilege management, the initial goal is to implement a model that provides an easy path for productivity.  Because of this, there are two types of systems:

• Database Servers
• Web Servers

Access and Privilege Management (all)
And two roles:  System Administrators and Regular Users.
System Administrators have the right to log in to all systems.

DBAs are allowed to log in to all database servers.
Web Administrators are allowed to log in to all Web servers.
For now, the company will continue to use their sudo scheme for privilege management

Naming Conventions and Object Storage in AD (Windows and UNIX Administrator)

After researching the product, the Windows Administrator comes up with a storage strategy for the new Unix objects:

UNIX OU (top level)	to store the top level objects
Servers OU	to store the Unix computer objects
Computer Groups OU	to the security groups for grouping computers
Roles OU	to the security groups related to Unix Roles
UNIX Groups OU	to hold the Security Groups that map to UNIX groups
Licenses OU	to store for the license information
Zones OU	to store the container objects used by Centrify to group systems.

Provisioning
Users:  Provisioning of UNIX identities will happen manually for now.  The UNIX administrator will work to perform an initial migration of the existing users.  From that point on, new users must have a unique UNIX identity.  Access and roles will be provisioned after the user is set up.
Systems:

• UNIX administrators will coordinate with the Windows DNS admins to add host records manually for now.
• Once a system has joined the domain, the Centrify agent will ensure that the UNIX systems are in sync with the AD domain controller's time.  This is is a Kerberos requirement.

Delegation (UNIX/Windows Admins and Security Analyst)

• Active Directory administrators will delegate the administration of the UNIX OU to the Unix/Linux Sysadmins.  This will allow them to provision UNIX identities, create security groups, join systems to Active Directory, etc.
• If a GPO is required, it will require the intervention of the Windows Administrators to ensure the proper scope.

Infrastructure (UNIX/Windows Admins and Security Analyst)

• Today the DNS and time services (NTP) are fragmented, there are duplicate services for each infrastructure (Windows/UNIX)
• UNIX systems that are integrated in to AD will use the AD DNS and time synchronization schemes to ensure proper authentication functionality.

Monitoring  (UNIX/Windows Admins and Security Analyst)

• Failed Attempts to log in to Unix or Linux servers must be logged 
• Privileged actions should be registered with the identity of the end user that performed it.

Tools

• Unix Administrators will require at a minimum Active Directory Users and Computers to review UNIX identities stored in AD.
• The Centrify tools will be installed in a shared server (APP1) as well as in the workstation for UNIX administrators (CLIENT1)