Powershell Semi-Privileged user provisioning

Following the Housekeeping series, we provide an idea on how to use Powershell to automate the provisioning of a new Semi-Privileged user.

OK, before we start, some background of Semi-Privileged user. The whole idea is to have the absolute least of Privileged users. A Privileged user is any user who is member of Administrators, Domain Admins, Enterprise Admins, Schema Admins, etc.

SemiPrivileged_overview
SemiPrivileged users and roles distribution. Advanced alternative to Microsoft model.

Indeed desirable, but somehow difficult if no Delegation Model exists. Let’s assume you have made your homework, and that the model is already implemented. Now we can provision a semi-privileged user. Remember, this user must not be part of any of the privileged groups mentioned before.

As we put in place Segregation of Duties, first of all a standard user account must exist. We are using this account as the “driver” of Semi-Privileged ones. In other words, if the standard account is lock out or disabled, then any semi-privileged account must be disabled immediately. If we delete this account, then the other related accounts have no reason to exist. 

Interesting part here, is how to “link” the standard (non-privileged) user to the Semi-Privileged accounts. There are many ways to achieve this, but we decide to use an existing AD attribute. Every AD user has an attribute called “employeeNumber”. This attribute is in use for storing the company identification number of the user. As we are provisioning “administration purpose” users, then this attribute can contain the SID of the standard user. By storing the SID here, we are effectively creating a “link” between accounts.

Rules for Semi-Privileged user provisioning

The following Powershell code will create the Semi-Privileged user taking into consideration:

  • Standard user (non-Privileged user) exists
  • Create or Update Semi-Privileged user
  • Send UserID and password by Email

Lets get some variables. We will use them at a latter time.

Next step is to retrieve the standard user and all its properties, so we can transform those for the new one. Here we will “try and catch” 2 exceptions:

  • Ad Identity Not Found (ADIdentityNotFoundException)
  • AD Identity Already Exists (ADIdentityAlreadyExistException)

When we enclose actions within try-catch block, we can catch specific exceptions and manage them accordingly. In this case, when the standard user is not found, we immediately stop. Remember, if no standard user exist, then we cannot have a semi-privileged user. The second exception indicates that the Semi-Privileged user already exists. So instead of “creating” we just “change it”.

Important attributes to bear in mind

TrustedForDelegation: Security account delegation provides the ability to connect to multiple servers, and each server change retains the authentication credentials of the original client. Delegation of authentication is a capability that client and server applications use when they have multiple tiers. It allows a public-facing service to use client credentials to authenticate to an application or database service. Is very rare that this is needed, and for sure not on our Semi-Privileged users.

AccountNotDelegated: Credentials can not be reused by a trusted service. This limits the scope of attacks that use delegation, e.g. elevation of privilege activities. Always enable this setting.

EmployeeNumber: We use this attribute to “link” this account to the non-privileged account (standard user). For example, if we need to reset the password, we will use the standard user email to send the new password of this Semi-Privileged account.

employeeType: We use this attribute to “tag” the semi-privileged user. For example, if this account is a Tier0 account, then we will store T0 as a tag.

msNpAllowDialin: Indicates whether the account has permission to dial in to the RAS server. We don’t want this kind of access in our Semi-Privileged account.

msDS-SupportedEncryptionTypes: Support for newer and more secure algorithm AES (RFC3962) (128 AND 256). Used by KDC to encrypt the corresponding ticket. A must in our accounts.

Powershell Semi-Privileged user provisioning Function

Final thoughts

Use this function in your test environment first. Make sure it will do exactly what you are looking for.

Provide a text file containing your HTML code (looks nicer!). Don’t forget to include #UserID#, #DomainName# and #unsecurePassword# placeholders. These will replace by the current data.

Some corporate policies forbid to send password over email. This is because non encrypted email is easy to read. If this is your case, this example is missing an email encryption section. Encrypting email will depend on your PKI infrastructure and Email application in use.

Social network sharing