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.

Security Corner: How your Centrify Deployment Affects your Existing Security Policies, Procedures and Standards

Background

Identity and Access Management capabilities fall under the umbrella of Information Security therefore any technical implementation (such as Centrify for Servers) needs to align with IT Security principles and procedures.  In the Security corner, we discuss topics related to information security and how they relate to these capabilities.

Blog Objectives Refresher

As per our first post, this blog's mission is to:

• Provide general information, discuss use cases and provide step-by-step guides
• Minimize or eliminate IT capability fragmentation
• Promote operational efficiency and process reuse
• Discuss problems from the business and technical perspective
• Project & Capability Management (Plan-Do-Check-Adjust)
• Promote proper security practices

That is quite a lot to balance, but hopefully the topics in this section can focus on the security side of the problem.

The Security Process

In our first post we outlined that all security measures should flow from a sensible risk assessment exercise. Depending on the nature of the business, organizations may protect from (in no particular order):

• Financial loss (mainly in for-profit organizations - here's a current topic)
• Reputation hits  (this affects for-profit organizations, but less and less - e.g. was there any fallout from the TJX data-breach?  I'm sure that management blunders, cost more to non-profits)
  Note:  Some things just don't make sense, but I guess that's the world we live in.
• Risk of injury or human life (or other externalities)
• And more....

The result of an assessment, as it relates to Information Security produces what are called Policies, Guidelines and Standards.  Although we can find a better description somewhere else online, let me try and simplify:

• Policy:  What shall be done.  (Regardless of how)
• Standard:  Establishes what should be the result (What/Per platform)
• Procedure:  The template or recipe on how it should be done in a particular use case  (How)
• Guideline: The best practice to shoot for.
  

We already stated, that a properly implemented countermeasure, includes technical, procedural and administrative controls that are preventive, corrective and detective.  

For example a policy statement like:  "the organization shall limit end-user Internet misuse"  (that I just came up with) may imply controls like this:

• Standard:  The corporate browser is Mozilla Firefox, configured to use a proxy server.
• Standard:  Microsoft TMG is the official Proxy Server, implemented with HTTP and HTTPS access with a filter to block all "Liability" categories.
• Standard:  Group Policies will be deployed to limit access to the Options-Advanced-Network tab of the browser.
• Standard:  All questionable internet usage will be reported and consolidated into a SQL server back-end.
• Guideline:  When possible, make the user acknowledge the fair use statement when users go to questionable sites.

The browser and proxy server standards are the preventive controls, the TMG filter is the corrective control and the reporting is the detective control.

Notice that these standards are mostly technical controls.  For a proper implementation, things that are relevant:

• Standard (administrative):  Background checks for prospective employees
• Standard (administrative):  Security policy attestation (proper use)
• Standard (procedural):  Discuss proper use with employees as an item for performance reviews.
• Guideline (procedural): Assign some points to proper use in the Housekeeping performance category.

Now we have some additional administrative and procedural controls that can prevent the hire of candidates with history of misuse of corporate assets, we are requesting acknowledgement and attestation of the fair use guidelines, and the fair use is being discussed as part of performance reviews.

Technical controls alone can't mitigate all risks, especially when there are human beings involved.

How your Centrify Implementation Affects your Standards and Procedures

With Centrify, the UNIX/Linux administrator has more tools at their disposal, this means that principles like least access, least privileges, separation of duties and more are easier to implement.  Let's look at an example - the password policy.  (by the way, here's a great example of a password policy)

Policy:  End users shall protect passwords and implement them in a way that are not easily guessable.  

Standard: An acceptable password contains at least 8 characters, 1 numeric, one special.  The age of a password will be 45 days, cannot be reused until after 15 iterations and will be stored with non reversible encryption.

So far this is very straightforward:  but when it comes to the sub-standards and procedures, here comes the variability:

On Windows Platforms:  Since all windows computers are domain-joined, the policy shall be implemented with the "Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy" Group Policy objets.

On UNIX/Linux Platforms:  All Linux platforms should implement the standard /etc/login.defs file. On Solaris, the standard /etc/defaults/login. The PAM library pam_cracklib should be implemented.

Notes:  This is overly simplified, but it has implications on the standard build (or image), maybe the files have to be centrally hosted and checked constantly, etc.

Process Reuse: With Centrify in place, the Windows Standard can be reused for the UNIX/Linux platforms and the agent will enforce it.  The standard may be needed for local accounts, but since all human accounts will be in AD, the root account (or any other service account) can have a long password that can be secured.  The privilege management component of Centrify allows to elevate to those accounts without knowing the password.

A Standard Framework to Enforce Access Controls

The Centrify agent implements Role-Based Access Controls (RBAC) that allows for easier implementation of the least access and least privilege principles.  The best way to see it is with our example.  We have a simple model, in which only DBAs can accesses Database Systems (so far CEN1), only Web Admins  can access Web Systems (so far SUSE1) and Sysadmins can access and manage all systems.  This means that standards like the ones outlined in the PCI DSS section 7:

Requirement 7: Restrict access to cardholder data by business need to know

To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities. Need to know is when access rights are granted to only the least amount of data and privileges needed to perform a job.

7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.

7.2 Establish an access control system for systems components with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

Only Doyle and Matt (Web Admins) with Jessie (sysadmin) can access SUSE1

Only Jeremy and Ramon (DBAs) with Jessie (sysadmin) can access CEN1

How is this accomplished with Centrify:

Zones will only allow Active Directory UNIX-enabled users that have a proper role to access the systems.

The privilege management module (directauthorize) with AD and authorization manager.

(And this same model can be extended to Windows too!!!)

Moderation note:  This is why Centrify Express is not discussed in this blog, because by default, it will allow every AD user from the local domain (and trusted domains) to access te UNIX/Linux systems.

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

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)

