How to check out passwords from the CLI using Centrify Infrastructure Services

How to check out passwords from the CLI using Centrify Infrastructure Services
As part of the security toolbox, we must deal with shared credentials, more specifically passwords.  Many of you know how Infrastructure Services can secure credentials, however, a lot of work is going on to enhance the DevOps or automation use cases.  In this article we'll discover the options available to retrieve passwords from the CLI and we'll focus on using it as a way for programs or scripts to retrieve them.

Using shared passwords in CLI scenarios while maintaining assurance
Passwords have been hard to get rid of, unfortunately, even with old technologies like Kerberos and PKI we must accommodate for the need to securely retrieve credentials.  However, at the same time we need to maintain assurance and enforce principles like:

• Try to eliminate passwords
• Limit lateral movement
• Just in time/just enough access/privileges
• Identity Assurance
• Monitoring and Auditing
• Policy enforcement, etc

The maturity model illustrates this best:

Eliminate Passwords
Centrify eliminates passwords in this use case by relying on PKI credentials; the process happens during enrollment when a system is onboarded by an authorized party.  The enrollment process looks like this:

Each system is represented by a service account in Centrify Infrastructure Service.  Please note that in order to modify the PKI settings on a system, you must have administrative rights (you you require privileged access on the client side), plus you must have either an enrollment code or a user credential of a user that can enroll a system.

In Linux, this is implemented with the cenroll command.  If ther's a manual enrollment, we also ask for MFA based on authentication profiles like here:

sudo cenroll --tenant vault.centrify.vms --user admin@opie.demo 
--verbose --features all --agentauth identity-broker-users 
--name centos7 --address centos7.centrify.vms

If an Enrollment code is available, you can use it (the most common way of doing this, especially for automation), here's how it looks on Windows, with a code:

Enroll-CIPSystem -EnrollCode "THISIS-YADA-YADA-CODE-682DBEF6CA78"  
-FQDN 'member.centrify.vms'  -ResourceName 'member-vault' 
-Endpoint 'https://vault.centrify.vms'

Access Control, Entitlements and Visibility
Centrify relies heavily on role-based access, but this is an interesting use case because it's highly-related to automation.  In this scenario, most likely a system will be built, and as part of the on-boarding it will automatically enroll to the Centrify platform.  Centrify includes a built-in group called:  Centrify Agent Computers;  by default, this group has visibility to systems, domains and databases.

As a best practice, don't overload the Centrify Agent Computers built-in group.  Just use it for visibility purposes.  Create sets and other roles, and leverage those instead.

Permissions
For accounts, there are several entitlements

This means that you need View+Check out at the account level to check out a password.  This is a mechanism for least access and limiting lateral movement.

Policy Enforcement and Monitoring
The most common password checkout policies (like multi-checkout or lifetime) are geared towards interactive use, but for machine communications, Centrify offers the ability to override the checkout lifetime settings at the account level.
 

A great policy that can be implemented is the use of internal/external, datetime or even Risk.  This can be applied at the account level.

Monitoring
Because a compromised system, although with limited access is still a potential "stakeout" point, monitoring service account checkouts outside the applicable time or at a rate that is out of the blue, the monitoring and alerting capabilites of CIP provide several tools like:  Dashboards, Reports or the ability to send events to a security operations or SIEM tool.


Deployment Utilities

• Enrollment codes:  allow Centrify clients to enroll the platform automatically.  The benefit of codes is that you can add restrictions (like how many times or from which networks they can be used) or organizational options like sets or RBAC.
• Sets:  Sets are collections of objects in CPS; they allow for dynamic or static membership as well as controlling permissions.
• Packages:  The CLI toolkits are delivered as part of the Centrify clients for Linux or Windows.

Implementations
The Centrify Agent for Linux, leverages the cgetaccount command (checking out the opieadmin local account password from as system called engcen6 for 5 minutes).

