Administrative accounts are necessary for IT workers, but they also pose a significant risk to an organization...
if they fall into the wrong hands. One way to tighten security is to deploy a bastion forest.
When it comes to IT security, the bastion concept is not new. A bastion host, for example, is a hardened server that proxies requests to a back-end resource. It protects the back-end servers from various threats by removing direct access. A bastion forest works in a similar fashion by shielding a sensitive resource, namely Active Directory administrative accounts.
Moderating privileged credentials access
Bastion forests are a part of a layered privileged access management (PAM) architecture. The overarching idea behind PAM is to give IT workers narrow administrative privileges with a limited life span.
Administrative activities typically require one or more very specific privileges. Creating an Active Directory user account does not require the same permissions as other administrative tasks, such as managing a group policy setting.
Also, IT workers do not require administrative privileges at all times. If an administrator has no management tasks to perform, then PAM can restrict the privileged access.
How to retrofit an existing AD setup
There may be reluctance to deploy bastion forests and the PAM architecture at a company on an older Windows Server version. For those organizations, it is possible to use PAM with an existing Active Directory setup without switching to Windows Server 2016.
To use PAM, the organization's Active Directory forest needs to be on Windows Server 2012 R2 or higher. There is no requirement to run Windows Server 2016 in your primary Active Directory forest. The bastion forest must use Windows Server 2016 domain controllers, which must be set to a Windows Server 2016 forest functional level.
How bastion forests restrict admin access
Bastion forests, which debuted in Windows Server 2016, are a key component in the PAM architecture. A bastion forest isolates privileged accounts from the rest of the Active Directory through a one-way trust to make it much more difficult for an attacker to compromise privileged accounts.
A bastion forest is different from a trusted forest that contains privileged accounts because an administrator does not log into a privileged account to manage Active Directory resources in the usual way. Instead, PAM only issues the permissions required for a specific administrative task for a limited time.
In a PAM configuration, when administrators need to create an Active Directory user account, they must request privileged access in one of three ways: through a REST endpoint, via the New-PAMRequest cmdlet or through the Microsoft Identity Manager Web Service API. After it has been approved, the privileged account receives the requested permission through a foreign principal group in the bastion forest.
The interesting aspect of this security setup is the administrator's account derives its privileges from a group membership in the bastion forest. The account does not hold any native elevated privileges in the organization's primary forest.
Also, when adding an administrative account to the privileged group in the bastion forest, the group membership eventually expires. The time limit is set by specifying a time-to-live value in the PowerShell Set-ADObject cmdlet.