Centrify 2017.3 - Windows: Self-Service and Win10 MDM Enrollment

This article is based on an entry I wrote for the Centrify Community.

Platform Capabilities
Self-Service Overview
The Centrify Identity Platform provides self-service capabilities that can be leveraged from the web portal  These capabilities include:

• Self-Service Password Reset for Centrify Directory and Active Directory users.
• Self-Service Account Unlock for Centrify Directory and Active Directory users.

Self-Service - How it works

• Policy-based implementation:  Self-service capabilities are implemented by policy.  This means that you can enable/disable these capabilities based on the scope of the policy and this is quite handy especially if you want to offer these capabilities only to a segment of the population.
•  Multi-factor Authentication:  MFA is the mechanism to establish identity assurance when performing self-service operations (password reset and unlock).  This allows for administrators to adjust Authentication Profiles based on the type and sensitivity of these operations in the target population.  For example, for a user that does not deal with sensitive data, step-up methods (like SMS, Phone Factor, e-mail or questions) may be acceptable; however, for an admin-type, you may require of them to use a physical (true) MFA method via Mobile Authenticator, RADIUS-legacy OTP, OATH OTP or even FIDO U2F device (like Yubikey) to facilitate.
• Automatic detection of locked accounts:  A locked CD or AD account is detected automatically and the corresponding activity workflow is triggered (e.g. walking the user through the unlock authentication profile).

Endpoint Management - Overview
Centrify was the first Identity as a Service (IDaaS) provider to include both endpoint (mobile device/container/application management) as a built-in capability (along with MFA).  This has given us a unique position in the market.  With Windows 10 supporting MDM operations we are embarked in a process of incrementally adding capabilities to the Centrify Agent for Windows(tm).


Endpoint Management - How it works

• Policy-based implementation:  Endpoint policies are implemented by policy.  This means that you can enable/disable these capabilities based on the scope of the policy and this is quite handy especially if you want to offer these capabilities only to a segment of the population (e.g. users with corporate-owned devices vs. personalized or BYO).
  The policy payload can be delivered using Centrify's policy engine or Active Directory Group Policy.
• Platform Diversity and frameworks:  Depending on the platform, Centrify can provide varying degrees of depth.  For example, iOS, Android and other mobile devices have their own frameworks (e.g. APNS for iOS), however with OS X, not only we support the existing framework, but we enhance application management via Munki-based services.  In the case of Windows, expect incremental capabilities to be delivered when Configuration Service Providers are implemented.

Self-Service Capabilities in Microsoft Windows
Password reset (and account unlock) are popular identity management capabilities, and Windows has had the framework for years.   The graphical identification and authentication (GINA) in earlier versions of Windows, and now with Windows 8  and above, the Credential Provider is the framework used to deliver these capabilities.

Since MFA was introduced on Windows a couple of years ago, weintroduced a Credential Provider that is now extended to provide self-service password reset (2017.3) and account unlock (2018).  These capabilities in this version apply to Active Directory accounts only.

User Flow
Precondition:  An Active Directory writable domain controller has to be reachable by means of the corporate network or VPN.

1. User presses ctrl+alt+delete to invoke the Windows credential provider.
2. User clicks the "Forgot Password" link and confirms and presses the arrow.
3. At this point, the Windows client talks to the Centrify connector that will verify if the user is allowed by policy to perform the operation.
4. Once verified, the user will be presented with the MFA or step-up methods defined for the SSPR authentication profile in the Centrify platform.
5. Provided the user types a password that is allowed by the Active Directory password policy rules, the user will successfully reset their password. 
6. An audit trail event will be logged in the application log of the Windows system and the Centrify platform event table will be updated.

Notes:  although account unlock is not officially released in 2017.3, the behavior is relatively similar, the biggest difference is that we will automatically detect the unlock state and trigger the proper identity assurance mechanism.

Controls

• Multi-factor authentication for identity assurance.
• Audit trail (application event log) to provide a mechanism for Security Operations solutions like Splunk, etc.
• CIP Events are also tracked in the platform's event table.

Audit Trail
Audit trails detail is especially important given that self-service metrics are usually captured to illustrate how these capabilities contribute to productivity.


