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

Using Centrify's AD Technology to Overcome IBM DB2 Database Access and Identity Challenges

Background

When running IBM DB2 on UNIX and Linux platforms, organizations are often faced with the following challenges:

• They find themselves maintaining local users and groups in the local user store (/etc/passwd or /etc/group) to support DB2.
• They face challenges with the 8-character username limitation
• Entitlements are managed with groups that are local to that system
• Users either make the password the same or use simpler passwords if policy is not enforced

This means: 

• Each OS hosting DB2 becomes an identity silo, this means:
• Policy must be enforced
• Access control rules must be in place
• Reporting and attestation are needed
• This often means audit comments for untimely offboarding of DB2 local users
• Promotes complexity and affects user productivity.

Centrify has had the IBM DB2 SSO Module for years now, but I still see organizations struggle.  We covered the set up of the plugin in a previous post, but this 20-minute playlist has a technical briefing with demo for those who are looking to overcome this challenge:

In summary, Centrify IBM DB2 SSO plugin provides:

• User/Password plugin:  Allows users to authenticate to DB2 with their AD credential, no short names required or local identities.
• Group plugin:  Exposes user's AD groups to DB2, this is an avenue to assign entitlements in a more effective way
• GSSAPI plugin:  Provides SSO services via  GSS interfaces.

Less identity silos, more productivity, more operational efficiency....

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.

Centrify's Value Proposition - Part 3: Privileged User/Identity Management with Least Priviliege

In the third part of this series, we'll discuss how Centrify provides solutions for privileged user/identity management and maintains these principles:

a) Eliminates identity silos

b) Implements strong access controls without interfering with the user experience

c) Use what you have: infrastructure, processes, knowledge (less IT fragmentation)

d) Promotes operational efficiency

e) Provides strategic value, rather than tactical solutions

Organizations come to Centrify for privileged identity management or privileged user management because of combinations of the following challenges or circumstances:

•  Overall: They want to increase accountability and implement strong privileged user identity and access controls based on a common identity repository.
• They have Active Directory and multiple platforms, but primarily for UNIX, Linux and Windows
• They have a traditional (on-premise only) or hybrid (public/private cloud) enterprise
• They want to eliminate the use of shared credentials or persistent administrative accounts (root, administrator, “-a”, etc)
• Their existing solution does not provide flexibility on grouping systems based on a security governance model
• They might have chosen to implement a password-centric approach as their unique strategy and they’ve come to realize that their users are less productive (or supportive), that they’ve duplicated identity silos and that ultimately, their systems (the main goal) aren’t protected by it.
• On UNIX: They understand that using sudo/sudoers, although it’s mature may not be enough for high-risk, highly-regulated enterprises; they are tired of the complexities of managing a sudoers file and want more granularity and flexibility
• They want a higher-degree of control on how their users access systems (beyond just granting/denying access) cross platform.
• On Windows, they want to eliminate the problem of the Local Administrator, are conscious of the “pass the x” attacks and want to eliminate the “camping” issue with “-a” accounts.
• They need to provide separation of duties (operational rights vs governance rights)
• They need timely reporting of who has access to what system(s), what are their privileges, and what granted them access to do this.
• They don’t want to deviate from existing processes or realized that by implementing point solutions or “best of breed” they ended-up fragmenting their IT in the context of processes.
• They have regulatory requirements that they need to meet or exceed.  These may be SOx, PCI DSS, HIPAA, NERC, FERC, etc.
• They want to solve the Shared Account Password issue, but they want a solution that reflects the state of modern trends (they hybrid datacenter, IaaS, mobile-first, etc)
• They have high-security requirements like FIPS, solutions common-criteria certified, perhaps they rely heavily on Smart Cards.
• They want log aggregation that is simple to their native tools (ARCSight, LogLogic, Splunk, etc)
• They may need to go beyond the traditional security operations and provide session capture and replay from anywhere (remote or via console) because today they don't have that capability, are required to have it or simply, they might have gone the "jumpbox" route to realize that they are missing crucial sessions.
• They hate having to invest in multiple solutions to enforce the same basic security principles.  Each time they do, this may mean:
  - Evaluate a product
  - Invest or procure new hardware or software
  - Add additional infrastructure
  - Train or hire specialist
  - Maintain the solution down the road
  - Manage the vendor relationship

