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.