It covers Centrify Enterprise Edition 2014 and provides a full product evaluation experience for security access controls (Authentication, Authorization, Auditing). Here are the evaluation objectives.
Category 1: AD Integration and Authentication - Standard Edition
Does not require any schema extensions or software loaded in DCs.
Not all AD users have access to UNIX/Linux systems by default
Solution uses Standards and Frameworks (LDAP, Kerberos, PAM, NSS)
Solution does not synchronize identities or passwords
UNIX-enabled AD users can be controlled from AD (enabling/desabling, logon hours, etc.)
Integrating UNIX/Linux systems can be performed from the GUI or command line.
AD Security policy is enforced in UNIX/Linux Platforms.
Multiple UNIX identities can be assigned to the same AD User
UNIX secondary group memberships can be managed from Active Directory as well
Authentication can be streamlined with SSO mechanisms.
Provisioning/Deprovisioning of UNIX users and groups can be automated.
Filer integration (Samba or NFS) - identity consistency for files and folders
High-availability: Users should have access if AD is not available.
Category 2: Access and Privilege Management - Standard Edition
Systems can be grouped using different criteria to enforce access.
Access can be limited based on groups of systems defined above (role-based access control)
Roles can be defined to control how the user signs into the system and the privileges that can be granted (Role-based access privileges)
Provides mechanisms to verify who used their privileges
Provides the ability to enforce separation of duties (operations vs. governance)
It's intuitive to find out who has access to what system and what can they do
We have been recently been asked questions from prospects to contrast Centrify solutions versus solutions that synchronize identities in the local system and if Password Management is the right approach for Privilege Management.
How Synchronization Works
Synchronization varies between providers but typically it works this way:
There is an authoritative source for an object (user, file, attribute, etc.) this is considered the Master copy. Then there are the targets that need copies.
Solutions like BMC ControlSA implement synchronization this way; there is a server or a source that provides master copies, and in the case of UNIX, the replicas are propagated to UNIX/Linux Systems. In the case of users, they are replicated into the /etc/passwd file; in the case of groups, into the /etc.groups file; In the case of passwords, the /etc/shadow file.
Problem solved: Identity is Centralized....?
Wait... let's examine this closely.
Synchronization can break (due to many things), this means that a compensating control needs to be implemented to make sure that replicas are in sync with the master. At this point, you have to deploy a monitoring agent to make sure that all your end systems are properly synchronized (detective); also people or automation has to be implemented to fix it (corrective). Centrify approach: We talk directly with AD and use NSS, so nothing has to be sync'd. Can we go offline? Yes. But most likely it has to do with someone making a change (maybe moving to a new subnet not registered in AD) and even there we have the cache.
Password Synchronization weakens confidentiality. This is because passwords have to be read from an authoritative source and synchronized with the master server or with the agents. If your users live in AD, that means that compromises need to be made (reversible encryption) just to make sure that your synchronization works. Centrify offers Password Synchronization, but we will be the first to tell you that it is just a competitive feature. We do inline transactions using Kerberos, so no passwords are synchronized or in the clear. It's all ticket-based.
The master copy is another directory. This means more assets, people and processes. Centrify uses AD. No duplication of capabilities.
Identity Synchronization is NOT authentication. In the scenario described below, authentication still happens locally since even passwords are synched locally. This is why you will see solutions like BMC combined with other solutions; they can't solve the other side of the puzzle. With Centrify, authentication is implemented as a PAM module on UNIX and it uses our MIT Kerberos-based libraries that have been extensively tested against Microsoft's Kerberos Implementation.
Identity Synchronization is NOT privilege management: Privilege Management is about limiting access, privileges, across multiple platforms, getting timely information about who has access to what. The Centrify Base Agent provides a robust RBAC model that not only works on UNIX/Linux, but in Windows as Well.
Identity Synchronization is NOT Governance: Governance is about being able to separate the people who set the rules from the people that perform the operations. At the Master copy level this may be possible, but not at the system or end-point level. With Centrify, delegation is possible by leveraging AD objects. Discretionary Access Control Lists allow us to separate the functions of a person that needs to join systems, vs. a person that defines roles and rights.
Synchronization may be inevitable in complex organizations, but when it comes to UNIX/Linux identities with Active Directory it does not have to be that way.
How Password Managers Work
This has been an interesting topic as of late. The whole capability has the key in the name: password Management (or shall we say Shared Account Password Management?). The whole premise is that there's a privileged account (or a service account) that needs to be controlled.
The great thing about password managers is that they can be the faster path to compliance (like a failed audit), but they don't really solve the Privilege Management issue. They are absolutely part of the solution, but help 20 to 25% of the use cases; the rest of the cases you should be using the principle of least privilege.
Password Managers offer capabilities like:
Robust Encryption
Customizable Workflows
Web Interfaces
Quick ways to keep auditors happy
Many password managers provide session management and can capture and replay the session
Problem solved: Privilege Management is conquered?
Shared Account Password management is not the same of Privilege Management, it's just a subset of capabilities needed for proper privilege management.
Let's look closely:
The privileged shared account is still used. It is still root or oracle that are being used; the only thing that happened is that there's a traffic cop (the password manager) that via the pre-configured workflows allows to check out the password for the account in the target system. With Centrify, this is not the approach; you can grant the individual (AD user) the proper rights; be it a super user or a person that can run only one privileged command. This is implemented with a modified version of sudo (dzdo). You can control how they access the system as well. And works on Windows.
Since the password manager is so important, now it has to be highly available = More costs With Centrify, we leverage the existing investment in AD. Reuse vs. New CapEx. What's easier to justify?
Password Managers are intermediate systems or proxies. What if the system accessed directly? With Centrify, the adclient is loaded on all managed systems, therefore the rules are enforced end-to-end. If John Doe can't log in to Web system, he just can't. Also, forget about the session capture data.
The fact that the shared privileged account is managed, does not mean that access is controlled at an individual basis. In an environment that follows proper security access management practices, it's still required to know who has access to what and what can they do. That's why Centrify's approach is identity-based (leveraging the AD account), not only access can be limited, but privileges can be set as well.
Perception of Security: A password manager does not secure the data in the target system. Don't forget the reason why you're doing security in the first place: to protect sensitive data. The problem is not the password, in the context of identity it's implementing strong access controls. With Centrify, the local agent will make sure that only folks that are authorized to access the system will be able to, and it can't be circumvented.
You are affecting the user's productivity: Ask any vault or SAPM user and they will tell you that they hate it. With Centrify, users sign in to the target system (regardless of using SSH, console, RDP) with their AD credentials and are able to perform privilege elevation. As a matter of fact, Vault makers don't disagree with this approach (otherwise why would they license this?)
Per-User Costs: A sad situation for any prospect is that vaults have a complex licensing scheme. The vault needs to be bought (+ additional vaults for HA), this is CapEx; Now add a per-user cost for all managed systems (UNIX or Windows)!!! (and I have yet to get to support/maintenance costs or complexities due to geographical deployments) With Centrify, we provide PERPETUAL per system licensing.
SAPM solutions are definitely necessary in complex enterprises. In Unix there's single-user mode, in Windows there's the local Administrator account and finally on there's the issue of network appliances. They can also be a quick solution to a tactical security issue. This is why Centrify is looking at this capability very closely.
In my personal opinion, I also think that since Password Managers are typically appliances, it's easier to say, well, "at least we have something to stare at" effect is present. Software-based solutions are harder to "get" - We go through this every day:
- Prospect: "Where is the server?"
- Centrify: "No sir/madam, there's no server, you already have the infrastructure in place."
- Prospect: "But where are you synchronizing?"
- Centrify: "No Ma'am, identities live in AD."
- Prospect: " But where do you put the sudoers file?"
- Centrify: "There's no sudoers. We leverage AD and our technology"
People are more interested in how we do things than the fact that we are making things simple. Most people can't believe it. Just like magic.
The HUMAN Problem
Another challenge is that a lot of UNIX administrators have not learned to let go of the root account and other service accounts. In looking at how some our existing customers use their systems today, it's very common to see them log in with their AD account, and the first command is dzdo su - or dzdo su - oracle, etc; what this means is that they see a vault as the easiest way to maintain the status quo.
This problem exists on Windows as well. It is quite common for admins to camp on different workstations or RDP sessions with their "-a" accounts. This is a poor behavior that must be eliminated by imposing privilege elevation on Windows too.
In a previous posting we discussed how to implement automatic provisioning of UNIX user identities using Centrify's Zone Provisioning Agent (ZPA).
As part of BP#2, one of the key requirements was to implement a provisioning model for secondary UNIX groups and to make it resemble the existing one for users.
This capability consists in the automatic creation of the secondary UNIX group as well as the lifecycle maintenance of members (add/moves/changes).
All the principles applied in the basic posing about ZPA apply here, but in the context of UNIX secondary groups. Let's apply the Plan-Do-Check-Adjust methodology.
Planning for Secondary Group Provisioning
Is the secondary group needed
The first place to start is to ask "Why is this secondary group required?" - remember that with Centrify there is no need to have these groups for Access or Privilege purposes, Zones and RBAC take care of all that. In these exercises, the typical answer "Because that's the way is done" is not a good answer so you may have dig deeper.
Naming Conventions
The same rules of UNIX systems apply here as well, but they are a bit more stringent; the 8 character limit for users is platform-dependent; the UNIX group case, it may be more of a hard requirement.
Active Directory
Basically the way UNIX Groups work in Centrify is as follows; there is a security group in AD for each secondary group in UNIX; the memberships are handled from AD (the process consolidator and time saver), however, governance and processes have to be taken into account. Questions such as:
How are AD Security group are requested today?
How is the membership lifecyle managed (add/moves/changes)?
Are group memberships subject to any attestation process?
Need to be understood and agreed upon.
Group Merging
Group Merging is the ability to mix members from other Name Server Switch groups (like /etc/group) with UNIX Enabled AD groups. For example, if an application requires the enumeration of all the members from the software group (UID 200) and the application uses local users (e.g. like the db2inst account) and AD users (like jessie.matthews), then this feature needs to be implemented as well.
Implementing (Do) Secondary Group Provisioning
The process is as follows:
Make sure the service account used for ZPA has the proper delegation to add/remove/modify group profiles. This is done through the Delegation Wizard of the zone.
An Active Directory "Source" Group is created.
ZPA is configured to look at that group as the source group. For consistency, this group is stored in the OU designated for provisioning
The rules for GID are set, the options are:
An unique value generated from the group's System ID (SID)
The RFC 2307 attribute (has to be populated in the object manually or programatically)
Using the defaults set in the zone (Group Defaults tab)
Using Apple's scheme (this is new for version 2014)
The naming rules are set (truncation, character sets, prefixes, etc)
Once this is set, ZPA is ready to provision UNIX groups.
Verifying the Implementation (Check)
Verifying group creation:
Restart ZPA (so the new zone provisioning configuration is processed)
Create an AD Security group.
Nest the group (make it a member) of the source group in the previous step.
Wait the ZPA refresh cycle or restart the service.
Verify that the new group exists under Zone > UNIX Data > Groups.
Verify that the group exists in the adequate UNIX systems. There are several ways: getent group | grep <unix name of group> adquery group | grep <unix name of group>
To verify the group's deletion, just remove the AD group from the source group and cycle ZPA; the UNIX group will be removed from the zone.
Verifying Add/Moves or Changes
Add a user to the previously provisioned group Note: this user needs to be at least listed in the system, otherwise he/she won't show. For example, if the user has a UNIX identity, but only has access to web servers, the user will not show in the Database Servers by virtue of the access rules enforced by Centrify.
Wait the ZPA refresh cycle or restart the service.
Verify that the user's UNIX name is in the list of users for that group. There are several ways: getent group | grep <unix name of group> adquery group | grep <unix name of group>
Remove the user from the AD group (go to step 2) and in step 3 verify that the user is gone.
Performing Adjustments
Adjustments may vary depending on the results. They can be:
Adjusting how the GID is generated (or reviewing the provisioning process)
Adjusting how the UNIX name of the group is generated.
