What is the logic behind PAM?

PAM is based on the just-in-time (JIT) administration concept. Back in 2014, Microsoft released the PowerShell toolkit, which allows Just Enough Administration (JEA). Let's assume that you are running a web server in your infrastructure; as part of the operation, you need to collect some logs every month to make a report. You've already set up a PowerShell script for this purpose. Someone in your team needs to log in to the system and run it. In order to do so, you require administrative privileges. Using JEA, it is possible to assign the required permissions for the user to run only that particular program. In this way, there's no need to add the user to the Domain Admin group. The user will not be allowed to run any other program with the permission assigned as it is, and it will not apply for another computer either. JIT administration is bound in time. This means that users will have the required privileges only when they need them; they will not hold privileged access rights all the time.

PAM operations can be divided into four major steps, as shown in the following diagram:

Let's take a look at these four major steps:

• Prepare: The first step is to identify the privileged access groups in your existing AD forest and start to remove users from them. You may also need to make certain changes to your application infrastructure to support this setup. For example, if you assign privileged access to user accounts instead of security groups (in applications or services), this will need to change. The next step is to set up equivalent groups in a bastion forest without any members.

When setting up MIM, a bastion forest will be used to manage privileged access in an existing AD forest. This is a special forest and cannot be used for other infrastructure operations. This forest runs on a minimum of a Windows Server 2012 R2 AD forest functional level. When an identity infrastructure is compromised and attackers gain access to Tier 0, they can hide their activities for months or years. But how can we be sure our existing identity infrastructure has not been compromised already? Well, if we implement this in the same forest, it will not achieve its core targets. Additionally, domain upgrades are painful, requiring time and money. But with a bastion forest, this solution can be applied to your existing identity infrastructure with minimal changes.

• Protect: The next step is to set up a workflow for authentication and authorization. We need to define how a user can request privileged access when required. This can be done using a MIM portal or an existing support portal (with an integrated MIM REST API). It is possible to set up a system to use Multi-Factor Authentication (MFA) during this request process to prevent any unauthorized activity. Additionally, it's important to define how the requests will be handled. It can be either an automatic or manual approval process.
• Operate: Once the privileged access request is approved, the user account will be added to the security group in the bastion forest. The group itself has an SID value. In both forests, the group will have the exact same SID value. Therefore, the application or service will not see a difference between the two groups in two different forests. Once the permission is granted, it will only be valid for the time defined by the authorization policy. Once it reaches the time limit, the user account will be removed from the security group automatically.
• Monitor: PAM provides visibility over privilege-access requests. On each and every request, events will be recorded, and it is possible to review them and also generate reports for audits. This helps to fine-tune the process and also identify any potential threats.

Let's examine how it really works:

Rebeladmin Corp. uses a CRM system for its operations. The application has the administrator role and Rebeladmin/CRMAdmins security group assigned to it. Any member of that group will have administrator privileges to the application. Recently, PAM has been introduced to Rebeladmin Corp. As an engineer, I have identified Rebeladmin/CRMAdmins as a privileged group and am going to protect it using PAM. The first step is to remove the members of the Rebeladmin/CRMAdmins group. After that, I set up the same group in the bastion forest. It's not just that the name is the same, but both groups have the same SID value: 1984.

User Dennis used to be a member of the Rebeladmin/CRMAdmins group and was running monthly reports. At the end of one month, he tried to run it and found that he did not have the required permissions. The next step for him was to request the required permission through the MIM portal.

According to the policies, as part of the request, the system wants Dennis to use MFA. Once Dennis verifies the PIN, the request is logged in the portal. As an administrator, I receive the alert about the request, and I log in to the system to review the request. It's a legitimate request, so I approve his access to the system for 8 hours. Then, the system automatically adds the user account for Dennis to the Bastion/CRMAdmins group. This group has the same SID value as the production group. Therefore, a member of the Bastion/CRMAdmins group will be treated as an administrator by the CRM application. This group membership contains the TTL value too. After it passes 8 hours from approval, Dennis's account will be automatically removed from the Bastion/CRMAdmins group. In this process, we didn't add any member to the production security group, which is Rebeladmin/CRMAdmins. So, the production forest stays untouched and protected.

Here, the most important thing we need to understand is that the legacy approach to identity protection is no longer valid. We are up against human adversaries. Identity is our new perimeter in the infrastructure and, to protect it, we need to understand how our adversaries are attacking it, and stay a step ahead. PAM with AD DS 2016 is a new approach in the right direction.