Dashboards
Self-Service operations are tracked by the security dashboard in Centrify Identity Platform.
The dashboard allows administrators or security leads to focus on an operation (e.g. denied self-service) and offers the scoping of the date range, once selected, you can drill into the users, failure reason as well as an overlay of their geo-location (if the client is reporting it) as well as the factors being used.

Windows 10 MDM Enrollment
MDM enrollment with the "connect to work or school"  facility.  Based on their own website:
" Windows 10 provides an enterprise management solution to help IT pros manage company security policies and business applications, while avoiding compromise of the users’ privacy on their personal devices. A built-in management component can communicate with the management server.

There are two parts to the Windows 10 management component:

• The enrollment client, which enrolls and configures the device to communicate with the enterprise management server.
• The management client, which periodically synchronizes with the management server to check for updates and apply the latest policies set by IT.

Third-party MDM servers can manage Windows 10 by using the MDM protocol."

With the Centrify Agent for Windows™ included with Infrastructure Services  2017.3, we now support automatic Windows 10 MDM enrollment as corporate-owned systems, with the optional capability for personalization.  In this release we provide:

• Administrative (bulk) enrollment (corporate-owned)
• Enrollment personalization (personal)
• Zero sign-on for to Centrify Apps Service from Windows (Internet Explorer or Edge) and Google Chrome browsers.

 This opens the possibility for future capabilities, including the configuration service providers.


Videos - Self-Service
Centrify Identity Platform - Self-Service Features Overview
 
Self-Service Password Reset using the Windows Credential Provider
 

Bulk Deployment - Corporate Owned Devices

Enrollment Personalization and Zero Sign-On

Centrify 2017.3 - Container Linux by CoreOS is now supported

In this article, we'll discuss Centrify's support for Container Linux by CoreOS introduced with 2017.3 (5.4.3).  This is based on an article I wrote for the Centrify Community.

About Container Linux by CoreOS
"Container Linux by CoreOS (formerly CoreOS Linux) is an open-source lightweight operating system based on the Linux kernel and designed for providing infrastructure to clustered deployments, while focusing on automation, ease of application deployment, security, reliability and scalability. As an operating system, Container Linux provides only the minimal functionality required for deploying applications inside software containers, together with built-in mechanisms for service discovery and configuration sharing." - Source: Wikipedia.

Engineering Challenges
We had to overcome some challenges based on how Container Linux is architected.

• No package manager (required to deploy our solutions).
• Read-only /usr filesystem (Centrify usually installs under /usr/share/centrifydc and audit under /usr/share/centrifyda).
• No Perl (required by group policy and other utilities).
• Kernel not compiled with auditd support (required for file/monitoring).

Needless to say, our Engineering team was up to the task and was able to provide a solution that enabled our capabilities and maintained the ease-of-use that is common with Centrify solutions.

Solution

• Centrify provides an installation tarball with the 2017.3 agent bundle that includes Access and Audit components.
  
• A special version of the install.sh utility will allow for interactive or automatic installations.
• Centrify software is installed in the /opt/centrify folder.
• Limitations:  Express mode, deployment manager installation and monitoring service are not available.

Features
Host-Based Security

• Increased accountability - Container Linux users can sign-in with their Active Directory account.  We provide identity assurance with Multi-Factor Authentication.
  In AWS deployments, organizations don't need to rely on the shared SSH Key-based credential called "core"
• Centralized administration - Organizations don't have to duplicate effort and continue to leverage Active Directory as the directory of record.  No modifications required.
• Identity Management - Leverage Centrify zones to maintain a consistent UNIX namespace.
  You can leverage AD groups to control the memberships in the docker secondary UNIX group.
• Role-based Access Control - Use Centrify zones to control who can access a system, and what commands can be run with privilege.  For example:
  • You can create a role that defines who can elevate to root or the core accounts.
  • You can use Active Directory group membership to define who is a member of the docker(233) secondary group.
  • You can define very granular docker commands that can be granted to minimize risk or enforce separation of duties.
• Attestation and Security Operations -  Leverage Centrify Reports to facilitate attestation and Centrify Audit Trail to enrich security operations.
• Advanced Auditing -  Enjoy audit trail events as well as session capture and replay. 
• Extend host-based security to Linux Containers (LXC) - Centrify "bridges" capabilities to Linux Containers to enjoy the same level of accountability at the container level.

