PAM is based on the just-in-time (JIT) administration concept. Back in 2014, Microsoft released the PowerShell tool kit, which allows just enough administration (JEA). Let's assume you are running a web server in your infrastructure. As part of the operation, every month you need to collect some logs to make a report. You've already set up a PowerShell script for it. 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. Users will have the required privileges only when they need it; 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 look at these following 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.

• Protect: The next step is to set up a workflow for authentication and authorization. Define how a user can request privileged access when required. This can be done using an MIM portal or existing support portal (with 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. Also, it's important to define how the requests will be handled. It can be 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 and also generate reports for audits. This helps fine-tune the process and also identify potential threats.

Let's see 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 only that the name is the same; 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 a month, he tried to run it and figured 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 received the alert about the request, and I log in to the system to review the request. It's a legitimate request, and 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 automatically be 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 doing it and stay a step ahead. PAM with AD DS 2016 is a new approach in the right direction.