Business Problems: Leveraging UNIX-enabled AD Groups and Kerberos to Control Unix/Linux/Mac Access to a Windows Share

Background

In the previous post we discussed how to leverage the Kerberized environment provided by Centrify's UNIX/Linux client and the computer's AD account to access a read-only Windows (CIFS) share. By leveraging Kerberos, the mount command (or filesystems table) does not have to use a cleartext password.

Windows (CIFS) shares are all over the Enterprise (for files and printers) and most likely a read-only share is not a very practical example, however, a departmental share that is used by a workgroup to share files is much more common.  This time, we will implement an example.

The Marketing Share

In our mock example we have a share in APP1 set for the Marketing department.  Both Elaine and J.Peterman are members of this department, however they consistently access these shares from OS X, Unix and Windows machines.  Today a Marketing Share Access AD group is used to control access by way of memberships.

Requirements:

• Marketing users should have the ability to exchange files (read/write)
• The current heterogeneous environment consists of Windows, Mac OS X and UNIX/Linux stations
• Users should be able to access the information from any type of platform
• Controlling access to the Windows share should not deviate from the current process.
• Users should alingn with the security policy and don't use cleartext passwords when mounting CIFS shares.

Challenges:

• This would not be an issue in a homogeneous environment
• Identity is key, UNIX identities should be uniform across platforms (for users and groups)
• Users should not have access to the root account to use the mount command

The Proposed Solution:

• Centrify the non-Windows platforms  (Mac OS X, Unix/Linux) - this provides the AD Integration, Kerberos environment and Privilege Elevation
• Leverage a common UID/GID scheme by leveraging Zones and the Autozone
• UNIX-enable the Matkeing Share Access AD group.
• On UNIX Platforms, allow the Marketing users to use the mount command with privileges

Video Labs

Lab Part I - Initial Setup (13.30 min):  https://www.youtube.com/watch?v=flp4L200o4c 
Lab Part II - Verification (11 min):  https://www.youtube.com/watch?v=M-fdtZeYYtk 

Elaine's mount command (CentOS 6.5):
dzdo mount -t cifs //app1.corp.contoso.com/marketing /mnt/share -o sec=krb5,user=elaine.benes,uid=1149240407,gid=99998,group=marketing-share-access,umask=0002,file_mode=0775,dir_mode=0755 --verbose
Share Permissions:
(this can be improved since the rest of the world would get read access given that ACL)

NTFS Permissions:

Role created for Marketing Users


We can improve on this by using Automount to access the user's Windows home.

Utilities: addebug

Background

The addebug command is used to use the log feature of the Centrify client for UNIX, Linux and Mac OS X.  Logs written to /var/log/centrifydc.log, however in HP-UX the location is /var/admin/syslog.  Only turn on debugging if you're troubleshooting a problem and you'll have to elevate (with sudo or dzdo) to use addebug and review the log.

Location

The utility is located in the /usr/share/centrifydc/bin folder.

Basic Usage

• Use /usr/share/centrifydc/bin/addebug on to start debugging
• Use /usr/share/centrifydc/bin/addebug off to stop debugging 
• Use /usr/share/centrifydc/bin/addebug clear to clear the logs

For more information, read the manual page for addebug  (man addebug).

What to look for

Modules

Centrify  implements directory lookups with Name Server Switch (NSS) and Pluggable Authentication Modules (PAM) for authentication, this means that you need to become familiar with some of  these calls:

• NSS calls:  These are name server switch function calls.  For example (oversimplifying) an application may use a call to determine the user's UID from the login name.  These calls start with "NSS".
• PAM calls:  These function calls implement the account, authentication, session and password modules that are implemented with the solution. These calls start with "pam_"

File Descriptors

FDs identity the transactions, they make it easy for the log reader to follow the same transaction.  They are labeled with "fd:nn"  (nn is the descriptor number).  

Keywords, Phrases and Functions

During the troubleshooting process, you'll become familiar with several keywords that will help you determine what happened during the transaction.  For example, here are a few:

• pam_sm_authenticate:  search for this call to determine the beginning of PAM authentications.
• "User is ours" / "User is not ours":  This phrase appears in a file descriptor when the function PAMUserIsOurResponsibility determines that the user is indeed an AD user that needs to be processed or not.

Labs: Testing the Availability Controls of Centrify for UNIX/Linux/Mac

In this Lab:

1. We'll use the dns.block parameter to use the domain controller fail-over capability.
2. We'll simulate a network failure on UBU1 and use the offline cache.
3. We'll attempt to kill the adclient process as a regular user
4. We will corrupt the /etc/nsswitch.conf and krb5.conf files 
5. We'll simulate an abnormal ending of the client process to invoke the watchdog process
6. We'll describe the domain controller telemetry process

Security Corner: Centrify UNIX Agent's Availability controls

Availability is the security principle that states that information should be available when needed and authentication mechanisms are required to be highly available since they are the door to the information that may be needed to make a business decision.

The Centrify agent for UNIX has a great advantage since it enables those platforms to integrate to Active Directory.  Active Directory was created with high-availability in mind and when properly implemented(*) provides:

• Replication:  Changes in the AD database are replicated to other domain controllers.  This process is called convergence.  Replication applies to LDAP objects and files.
• Multi-master:  Unlike NTDS 4.0 that relied on a Primary Domain Controller (PDC) role for write operations, in AD all DCs are writable.  There are some exceptions in what are called Flexible Domain Master Operations roles.  
• Sites and Services and DNS SRV records:  AD leverages DNS to provide the closest-to-client services;  any services that rely on these capabilities will be able to access the best connected service based on network location.

(*) Sadly, on the field (especially on lab environments) we see a lot of single DC environments and improper configuration of AD Sites and Services.  When we see the infamous "Default-First-Site-Name" displayed it decreases the credibility of the environment's maintainer.

One of the biggest concerns for any UNIX/Linux Systems Administrator is not having the ability to do their job because authentication scheme is not available;  as a matter of fact, that is why many of them are biased on using shared accounts (like root), because those accounts are reliably available.  Unfortunately this perpetuates the poor security practice of sharing those sensitive accounts.  The benefit with Centrify is that the mitigation for HA happens automatically without the need to re-target LDAP services or reconfigure krb5.conf files.

How does Centrify mitigate the Availability question?

Any true risk is mitigated by preventative, detective and corrective controls.  The controls deployed by Centrify are:

1. AD Sites and Services compatibility:  this means that the agent will pick an alternative domain controller based on the AD site topology.  (Corrective/Preventative)
2.  Performance Optimizations:  the agent performs its own telemetry calculations to determine if it's talking to the most optimal domain controller. (Preventative)
3. No AD available:  In case of a network-level failure (inability to connect to any DC) the agent provides the offline credential cache. (Corrective)
4. Abnormal termination:  the cdcwatch process is a watchdog that will spawn a new agent process in case of an abnormal termination.  (Corrective)
5. System file corruption:  Any changes in name server switch (NSS) (nsswitch.conf), Kerberos (krb5.conf) or pluggable authentication module (PAM) config files is monitored and rolled-back to proper operational mode if needed. (Corrective/Preventative)
6. Process Protections:  All agent-related processes (and the watchdog) are owned by root. (Preventative)
7. Logs and Core Dumps:  Centrify integrates with the syslog facility and provides its own core dumps in case of an abnormal termination. (Detective)

As you can see, Centrify's agent implements a high-level of controls to ensure high-availability.

When will a privileged system or local account be needed?

In two instances:

a) Normal termination of the Centrify agent process:  The agent has been stopped, therefore there's no communication with AD or the cache.  The authentication stack will continue on.  For example, on your /etc/nsswitch.conf you may see a line for users (or groups like this):

passwd         centrifydc   files

In case the adclient process is not available, any local account will be granted access.  This is the same under normal operations.

b) Single-user mode:  If the system abends and falls into that mode, the only account that can access the system is root.

Command Line Tool tips

The best command to troubleshoot the agent is adinfo.  Use it with the --test option perform connectivity tests.  Sample output:

george@suse1:~> adinfo --test

Domain Diagnostics

  Domain: corp.contoso.com

  Subnet site: CorpHQ

    DNS query for: _ldap._tcp.corp.contoso.com

    Found SRV records:

      dc1.corp.contoso.com:389

  Testing Active Directory connectivity:

    Domain Controller: dc1.corp.contoso.com

      ldap:      389/tcp - good

      ldap:      389/udp - good

      smb:       445/tcp - good

      kdc:        88/tcp - good

      kpasswd:   464/tcp - good

      ntp:       123/udp - good

Tips about conducting Disaster Recovery tests

Disaster recovery with Centrify for Servers can piggyback on the AD infrastructure and work performed for Windows domain members.  Unix/Linux systems just become another "customer of AD" this means:

• If you're performing a total (from scratch) AD recovery, AD DCs and DNS go first, then the Zone data has to be rebuilt.  UNIX/Linux systems rebuild happens in parallel, once ready, load the agent and join the zone; at that point instead of using the root account, you can switch to dzdo.
• If you're performing a partial or restore of existing systems, restore the AD infrastructure first;  you can work in parallel with UNIX/Linux systems  (credentials will be cached up to the moment of the backup or snapshot) and access will be offline - once AD is online the agent will go in connected mode.
• If you're testing with a disaster recovery site that goes online during tests your strategy may vary. In some outfits its not desirable that the agent fails over to the DR site; so using the dns.block parameter (or the Blacklist DNS DC hostnames GPO) to have those DCs blocked during production is desirable.  However, during the disaster, it should be scripted (or automated) that the DR Site DCs will be unblocked so they are eligible for fail-over.  Another variation of this test is to block the production DCs and only allow the DR DC (that is a crude/forced DR test).
• In larger environments, it's quite common that not all trusted sysadmins have had logged on to all target systems, that is why Centrify has the ability to pre-validate (or pre-cache) user credentials.  Prevalidation will be the subject of another posting.

Description of the dns.block parameter

This configuration parameter specifies which DCs should be filtered out of the pool of existing DCs for the domain.  This is useful when a DC is behind a firewall, has been decommissioned but there's a stalled object or for DR tests.

The parameter in the /etc/centrifydc/centrifydc.conf file works by specifying the directive followed by the FQDNs of the DCs in question separated by commas.

dns.block: dc1.corp.contoso.com,exp1.corp.contoso.com

If you prefer to use GPOs, the path is:  Computer Configuration > Policies > Centrify Settings > DirectControl Settings > Network and Cache Settings > Blacklist DNS DC hostnames group policy.

Labs