Vault-Based Security 

• Shared Account Password Management - if you need to use shared credentials, use the Centrify Privilege Service vault and enjoy the deployment flexibility and traditional password-related controls.
• Secure Access -  privilege Service connector infrastructure allows for Web, Native or SSH jumpbox client access regardless of on-premises or IaaS deployments. 
• Session Proctoring, termination and recording - Enjoy the benefits of session control as well as auditing without the need to add local capabilities.

Videos - Centrify + Container Linux in action

What's different in Container Linux

Host-based  Access Control, Identity Assurance and Role-Based Privilege Management
 
Vault-based Access Control, Shared Accounts and Secure Access

Using Role-based Access Control to manage and establish accountability for Docker operations


Centrify and Linux Containers (LXC)

[Labs] Centrify's SSH Gateway Explored - On Premises, AWS, Azure and GCP

This article illustrates the steps to set-up a lab to test the SSH Gateway capability of Infrastructure Service.  This capability provides secure access to on premises or IaaS (AWS, Azure or Google Cloud Platform) systems leveraging the Secure Shell protocol (SSH+File Transfer).

Background
Centrify Infrastructure Services provides a full-fledged secure shell and file transfer capability (SSH Gateway).  This "jumpbox"  supports all the core features of the platform including multi-factor authentication, workflow, real-time monitoring and session capture and replay.

Goals of this Lab

• Identity Consolidation:
  • Leverage existing Organizational Directory Services.
  • Accomodate for user populations outside the organization (e.g. Federation, other Directories, etc).
• Usability:  Provide secure access to systems running the SSH Service without visiting the Centrify portal.
• Access Control:  Align with best practices for security access controls, like:
  • Identity Assurance via Multi-factor Authentication.
  • Adherence to the Least Privilege principle  (users shall only access systems and accounts that they have a business need to access).
• Auditability:
  • Event tracking (who, what, when).
  • Allow the real-time proctoring of shell sessions as well as the session recording to be replayed later (e.g. PCI DSS 10.2.2).
• Simplicity and multi-use:  Provide these capabilities with minimal infrastructure or to reuse components of Centrify Infrastructure Service (E.g. leverage other services like AD or LDAP Proxy, or RDP jumpbox services).

Requirements

• A Centrify Infrastructure Services instance (SaaS or Customer Managed) - 17.10 and above.
• A Centrify Connector running the SSH gateway in all the subnets required for SSH jumpbox access.
• A handful of test systems running the SSH Service.
• SSH and sFTP client software.
• If testing "true MFA": An OATH OTP, configured RADIUS token or enrolled Mobile Authenticator.
• Familiarity with Centrify Infrastructure Services.
  • Policy and Authentication Profiles.
  • A configured "Corporate IP Range." 
  • Familiarity with CPS Roles, Permissions and Sets.