Here's more info about cgetaccount.
Here's how it looks in PowerShell  (checking out the sa SQL server account from the database enterprise for 2 minutes)
 

Note that these examples are interactive checkouts.  Ideally, a script or program would call this command to retrieve the password string and use it or assign it to a variable.  Notice that you can specify the checkout lifetime.

Futures
This is an area of a lot of interest for Centrify.  Stay tuned.

Overcoming the Identity or Infrastructure Duplication to Secure Linux Instances in Public Clouds

Background
Securing Linux instances in public (or private) clouds often requires the duplication of infrastructure (or additional overhead) just to be able to provide basic services like authentication.  Centrify just debuted a new client that leverages a capability called Identity Broker.  This allows users of Centrify privilege service to extend authenticaiton to Linux systems using Active Directory, LDAP, Google Directory and others without the need to implement extensions to AD or LDAP or any supporting infrastructure (like site-to-site VPNs).

The Challenges (AWS as an example)
In previous blog posts, we discussed the additional controls that can be implemented on top of Amazon's IAM and cryptography-based capabilities.  The model suggested the use of Active Directory and Centrify Server Suite.
Regardless of the solution, organizations need to find ways to extend this infrastructure by using these techniques:

• Re-creation of infrastructure (e.g. standing-up Active Directory or LDAP-like infrastructure)
• Network extension (e.g. treating the public cloud like a branch by implementing site-to-site VPNs)
• Capability duplication (e.g. implementing software and services in AWS)

In this article we'll discuss how organizations can leverage Centrify Privilege Service and the new Linux Agent (Identity Broker) to secure Linux instances and extend Enterprise Identity out to public clouds without the need of the additional overhead.

Centrify Privilege Service

Privilege Service is Centrify's answer to the traditional "password-driven" use cases (the industry refers as Shared Account Password Management, Privilege Session Management, etc);  however unlike other solutions, there are several capabilities areas that set it apart from the traditional "Password Vault"

• Flexible deployment:  Both as SaaS and On Premises  (in fact, it was designed as a SaaS solution first)
• Identity Sourcing and Federation built-in (includes Identity Service, this means support for AD, LDAP, Google and others  plus simplified SAML-based federation and 3K+ ready web and mobile apps)
• Policy, Workflow and MFA Engine:  Policies for time and geo-location, RBAC, step-up authentication and Multi-factor including Smartcard, plus a built-in access request system (+ServiceNow integration)
• Infrastructure Extensibility:  Privilege Service can be extended to any network using a Windows-based Centrify Connector via web protocols.

New Linux Agent
The new Linux agent takes advantage of a capability called "Identity Broker" this allows the bridging of identities known to Centrify Privilege Service;  this is done via the Centrify connector.  This means that the overhead of duplicating enterprise identity infrastructure or extending the enterprise to the public network can be avoided in this particular use case;  all that is required is to deploy a Centrify connector wherever you want to extend Password-related services and Linux authentication.  Let's show an illustration.

Company X needs to provide identity-based reporting and attestation of who has access to their public cloud EC2 instances in AWS;  their primary identity source is AD.  They could have used any model (independent forest, one-way trust + site2site VPN or RODC) to extend AD to AWS  or they could have deployed Amazon IAM roles and used SSH keys; but any of these models implied additional overhead.  With CPS and Identity Broker, all they did is this:

With this model, CompanyX not only can accomodate their corporate IT users, but external entities as well.  And as we discussed before, password, session and additional services are consolidated as well, both on premises and on any public cloud.  Plus

• No need to deploy "jumpboxes" to the private clouds (limits exposure)
• Shared account passwords for local accounts (Linux, Windows) or databases (like Amazon RDS) can be controlled
• Access Request provides the assurance of "documented approvals" to sensitive systems
• Deploy MFA or access only from the OnPrem network as additional controls.

