Background
There
are several kinds of non-user accounts like local admin accounts (e.g.
root, Administrator), application service accounts (e.g. oracle,
Apache), network services (e.g. hdfs, yarn) or batch job/multi-tier apps
(e.g. sftp, ssh, etc.) The goal of Local Account management is to
leverage the existing management infrastructure and framework (Active
Directory, Centrify Zones, DirectMange/PowerShell/UNIX adedit) and the
Centrify client (DirectControl) to provide an additional set of security
controls. Centrify Suite 2016 provides the ability to:
Control local UNIX user accounts (provision, disable, visibility or removal from /etc/passwd)
Control local UNIX primary or secondary groups (provision, visibility control membership, or removal from /etc/group)
Perform actions upon user creation/deletion, e.g. home directories, environment variables, password management/lifecycle.
We will provide the basic building blocks for you to evaluate this feature in your lab to explore the feasibility of it.
Like other posts, we'll use the Plan-Do-Check-Adjust model.
Planning
Use
these planning steps for your test environment. We'veve added enough
information that can be recycled towards production deployments.
Potential Stakeholders
Centrify SME or Security Lead: These users are entitled to perform management of zone operations inside Active Directory.
Account
Owners: These are the subject matter experts that understand how the
user or group accounts are used in the environment. They can answer
questions like these a) What local user (or group) accounts are required in a system or collection of systems? b) Should the account have a password? should the password be managed? c) What are the group account members? d) Should the user or group account be visible to apps using name service (NSS)?
Security
Lead for Password Management: This is the SME for a shared account
password management solution. They may know how to invoke any tools to
manage the lifecycle for a shared account.
Technical Requirements
Active Directory and Centrify
A licensed or evaluation copy of Centrify Suite 2016
An Active Directory test or production environment with Centrify a Centrify Hierarchical zone
A UNIX/Linux system with Centrify DirectControl 5.3+
Password Management (optional)
If
using Centrify Privilege Service (CPS), you need the CLI toolkit for
your platform and a Cloud Connector that can reach your test systems.
If using a 3rd party password manager, you need the tools and knowledge of the methods provided by the vendor In this example, we'll be using CPS.
CLI tools and scripts: admanagelocal, adflush, cjoin (CPS) cgetaccount (CPS)
How Local Account Management Works
The design and management is very similar to what you're used today with Centrify and UNIX-enabled AD users or Groups.
Information
about the local user or group is stored in Active Directory. The local
users or groups are defined in the zone. The scope of the local
account is determined by where the identity is defined and the role that
is assigned. For example, if an account should exist and be enabled in
all servers, then it's defined in the topmost zone and assigned a role
with visibility at that level. If it should only be visible to a group
of systems (e.g. Database Servers) this can be done at the child zone or
computer role level. The management is exactly identical to
UNIX-enabled AD users.
Once the changes are made in AD and the
flush interval passes (or the adflush command is issued) the local
account actions will be triggered.
There are additional CLI tools:
admanagelocal: to view existing managed local accounts or refresh the changes (or use adflush).
handle_local_accts.sh:
this is a sample script provided to perform post-provisioning actions
(e.g. home directory creation). There are two versions of this script,
one included with DirectControl, another one included with the CPS CLI
Tools.
A Basic Lab Design
In my test environment I have:
1. An AD domain (centrify.vms) with a single domain controller (dc.centrify.vms)
2. A domain-joined server called "member" that has Access Manager installed (Suite 2016)
3. A Centrify zone called global with 2 computer roles: App Servers and Web Servers
4. Two Linux servers (engubu1404 in the App Servers collection and engcen6 a Web Server)
5.
Optional: because I'll be testing the password lifecycle management, I
have a CPS tenant and a cloud connector running on member. CPS will
provide the shared account password management functionality and
workflow.
Use Cases
We are going to focus in several use cases:
Local UNIX Group Tests
Provision a local group: - to all domain-joined systems - to a subset or individual system
Manage group memberships
Remove from /etc/group
Local UNIX UserTests
Provision a local user - to all domain-joined systems - to a subset or individual system - have the password randomized and the home directory created
Disable the user
Remove from /etc/passwd
Local User and Password Management (optional*)
Provision a local user and manually manage the account's password
Provision a local user and automatically manage the account's password
Retrieve the password for usage in break glass or scripting scenarios (admin or request via workflow) * These tests are optional given that they require a password manager that provides certain toolsets
Implementation Download and Install the Centrify Suite 2016 bits
Download the Standard Edition 2016 Consoles
Download the Centrify client bits for your platform
Install Access Manager
Install or upgrade your agents (e.g. install.sh, rpm or yum, apt or dpkg, etc)
Join a zone (use adjoin)
Although these steps should be straightforward to you, they are documented here:
General Test Cadence
There's a simple methodology to these tests:
Perform the change or update (e.g. create the local user/group, make visible, remove, change membership, etc)
Open a session to a system in scope of the previous change
Run getent (passwd or group) [target user or group] > these result should not yield the results
Run
adflush or 'admanagelocal --reload' (with sudo or dzdo) > this step
causes the flush interval to expire and the changes in the zone to
be committed by DirectControl
Run getent (passwd or group) [target user or group] > these result should yield the results expected.
For
example, if you create a new UNIX group called my-group (GID 3232) in
all systems, after an adflush all systems should produce the same
result. If you do this in an individual system (or group of systems.
Differences between Group and User tests a) Local Users follow the same rules as UNIX-enabled AD users
Local
users must have an identity and a role assigned to be visible in a
system. This allows for you to scope the visibility to the zone (all),
child-zone (subset), computer role (subset) or individual system. This
differs from Groups that can be enabled at the zone, child-zone or
individual system.
You can even time-bound the visibility of the role assigned to a local user. b)Users must belong to at least a singe existing primary group
Otherwise, the provisioning won't work. c) Post-provisoning actions must be defined via parameter or GPO
Provisioning
users does not mean that home directories, environment variables or the
password lifecycle will be handled by the Centrify agent; those actions
are customizable. Centrify provides a parameter called adclient.local.account.notification.cli;
it can be used with a provided script
/usr/share/centrifydc/samples/localaccmgmt/handle_local_accts.sh to
perform these actions.
d) Don't fall in the poor habits
Always prefer computer roles (users) and child zones (users, groups) instead of computer overrides.
Local Group Testing Video
Local User Testing Video (without actions)
Testing local user provisioning plus actions Using the provided handle_local_accts.sh to enable provisioning actions
In
order to allow for actions to be performed upon user provisioning (or
de-provisioning), Centrify provides a sample script called
handle_local_accts.sh that will perform actions like assign a random
password, create home directories, etc. To enable this script:
Enable the adclient.local.account.notification.cli parameter (set for none)
$ dzdo vi /etc/centrifydc/centrifydc.conf
# search for adclient.local.account.notification.cli
# enable the parameter by removing the pound and
# set it to the path of the sample file
adclient.local.account.notification.cli /usr/share/centrifydc/samples/localacctmgmt/handle_local_accts.sh
Run adreload (as root or with sudo/dzdo) and restart your testing. For example, to verify that a home directory was created after enabling a local account, you can use the following sequence:
# use access manager to enable the account (e.g. james-foo)
$ dzdo /usr/share/centrifydc/bin/admanagelocal --reload$ getent passwd managed-all
# this should confirm that the user is enabled
$ ls -l /home
# there should be an entry for the recently-created account
Testing local user provisioning plus password management Using CPS to manage the password lifecycle of a Centrify-provisioned local user account
This
test can be performed with any password manager that provides
UNIX/Linux-based CLI utilities. The idea is that upon local account
creation, the password manager is notified of the account creation, the
password is randomized, changed and managed by the solution. This
example uses Centrify Privilege Service to illustrate the use case.
To
set up this test, you need to have a CPS tenant with a Cloud Connector
that can reach your systems and a Linux system with the CLI Toolkit.
Create a CPS role for the systems that will be used for testing and assign the Privileged Management right You can also use an AD group and add your computer objects and use it to nest it into the CPS role.
Now you can download and copy the CLI toolkit to your test system. You can add the bits to your repository or copy the installation files manually.
Install the CLI toolkit and add the system as a CPS resource (e.g. in my engcen7 RHEL system)
# install the CPS CLI toolkit bits
$ dzdo yum install centrifycc-rhel6-x86_64.rpm
# add the system as a CPS resource
$ dzdo cjoin -k -n engcen7 -a engcen7.centrify.vms
# The command joins a system using Kerberos, names it engcen7 and gives it the
# hostname/ip of engcen7.centrify.vms (FQDN instead of address).
# You can verify the status using the cinfo command.
Switch the provisioning handler. The CPS CLI toolkit includes another version of the handler.
$ dzdo vi /etc/centrifydc/centrifydc.conf # modify the parameter belowadclient.local.account.notification.cli /usr/share/centrifycc/samples/localacctmgmt/handle_local_accts.sh
Run adreload (e.g. dzdo/sudo adreload)
Now you can add a new local account using access manager (e.g. managed-all)
First, verify that the home directory has been created, and then verify in the CPS accounts page that the account exists under the server.
You can also use the cgetaccount command to check-out the password for temporary use directly from the CLI. This is not really a practical example, most likely you'd assign the value of the password to a variable and use it on a script.
Provisioning local account with actions (random password/home directory) video
Provisioning local account with password lifecycle management (requires CPS or Password Manager)
This last video provides an example of Server Suite and Privilege Service working together:
We review the set up in the Centrify Privilege Service (connector, managed system role)
We verify the CLI toolkit in the target systems
We join the system as a resource in CPS (using cjoin)
We enable the adclient.local.account.notification.cli parameter to use the handle_local_accts.sh provided with CPS and reload the configuration
We enable our test account in Access Manager
We verify that the account exists in /etc/passwd and that home directory has been created
We verify that the acccount exists under the CPS server resource
We check-out the password via CPS Web GUI and UNIX CLI (with cgetaccount)
We perform an assisted SSH session with the account via CPS console.
Adjustments
There are several improvements to be made, for example:
Customize the handler script to be suited to your environment
Use your existing password manager to manage the lifecycle
Upon deprovisioning, the home folder can be gzipped+tar and removed
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)
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 decreaseidentity 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.
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:
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.
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 Identity Platform consists of two products: Identity Service and Privileged Service
Centrify Identity Service (formerly User Suite) has continued its meteoric rise and I want to congratulate many of my coworkers on their hard work and dedication.
In the past two weeks, to major publications have continued to highlight its critical acclaim:
Positions Centrify as a visionary, proving and validating the completeness of the vision that combines On-Prem/SaaS SSO with Enterprise Mobility Management plus robust policy, Multi-factor Authentication and VPN-less Access.
Ranks #3 among the solutions in a year that saw Salesforce, IBM and Microsoft enter the market and continues to beat the leader in execution and completeness of vision (#2 in pure play). It's only a matter of time given Centrify's leadership.
This is all looking at data from last year!!!! This is before App Gateway, Privileged Service, ServiceNOW integration and others were ready to go. Get the report here.
Calls out the integration of SSO+EMM+MFA+Management interface. Everyone else left to eat the dust.
Centrify Privileged Service (CPS) is a new entry (announcement) to the hybrid family of products that has a pure play in two areas (and growing): Shared Account Password Management (SAPM) and Secure Remote Access, but it builds on the existing capabilities of the Identity Service to deliver complementary capabilities to Server Suite.
RBAC continues to be the preferred method for Privileged Account Management (PAM), however, for emergency, one offs and change control, using a shared privileged account can be useful. Here's a video that illustrates the differences between the approaches:
Capabilities of CPS
Shared Account Password Management
Use your AD account and Multi-factor authentication to check out UNIX, Linux or Windows accounts, enforce policy, access anywhere (centrally or via mobile app). Upon check-out, the password is rotated for you.
Secure Remote Access
Leverage the existing cloud connector infrastructure to deliver secure remote access to resources regardless of their location (on premises or in the cloud IaaS).
Apps, UNIX, Linux and Windows sessions can be presented to users in a cohesive way
Much more to come, and many synergies with Server Suite
Very exciting time to be at Centrify and especially to help out prospects and existing customers.
