When MIM 2016 was announced, I was excited to see the inclusion of Privileged Access Management (PAM). This was a big step forward for Microsoft security. As with any new technology, PAM was a little slow on the uptake. MCS Cyber already had its own version of “PAM” as part of their ESAE engagements and most large enterprises are not going to quickly jump on the next new thing.

Fast forward a couple of years and PAM implementations are going strong. The technology not only works, it works very well. Large scale enterprises are starting to roll it out.

The MIM/PAM portal handles PAM roles, requests and approvals pretty well, but what about the users and groups? The main user and group management is happening in the CORP forest. What do I do as a user who needs a PRIV account? Run a PowerShell script? Call the help desk? Who will approve the account creation? Does my manager even exist in the PRIV forest?

These are important questions. Why not have the user and group request, approval and attestation process take place on the CORP side where the main user and group management already exists? There are a couple of things to consider here. While the CORP forest trusts the PRIV forest, that’s not the case in the other direction. Reaching out from the CORP forest to manage the PRIV forest means storing elevated credentials on a CORP server. Not a good idea. My suggestion is to have a process running in the PRIV forest reach out to the CORP forest. To do this, there needs to be an intermediary for the two sides to communicate with each other. I’m using a simple SQL “PAM Transaction” table for this.

  • PAMTranactions SQL table
    • Fields
      • TransactionID – int
        • Auto incrementing identity
      • TransType
        • CreatePAMUser
        • RemovePAMUser
        • CreatePAMGroup
        • RemovePAMGroup
      • CreateDate
        • Date transaction was submitted
      • AccountName
        • Source account name
      • Domain
        • Source domain
      • Status
        • Pending, Completed, Error
      • StatusDate
        • Last time the status was updated
      • Parameters
        • Any additional command line parameters “;” delimited
        • Example: param1,val1;param2,val2;param3,val3
        • Using XML here is probably a better option.
      • Message
        • Error, info or debug messages

A user can request a PRIV account from their own profile on the CORP side.

The request can go through the required approval process on the CORP side before it ever gets queued up for the PRIV forest to process. The periodic attestation of the account can also be managed on the CORP side. You might want to include a “business justification” field here as well. It all depends on the client’s requirements.

A similar process will be used by group owners to request PRIV groups.

Once the PRIV user or group has been approved, use a MIMWAL workflow to add a transaction to the PAM transactions table. I use a single workflow to do both the CreatePAMUser and RemovePAMUser transactions, based on the current state of the privAccount bool attribute. If it’s true, the first action executes. If it’s false (or Null) the second action executes.

The Create PAM User action does the following:

  • Gets the target’s account name
  • Creates a SQL transaction to request a new PRIV user
    • ExecuteSQLNonQuery(“UtilsDB”, “Insert into PAMTransactions (TransType, CreateDate, AccountName, Domain, Status, StatusDate, Parameters) values (‘CreatePAMUser’, GETDATE(), ‘” + $acctname + “‘, ‘iam-srv.com’, ‘Pending’, GETDATE(), ‘verbose,true’)”)
  • Sets the account attestation date to 180 days in the future
    • DateTimeAdd(DateTimeNow(), “180.00:00:00.0”)
  • Adds a create record to the PRIV account history
    • InsertValues(Concatenate(DateTimeFormat(DateTimeNow(), “yyyy-MM-dd”), “: “, UpperCase([//Requestor/AccountName]), ” – PRIV Account Created”))

The Remove PAM User action does the following:

  • Get’s the target’s account name
  • Creates a SQL transaction to remove the PRIV user
    • ExecuteSQLNonQuery(“UtilsDB”, “Insert into PAMTransactions (TransType, CreateDate, AccountName, Domain, Status, StatusDate, Parameters) values (‘RemovePAMUser’, GETDATE(), ‘” + $acctname + “‘, ‘iam-srv.com’, ‘Pending’, GETDATE(), ‘verbose,true’)”)
  • Clears the account attestation date
  • Adds a remove record to the PRIV acount history
    • InsertValues(Concatenate(DateTimeFormat(DateTimeNow(), “yyyy-MM-dd”), “: “, UpperCase([//Requestor/AccountName]), ” – PRIV Account Removed”))

The end result will be either a Create or Remove user transaction in the PAM transactions table.

A scheduled task (PowerShell script) running on the PRIV side periodically polls the transation table to get the new transactions.

  • SELECT TransactionID, TransType, AccountName, Domain, Parameters from PAMTransactions Where Status = ‘Pending’ ORDER BY TransactionID ASC

The script cycles through the pending transactions, executes the proper transaction type and updates the table with the result.

That covers the basic use cases of getting users and groups into the PRIV forest. Once they are there, the actual role requests and approvals can be managed on the PRIV side. The attestation process has been covered in previous posts, so I won’t repeat that here.

Let me know what you think in the comments. I’m always open to other creative ideas. 🙂

Thanks,

Mark