Agent Architecture
The client architecture is using UNIX frameworks like Name Service Switch (Identity) and Pluggable Authentication Modules (Auth).  It also supports offline login as well as direct or proxy-based user/password or OAUTH-based enrollment codes (very useful for automation). This client implements the CLI tookit for setting, retrieving or deleting credentials under management.

Supported Platforms
Platforms supported in the initial release - more on the way

UNIX Identity
Following on the legacy of Server Suite, the new agent generates identity like DirectControl in workstation mode.
Login - user's short name (must use the fully-qualified name the first time)
UID - auto-generated based on the GUID
Primary group - auto-private (same as UID)
GECOS - the display name in Centrify Identity Service
Home/Shell - configurable in the Settings tab.

Since most public clouds don't need legacy identity (for services like NFS), this makes the client very lightweight.

Automation
There's an implied expectation of DevOps "friendliness" when a private or public cloud solution is implemented.  The new Linux agent leverages enrollment codes for this capability.

Centrify provides a sample AWS script that can be used with enrollment codes in the User Data field or with any other framework like OpsWorks (see attachment)

Identity Broker
Privilege Service can accomodate several identities, including:

Note that it can accommodate identities from Active Directories without any trust relationships.
These identities can be aggregated using Identity Service Roles:

 Roles, in turn can be assigned the AgentAuth privilege on a Linux Resource:

As you can see the model works like this:
Users or groups from Identity Sources are added to CIS Roles that are granted the AgentAuth right in CPS.

Basic Commands
Agent Operation

• cinfo – obtain information about the agent
• cenroll – enroll the identity platform and enable features
• cunenroll – leave the platform and optionally delete resource and any managed accounts
• cflush – flush the local cache

AAPM

• csetaccount – add a managed account for the resource
• cgetaccount – obtain a managed account’s password
• cdelaccount - delete a managed account's password

A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory - Part 5

Background
This is the fifth and final article in the series titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" in the previous post we discussed how to integrate your Linux and Windows systems to Centrify zones in AWS Active Directory for the purposes of authentication and privilege management.

In this article we'll discuss how to use Centrify Privilege Service to provide shared account password management, privilege session management and recording and strong access controls.  Here are the detailed goals:

• To provide a redundant secure point of access for AWS-hosted systems
• To provide password lifecycle services:  request-approve-check-out-check-in-rotate-auto/rotate
• To provide temporary access (sessions and password checkouts)
• To provide application to application password management capabilities
• To provide advanced jumpbox access to SSH and RDP systems in AWS
• To be able to proctor in real time
• To be able to review session transcription and provide session replay
• To provide advanced access controls like strong authentication, time-fencing, geo-fencing and more
• To continue to leverage Active Directory or use other identity schemes(LDAP, Google Directory, Social Identity, Centrify Cloud Directory or even a SAML IdP as the identity source)
• Minimize exposure by eliminating the need for elastic IPs (publicly facing)

Centrify Privilege Service Architecture
I've written about CPS in the community before, for some features and demos review this article:  http://centrifying.blogspot.com/2015/08/in-depth-centrify-privilege-service.html

In summary, it is a SaaS-based Password Manager and Jump Box (in Gartner speak, provides SAPM, PSM and AAPM), however it uses the assets of identity service:  Federation, Workflow, AD-Bridge, Multifactor Authentication and more.  CPS has a connector-based architecture like this:


This means that there are several ways to use Privilege Service in IaaS scenarios.  However, I will focus on this type of design:

The benefit oft his design is that it allows flexibility. Here are some highlights:

• The single source of identity continues to be the on-premises Active Directory.  AD Principals (like groups) can be used to control entitlements like who can access the management portal, check out passwords, modify resources, etc.
• Allows for connected or disconnected AWS connectivity.  Cloud Connectors in AWS act as jumpboxes, regardless of the EC2 scheme (domain-joined or not) the connectivity is centralized.
• Advanced Controls like
  • Step-up authentication:  Centrify MFA, OATH OTP, Phone factor, SMS, Email, PKI/Smartcard
  • Allow access only from corporate network: Users must be on-premises to access AWS assets
  • Geo-fencing:  access can be limited to only corporate locations.
  • Workflow:  Resource and password check-outs can use an access request system (Centrify or ServiceNOW)
  • Temporary access control.