About Access Controls (Identity and Access Management)

The challenge with organizations, capabilities and projects

Many security solutions provide technical capabilities, but the sad truth is that many customers see these solutions like a project that must be implemented and forgotten.  This is why is hard to sell solutions in the Identity and Access Management space.

What's a capability?
According to the Free Dictionary,  a capability is  "the capacity to be used, treated, or developed for a specific purpose."  In the context of IT infrastructure, an IT capability typically is a triad:

• People:  members of the organization need to have the cognitive knowledge, skills and experience to launch and operate the capability.
• Process:  processes govern how the capability is implemented
• Technology:  the tools that aid in the implementation of a capability. 

Any security capability has to be aligned with Security Policy, and the security policy responds to the business risk factors. Policies are just statements, the implementation of the policies may be simple controls or fully managed capabilities.

IT Capability Fragmentation
Fragmentation happens when capabilities are duplicated (due to lack of knowledge, legacy, politics or status quo) and negatively affects the organization's agility or operational efficiency.

About Security Controls
Security controls can be preventive, corrective or detective controls, and are implemented as administrative, technical or physical controls.  A risk is truly mitigated if controls have been implemented to prevent the event from happening, to correct or recover from the event, and detect the event during or after it happens.

Access Controls
Access controls are the security capabilities that deal with the controls for Authentication, Authorization and Privilege Management and Auditing.

Authentication verifies the user's identity using different factors.  The most common is username and password (single factor).
Authorization determines if a user (or subject) is able to perform an action against an object (or resource).  Controlling what people can do in the context of operating systems, applications, resources, etc. is part of privilege management.
Auditing is the accounting of what a subject (user) actions.

What's a Directory Service?
According to Wikipedia, a directory service is the software system that stores, organizes and provides access to information in a directory.  There are many directories out there, but we will be focusing on Microsoft's Active Directory (AD).

What this blog is about?
The objective of this blog is to build a recipe of background information, use cases, requirements, solutions, step-by-step guides and any other information to leverage the Centrify Server Suite and Active Directory to address the challenges of Unix and Linux administrators in the Identity and Access Management space with deep focus on access controls.  We will attempt to marry the business and security needs with the implementation of these tools.  The ultimate goal is to achieve operational efficiency by reusing existing infrastructure, processes and knowledge. 

Tools and Methodologies
We will use existing resources like the Microsoft Test Lab Guides and the Plan-Do-Check-Adjust methodology.

Acknowledgements and Legal Notices
Active Directory, Forefront Identity Manager, SQL Server, Exchange Server are products and trademarks of Microsoft Corporation
CentOS is a trademark of the CentOS project
Solaris is a trademark of Oracle Corporation
SUSE is a trademark of Novell Corporation
Centrify, Centrifying, DirectControl, DirectAuthorize, DirectAudit, DirectSecure are trademarks of Centrify Corporation