Here's a technical demonstration on how Centrify delivers this value:

The key differentiation areas are:

• AD Orientation - implemented in more of 90% of enterprises, users use a unique identity.
• Centrify Zones - unique patented way to create groups of systems in Active Directory
• Granularity of Access Controls - control HOW users log in to systems
• Granularity of Privileges - no need to know the privileged account password.
• Simple privilege elevation:  sudo-like tool in UNIX/Linux, shell and command line on Windows.
• No proprietary magic on how events are stored: no need to have a central system just to know who did what and when - need to rely on a central system to correlate who had a privileged account.
• Quick attestation and robust reporting - the data is in AD.
• Separates the operational tasks versus the governance tasks - to enforce SoD
• Works in multiple core platforms:  UNIX, Linux and Windows
• Protects your systems: Provides end-to-end enforcement of the rules as well as session capture and replay.

Finally, the end user experience is not affected, no identity silos are created  and your AD infrastructure, processes and technology are reused.  We propose that the "least access/least privilege" approach to Privileged Identity/Super User Privilege Management should be used at least in 80% of the use cases.

In the next post we're going to talk about the next 20%, this includes Shared Account Password Management, Proxied/Brokered/JumpBox initiated sessions (what gartner calls Privilege Session Management).

A commentary on Privileged User Management

A commentary on Privileged User Management

When I visit customers and prospects, I see an amalgam of priorities, knowledge, organizational dynamics, but most commonly complexity and a feeling that most people don’t know where to start. Ultimately the decision is simple.  There’s no access controls without a consistent identity store.

I’m also surprised on how easy analysts are influenced by vendors. Let’s take for example the topic of passwords; I've  always conceded that shared account password management is needed in the enterprise, but that it only applies in break-glass scenarios, change control or network devices; however, vendors in their effort to expand have positioned their solutions as the “end-all-be-all” (regardless of the true need) which to me is a disservice to the customer or prospect.

My personal philosophy is clear, least privilege management is the right way to go because it applies in most of the cases (the cases would be larger if network devices had better AD integration); however, now that Centrify is in the SAPM business as well, I feel it’s my obligation to position it, but in its proper context and use cases.  This is validated by the fact that most data breaches have components of credential theft; threat agents are counting on somebody that has more power than they should have, to get to the sacred keys of the kingdom.

Here’s what I propose to readers of this post, (I will be the first to admit that I’m just reusing the 80/20 rule) but, I think that if 8 out of 10 privileged actions are part of my day-to-day job and they have been defined with a privileged elevation mechanism, I’m quite happy.  This is becoming increasingly important on Windows, where admin account (e.g. “-a”) accounts are no longer the best practice.  On UNIX/Linux privilege escalation has existed for years in the form of sudo.  What you’re trying to avoid here is that if you implement a password-centric system, users will naturally “camp” or will try to get around the proxy system (forcing the implementation of complex network rules).

This should settle the whole “what’s my goal post” question, and ultimately, it’s up to the organization dynamics to determine if this is a realistic and attainable goal.

Least Privilege Management - Where do I start?

Ultimately, the game it’s all about control.  Here’s a playbook that I often share with customers and prospects:

• First, you have to start with a Common Identity (e.g. AD)
• Then you have to be able to group systems based on a security governance model
  (e.g. web servers, database servers, PCI servers, Financial Systems)
• Implement granular access controls:

• Define where the user can log in as part of their job functions 

• Define how the user can log in to systems (E.g. SSH but not console;  RDP but not console)