• Understanding of the communication paths for CPS (e.g. between connector and instance (HTTPS), between connector and SSH Servers (standard SSH port TCP 22).  Note that these ports are customizable.
• Understading of Infrastructure Services Role-based Access Control.

Conceptual Diagram


This diagram showcases the major components, the location, firewall rules, and additional details depend on the environment.

Diagram for this Lab


High-level Implementation Steps
AWS

• In this implementation, I'm using an AWS VPC as my "corporate HQ"  it has an AD domain, some systems (Windows and Linux) as well as a hosted AD domain.  This will allow me to have different user populations.
• I am leveraging an existing Active Directory and DirectAudit infrastructure.
• Launched a Windows 2012 R2 instance with a public IP address, Fthis instance is in a security group,  that allows inbound HTTPS and SSH from the internet to the instance, plus it can reach the rest of the systems internally, including AD (to allow for it to be joined).
• For internet name resolution, I created a CNAME record in the rpdemo.net DNS domain for the cps record that resolves to the public DNS name for the EC2 instance above
• Obtained a publicly rooted certificate, and exported it with the private key for Privilege Service to use.
• Installed Privilege Service (on-premises) in single-master mode (no HA);
  Note:  The single-master configuration does not provide HA or allows for upgrades.  This is for testing purposes only.
• Added a Centrify connector with the adproxy and SSH gateway services.
• Configured Privilege Service to use my ISP's IP address as part of the corporate IP range.  This is to provide the assurance that only I can access it.
• Configured 2 roles:  An Administrator, and a Least Access role.
• Configured Workflow for the resources.

Microsoft Azure

• Created inbound rules that allow the connector in AWS to reach the systems over RDP and SSH.
  Note: Depending on the services needed, an additional connector in Azure (or GCP) is needed.
• Launched existing Windows and Linux systems.

Test Matrix (Success Criteria)

Category	Description	Result
Identity Consolidation	Users from Active Directory and Centrify Directory can access systems via Web Portal or SSH Gateway.	Pass
Identity Assurance with MFA	Users must use an MFA or Step-up method to authenticate via Web portal or SSH Gateway.	Pass
Policy	Users can only access from a specific subnet.	Pass
Least Access	Users can only access the systems based on business need to know via Web Portal or SSH Gateway.	Pass
Access Request	Users must request temporary access to shared accounts.	Pass
Monitoring (real time)	SSH/RDP – Sessions can be monitored in real time. SFTP – Active sessions can be tracked.	Pass
Advanced Auditing	Sessions can be reviewed after the fact (indexing, replay, etc.)	Pass
Infrastructure Simplicity and Reuse	The same components can be used for other capabilities (e.g. RDP, etc).	Pass

Test Videos
Identity Consolidation and  Assurance with MFA

Policy, Least Privilege and Access Request

Real-time Monitoring  + Session Capture and Replay

Infrastructure Simplicity and Reuse

Centrify's Support for IBM i (AS/400) with Privilege Service

In a nutshell

• Centrify Infrastructure Service provides support for AS/400 systems
• Versions 6.x and 7.x (although 6.x will be EoL soon)
• You must be running SSH on your AS/400
• Apply all platform PIM features (Policy, MFA, Workflow, RBAC, SSH Gateway, etc)
• Secure Access via SSH
• Password Lifecycle
• Support for different password profiles.

See it in Action

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

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

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

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

The maturity model illustrates this best:

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

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

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

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

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

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

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

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

Permissions
For accounts, there are several entitlements

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

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

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

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


Deployment Utilities

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

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

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

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

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

Examples of Identity Assurance with Centrify MFA in AWS (Console, EC2 and CLI with PowerShell)

Note:  This is a repost of an article I recently wrote for the Centrify Community Techblog

Background

Centrify recently commissioned a study with Forrester Research that yielded some important information about the state of Security.  Bottom-line, we have decided to throw money and resources to the problems around information security rather than rethinking our approach, the results are more breaches and exposures.

You can access the study results here: https://www.centrify.com/lp/rethink-security-ebook

A key conclusion on over 200 organizations surveyed is that those with higher Identity and Access Management (IAM) maturity were breached 50% less while maintaining operational efficiency. 

As you read the previous paragraph, you may ask yourself: what is the first step the journey to the continuous improvement required for IAM maturity?  As illustrated in the model below,

a the key component is to establish identity assurance with technologies like MFA or PKI, however this is challenging enough because many organizations have not achieved this on-premises, much less in IaaS/PaaS platforms like Amazon AWS.

This is where Centrify can help.  This article is about guiding you on how to use the Centrify platform to establish identity assurance in several use cases:  

• Accessing the AWS Consoles with shared accounts (like Amazon root) or Federated identities
• Accessing EC2 instances locally (Linux or Windows)
• Accessing AWS commands via the CLI (E.g. PowerShell or Python)

Please note that identity assurance concepts apply to both users and systems (due to API access);  in this use case we'll focus on interactive (user) use cases.  For system/system or app/app, other mechanisms like PKI or Kerberos can be used and we can cover in another entry.

The Centrify Advantage

The biggest advantage for Centrify lies in it's platform and integrations, as a company that covers both Identity as a Service (IDaaS) as well as Privileged Identity Management (PIM) we understand that everything starts with Identity Consolidation.   This is not the "legacy" (metadirectory/connector-based mid-2000s) identity consolidation, this is the "straight-to-the-source" standards based approach using Federation in the IDaaS side, plus direct-integration (with Kerberos) in the case of heterogeneous OS platforms.  We add to this a series of services:

• A policy service
• A multi-factor authentication engine (that includes modern and legacy-based support)
• A risk-based engine (analytics) 

Our native integrations with Active Directory make us a prime vendor to consolidate capabilities;  here's an example, if an organization wants to secure access to a web app, integrate a non-windows platform to a central directory like AD and get MFA, they may engage 3 distinct vendors, however Centrify can help with world-class solutions on the three areas.  Let's look at a the examples.

  

Securing Shared or Federated Access to the AWS Console

Centrify Identity Service provides several turn-key templates to help with shared or federated (via SAML or using the AWS API) SSO for Amazon Web Services.  We have covered these integrations here:

• For a shared credential (like the amazon account)
• Using SAML or Amazon API for federated SSO + Provisioning

However, the powerful policy engine and the support for multiple authentication profiles makes this integration simple and flexible.  

Here's a quick demo on how this integration is enabled and the user experience:

Notice how we achieved our goals:  identity consolidation and assurance while maintaining usability.

Securing Access to Linux and Windows AWS EC2 Instances

Centrify Server Suite provides native integration with Active Directory, regardless of your deployment model. 

By leveraging AD (hosted by you or in AWS), you are eliminating the duplication of identity sources caused by SSH keys with the addition of DirectAuthorize technology that provides role-based access control and privilege elevation and is fully-integrated with the policy and authentication profiles provided by Identity Service or Privilege Service.  We have discussed these integrations here:
 

• MFA for UNIX/Linux
• MFA for Windows 

Provided the Identity Service/Privilege Service setup is correct and the proper PKI trust is in place, for Access and Privilege elevation, all we need to do is set up the proper checkbox at the role, UNIX command or Windows desktop or application.

 

Here's the user experience that meets the requirements for identity assurance via MFA for both Linux and Windows in the context of access and privilege elevation.

 

Notice how we achieved our goals:  identity consolidation and assurance while maintaining usability.

Securing Access to AWS CLI (e.g. PowerShell)

Administration of AWS Services is often performed via the AWS CLI (implemented via Windows PowerShell or UNIX CLI).

If you're using Centrify Identity Service with SAML federation into AWS, you can implement the SSO plugin provided with the template.

References:

• PowerShell script module help
• Using Python commands

Here's the user experience in PowerShell.  Note that the experience will be based on the authentication profile that applies to the user by policy.

If you have multiple roles, you get to select them:

 

Finally, the authentication token is stored in the $me variable and the user can move-on to use AWS PowerShell commandlets.   See the pattern here?  Identity assurance with MFA and role-based access without compromising usability and achieving this with with a single solution set.

  

Metrics

A cliché of business schools is the statement "you can't manage what you can't measure"; but since we're dealing with IT security, you may want to track how we are performing towards our goal of consistent identity assurance, in these AWS examples, we can use AWS CloudWatch metrics to measure the percentage of access in the proper context (e.g. Console, EC2, etc) is performed with assurance.  Therefore a good metric to track would be:

 

MFA events are tracked for Linux, Windows and Identity Platform, this allows you to be creative and get information from CloudWatch or from Identity Service.

Note the CloudWatch widgets above.  In my Linux space, I have a ratio of close to 60% identity assurance (4 out of 7 successful logins were with MFA), however my track record on the sample data I created on Windows is much better (100%).  You use the same approach for privilege elevation via Centrify-enhanced sudo or Centrify Agent for Windows.

In the case of Identity Service or Privilege Service, the platform provide dashboards and reports like the Security Overview - User Logins

These dashboards allow for reviewing information within 7 days or 24 hours and to look at specific date-time ranges. 

Conclusion

Identity assurance is closer than what you think, with the "barriers of entry" for MFA solutions going down, it's all about working with the right partner and Centrify excels at securing apps, endpoints, infrastructure and secrets; finally, the obvious challenge is organizational dynamics;   If you still have groups opposed to centralizing directories or maintaining legacy infrastructure, you can split the project in several phases and attack the platforms that are easier from a people/process standpoint.  Once you can demonstrate identity assurance within those applications or infrastructure, it's going to be hard for those "holding on to the past" to ignore that the best practices are here to stay. The model applies to all aspects of any risk-sensitive information technology area and like every other framework it's not a silver bullet; new threats, attack vectors, compliance requirements and tools are introduced, therefore this has to evolve as well.