ESAE series part 1- Introduction - TEAL Technology Consulting GmbH
post-template-default,single,single-post,postid-1840,single-format-standard,bridge-core-3.1.4,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-30.3,qode-theme-bridge,disabled_footer_top,qode_header_in_grid,qode-wpml-enabled,wpb-js-composer js-comp-ver-7.5,vc_responsive

ESAE series part 1- Introduction

In the blog category “Secure Administration Environment” we want to share our experiences from customer projects around Microsoft’s Enhanced Security Administration Environment (ESAE), so that others can learn from our experiences and not stumble across the same problems as we did.

We will start with a series on a very exciting topic that we have been able to work on for a globally active insurer in recent months: The complete implementation of an environment inspired by ESAE.

In this first article of the series, we want to explain what it deals with, why it is necessary and what components the environment is made up of. In further articles, we will examine individual components in more detail and finally to summarize our practical experiences and our handling of the stumbling blocks in the last article.

ESAE is a design approach by Microsoft (ESAE documentation by Microsoft) to make credential theft and pass the hash/pass the ticket attacks more difficult or to at least to reduce their impact. There are entire blog series and white papers ( and Microsoft white paper) on credential theft, pass the hash/pass the ticket, so we’ll only cover a short summary and provide links to more in-depth topics.

The problem:

Because of the way Windows and Active Directory work, there are a number of ways for attackers to read and use passwords or their hashes. All that’s needed are admin rights on a workstation and freely accessible tools like Mimikatz (Github and BlueHat talk).

Admin rights can be acquired through a phishing attack or a social engineering attack, for example. According to the study ‘Wombat Security State of the Phish 2017’, 76% of all organisations were the victims of phishing attacks in 2016 alone. Particularly with larger organisations, chances are that sooner or later, an attacker will succeed.

In the next step, the attacker will try to spread themselves in the network. In the past, attackers had to spend a lot on moving around the network via trial and error methods in order to eventually acquire privileged accounts. Today, there are tools like Bloodhound (Github and – DEF CON 24 talk) which display the path from the captured computer to the domain admin account (or any other) within a few minutes.

I advise everyone to look at the linked talks. It’ll open your eyes!

The (ESAE) solution:

As already stated above, ESAE is not a single technique, no tool or service that solves all these problems, but a set of techniques, tools, and work methods that make it difficult for an attacker to acquire highly privileged accounts and cause damage with them.

The core of the solution is to subdivide the IT services and systems into different tiers on the basis of the protection needs and to outsource the admin accounts for the tiers with high protection needs to a separate administration forest.

If you check out the Microsoft documentation, the systems are devided into the tiers as follows:

Tier 0: Entreprise identity systems such as Active Directory, PAM systems, ADFS.

Tier 1: Entreprise applications such as email, collaboration and other line of business applications.

Tier 2: Workstations.

This classification has to be enjoyed with a pinch of salt, of course. Every company has one or another highly protective system which doesn’t fall into the above definition for tier 0. These systems can and should be protected as well just the same, of course.

The admin accounts don’t have constant standing administration rights per se, though. These need to be requested via a just-in-time Privilege Access Management (PAM) solution for a defined period of time. Furthermore, the environment can only be administered with hardened Privilege Access Workstations (PAWs).

Since the introduction has become a little bit longer than expected, we’ll do a cut here and present the specific customer scenario and the selected architecture in the next blog article.