Post Update:

When we published a blog post on Enhanced Security Admin Environment (ESAE) Retirement in early 2021, we had no way of knowing that it would become one of the most-read articles. Reason enough to reassess the situation a year later and reflect our current view.

The documentation has not changed fundamentally since then, Microsoft describes the procedure as follows – Securing privileged access. The following picture still exists, suggesting that the “old” ESAE model has had its day and is being retired.

Source: https://docs.microsoft.com/en-us/security/compass/esae-retirement

At first glance, this is confusing. Have all ESAE efforts now been in vain? We at TEAL have also based our offerings on the ESAE model to this day, so do we have to redo everything now? This much in advance, even if Microsoft presents many important points differently and supplements them, the basic principles remain the same and whoever wants to operate a secure infrastructure environment will not get around the classic ESAE measures in the future.

Shortly after the release of the new documentation, there was a lot of excitement and customers were afraid that investments already made were for nothing. In summary, we see three core issues:

But before we get into that, a definition of terms is necessary. What exactly is ESAE for Microsoft?

How does Microsoft define ESAE (in the Retirement article)?

The article says it in black and white:

“The Enhanced Security Admin Environment (ESAE) architecture (often referred to as red forest, admin forest, or hardened forest) is a legacy approach to provide a secure environment for Windows Server Active Directory (AD) administrators.”

So ESAE is more or less equated with the RED Forest model.

If you’ve read our past articles, know our Top 10 Measures infographic, or read the numerous other sites on the Internet about ESAE, you’ll find that the term ESAE means much more than “red forest” to most people.

To answer the questions in this blog article, we will use the definition from the ESAE Retirement article.

ESAE Support

“Do we run the risk that our on-prem [ESAE] architecture will no longer be supported by Microsoft?”

The direct answer from Microsoft: “While not a mainstream recommendation, this architectural pattern is valid in a limited set of scenarios.

• Isolated on-premises environments
• Highly regulated environments
• High level security assurance is mandated”

So there are still valid scenarios where Microsoft supports the “classic ESAE” model. It is also interesting that Microsoft itself continues to operate an ESAE setup.

Furthermore, we would like to explain that ESAE is an architecture and not a product. In this respect, there is and has never been a product support in the classical sense. So, to answer the question in more detail, we need to look at what components an ESAE architecture essentially consists of.

Fortunately, the architecture uses many built-in functionalities of the operating systems, which is why the list is pleasantly short

We address each of them below.

ESAE and Privileged Access Workflow & Identity Systems

If you take the definition from the Retirement article “provide a secure environment for Windows Server Active Directory (AD) administrators” and compare it to securing the complete Privileged Access Plane, the security gain is of course significant.

Source: https://docs.microsoft.com/en-us/security/compass/privileged-access-access-model

We took the trouble to dig out the original ESAE documentation from 2017 from www.web.archive.org:

“Tier 0 – Direct Control of enterprise identities in the environment. Tier 0 includes accounts, groups, and other assets that have direct or indirect administrative control of the Active Directory forest, domains, or domain controllers, and all the assets in it. The security sensitivity of all Tier 0 assets is equivalent as they are all effectively in control of each other.”

So if you’ve already secured your entire Tier 0 systems today, including those in the cloud, the security gain is small in our view. Of course, everyone must evaluate for themselves how far advanced the project is. From our experience, however, it is an intensive process to identify and secure all Tier 0 systems. However, this is not left out in the new model and is at least as complex as before.

ESAE and User Access Workflow

Unfortunately, this point cannot be evaluated without further explanation from Microsoft.
In the diagram of the “planes” above, there is no “authorized elevation path” from normal user to “privileged access”. From our point of view for a good reason, because by definition it should not exist…

ESAE and Application Interfaces

From our point of view this is really an innovation compared to the “classical approach”. At least in the consequence with which it is demanded in the Zero Trust documentation:

“This is the core of Zero Trust. Instead of believing everything behind the corporate firewall is safe, the Zero Trust model assumes breach and verifies each request as though it originated from an uncontrolled network.”

Source: https://docs.microsoft.com/en-us/security/zero-trust/

However, one has to question the practicality of the point (in the required consequence) from our point of view. Sure, there are technologies available today, such as Azure Conditional Access and Azure Application Proxyy, that make it relatively easy to verify requests based on multiple data points for a subset of applications before granting access to a user (or app). However, if you take a closer look at the technologies, you will notice that the story is not yet round.

For example, the Azure Application Proxy only supports web apps. But what do you do with all the (purchased) applications that have their own fat client? Only a comprehensive app modernization program can help…

In the other five areas, the situation is probably similar or worse. From our point of view, it will take some time until a normal company can use Zero Trust on a large scale.

Effort

At this point, it’s hard not to become cynical. On the one hand, one of Microsoft’s arguments is that it takes too long to build the Red Forest; on the other hand, one of the criteria for success is the introduction of a Zero Trust model at all technical levels of the company. Such an introduction certainly takes several years, depending on the company.

With the current documentation, we currently do not see ourselves in a position to make even a high-level estimate for this. Basically, however, it can be stated that both the old ESAE model and the new architecture are enormously time-consuming and cost a lot of energy to introduce. However, it is imperative that these efforts be addressed; compare, for example, the damage caused by a successful ransomware attack. IT security should be seen as a constant investment in the knowledge of one’s own workforce and the protection of the infrastructure. It is simply wrong to believe that a large amount can be invested once and then you are “safe”. As Microsoft itself says, it is about setting the hurdle as high as possible and making it as expensive and unattractive as possible for the attackers.

Resumee

It would be easy to argue that Microsoft is changing the architecture to get rid of on-prem Active Directory in the long run while boosting its cloud business. The truth, in our opinion, is in between. Microsoft is absolutely right that more and more cloud services will be used in the future and that old legacy architectures in particular will repeatedly lead to successful collapses. That’s why we think it’s right and consistent to get rid of old habits for the future and implement modern and highly secure products and ways of working.

At the same time, we believe that the reality for most customers is different. Very few grown structures can “just like that” rely on a cloud-only strategy and modernize or simply replace central and important legacy applications. The same applies to an Active Directory that has grown for years. You can’t migrate that to Azure AD just like that.

Ultimately, we are watching a hybrid strategy. None of our customers have yet made the journey 100% to the cloud. At the same time, however, more and more workloads are being mapped in the cloud. It is therefore only logical to also look at cloud products. These can be used to secure one’s own cloud instance, but at the same time also make on-prem environments more secure. We are seeing more and more that customers are using cloud PAWs or services such as Azure sentinel to replace SPLUNK, for example. This can be useful and offers a lot of new possibilities to better secure an environment.

In summary, however, it can be said that Microsoft addresses very important points and raises the question of whether one can reasonably secure the respective environment with the local circumstances. It is clear that you have to deal with the topic of security in the long term and improve your environment consistently and iteratively. Whether with or without RED Forest, most of the other measures from our TOP 10 list or our assessment are still valid and must be considered and can be expanded in the future with cloud solutions if necessary.

Quelle Titelbild: Adobe Stock/Nomad_Soul