Lab - Migrating Centrify PAS from OnPremises to HyperScalable Architectu...

Centrify PAS OnPremises Testing - August 2020

It's been a while...

 New Posts coming....

Centrify and the Microsoft Enhanced Security Administrative Environment - The basics (FAQ)

This is an article I wrote for the Centrify community around Microsoft Red Forest (ESAE).  The goal of the article is to serve as an introduction to the topic.  For the full series, visit https://community.centrify.com 

FAQ: Microsoft Enhanced Security Administrative Environment and Centrify - The Basics
1. What's the MS Enhanced Security Administrative Environment?
It's a series of recommendations and technologies to prevent credential theft in Windows environments.

2. What is Red Forest?
Although the terms MS ESAE and Red forest are often interchanged, Red Forest refers specifically to ONE of the recommendations:  Set-up an administrative Active Directory forest exclusively for privileged accounts and connect it to the corporate forest by a selective one-way trust.  Note that this is an over-simplification.  For more info, click here.

3. What is Pass the Hash (PtH)?
PtH is a very commonly used attack used in Windows networks to harvest credentials, it's been around since early this decade (but may have been around earlier). The idea is that after a Windows system is compromised with a specific program running with Administrator rights, the NTLM password hash of a user can be captured once any of these things happen:

• A user logs in interactively to the infected system (remotely or using RDP).
• A user launches a program using the "Run As"  command.
• The user types-in a new credential to access a network resource that she is not authorized to use (or under a different realm).
• A Windows service configured with a credential is started.
• And many more.

Note that PtH is one (quite popular) way to harvest credentials to move laterally in an environment. There are many other techniques used to harvest credentials.
For more info about PtH, click here.
For more info about attractive credentials in Windows environments, click here.

4. What's the worse case scenario when PtH (and other related techniques) are used?
Total breach, including the ability to impersonate any user on an Active Directory-based infrastructure.

5. What is the goal of MS ESAE?
Although the ideal goal is to completely protect against techniques for credential theft, the more realistic goal is to take the credential theft techniques off the attacker's toolbox, like PtH. This will force them to use riskier techniques that increase the likelihood of detection.

6. What are the principles around ESAE?
Although any principles outlined in this section are likely to evolve as Microsoft adds newer technologies (and bad actors adapt to them), There have been several versions of the techniques to protect Windows Networks starting with some of the original "Securing Active Directory" whitepapers.

Assume Node Breach
Based on my research, the most basic principle is to operate under an assumed "node breach" - this is aligned with another assumption in a different stack: networking.  In this stack ideally you'll treat every network as if it were a public network. In the context of Windows systems, this is to assume all nodes can potentially be compromised unless you have deployed controls to provide the assurance otherwise.  This aligns as well with some of the concepts around our Zero Trust Model.
The pillars of the Zero Trust Model
Now, here's my attempt to consolidate the principles outlined by the different whitepapers that discuss the Microsoft Enhanced Security Model.  We will expand on each principle (as it relates to Centrify in the next posts in this series).

• Principle # 1 (P1)  Perform the basic steps to secure your Active DirectoryWhy?  Because any serious security shop makes this into their normal policy.  It's all about reducing the attack surface.
  Here are some of the "common-sense" practices (however, the reality is that even the most mature organizations struggle with these).
  • Reduce the number of Administrators and manage security group membership.
  • Establish administrative workstations (or servers).
  • Protect Domain Controllers and maintain them up-to-date.
  • Monitor your environment.

• Principle #2 (P2) Have a plan to migrate applications and services that depend on NTLM.Why? Because eliminates PtH outright.  If there's no NTLM hash to be harvested, the bad actor needs to move on and use other techniques.
  This is probably one of the hardest projects for any major enterprise.  Windows services and business apps "just work" in many instances because of the backwards-compatibility capability enabled by supporting NTLM. 
  The good news is that Centrify for UNIX, Linux and Mac does not need NTLM to work. You can disable it in favor of Kerberos-only, nonetheless, as stated, your mission critial application or service may not agree with you disabling NTLM.
  
• Principle #3 (P3)  Separate user accounts vs admin accounts.Why?  Malware has limited effect on regular user accounts.  Also, remember the preconditions for the common credential theft techniques:  Rogue software needs to be running with administrative rights.
  This one has been controversial over the years, especially because Centrify has always embraced least privilege. 
  
  At Centrify we are commited to making the best Administrative account management capability and this will be evident in a couple of months with our Infrastructure Service CPS; however, rest assured that Centrify supports Separation of Duties and Delegation in all its products.
  
• Principle #4 (P4)  Implement distinct admin passwords per workstation.
  Why?  Same as above:  to prevent lateral movement.  If the same "corporate password"  is used for local Administrators, you just enabled the bad actor to move laterally times all the workstations/servers that are available.
  At Centrify, with our vault we have attacked this problem on servers and desktops, last year we tackled the problem on OS X for laptop users, and we are working to bring this for laptop users on Windows.
  Centrify's LAPM for Mac offers a Self-Service capability
  
• Principle #5 (P5)  Use "Privilege Access Worksations" for administration (using the clean source principle).
  Why:  to limit the possibility of malware (or persistent malware).
  This is an enhanced versio of one of the common-sense Windows practices; but now with how pervasive VDI technologies are, it's possible to almost eliminate the possibility of malware.   For example, a computer with Windows administrative tools (or Centrify's) can be launched as a non-persistent VDI session from a clean source.  This provides the assurance that this is a "clean" system.  Centrify does offer additional capabilities to enhance the use of PAWs:
  • MFA
  • Conditional Access
  • Centrify Zone-based access control (this layers an additional access model to Windows leveraging AD)
  • Secure Privilege Elevation (use token manipulation instead of password replay)
  • Audit Trail to enrich security operations
  • Session Capture and Replay
  • Attestation for Access and Privileges
    We will dedicate a post only to discuss how we can enhance Microsoft's PAW recommendation.

