Microsoft PAM Simplified

Microsoft MIM PAM (Privileged Access Management)

Some pitfalls and how to deal with them.

If you don’t know Microsoft PAM, here is an introduction. This short essay, does not intend to inform you about the

product, but rather share some findings with colleagues who are trying to make it work.

Here is the link if you want to learn about it:

https://docs.microsoft.com/en-us/microsoft-identity-manager/pam/privileged-identity-management-for-active-directory-domain-services

What I do want to share today, are some of my own findings.

The most important one is the treatment of the CORP account.

If you read this document, https://docs.microsoft.com/en-us/microsoft-identity-manager/pam/step-6-transition-group-to-pam, it tells you that you need 2 accounts for each user in MIM Service Database.

I have been struggling with this since first time I saw it and I was not able to find any explanation as to why? I doubted and I believe I was right on doing so.

Let us examine what is happening, from a very high level.

NO PAM: You start with a CORP Domain. This is what you have today.  User ‘CORP\NoshPam’ is member of ‘CORP\DomainAdmins’ Group

WITH PAM: Now you bring MIM PAM and this is what you get

USER OBJECTS:

  • New user in BASTION Forest called ‘BASTION\Corp.NoshPam’. This is a normal user with its own objectSID.
  • In Addition, the object type is person, so a perfectly normal user.

CORP AD ACCOUNT:

BASTION AD ACCOUNT:

SECURITY GROUPS:

  • New Shadow Principal Group in BASTION called ‘Corp.DomainAdmins’, assigning the same objectSID as ‘CORP\DomainAdmins’

CORP AD GROUP:

BASTION AD SHADOW PRINCIPAL (AD GROUP) 

FYI: This is done using “Active Directory Sites and Services” and it is under Services Node. 

 

AD FOREST TRUST:

    • One way trust from BASTION to CORP. Meaning, CORP trusts BASTION, but BASTION does not trust CORP

MIM USER:

  • We are told that we need 2 users in MIM Service database, one for each domain. ‘CORP\NoshPam’ and ‘BASTION\NoshPam’

MIM SECURITY GROUP:

  • A Security group that matches the ‘BASTION\Corp.DomainAdmins’

 

MIM ROLE:

  • A role that applies to ‘BASTION\Corp.DomainAdmins’

  • We are told that both accounts ‘CORP\NoshPam’ and ‘Bastion\NoshPam’ need to be added to the role as candidates.  

 

PUTTING IT ALL TOGETHER:

Let us see what we have so far.

  • User and group in CORP Domain.
  • User in Bastion Domain
  • Shadow Principal (group) in Bastion Domain
  • A Role in MIM
  • A Security Group in MIM
  • 2 User Accounts in MIM
    • Both are Candidates to the role

Let us get access now.

  • ‘BASTION\Corp.NoshPam’ requests access to ‘BASTION\Corp.DomainAdmins’ and gains access to ‘CORP\DomainAdmins’ because of the objectSID and trust mentioned above.

THE ISSUE:

  • Why do I need the CORP\NoshPam in MIM?
  • Why do we need CORP\NoshPam in CORP AD?
    • I can’t see a reason why. Not only we don’t need this account in MIM Service, but also we might as well delete it from the CORP AD period, provided the account is not used for something else, not managed by PAM.

THE PROPOSED SOLUTION:

To reduce overhead and simplify the implementation, I propose the following setup for PAM:

  1. In CORP AD, there are should be no admin accounts, besides a break-glass account, which is never used and highly secured. A monitoring mechanism should be in place to alert if this account ever logs in.
  2. Create all Admin Accounts in BASTION forest only.
    • Do not name them ‘COR.NOSHPAM’, or ‘CORP2.NOSHPAM’ or anything like that. Name them simply ‘NOSHPAM’ ‘JackAdmin, etc.
    • If the CORP Groups are not managed by PAM, you can always add the ‘BASTION\NoshPam’ account to the group in question, since Bastion is already trusted.
    • We don’t need multiple accounts in BASTION to represent the different CORP Domains. One account per person globally suffices
  3. There will be one Shadow Principal for each group, as current. No Changes.
  4. Shadow Principals will have the correlation to the CORP AD or CORP2 AD, such as ‘BASTION\CORP.DomainAdmins’ and ‘BASTION\CORP2.DomainAdmins’
  5. Roles in MIM PAM will be named ‘CORP.DomainAdmins’, ‘CORP2.DomainAdmins’ and so forth.
  6. ‘BASTION\NOSHPAM’ will request access to these roles and gain access to those domains as the underlying groups have the objectSID associated with them.
  7. PERIOD. Everything else is an overkill.

 

SAMPLE USE CASE:

We have 2 domains, CORP and CORP2. We want to manage the ‘DomainAdmins on each domain via MIM PAM.

  1. We create one user in BASTION AD, ‘Bastion\NoshPam’
  2. We create 2 Shadow Principals in Bastion Domain, one for each Domain Group
  3. We create 2 roles in MIM PAM adding their respective groups as Privileges
  4. We create one user account in MIM PAM ‘Bastion\NoshPam’ and add it to both roles as candidate
  5. User ‘Bastion\NoshPam’ can request access to each role (Thus gaining access to each domain) using the same account ‘Bastion\NoshPam’

Of course, if you use the scripts provided, you will get all the stuff you don’t need, but you must abandon the scripts.

 

DISCLAIMER: This posting is provided “As-Is” without any warranties. It is your responsibility to test and verify before implementing it into your Environment.

CAUTION     : This scenario has been tested on Windows 2016 AD Forests only.

Submit a Comment

Your email address will not be published.