On the other hand, pass the hash (PtH) and pass the ticket (PtT) attacks also work across trust borders. In order to be able to operate such a construct safely, all national companies would have to take the same security measures and monitor these consistently. In the case of our client, this isn’t the case today.

Another solution is claims-based authentication. With the advent of cloud applications, this type of authentication became increasingly popular and important. With that, it’s all about the identities being managed separately from the application. In the first step, the application provider establishes a trust relationship with an identity provider (such as Active Directory Federation Services). In the second step, the user is identified on the basis of various information (claims). These claims are transported via a security token.

You can find a more detailed description here. As can be seen in the image, the process can be used loosely coupled via the internet but doesn’t necessarily have to.

As an attentive reader, you’ll now wonder whether you don’t need just as many (ADFS) trusts as in the scenario described above. At first glance, that’s the case, but Microsoft Active Directory Services can be configured in a way that a central entity acts as a hub for the authentication tokens. This way, each application and each identity provider (aka national company) must enter exactly one trust with the central entity.

Precisely such a construct should be built in a separate location and administered by ESAE.

The requirements

Now, of course, we have the question as to which components are necessary for the overall solution and according to which principles these should be set up and operated. Below, we tried to summarise this in as compact a way as possible. In doing so, we limit ourselves to the specifics of an ESAE environment and omit some aspects from the list which are necessary for the operation of each IT environment (e.g., detailed backup and disaster recovery requirements).

Separation of layers and least privilege administration

• Physical and logical separation of tier 0 systems from tier 1 and 2

• No use of tier 1 and 2 services that could compromise a tier 0 system (monitoring agent, f. ex.)

• Access restriction of the accounts (administration only on the same tier. No login on a lower tier):

Source: Microsoft

• Principle of least privilege with just-in-time administration

Hardening

• All systems must be hardened according to Best Practice.
• Administrative access only via hardened privilege admin workstations with multi-factor authentication
• Encryption of the hard drives
• Installation only from trustworthy sources (hash control)
• Long passwords with short durations. For service accounts group managed service accounts, if possible

Processes and operation

• Reduction of tier 0 administrators to a minimum
• Well-trained staff with positive proof of good conduct

Anyone who’s been around IT for long enough will be used to most of the requirements. As outlined in the introductory article, an ESAE environment is not a ground-breaking new technology, but mostly a matter of consistently implementing various techniques and procedures. However, for the ‘principle of least privilege with just-in-time administration’ requirement, Microsoft has a new technical answer that is designed to defend against credential theft and PtH/PtT attacks.

Exactly, you’ve already guessed it – this is about the administration forest with the privilege access management solution mentioned in the introductory article. It’s realised specifically through a new Active Directory feature, the shadow principal, in connection with the new Microsoft Identity Manager (MIM) module ‘Privilege Access Management (PAM). In the next article, we’ll describe we’ll describe how these features work in detail

Finally, we’d like to show you the precise overall architecture of the client project:

As you can see in the diagram, the environment only exists of a handful of servers. At first glance, it seems like a lot of effort to set up an ESAE-oriented environment for the operation of only two ADFS servers. This is due to the client’s project approach which intends a phased set-up and expansion of the environment. The architecture shown is only the first step. In perspective, other critical services are to be set-up in the environment (f. ex., a global PKI) and, secondly, the environment is to be expanded with additional security measures (e.g., connection to a SIEM system).

Below, for the sake of completion, is a list of the systems with a brief functional description. The core components will be discussed in more detail in follow-up articles.

2 Hyper-V Servers

• Virtualisation platform to host all other systems

External firewall and VPN gateway

• Endpoint for establishing the administration connections
• External firewall

Load balancer

• Load balancing for the ADFS server

Internal firewall

• Separation of DMZ and the internal network

2 Active Directory domain controllers (‘green forest’)

• Production forest with the services that are to be consumed

2 Active Directory domain controllers (‘red forest’)

• Administration forest with the tier 0 systems

2 Active Directory federation servers

• Hub for claims-based authentication

1 MIM PAM server

• Privileged Access Management with just-in-time administration

1 WSUS server

• Installation of Microsoft updates

1 SCOM server, one SCOM Gateway and an SQL server for the SCOM databases

• Monitoring the environment

1 NXLog server

• Collecting and transferring event log entries

Source: freepik.com

LATEST POSTS