• Define any time effectiveness of a role  (E.g. Backup guy should only run tar as root from 5PM to 6AM

• Reuse Processes

• Assign roles to AD groups

• Manage memberships or requests via your ITSM or workflow tool.

• This way you can use that tool for attestation as well.

With least privilege, where I see customers often think that the task will be very large because they must identify and catalog the tasks that users are performing with privilege; but the view is a bit myopic because those things are managed and it is after all a capability (people-process-technology) that should have its own road map.

At Centrify we suggest this:

1. Start with a “broad scope” but with a simple goal:  Eliminate shared account usage.  Maintain status quo as it relates to super users.  Allow them to elevate as root/Administrator; but deny them the knowledge of the password.  
2. As you are able to increase accountability, then start “narrowing the scope”; e.g. “What’s does a Database guy do, with privilege in their day-to-day?” 

As you move to this model, concede that there will be areas of improvement (hence the need for feedback and a road map). This is another area where customers and prospects have misaligned expectations;  you will have to work on privilege management all the time, this is not a "set it and forget it" type of deal.  There are governance and operations components, there's attestation

The other 20%, perhaps break/glass, or access to production systems, I’m happy with proper workflow/approvals and change control.  Otherwise I’m getting in the way of the user’s productivity and they will try to find ways around the “broker” system.

The ever-expanding definition of a Privileged Account

It's not just about root, Administrator, oracle, apache, jboss or xyz service/privileged account.  Your privileged users exist everywhere.   What about your social media accounts?  The embarrassment of losing control of these accounts is evident every day for corporations;  the same with SaaS applications.  Isn't the Sales Admin in Salesforce, or the Finance or CFO lead in Netsuite a privileged user?

In a hybrid enterprise, the rules have changed;  however, I believe that Centrify has you covered.  In the next post we'll continue this series and we'll talk about the Centrify value in the context of Privileged User Management.

Centrify's Value Proposition - Part 2: The hybrid and heterogeneous enterprise

Organizations with traditional (on-premise) and  hybrid (private/public cloud) with Active Directory, come to Centrify because:

• They have diverse platforms (UNIX, Linux, Macs) in their enterprise (on-premise and in the cloud).
•  They are looking to Centralize the administration (or implement effective controls) for user access in those different platforms.  Their reasons may be due to security, regulation, operational efficiency or simply because they are reacting to an audit or other event.
•  They are also looking to leverage the secure authentication methods provided by Active Directory. 
•  They are looking to find a way to effectively manage UNIX identities by using Active Directory, but preferably, they don’t want any schema extensions to AD or software loaded in Domain Controllers.
• Some other organizations (and this is quite common on the Mac side) are looking for a more robust way to support AD integration and are also looking to use a common management framework (like Active Directory Group Policies) to enforce security policy or configuration management policies.
• Other organizations are looking to focus on their core competencies because perhaps they invested a lot of engineering cycles using open source software (like Samba/Winbind, RedHat’s SSSD, OpenLDAP with MIT Kerberos) and realized that the speed of requirements and diversity of platforms does not align with their goals.  (E.g. a Financial organization spending hundreds of man hours on “manual” identity and access controls rather than portfolio analysis).  These types of organizations are ready for a solution that “just works”
• Organizations want solutions that are friendly to private/public cloud scenarios; this means a toolset that promotes automation.
• The organization may have high-security requirements like smartcard authentication, FIPS encryption or common-criteria certified solutions
•  Finally, some organizations tried to wait as long as they can keeping the status quo; and a compelling event has made them change like:

• Change of leadership

•  A merger or an acquisition

•  A new technology (like BigData)

•  Acknowledgement that advanced persistent threats can’t be ignored

•  Another solution isn’t providing timely updates, proper support or their future is uncertain

• An audit or data-breach

•  Perhaps there’s an old infrastructure (e.g. NIS, LDAP) that found fresh blood that isn’t afraid of “touching the server, who knows what will break”  <= yes, this sadly happens.

Everything I outlined above is core of what some analysts call “Active Directory Bridging” but when you look at it is much more; it is the basis for implementing critical access controls and a management framework that is based on reuse of existing infrastructure and processes rather than point solutions.  It’s also the foundation of making sure users can do their work, without interrupting their flow.

Here’s a technical demonstration on how Centrify provides value:


 A very unique capability that is exclusive to Centrify is the zones technology.  Nobody else can do what Centrify does to group systems in a hierarchical way while consolidating UNIX identities for Users, Groups and NIS Maps.

Note that also, a large number of "born-in-the-cloud" organizations are coming to Centrify for Web Application SSO and Enterprise Mobility.  We will cover that in other entry.

In the next post, we'll focus on how Centrify builds on their AD bridging capabilities to provide Privileged User Management on UNIX, Linux and Windows and how it uses it's Identity Platform for secure access and shared account password management.

Opinion: On Centrify's Value Proposition - Part I

My take on Centrify's value proposition

Non-IT people often ask me:  “What is it that Centrify does…?” the answer to that question is becoming increasingly broad, because the product portfolio is growing; what I typically like to say  is this:  “we provide Active Directory-centric Access Controls(*)”; however, in the past 3 years we have released capabilities that expand beyond the basic premise of a heterogeneous data center.  The overwhelming response to some of the briefings we have with prospects or customers is this:  "Wow, I didn't know you did that much?"

I've expanded the definition to:  “We help you with your existing access control challenges in the data center, in the cloud and with mobile devices” this is regardless of directory bias especially in the context of Cloud (IaaS, SaaS) we are dealing with extended borders where Active Directory may not exist. However, ultimately common sense dictates that organizations should be aiming to reduce identity stores, not increase them.  However, when I look at our customer successes, and I'm a bit more bullyish.  Perhaps the answer should be: "We allow you to implement strong access controls in your systems and apps, regardless of location while promoting usability and operational efficiency" 

In this long entry, I'm going to present Centrify’s value proposition in 3 major areas:

• The diverse data center (using Active Directory to conquer AAA challenges with non-Windows platforms:  UNIX, Linux and Macs)
• Privileged Identity Management (using Centrify software and Services and Active Directory) to conquer the Super User Privilege Management (SUPM), Shared Account Password Management (SAPM), and Privileged Session Management (PSM) for Windows, UNIX, Linux, Macs and Network Devices.
• Web application and Software as a Service (SaaS) access controls, single sign-on (SSO), mobile access and mobility management

The subsequent posts will consist of “problem statements” or “challenges” that our customers and prospects provide us, and I will deliver a series of technical briefings (or demos) to cover each problem set.  As always, the intended audience is typically architects, security professionals, systems administrators and application owners.

In summary, and in business terms Centrify’s value proposition is around these principles:

• Implementing Strong Access Controls to protect your systems regardless of location
• Eliminate or consolidate identity stores
• Use what you have:  de-duplicate processes and infrastructure 
• Promote operational efficiency
• Be strategic, rather than tactical - solve the problems of today and tomorrow.

The goal is not to go in depth in technical terminology but to look at problem sets and solution sets "a la Centrify" - If you're just a visitor, it's a great way to look at Centrify in a non-technical way, although the demos will be somewhat technical.

(*)Why not use “Identity Management”?   Centrify uses the term too.

I personally refrain from using the “Identity Management” term because years ago, the term was intimately linked with Gartner’s definition AND for too many IT professionals it is synonymous with software that was expensive, consultant-heavy and projects that showed very little results.  

I think Centrify is in the identity space, but our approach is much simpler and integrated (producing faster results), besides, prospects often have unrealistic expectations if they think a single solution can solve all their Identity-related problems.  What I’m willing to concede (and I’m BIASED) is that if an organization is committed to Active Directory as their main identity store, using Centrify will provide “pound-per-pound” the best capability return per dollar invested, however, I’m also able to recognize that not all organizations are the same; there are complexities, political battles, biases and the simple commitment to use Active Directory is a tough decision to get to.

I also don’t want to have to tell people what they don’t want to hear.  If you were to ask me “Can you synchronize between PeopleSoft and target “X” system” – my answer is basically “No. user provisioning happens upstream and we try to avoid synchronization at all costs”  - sometimes briefings become a contest of “what can you do?” vs. “what problems can you help me with?” and this is the most frustrating part of being in technical sales.