• Principle #6 (P6)  Control the privileges of service accounts.Why:  control privileges, reduce the attack surface.
  This is another hard goal to achieve because it's deeply tied to how applications are written.  In the subsequent articles we'll discuss how we can discover, manage and secure Windows Services, Scheduled Tasks and IIS Application pool identities.
  Service Discovery in Infrastructure ServicesThese principles have been in Centrify products for a while.  We use a reduced number of service accounts and we guide you with exactly what's required for least privilege when those are needed.
  
• Principle #7 (P7)  Don't allow regular users to have administrative rights in endpoints (desktops, laptops, etc.)
  Why:  the attack surface in an organization where all users have admin rights is: all users and workstations.  It's about reducing the attack surface.
  Unfortunately, organizations struggle with this concept because the security industry has not embraced temporary access in a way that makes it easy to request spot administrative rights in Windows workstations. 
  
  We have some capabilities already and are working focused in this area.  In the next few articles we'll discuss in-depth.
  
• Principle #8 (P8) Embrace Temporary Access Controls (JIT, on-demand).
  Why:  Because once a credential is used, if it's no longer privileged, lateral movement and the effects of compromise can be limited.
  Organizations must declare war to permanent privileged accounts; however, this problem is not about technology but around workflow. 
  
  This is why we are investing in areas like faster and simpler workflow, mobile approvals, ServiceNow integration and fast communication to our clients.  The idea is to eliminate some of the "business dynamics" that challenge the implementation of just in time access and privileges.  Just in time access is another pillar of our implementation of the Zero Trust Model.
  
• Principle #9 (P9)  Deploy an administrative forest (Red Forest) with a selective one-way trust and limit upwards administration in the corporate side.
  Why:  To proctect privileged accounts and set new rules.
  Although we are of the opinion that Red Forest adds a lot of complexity, it comes from Microsoft and many organizations will deploy the model or components of it.
  Depending on the data classification of the information on systems secured by Centrify; administrative accounts need to adhere to the principles; and we can provide administrative privileges to accounts coming from the red forest.  This is something our competitors (especially on the UNIX/Linux side, have a tough time achieving).  Ultimately this works in conjunction with all the principles outlined here.
  
• Principle #10 (P10) Use critical thinking - MS ESAE is complex and may not work in all instances
  Why:  Because the principles of security need to be maintained.  This is all about risk mitigation or management and due-diligence. 
  At Centrify we specialize in Access Controls and have always preached the maximization of "what you have" and the use in non-Windows systems on premises and in IaaS.  Follow the principles of controls stacking (spend more on prevention and correction than detection). 
  For example, our Identity Broker capability on Linux allows for AD (LDAP, Google, etc) users to be authenticated to AD without the need of using Domain Controllers nearby.  There is no NTLM hash.

7. I see Centrify has a Password Vault, can it protect me against Windows Credential Theft techniques like PtH?
I think no security vendor with regards to their credibility will pitch a password vault as the sole mechanism against Windows credential theft.  It can't... just use privilege session or replay the password and that's it!  Compromised credential; and most likely, since you had it vaulted, it will be very useful to move laterally or escalate privileges.   
A vault can, however:

• Help you separate user vs. administrative accounts
• Help you rotate passwords automatically
• Be used to in conjunction with a Privilege Access Workstation
• Allow you to establish distinct local server/workstation passwords and help you rotate them
• Some vaults provide the ability to provide and enforce Temporary Access

The answer you want to hear here is:  A PV can help you as part of the toolset to implement controls against credential theft. The benefit here is that Centrify is the only vendor uniquely positioned to provide vault-based, system-based and IDaaS based security.  This helps in vendor consolidation and productivity.

8. I see Centrify provides MFA capabilities, can it protect me against Windows Credential Theft techniques like PtH?
Same response as above.  MFA can't help you against a compromised Windows system running malware.  You have to replay your password!  If your system, group or policy allows for you to issue an NTLM hash, you are done (in the case of PtH). 

MFA can absolutely protect you against credential theft if the credential is being used interactively on a resource being protected by MFA.   The difference here is that most of the time, when a credential is harvested, it tends to be used programmatically.

9. I see Centrify supports Smart Card authentication, we are deploying it as a technique to prevent Windows Credential Theft techniques like PtH.  Am I in the right track?
Same response as above.  MFA can't help you against a compromised Windows system running malware.  In the case of Smart Cards, there is still a password generated for you by the AD domain controllers.  Great control to prevent interactive theft.

10. What are the Active Directory Capabilities that help against Credential Theft and how do they map to Centrify capabilities?
At this point there are dozens of capabilites in place, starting with stronger crypto in Windows Server 2008 Active Directory all the way to Shadow Groups in Windows Server 2016 AD.  We will dedicate a full community post just to go over these in the context of a Centrify deployment.

Resources

• Microsoft's PTH website: https://technet.microsoft.com/en-us/security/dn785092
• Microsoft's Securing Privilege Access: https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material#ESAE_BM
• Best practices for securing Active Directory: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory
• Channel9:
  • https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B213#fbid=
  • https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B359

Next Article:
MS ESAE - Principles Showcase: How Centrify aids, enhances or fits in this model.

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