Using Centrify in Microsoft Red Forest Deployments
What is a Red Forest?
Red Forest is the project name for Enhanced Security Administrative Environment or ESAE. It’s not a new product but rather a highly descriptive security architecture using existing Microsoft tools to better prevent privileged identities from being compromised. The general focus is around a three-tier model of isolation.
Tier Two contains all privileged identities and associated management workstations for those who manage the corporate workstation environment. Think help desk staff and workstation administrators. All related computer objects, user accounts and security groups would all be managed in a dedicated Tier Two organizational unit within the production forest.
Tier One is similar to Tier Two except focuses on enterprise servers and applications. Think server administrators, application owners, etc. All related computer objects, user accounts and security groups would all be managed in a dedicated Tier One organizational unit within the production forest.
Tier Zero is entirely different. This tier focuses on the privileged identities and assets used to manage the Active Directory environment itself. Rather than isolating these assets in independent organizational unit architectures within the same forest/domain as prescribed for tiers two and one, tier zero assets are stored in a new trusted administrative forest. The idea is that these accounts are just standard users in the administrative forest but highly privileged accounts in the production forest. Since these are trusted users, there will be no default permissions in the production forest. All rights will have to be explicitly defined for these accounts.
In addition to this tiered model, there are many other security best practices such as smart card use, password hygiene, and workstation/server hardening. If you’ve ever reviewed the NIST guidelines for Windows security, you’ll find many of the same concepts here.
Centrify Design Considerations
Creating logical security boundaries around enterprise computers, the identities that will access those systems and the security groups used to manage privilege is not a new concept to Centrify. This has been one of the core strengths of the infrastructure platform for many years. Using Centrify hierarchical Zones allows organizations to not only extend this model to Linux, Unix and Mac but also goes much further in providing true least privilege controls across the entire enterprise.
Generally, the Centrify design can be deployed in one of two likely scenarios in this type of environment.
The first is to follow the already established isolation and create dedicated Zones and associated Centrify organizational unit structures within the tiers and domains where the systems are located. For instance, a privileged workstation Zone beneath the Tier Two organizational unit, a privileged server Zone beneath the Tier One organizational unit, and a Tier Zero Zone located in the administrative domain.
The second approach would be to use a hierarchical design structure with a parent zone and Centrify organizational unit found at the root of the domain. Within this Zone structure, independent child zones can be created for each Red Forest Tier. You’ll still need another Zone in the administrative domain for those computer assets but Centrify would generally be managed outside of the dedicated organizational units for each tier.
Either approach will work and it just depends on an organization’s administrative model to determine which path will provide the most amount of security with the least amount of management overhead. The only real gotcha here is granting login access to accounts found in the trusted administrative forest to assets in either the workstation or server Zones. It’s quite common for organizations to assume the domain controllers for the administrative forest should be blocked from all workstations and servers in the production domain. However, in order to achieve Kerberized authentication, the workstations and servers will have to communicate directly with the KDC for that realm. For this reason, it is best to leave Active Directory ports open between the two domain environments. The Centrify agent does have the ability to fall back to NTLM if configured to do so but this is not only a less secure protocol, it also breaks SSO which could lead to credential fatigue when users have to reauthenticate using a myriad of accounts dedicated to each tier.
Red Forest + Centrify
The Red Forest design provides many sound recommendations for improving security related to privilege. However, the nature of the architecture still leaves much to be desired. The point after-all, is to reduce the attack surface so that malicious code running on a server is mitigated. Yet administrative users are still over-privileged, administrators have to deal with multiple accounts and are trusted to know the appropriate time to use each, and it does little to address systems not distributed by Microsoft.
Centrify is perfectly suited to fill most if not all of these gaps by layering in a zero-trust policy and the tools necessary to further reduce the attack surface, across the entire enterprise, regardless of operating system. Below are just some of the areas that should be considered:
As previously mentioned, the goal is to stop malware/ransomware before it can get a foothold within the network. Logging in with an administrative account directly does very little to stop this. Yes, the blast radius may be limited to all of your workstations or all of your application servers but that’s still a steep price to pay for infection. Centrify’s DirectAuthorize tools gives organizations the means to completely remove the default rights from an account while still allowing those users to perform their job duties through command/process elevation. Administrators are placed into Role groups which will determine the policy processed by client agents. When a task that requires administrative rights is required, DirectAuthorize will allow the user to run the process or command by adding the rights to the process itself, not the user. Malware dependent on administrative user context to inject itself or cause any real harm suddenly has nowhere to go.
The Red Forest architecture recommends that each administrative account be required to login with a smartcard rather than password alone. This does well to prevent access through stolen passwords or lateral movement from server to server if a smartcard authentication is required at each stop. However, this too can be improved. The Centrify identity platform includes adaptive multifactor authentication as a core service. Using this instead of, or in addition to, smartcard allows organizations to implement smart MFA wherever necessary in a less burdensome way. An example of this may be logging into a Windows or Linux Server, elevating a command/application, logging into a central application portal, checking out a password…the list goes on and on. And because Centrify can learn the common behavior of the user through its analytics engine, the action can be scored, and the level of identity verification adjusted accordingly. This leads to a better overall user experience and more granular checkpoints beyond login.
Privileged Credential Management
The Centrify Identity platform also includes a credential vault. This can be used to manage non-human account credentials and redundant accounts created for each administrator. The portal can then be used to provide VPN-less point-to-point remote access to assigned systems either on premise or remote cloud resources from a single pain of glass. Administrators can use one main account throughout the day and when an additional account is required, simply inject this managed credential into the connection for seamless connectivity. The same works for any SaaS applications as well. You can still check-out and check-in if there’s an event that requires the credential, but the bastion model will provide a better day-to-day experience in this kind of environment.
One of the other concepts recommended by Microsoft is “just-in-time” privileges. The basic concept is that no rights are provided on a permanent basis. Any privileged access first requires a request for specific rights, which is then approved by an approver, and granted only long enough for the task to be completed. Centrify provides this capability natively within the infrastructure portal. Access to a managed account or Zone role can be requested. If approved, Centrify handles all of the workflow to add the user to the role assignment for the specified period or grant the user access to the account being requested.