• Time-to-Market:  Password and session access can be deployed in minutes by launching an instance and deploying a cloud connector.  The same goes for internal datacenters.

We'll discuss some planning and provide some implementation/verification videos:

Planning
Stakeholders:   Infrastructure Lead, Directory Services Lead, Security lead, AWS SME, UNIX/Linux or Windows image lead, Database (SQL Server) SME etc.

Discussion topics:

• What are the systems that need to be accessed?
  The answer to this question has implications for AWS security groups.  For example, the security group where Cloud Connectors will be residing must be able to establish connections over port 22 (SSH) and 3389 (RDP).
• What are the user populations that need access to AWS systems?
  This determines the identity stores.  User populations can be full-time employees, contractors, vendors, etc.  Depending on the existing strategy, maybe not all users have AD accounts, this is where identity flexibility of CPS becomes handy.  Some examples:
  - Temporary contractors may be provisioned in the Centrify Cloud Directory instead of AD.
  - Perhaps ADFS has been implemented or partners need access, in that case CPS can be the service provider in a federation relationship.
• What are the groups that should manage the system?  what are their entitlements?
  The answer to this question has directory service and functional implications.
• What are the security controls to be put in place?  (strong auth, geo-fencing, time-based controls, workflow/approvals)
  The data classification of the systems determines the controls that should be in place.  The most basic could be that all AWS access must be generated from the corporate IP range, and access to the portal requires strong authentication.
• Password Management lifecycle questions:
  Should approvals be required for password checkouts?  Should multiple password check-outs allowed? should passwords be rotated in a specific interval?  Should password health be monitored? should password be allowed from mobile devices? Should passwords for temporary systems be managed?  Should active directory account passwords be managed?
• Password Storage
  Should the Centrify Secure Storage be used or is a physical or hardware HSM (Safenet SecureKey) available?
• Will AAPM or self-registration be needed?
  The answer to this question has implications for AWS images or DevOps.  Centrify provides a Linux package (CLI toolkit); this allows for automation and automatic system registration.
• Monitoring and Reporting
  What events should be sent to log aggregation (SIEM) platforms?  What reports should be generated and who are the consumers of these reports?
• Attestation
  What is the process of validating that certain privileged users should have (or continue to have) access to certain resources?
• Session Recording
  What is the data retention policy for audited sessions?  How many concurrent sessions (SSH/RDP) can be expected?
  These topics are covered in depth in Chapter 2 of the DirectAudit Administrator's guide. 

Implementation
In this example, I will use an AWS environment with Active Directory to:

• Add a cloud connector for privilege service session management
• Manually register some EC2 Linux and Windows systems for jumpbox accesss
• Manually manage the password of a local Linux, Windows and Active Directory domain account.
• Use two AD groups:  AWS-CPS-Full Access and AWS-CPS-Read-only access. Members of the 2nd group must request access for password checkouts or proxied sessions.
• Enforce Strong Authentication.
• Using the CLI toolkit for CLI password checkouts and manual and automatic.

Moderation note:  Due to the blog's 20K character limitation, videos will be used.

Requirements for this Lab

• An AWS instance with Active Directory (managed by you or hosted by Amazon)
  • Two AD groups:  AWS-CPS-FullControl & AWS-CPS-Limited
  • A Domain Administrator to authorize the cloud connector
  • Outbound Internet connectivity via single-attached Elastic IP or Internet gateway (preferred)
• From Centrify you'll need:
  • A Centrify Privilege Service evaluation or production tenant with sysadmin-like credentials.
  • The Installation bits for Centrify DirectAudit
