28 Feb ESAE is dead – Long live SAE?
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:
-
- Do we run the risk that our on-prem [ESAE] architecture will no longer be supported by Microsoft?
- What is the security gain of the cloud model compared to the current [ESAE] setup?
- How high is the effort to implement the new architecture?
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
Product | Support-End |
Windows 10 / 11 | Rolling 12 months since last update |
Windows Server 2019 | 09.01.2029 |
Windows Server 2022 | 13.10.2031 |
MIM 2016 SP2* | 13.01.2026 |
LAPS** | N/A |
Product | Support-End |
Windows 10 / 11 | Rolling 12 months since last update |
Windows Server 2019 | 09.01.2029 |
Windows Server 2022 | 13.10.2031 |
MIM 2016 SP2* | 13.01.2026 |
LAPS** | N/A |
*MIM can be used to request shadow principal rights, but you can also request the higher rights via Powershell, but then you lose the possibility of approval workflows.
**LAPS is now part of the Windows operating system and has the same end of support as Windows 10/11.
The table (including long footnotes 😊) thus also confirms what Microsoft says in the Retirement article, you do not have to worry.
Security gain
“What is the security gain over the current [ESAE] setup?”
As mentioned above, this question can only be answered concretely in the customer context. Kindly, Microsoft itself defines success criteria in the Measuring Success article:
„A successful strategy must address all the points attackers can use to intercept privileged access workflows including four distinct initiatives:
-
- Privileged Access workflow elements of the privileged access workflow including underlying devices, operating systems, applications, and identities
- Identity systems hosting the privileged accounts and the groups, and other artifacts that confer privilege on the accounts
- User access workflow and authorized elevation paths that can lead to privileged access
- Application interfaces where zero trust access policy is enforced and role-based access control (RBAC) is configured to grant privileges”
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
LATEST POSTS
-
Windows Server Deployment
Our blog post for this month deals with a topic that is not directly related to information security. Nevertheless, this topic should not be underestimated and neglected. It is about the automated installation of Windows Server in the enterprise....
16 November, 2021 -
Windows LAPS: What can the “new” LAPS do and should I use it?
A new version of LAPS - Windows LAPS - has been available for some time now. In this article, we will look at the new features and discuss whether it makes sense to migrate to the new version....
15 July, 2024 -
We celebrate five years TEAL
We are celebrating five years of TEAL with our team this month. Five years packed with constantly evolving know-how in customer work, internal projects and continuous growth of the company. With an increasing growing team and great customer projects, we have been able to develop...
15 February, 2022