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.
I've been very busy ramping up with some new product releases but I'd like to highlight some of the new features of Centrify Server Suite 2014 that was announced this week at the RSA Conference.
Some highlights include:
More OS platforms supported (highlights include RHEL/CentOS 6.5, which worked but had not been listed because they hadn't been extensively QA'd)
PowerShell Module for Access Manager: over 75 cmdlets open the possibility for more automation coming from the Windows side. The SDK used to be the only avenue in Windows; in UNIX we are all set with the CLI tools and adedit.
Audit Events now report PAM or Centrify-enhanced sudo events: This makes for a more robust audit infrastructure and alerting combined with the capture and replay capabilities.
Windows Privilege Management Match Criteria & Application Rights Builder: This capability accelerates windows application rights creation and increases the filtering granularity.
New Built-in Windows application rights: Pre-canned rights for common Windows applications also accelerate role creation.
This is the implementation portion of the 4-part series around Privilege Management with Centrify for UNIX/Linux. Read the previous post to catch up. The basic knowledge for this post, although focused on UNIX, it's applicable with the exception of rights, applies to Windows too. The activities required to implement roles with Centrify requires:
Create Computer Roles if needed
Create and Configure Roles
Build the PAM access rights if needed
Build the Commands if needed
Assign the role
Creating Computer Roles
Centrify computer roles are groupings of systems that perform a particular role. I like to call them computer groups. Systems can be grouped any way it makes sense to you. The real power of computer roes is that they are based on AD Security groups, this means that you can have computers (just like users) that have multiple roles. Examples:
Fragmented (vertical) model: Web, Database, Utility, Network Services, etc.
Mixed mode (horizontal/cross funtional)l: Application X - Dev; Application X - Prod (Application X has Database, Web and Application servers).
To create a computer role:
Create an AD Security Group (this is the Computer Role container)
In Access Manager, Open the Zone, and expand Authorization > Computer Roles
Right click Computer Roles and select Create New Computer Role
Set the name, and browse for the AD group created in step 1.
What happens when you create a Computer Role?
A computer role adds a new scope to assign RBAC and to categorize systems. The operations associated with Computer Roles are role assignment and member add/moves/changes.
The add/moves/changes for roles are performed within the AD group that grants the role, this makes the Role Assignment a first time/adjustment activity.
Creating Roles
Centrify roles are the building blocks for Role-Based Access Controls. Roles are defined, then assigned to AD security principals. In UNIX roles are composed of PAM Access and Commands.
PAM Access: Defines the PAM-aware protocols that are allowed in the the role. Examples: Secure Shell (ssh), xdm, VNC, and of course, not recommended: pure telnet & FTP. The built-in login-all PAM right allows access on all protocols including the console. Note for AIX:Some AIX platforms are configured for LAM can't provide granular access.
Commands: are the privileged (or non-privileged) commands defined for the role. They can be defined explicitly, or with regular expressions, tied to the Centrify restricted shell, scoped for a particular user, and defined with additional authentication requirements.
To create roles:
You need to know how the role will access the system (e.g. via SSH), what privileged commands it needs (e.g. service control for httpd), any time restrictions and if you have Centrify Enterprise, you
In Access Manager open the Zone > Authorization > Role Definitions
First, always review your roles to see if a role exists that can be reused.
Examine PAM The UNIX Rights definitions node for PAM and Commands and make sure the building blocks exist.
Right Click Role definitions and Select Add Role
Name the role, use the description field and add any time/day restrictions if needed.
Go to the System Rights tab. Define the logon experience.
Password login and non-password login (SSO) are allowed: if you plan to use both SSO and passwords (check it)
Non-Password SSO login allowed: You would uncheck the one above and only check this if you're in a Smart Card scenario. (check it)
Account disabled in AD can be used by sudo, cron, etc: Only required if you're defining a role for a service account managed from AD. (leave unchecked)
Login with a non-Restricted Shell: This is going to be not selected if using the Centrify Restricted shell (white-list mode). (check it) Note the Windows rights, not covered in this posting.
If using Enterprise Edition, go to the Audit Tab, and select the appropriate option:
Especially when Auditing roles for Windows, the integration of RBAC and auditing can result in auditing risky actions and less storage usage in the Audit database.
Press OK. Very important: At this point, the role is defined, but it has no rights assigned to it, this has to be the most common mistake in the area of RBAC along with assigning a role without granting an identity.
Right-click the newly-created role and select Add Rights
Check all the rights (PAM) and commands for the role and press OK.
Now the role is ready to use (be assigned).
Assigning Roles
As described, Role assignment is the granting of a UNIX (or Windows) role to an AD Security Principal in the correct scope. Roles can be assigned at:
Zone Level: This role will apply to all systems in the zone. (Limited Use)
Child Zone: This role will apply to the child zone (Depends on your design)
Computer Role: This role will apply just to the set of systems in the role (Optimal usage)
Computer: This is a local override or exception (If you find yourself doing this a lot, you have a governance problem)
Time-bounding Role Assignments
Permanent vs. Temporary Role assignments: Time-bounding of role assignments is a powerful feature of Centrify, this allows for scenarios like this:
Change-control windows: You can have your population be regular users all the time, and only get a role with privileges when a change control has been granted. The access/rights expire automatically at the time specified.
Contractor scenarios: A set of external users may need access to systems in a specified period of time.
With the AD Group, scope and time, all the information is ready for do do an assignment.
In Access Manager, go to Zone > Authorization
At this point, it's time to pick the scope:
To assign at the zone/child zone level, select the Role Assignments node right under authorization.
To assign at the Computer Role level, expand Computer Roles, find the correct system group, and expand to expose Role assignments
Exception: At the system level, go to the Computers node, find the computer, expand it and find Role Assignments.
Right click Role Assignments and select Assign Role, then pick the role you are going to assign.
In the Assign Role box, time-bound based on your information (scope or permanent), then use the Add AD Account button and find the Group (or user -not recommended- promotes exceptions) that you will grant the role to and press OK.
Process Reuse: The biggest benefit of assigning the role to a group is that this makes the integration with other tools and process reuse much easier.
In the next post we will talk about the Check (Verify the implementation) portion of Privilege Management.