• A domain-joined system for:
  a) Centrify Cloud Connector (although not recommended, this can be the DC if running a simple lab).  Cloud connectors require outbound HTTPS connectivity and to act as jumpboxes for Linux and Windows systems, they should have connectivity over TCP ports 22 and 3389  (or your custom ports if changed).
  b) DirectAudit components:  this will be the not recommended all-in one scenario (Database/Collector/Agent). 
• Test Linux and Windows EC2 instances.
• Optional:  An Android/iOS mobile device for Touch/OTP MFA or a Yubikey 4 or NEO for OATH OTP

Requirements Verification

Installing a Cloud Connector

Installing DirectAudit

Configuring Roles for CPS Access


Configuring Workflow and Approvals

Using the CLI Tookit (AAPM)


Managing Active Directory Domain Account Passwords

Session Management, Proctoring, Capture and Replay

Dashboards and Reports

Advanced Controls (Policies, Authentication Profiles, Strong Authentication)


Adjustments
Some of the adjustments that can be made include:

1. Password storage:  HSM or Secure Centrify Storage
2. Different directory sources for different user populations
3. Smart Card Authentication
4. Bulk import of systems
5. CLI tookit baked into master AWS EC2 Linux instance.
6. Use of PowerShell to automatically register Windows accounts
7. Limited visibility of resources using the Privilege Portal login right.

End of Series - Conclusion
This ends the series on AWS and hopefully you've seen how the Centrify product lines:  Server Suite, Privilege Service and Identity Service work together to secure your AWS environments while balancing operational efficiency and productivity.   

In Depth: Centrify Privilege Service (August 2015)

What's Centrify's Privilege Service (CPS)? 

CPS is Centrify's complement to the existing Privilege Management capabilities offered by Server Suite.  The focus is on Shared Account Password Management (SAPM), Privilege Session Management (PSM) and more.

Platform shared capabilities

