Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >

[Security Corner] Centrify and the Microsoft Enhanced Security Administrative Environment (1/3)

11 April,19 at 11:51 AM


This article is written for any security or infrastructure stakeholder that is planning, implementing or looking into the Microsoft Enhanced Security Administrative Environment (ESAE).  In addition, if you are a SME that has been tasked to find out Centrify's role within this security model, this is one starting place.



The first article starts with the basics. This FAQ is for those who don't know what MS ESAE is, and would like to get a quick primer on these recommendations.  Please keep in mind that in security, the main reality is evolution, this means many of the topics in this article will change over time as threats and threat agents evolve their tactics around credential theft; change will also be driven as new technologies are implemented to address these risks.


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.

zero-trust.PNGThe 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 Directory
    Why?  Because any serious security shop makes this into their normal policy.  It's all about reducing the attack surface, preventing lateral movement and being able to know when something it's not normal.
    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.
      What to measure?  # users with Admin rights, # users in key Security Groups, Domains with lower encryption (pre-2008), Writeable DCs in risky networks, Unauthorized attempts to administrative shares (e.g. drive$, admin$) etc.

  • 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 critical application or service may not agree with you disabling NTLM.

    What to measure?  % of apps and services with NTLM turned to total apps and services that use NTLM ratio.

  • 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 committed 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.

    What to measure?  Ratio of admin users to regular users;  Ratio of managed admin accounts to total admin accounts;  Admin accounts with infrequent password changes;  Admin accounts with permanent sensisitive group membership.
  • 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.
    lapm.PNGCentrify's LAPM for Mac offers a Self-Service capability

    What to measure?  Ratio of managed local accounts vs. total accounts; Frequency of usage of local accounts.

  • Principle #5 (P5)  Use "Privilege Access Workstations" for administration (using the clean source principle).
    Why?  to limit the possibility of malware (or persistent malware).
    This is an enhanced version 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.
      What to measure?  All access control metrics on PAWs.
  • 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.
    nd.PNGService Discovery in Infrastructure Services

    These 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.

    What to measure?  Ratio of managed service accounts vs. total service accounts; over-provisioned accounts; AD security groups that contain service accounts.
  • Principle #7 (P7)  Don't allow regular users to have administrative rights in endpoints (desktops, laptops, etc.)
    Why?  It's about reducing the attack surface. The attack surface in an organization where all users have admin rights is: all users and workstations.
    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.

    What to measure?  Ratio of managed service accounts vs. total service accounts; over-provisioned accounts; AD security groups that contain service accounts.

  • 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.

    What to measure?  Average approval time for on-demand access; exceptions to on-demand (e.g. emergency access).
  • 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 protect privileged accounts and set new rules for Windows administration.
    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.
    Figure showing an ESAE forest used for administration of Tier 0 Assets and a PRIV forest configured for use with Microsoft Identity Manager's Privileged Access Management capability

    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?  Organizations are diverse, they have different charters, cultures, levels of maturity, plus the human factor (coordination, cooperation and cognitive knowledge).  Controls need to be balanced based on the risk assessment exercise and business impact based on each different type of organization.

    Probably the worst mentality within the context of security is to try to find a "cure for all illnesses" - a mature security practice has operational efficiency and constant improvement at the heart of its charter.

    When embarking in these projects, there is a cultural aspect that cannot be ignored.  A troubling commonality in Windows credential theft incidents is usually a SME (or a group of SMEs) that don't want to give up the habits of keeping permanent membership on attractive security groups (e.g. Domain Admins,  Administrators), plus using unsecure or personal workstations for administrative duties.  This is all too common and the SMEs that maintain these practices have legitimate reasons (usually being able to quickly break-fix or maintain productivity).  The challenging problem for architects and security providers is this:  How can we balance these threaths and provide solutions that align with the needs of these SMEs?  How can I make sure that the projects are well-chartered  and have the executive exponsorship needed to overcome some of the expected resistance to change?

    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 if the system is not configured to store one or if cached credentials are not allowed.  Sometimes, using some specific technologies will eliminate the need for additional controls.  Another example may be Samba integration.  If tied to a critical app that cannot be migrated in the near future, you have to surround the systems around that capability with additional controls due to the risk profile.

    What to measure (P9 & P10)?  Can you maintain business agility with the added complexity?  (these are hard things to measure).


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 capabilities 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.


Centrify's IAM Maturity Model

Windows credential theft is just one of the challenges facing security practitioners.  It's well-known that this is one of the tools widely used by threat agents; this is why we preach the implementation of a constantly evolving Identity and Access maturity model depicted here:


The principles outlined in this model are transferable to all platforms and contexts (endpoint, apps, infrastructure) that are susceptible to credential theft.  It's called an "identity perimeter" and Centrify is constantly investing in this area.




Next Article:

How can Centrify help - attack the principles (establish identity assurance, reduce the attack surface, prevent lateral movement, audit everything).