MIM — Extract AD MA pending exports of highly privileged accounts
Background
A complete identity life-cycle process requires, among other things, control over administrative accounts. Besides a normal user account, some users often have one or more administrative accounts, especially these accounts should be subject to a life-cycle process as they often allow access to very important data or systems.
Recently I was faced with the challenge of a project to keep control over administrative accounts when the IAM system (MIM) does not have permission to manage these accounts. In this specific case it was the management of highly privileged accounts in the Active Directory. For security reasons, it is not recommended to grant these permissions to the Identity Management System. This recommendation is based on the Active Directory administrative tier model, many thanks to and Ryan Newington who reminded me of this in a Twitter conversation on this subject.
Even if this tier model is not actively implemented in a system environment, Active Directory forces this separation at least at the permission level for highly privileged accounts. This process can be found under the terms AdminSDHolder, SDProp and adminCount, a lot has already been written about this, therefore only a few links:
- List of Protected Accounts and Groups in Active Directory
- “Ask the Directory Services Team” Blog
- AdminSDHolder documentation
- SDProp documentation
Process and issue
While one could argue that these highly privileged accounts should be managed completely independently of the IAM system, two points are worth mentioning:
- Even if there are very few accounts, a manual process is always error-prone.
- Often administrative accounts are not provided with these permissions from the outset and are already in the administration of the IAM system when the permission is granted.
As the simplest example, we want the administrative account to be deactivated when the employee leaves the company and the IAM system automatically receives this information from the human capital management system (HCM).
The process up to the error case could therefore look as follows:
- Employee joins the company
- Employee receives normal account managed by IAM
- Employee receives administrative account managed by IAM
- Administrative account receives highly privileged permissions and gets protected by AdminSDHolder.
- Employee leaves the company
- IAM System is unable to deactivate account due to missing permissions (AD MA permission-issue)
This is just an example of course there may be other changes like names or contact information.
Solution
Of course, you could remove the account after it received the highly privileged permissions from the IAM administration, but then nobody would notice if someone left the company.
Therefore we decided to keep the accounts in the IAM administration, not to grant the IAM system the permissions to manage them and instead to react to the error message of the AD MA when changes are due for such accounts.
To simplify the process, I created a script that reads the pending changes via Lithnet miis-powershell and writes a CSV file. A second script reads this CSV afterwards and writes the changes directly into the AD, this script must be executed by an employee with the appropriate rights.
The administrative accounts are marked in the metaverse with the attribute PrivilegedAccount which reflects the AD attribute adminCount.
The scripts should only serve as a basis and have to be edited for error handling, logging and respect of the domain.
Script 1
Script 2
Noteworthy
This should be a short blog, worth mentioning are Privileged Identity Management systems like MIM PAM and Azure AD PIM.