• Active Directory Integration:  CPS uses Centrify's leading AD Bridging capabilites to provide organizations AD integration to the solution.  It leverages the assets of Centrify Identity Service (formerly known as user suite).
• Single Sign-on (SSO): When users have an authenticated Windows session, if configured by the administrator and with a supported browser, the privileged users will get SSO to the portal or apps.
• Password Wallet:  Users and Administrators can use the built-in password wallet for Web Apps that 
• Multi-factor Authentication:  The platform uses several mechanisms for MFA (Centrify Mobile Authenticator from the registered device's Centrify app, one-time-passwords using SMS, E-mail link, or voice call placed to the user's business or mobile phone.
• Geo-Fencing: Identity platform leverages geo-location for several purposes: access policy, smart MFA, reporting and analytics.
• Multiple Identity Stores:  CIS today supports users from connected or disconnected (no trust-relationship) Active Directory forests, but also users form the Centrify Cloud Directory or LDAP; (the list of sources grows as I type).
• Per-App VPN (reverse-proxy):  Allows the elimination of persistent VPN connections and provide remote access just to the individual application.
• Role-based Access Control:  System access, and system rights are all based on roles that can be assigned to users from any source.
• Federated Identity Support:  Enable user access to applications or resources from your partners with a few simple steps.
• User Access Request (Workflow and Approvals):  Access to apps, login sessions to servers, password checkouts and more can be tied to requests and approvals built-in to the platform.
• Enterprise Mobility Management:  In the modern enterprise, with apps being accessed from anywhere, mobile phones/tablets being used as secondary factors of authentication, providing MDM, MCM and MAM is very important and this has been a key capability for iOS, MacOS, Android and other platforms.
• Self-Service Capabilities:
• App portal for a consolidated view of the user's apps and servers
• Device portal to allow the user to enroll and manage their devices
• Activity portal to self-review activities
• AD or Cloud user self-service password reset
• Self-Service from Mobile App
• Management Portal:  Wizards, Dashboards, Apps, Policies, Roles, Reports, Settings, etc.
• Simple architecture:  On-premise capabilities like AD Bridge, App Gateway (reverse-proxy), support for LDAP are available by installing components that sit behind the corporate firewall (even behind the Proxy).
• Datacenter and geographical redundancy plus multi-language:  The Identity platform is distributed across Microsoft's Azure infrastructure and it has been translated to over 15 languages.
• PKI - Certificate Services:  An independent built-in Certificate Authority for each tenant to provide additional encryption services, mutual trust and authentication using PKI certs in the context of data at rest and in transit, federation assertions, end-point certificates, etc.
• Bottom-line:  CIS is a full-fledged Identity as a Service (IDaaS) solution that eliminates the need for complex federation infrastructure and can be used for multipurpose scenarios of over 3,000 apps.  

Privilege Service capabilities

• Privilege Session Access:  CPS provides the ability to access system resources from a central set of servers (jumpbox).  The CPS infrastructure components can be deployed in a few minutes anywhere the organization has IT footprint.
• Privilege Session Proctoring and Session Abort:  Allows a supervisor to view remote sessions in real time, as well as triggering remote disconnections.
• Shared Account Password Management lifecycle management:  CPS provides the ability to request access to, check out, check-in and rotate passwords in Windows, UNIX, Linux and a variety of network devices.
• Mobile First:  Remote access and Password operations are available from the Centrify mobile app with PIN or bio-metric compatibility.
• Self-Service Workspace:  Provides the privileged user with a consolidated view that includes status of their password checkouts, sessions, recent and favorite resources.
• Privilege Session Recording:  Leverages Centrify's DirectAudit to provide proxy-based auditing or end-to-end auditing if Centrify Server Suite Enterprise is deployed.
• Flexible Storage of Secrets:  Organizations have the flexibility to store secrets with the built-in Secure Storage (secured with their individual CA key) or they can use their own Hardware Secure Module.  Centrify has partnered with Safenet to deliver integration with KeySecure devices.

Explore:  The Platform from the End User Perspective

Explore:  The Platform from the Administrator's Perspective

Explore:  CPS User Experience

Explore:  CPS Privilege Session Brokering and Proctoring and Termination

Explore:  CPS Shared Account Password Management

Explore:  Privileged Session Auditing

Explore:  Worklfow and Approvals (User Access Request)

Explore:  Flexible Storage

A second commentary on Privileged User Management - Shared Account Password Challenges

In my first commentary on Privileged User Management, I suggested that organizations looking to implement Privileged Account Management capabilities should aim for the following initial goals:

• >80% the privileged user has tight access and privilege controls that are based on their centralized identity repository (90% of the time Active Directory in enterprises).
• <20% the privileged user may request the use of a shared account, and this is in the context of 
• activities tied to change control  (based on the environment or governance model)
• activities tied to break-glass scenarios
• specialized-purpose systems like network devices (switches, routers, etc)

I also noted that this is not based on any scientific research, just an initial goal, to be adjusted based on the circumstances of the enterprise.  

In addition, in the previous post outlined Centrify's value for privileged user management and showcased how DirectAuthorize can help achieve this goal in Windows, UNIX and Linux systems on premise or on public IaaS scenarios using Active Directory.  In this post, I offer my personal view on the state of the Shared Account solution space.

The other approach for Privileged User/Account management is Shared Account Password space (Gartner calls it Shared Account Password Management or SAPM).  These "vaults" are typically appliances with a secure storage and a web front-end;  they provide also additional capabilities like request handling and approvals, privilege session brokering, recording of the sessions as well.  These solutions are a must have in the modern enterprise.  I've seen organizations get by with highly-sophisticated and solutions as simple as a personal password wallet and a few scripts.  The bottom-line:  when it comes to shared privileged accounts (root, Administrator, Cisco enable password, oracle, etc) there's got to be a way to check-out, check-in, rotate and enforce policies.  I will use the terms vault, jumpbox or SAPM when referring to these solutions.

I've had the chance to speak to many customers and prospects that use shared account password solutions today, and here's the consolidated set of challenges that exist:

• The shared account password management solution is not really protecting their systems
  Keep in mind, the whole goal of information security solutions is to protect information;  when you have a SAPM solution, unless you add complexity to your environment (like firewall rules to make sure all remote sessions are initiated via the jumpbox), the SAPM solution is not really protecting their systems, it's managing passwords, brokering checkouts and rotating the password based on rules, that's it.  The only real way to to protect the system itself, is the existing network client in the box.  If the box only has one human account which is privileged  (like in the case of some network devices) then this solution is perfect; otherwise, if the system has several local and network human users it becomes evident that other mechanisms for access control have to complement these solutions.
• Lowered productivity of their privileged users
  When an organization uses a SAPM solution as the only means for privilege management, a few things become evident:
  a) organizations realize that they have created a bottleneck
  b) end-users start seeing it as being "on the way" of their day-to-day tasks and start trying to find ways to "get around it" or simply, if the rules are very relaxed, "camp" with the privilege credential as long as policy will allow them.
