Security Corner: Opinion about Synchronization of UNIX identities and Password Management

Background

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.

Note (May 2015):  Centrify has released their own SAPM solution; this means that now they can offer both the Least Privilege and Shared Account approaches.




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.