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
Background
Many governmental and commercial
organizations have implemented smart cards as their preferred method for
Multi-factor Authentication. This post explains how to configure
Centrify Identity Service (CIS) or Centrify Privilege Service (CPS) to provide
authentication using Smart Cards. This article provides the
configuration steps to enable Smartcard (certificate)-based
authentication for CIS or CPS.
How it works
Generally,
cryptographic credentials (user certificates) are stored in the
smart card (PIV or CAC card) and the system has a dedicated reader.
Upon successful authentication (credentials verified and PIN submitted)
the operating system or application will use a standard protocol (like
Kerberos) or a one-time-code to grant access to the system or
application.
For example, Centrify Server Suite allows the
user of Kerberos for SSO to applications like Secure Shell (SSH). Our
DirectAuthorize can enforce if the user is allowed to log in with a
password or with Kerberos/GSSAPI only.
In the case of
Identity Service and Privilege Service, we use a Centrify capability
called Zero Sign-on (SZO). SZO provides a one-time token to use for
authentication if the Authentication Profile that applies to the user is
configured for Certificate-based Authentication. All the user needs to
do is navigate to the CIS/CPS site, select the smart card certificate
and PIN.
This setup provides strong authentication to access Apps or for Privileged Identity Management scenarios.
What you'll need:
An instance of Centrify Identity Service App+ or Privilege Service (CPS can be SaaS or On-Prem)
Public
Key Infrastructure Infrastructure (Enterprise CA, Revocation
Infrastructure, well-configured PKI clients) and understanding of how
the subject name is being provisioned.
A copy of the Certificate Chain (or Root CA) for your PKI infrastructure.
Strong
Disclaimer: This is a PKI-related topic. You should always be workign
with your PKI SME with anything related to certificates, trust chains,
revocations, etc.
Configuration Overview
The configuration depends on the deployment option of the service.
Configuring the Root CA in Identity Service App+ or Privilege Service
Configuring a Policy that allows for Integrated Windows Authentication
Testing the configuration
Appendix: Configure Privilege Service On-Premises CNAME and Zero Sign-on SSL Certificate
Configuring the Root CA in Identity Service App+ or Privilege Service (SaaS)
Sign-in to Cloud Manager
Go to Settings > Authentication > Certificate Authorities Note:
If you can't see the Certificate Authorities option, you're not running
the App+ edition or in the case of Privilege Service on-premises, you
have to perform the activation steps (see below).
Press Add and complete the follwing information: Name: descriptive name of the CA Extract login name from: The options are a) Principal Name from Subject Alternate Name b) E-mail address field from Subject Alternate Name c) Username from Subject
Click Browse and select the location of the root ca certificate.
If
you are confident that you have a highly-distributed (Internal &
Internet facing) Certificate revocation infrastructure, check the
"Enable Client Certificate Revocation Check" if you are not sure
un-check the box for now. Note: If you don't
know what PKI certificate revocation is, it's time to find your in-house
PKI expert and get him or her involved. This is a serious topic.
Press Save
Configuring a Policy that allows for Integrated Windows Authentication
Sign-in to Cloud Manager
Go to Policies > [Select your Test Policy] > Expand User Security Policies > Login Authentication
Set the "Enable authentication policy controls" setting to Yes, if not selected.
Scroll down to "Other Settings" and make sure that the "Allow IWA connections..." is checked. Then note the following: Note: Certificate-based authentication bypasses the login authentication rules set up for that profile. The key settings are: The first setting "Use certificates for authentication..."
is the main switch. If you un-check this box, the users in scope for
this policy won't be able to use smart cards for authentication. This
bypasses any controls set under "Login Authentication" in the preceding
section. The second setting "Set identity cookie..."
controls whether the cookie is set for the browser. I would not set
this flag if you expect users to access via non-managed systems. The third setting "Accept connections using certificate..." defines whether if users logging in with smart cards or certs are treated as "strongly-authenticated"
Make your selections based on your desired security posture.
Press Save.
Testing your configuration
Navigate to your Identity Service or Privilege Service URL
Depending if your browser is configured correctly, you'll see any of the following pop-ups will come up:
After selecting the Certificate on the Smart Card, you'll be prompted for the PIN:
Once you type-in the PIN, you'll be redirected to the appropriate portal (User | Cloud Manager | Privilege Manager).
Quick Setup Video
Appendix 1: Enabling Certificate Authorities for Centrify Privilege Service (On-Premises)
Background:
Centrify Privilege Service can be deployed on premises on a Windows
Server 2012 R2 system. You need a CNAME record for the Zero Sign-On
website and a x.509 certificate with that DNS name.
Pre-requisite tasks:
a)
Set-up a DNS CNAME record to with the name hostname[zso].domain.name
pointing to the hostname.domain.name. E.g. if your system name is app1.corp.contoso.com, create a CNAME record to app1zso.corp.contoso.com and point it to the original host name.
b) You need an SSL Certificate with the DNSname for the SZO special host.
Log in to the server hosting Centrify Privilege Service
Open an Administrative PowerShell and navigate to %Programfiles%\Centrify\Centrify Identity Platform\Scripts
Run the setup_certauth.ps1 script. The program will ask if the pre-requisites have been met.
Confirm and you'll be prompted to provide the x.509 (SSL) cert for the SZO site.
Once completed, you can return to Cloud Manager and perform the steps outlined above in the: "Configuring the Root CA in Identity Service App+ or Privilege Service (SaaS)" section.
If you're familiar with Identity Service and Privilege Service, they provide built-in step-up authentication like:
Centrify Mobile Authenticator
SMS
Phonefactor
E-mail
Security Question
We are going to cover
YubiKey (Smart Card) for PKI-based auth to Apps secured by CIS and secrets and sessions secured by CPS
OATH OTP (TOTP/HOTP) using YubiKey or other OATH compatible Authenticator (e.g. Google Authenticator)
Centrify uses Authentication Profiles to control what authentication mechanisms are used in different contexts:
a) Securing access to applications or the Centrify Portal (IDP initiated)
b) Securing access to UNIX & Linux systems
c) Step-up (privilege elevation) for UNIX, Linux and Windows systems
c) Provide RADIUS-based challenges for Cisco, Juniper and other VPN scenarios
d) Securing access to reverse-proxied on-prem applications made available via Privilege Service
e) Secure applications that implement Centrify APIs (e.g. Web, Mobile SDKs)
The challenges
Web Apps (on Prem or SaaS) need to be protected with strong mechanisms
Systems that provide access to secrets (like password managers) and secure session brokers also require strong authentication.
The
proliferation of "best of breed" solutions promotes IT fragmentation
and limits organizational flexibility. There's no need to have a
solution to secure servers, secure apps, provide multifactor and other
services. This promotes complexity.
Regulatory frameworks (like the upcoming PCI DSS 3.2) stress the use of Multifactor Authentication in sensitive systems.
Organizations
may have already standardized on OATH or PKI authentication and it may
be undesirable for them to adopt new mechanisms or train users.
The opportunity
Both CIS and CPS support Certificate-based authentication (Smart card) and OATH OTP
YubiKey simplifies the adoption of both mechanisms in a single form factor.
Lab Goals
Limit application users (on-prem web or SaaS) to strong authentication via Smart Card (YubiKey) or OATH OTP
Limit privileged users (of shared passwords and secure sessions) to strong authentication via Smart Card or OATH OTP
What you'll need
For All
Centrify Identity Service or Privilege Service Tenant (start a trial here) with basic knowledge an account with system administrator's rights
For the Contractor Scenario
A test user (can be from any source: AD, LDAP, Cloud Directory, Federated or Social Identity)
A YubiKey4, NANO or NEO and Yubico Authenticator (alternatively, any OATH-compatible authenticator like Google Authenticator will do fine)
For the Employee Scenario
Active Directory with Certificate Services
A Certificate provisioned for the user's smart card or YubiKey To see instructions on how to set this up, check out the Announcement Post that contains the base lab instructions.
Define an authentication profile for login that requires Smart Card or OATH OTP for login to the Centrify Portal This will cover any portal-based access (IDP initiated) or unauthenticated service-provider initiated connections
Request OATH OTP multifactor authentication to access to an application.
Employees with SmartCards
Define an authentication profile that considers users authenticated with Smart Card as strongly authenticated
Centrify Identity Service (or Privilege Service) Setup for Contractors
Sign-in to Centrify Identity Service (or privilege Service) and go to Cloud Manager > Policies. At
this point you can either create a new policy or work with a new one
tied to an specific role. I am using a Contractors role and tying it to
that role.
Navigate to Policies > Your Policy > User Security Policies > OATH OTP > Allow OATH OTP Integration: YES Show QR code for self service: [Select your appropriate setting] OATH OTP Name: [type a descriptive name]; I used Google Authenticator or YubiKey OATH OTP has been enabled, now it's time to enable it for an authentication profile.
Navigate to User Security Policies > Login Authentication - To configure the policy for login - capture the name of the effective rule (e.g. GlobalAuth High) - To configure the profile for secure app access - capture the name of the effective policy. Save the policy.
Navigate to Settings > Authentication > Authentication Profiles and identify the profiles form Step 3. For each profile: In my example, I'm using a single profile that allows for phone call and OATH OTP client, then Password.
Onboarding OATH OTP tokens for Contractors
This step can be performed in two ways:
Self-service from User Portal > Account > Actions > Set up "[OATH OTP name]"
Bulk (this is for larger deployments); from Cloud Manager > Settings > Authentication > Other > OATH Tokens Use the provided Excel template to perform a bulk import of OATH tokens.
Centrify Identity Service (or Privilege Service) Setup for Smart Card Employees
Upload your PKI trust chain to your tenant using Centrify Support
Log
in to Cloud Manager and go to Policies > [policy that applies to
employees] > User Security Polcies > Login Authentication
Edit the "Other Settings" accordingly:
Press Save
Test Matrix
Contractor can self-service enroll their OATH OTP using the user portal
Access
the Centrify Identity Service (or Privilege Service portal) requires
OATH OTP, then password (to protect the user's Password).
Access a designated application (e.g. Amazon AWS) requires OATH OTP.
Testing for Employees
Authenticate using your Smart Card or YubiKey
Attempt to access Centrify Privilege Service or Identity service URL or SP-initiated connection.
Select the Certificate in the picker.
Type the PIN for your smart card or YubiKey
Depending on how you set up your policy, Smart Card sessions can be set up to bypass additional controls.
Video: Contractor Setup
Other considerations:
When
using self-service onboarding for OATH OTP tokens, allow for a
secondary step-up (like phone call) so the user can enroll their OATH
token.
When using self-service onboarding for OATH OTP tokens,
be careful about allowing access to QR codes. Users have to be educated
that it is a sensitive operation. Centrify provides a policy to allow
this capability.
In this first part, we'll
address how to secure the AWS Root Account. Amazon suggests protecting
the root account with Multi-Factor Authentication, however, in this
article I'm describing a strategy to not only meet but exceed the
requirements to protect this account.
Enhanced Objectives
Eliminate sharing of the Amazon AWS root account
Protect the password by not exposing it to any users
Limit access only from the corporate network
Limit access to the AWS account to those with business need-to-know
The Value of Centrify Identity Service Centrify Identity Service
provides a powerful policy engine that allows for the implementation of
these controls, not only for the Amazon AWS app, but for any web
application that has a user/password authentication pattern and uses a
shared account.
As customary, we'll use the Plan-Do-Check-Adjust methodology.
Planning Role-Based Access Control - Should the application always be accessible by a limited group of users? - Should application access be governed by AD group membership or Centrify Role? Should the application be accessible to nobody and only requested on demand? - Who will approve the application access request?
Additional Controls
Should the application be accessible only from the corporate network?
Should the application be accessible at certain times?
Should the application require step-up authentication.
What should be the step-up mechanisms? (Centrify MFA, OATH OTP, Phone factor, Email, SMS, Amazon Virtual OTP, etc)
An example Access Control will be
controlled by AD group membership (e.g. AWS-Root-Users); ad-hoc access
will be controlled via workflow. The app will be accessible with a
step-up mechanism. The approvers will be an AD group called
AWS-Root-Approvers.
Implementation This implementation steps assume you have a Centrify cloud connector set up providing bridging for an AD domain.
Access Control Building-Blocks Create the AD Groups
In Active Directory Users and Computers, navigate to an OU for a CIS bridged-domain.
Create Two AD groups:
- AWS-Root-Users: add the permanently authorized users. - AWS-Root-App-Approvers: add
a set of users that will approve access requests (ideally not the same
as above to enforce separation of duties)
Create the AWS Root Role Members of this role will have permanent access to the AWS Console as root. This is controlled by AD group membership.
In Cloud Manager, navigate to Role and Click Add Role
Description: AWS Root
Members: Go to the Members section and click the Add button and browse for the "AWS-Root-Users" AD group.
Create the AWS Root Approvers Role Members of this role will be able to approve who gets to access this app. This is controlled by AD group membership.
In Cloud Manager, navigate to Role and Click Add Role
Description: AWS Root Approvers
Members: Go to the Members section and click the Add button and browse for the "AWS-Root-Users" AD group.
Configuration in Identity Service Add and Configure the AWS User/Password App
In Cloud Manager, navigate to Apps > Add Web App
In the Search Box, type AWS
and press Enter, on the results, pick the "Amazon Web Services AWS
User/Password" template and click Add.
When ask to confirm if you want to add the app, click Yes. This will open the app template for configuration.
Description - in this step you will change the name to something descriptive to your environment.
User Access - check the box next to the role you created for this purpose (in our example AWS Root)
Policy - we'll revisit this in the "Adjustments" section.
Account Mapping - This is where you'll securely store the AWS credentials. Select a) Select "Everybody shares a single username" b) Populate the username with the AWS root account email address and the password with the current password.
Press Save, you're ready for initial testing.
Verification At this point you can sign-in
to Centrify Identity Service with any user in the AWS Root CIS role or
an access request can be triggered via the "Add Apps" menu of the User
portal.
Sign-in to the Centrify Identity Service User Portal with a user from the AWS Root Role
You should see the AWS As Root App. Click on it.
This should launch a new
browser tab and provide you with assisted injection of the credentials
using the Centrify Browser Extension.
You can also test the Access
Request/Workflow capability by logging in with a user that is not
entitled to the application, then click "Add App" and search for the
newly-created app.
Adjustments Limiting Access only from the Corporate Network This is desirable if you want
to make sure users can only access the AWS console from the on-premises
corporate network. The planning steps imply the addition of corporate
subnets to the Centrify Identity Service Settings and using the Policy
tab of the AWS Root App to enforce these controls.
Adding Multifactor Authentication or Other Controls MFA is built-in to Centrify
Identity Service. All you need to do is check the box, and provided
there's an authentication profile that will support the step-up methods
you will be set.
Enhancements of CIS 2016.2 Amazon AWS provides an
virtual MFA capability that leverages OATH. As of February 2016,
Centrify allows you to use any OATH based OTP mechanisms, this means
that you can leverage those mechanisms as well.
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
Centrify Server Suite 2016 - New features, New Platforms, New Possibilities
Just in time for the Holidays and the New Year Centrify delivered Server Suite 2016; this release is focused on unleashing the power of the Centrify Platform:
a) Server Suite
b) Identity Service
c) Privilege Service
As well as continuing to delight customers and prospects.
Here are a few demos:
Step-Up Authentication (+ CIS)
Reporting Services (+SSRS)
Local UNIX User and Group Management
Privilege Service Integration - Automation Unleashed
Centrify Start Menu for DirectAuthorize Windows, CLI Tools, PowerShell, GPOs
New Supported Platforms (CDC)
-Windows 10 (x86_64)
-Mac OS X 10.11 (x86_64)
-Fedora 23 (x86, x86_64)
-CentOS 6.7 (x86, x86_64)
-Oracle Enterprise Linux 6.7
(x86, x86_64)
-Red Hat Enterprise Linux
Desktop 6.7 (x86, x86_64)
-Red Hat Enterprise Linux Server
6.7 (x86, x86_64)
-Red Hat Enterprise Linux
Server 6.7 (ppc64 – no Power8)
-Red Hat Enterprise Linux
Desktop 7.2 (x86_64)
-Red Hat Enterprise Linux Server
7.2 (x86_64)
-Red Hat Enterprise Linux
Server 7.0, 7.1, 7.2 (ppc64 – no Power8)
-Scientific Linux 6.7 (x86, x86_64)
-Ubuntu Desktop 15.10 (x86,
x86_64)
-Ubuntu Server 15.10 (x86,
x86_64)
-SUSE Linux Enterprise
Desktop 11 SP4 (x86, x86_64)
-SUSE Linux Enterprise Server
11 SP4 (x86, x86_64, ppc64, ia64)
-SUSE Linux Enterprise Server
12 (ppc64 – no Power8)
Amazon AWS EC2 is quickly becoming one of the most popular options for
Enterprises to extend their Data Center infrastructure out in the cloud.
IaaS vendors like Amazon provide an array of services that include
directory services, orchestration, automation, APIs and more.
It's important to understand that flexibility can slowly become
chaos, especially for enterprises that have fought hard to consolidate
processes around Identity and Access Management.
This multi-part series discusses a basic IAM playbook that can be
enabled with Centrify’s Identity Platform (Identity Service, Server
Suite and Privilege Service). The principles continue to be the same:
Implement Strong Access Controls using what you have: Active Directory
as the Identity Store and enhance the experience and security controls
leveraging Centrify Technologies.
Part I - The Requirements and Challenges
Identity and Access Management Requirements
Secure Access to the Amazon Root Account The experts at Amazon will be the first to tell you. Don't use
your Amazon root account as the means for regular administration. Don't
share it. Look at this account only for break-glass scenarios
Use Role-Based Access Control This is another best practice documented by our friends at Amazon.
However, what's not very obvious is that you may want to do this from a
common identity source. We don't want AWS to become an additional
identity silo. Remember, there's always attestation needs. We need to be able to report who can perform which actions in the Amazon Console. Also,
remember, RBAC needs not only apply to the Amazon console, but to the
systems that are running in the IaaS cloud; you must be able to enforce
the least access, least privilege, separation of duties and be able to
attest or report which users has access to each system, what can they do
with privilege and how they got granted the access.
Use Multifactor Authentication Amazon
recommends strong controls for the root account; however, We argue that
we have to apply stronger controls like being able to access the
console only from on-premises in some cases (or example, when using the
amazon root account) and apply MFA across the board in cases where the
user is accessing externally.
The challenge for many
organizations is that Multi-factor Authentication is also a fragmented
capability, because most IAM vendors until recently have not considered
it a must have. There’s also the issue of modern use cases. Physical
OTP tokens are expensive and don’t provide enough information for the
modern enterprise. We need more significant information and
workflow-like capabilities and to be able to use that same scheme in
other use cases, like when elevating to use your privileges. Since
all roads point to the mobile device in your pocket, this means strong
Enterprise Mobile capabilities to secure that device as well.
Finally,
wouldn't it be better to go beyond MFA and be able to apply stronger
policies? Perhaps only allow access to the AWS console only from your
on-premises infrastructure? Provide authentication policies that
request MFA before the user's password?
Apply a Security Policy This is another item in the Amazon checklist, they specificaly talk about passwords. However,
organizations with mature security practices understand that using a
common identity store (like Active Directory, used in 90%+
organizations) also allows for consolidating policy definition and
enforcement. Amazon systems can be integrated to the common directory for the purposes of Access Control. This
step requires the extension of your corporate IT directory to the IaaS
infrastructure. This can be accomplished several ways (in the case of
AD). A resource domain with a 1-way trust and a site-to-site VPN, an
RODC, etc.
The benefits of this approach include less IT
fragmentation and complexity, and consolidation of processes and tools,
however, the solution should be ready for automation and orchestration;
one of the principles of public/private clouds is elasticity, this means
that if machines are spun up or down, the tools should have simple ways
to satisfy these needs.
Session Management Systems in the Amazon cloud
should be accessed in a way that allows for accountability,
centralization of access and enforcement of strong policies. Although
it's possible to access directly via Amazon, this tends to open itself
to challenges with sessions and key management.
Password Management Finally, we need to
eliminate the human challenge of shared credentials. Accounts like root,
Administrator and any others should be brokered with a repeatable
process: request/approve-check-out-check-in-rotate.
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)
Platforms supported in the initial release - more on the way