• Most of the time, the SAPM solution itself becomes another identity silo
  Yes, at the beginning it's hard to notice it, but although some have some degree of AD integration, it only exists for the purposes of correlating the AD account's information with their internal identifier.  Ultimately, the identity silo is the shared account and the current encrypted password.
  Any smart organization is looking to decrease identity repositories not looking forward to add new ones.
• Added burden for Security Operations
  When you use a vault or SAPM solution, only the software or appliance knows who had a shared account, when and for what length of time, it will also know in which systems it was used as long as the session is initiated from the jumpbox.   This means the log aggregation and intelligence tools need to be tightly integrated with these solutions.
• Expensive and Inflexible
  The form factor for these devices is typically an appliance; appliances need to be procured, installed, made redundant and available anywhere there's a concentration of privileged users or anywhere the organization has a large set of systems.  These vendors may have complex licensing schemes as well.
  Many organizations think that they will gain time by using a password-first approach, only to realize that it's been months after the PoC and their device isn't ready for prime-time yet.  Also, what about the systems that exist in IaaS infrastructure (e.g. Amazon, Rackspace, Azure, etc).
• As a sole strategy, does not meet security regulations
  We've had the chance to work with highly-regulated prospects and customers that had to rethink their strategy completely due to audit comments and because they thought that a vault was going to address all their regulatory needs (reasons vary between were told by vendor, thought it was an easy way out, just wanted to overcome an audit comment, did not really do their do diligence etc.); the ultimate reality is that you need a password centric approach for the appropriate use case; but that in itself won't be enough.  Unfortunately, highly-publicized data-breaches have a component of "taking advantage of poor password-related practices" but due-diligence is the implementation of preventative, corrective and detective controls around all risk information areas.   
• Legacy remote session access
  Although these solutions do provide RBAC (privileged users can only see the systems that they have access to, and can request access to new ones), however, if a privileged user is remote, they still need VPN connectivity to get to the jumpbox,  another solution  (Citrix-like) or presence on the DMZ.  
• Closed and capability-complacent
  Another challenge with these systems is that although many are feature rich, reliable and mature, they have the same issues of appliance vendors - they are slow to react to market/customer needs (to be fair, not all vendors are the same).  This is due to an enjoyed leadership or simply because the software lifecyle for appliances is slower than traditional software vendors.  Also, because extra, expensive appliances are needed for testing, implementing new features is always higher risk than they good old: "if it ain't broken, don't fix it"; however, the modern enterprise is very dynamic, and this type of thinking is not present in companies that lead, but in companies that follow.  Following may mean to many companies the loss of market share or in the case of security: data breaches.

In the next post I will talk about Centrify's Privilege Service (CPS).  This product has been around since May 2015, and it was built to address the need of these use cases (that I propose should only be the approach 20% or less of the privilege user interactions).  In addition to continue to add value, you'll discover how Centrify has listened to existing customers that have vault solutions to overcome the challenges outlined above.