Delegating the minimum set of permissions for user provisioning

The purpose of this post is to provide information on the permissions required by the user account that the Active Directory Domain Services (AD DS) Management Agent (MA) or ADMA uses when it interfaces with an AD domain.  I’ve seen far too many implementations of FIM –both in the various types of lab and in production that grant the ADMA accounts more permissions and privileges than they require.  In this post I’d like to discuss the minimum permissions required to perform certain operations as well as a general approach on how to actually deploy the permissions to an AD domain.

Note. I’m using the DSACLS nomenclature including the inheritance options. From the DSACLS help:

  • T. The object and its child objects.
  • S. The child objects only.
  • P. The object and child objects down to one level only (propagate inheritable permissions to one level only)

We’ll start off by discussing the permissions required to create, delete and move (between containers) users.

Creating, deleting and moving a user

To create a user you require create child permissions on the parent container.  No other permissions are required.  The created user is disabled as it has no password.  To create an enabled user you require the following permissions.

Permission/ Access Right Object type/ Attribute Inherited object type Inheritance
CC user
WP userAccountControl user S
Reset Password user S

In addition to create child you also need the ability to set the password (the Reset Password control access right is required for this operation) and then change the userAccountControl bitmask such that the user is enabled, e.g. you might set the password and set userAccountControl to 512.

To delete a user you obviously require delete permissions too.

Permission/ Access Right Object type/ Attribute Inherited object type Inheritance
DC user

If the permissions need to be set such that users can be created in child OUs the following are also required.

Permission/ Access Right Object type/ Attribute Inherited object type Inheritance
CC user organizationalUnit S
DC user organizationalUnit S

If you want to move a user then you need to add the following permissions in addition to those defined for create and delete.

Permission/ Access Right Object type/ Attribute Inherited object type Inheritance
WP cn user S
WP distinguishedName user S
WP name user S

Moving a user is a rename. We write the distinguishedName but the LDAP operation also requires that we change the CN and the name (the RDN, i.e. CN={CN}). The operation also requires delete child on the source and create child on the target.

Note.

The Windows Server 2008 Active Directory Users and Computers (ADUC) snap-in option “Protect object from accidental deletion” writes a deny { delete, delete tree } ACE for the EVERYONE principal that will interfere with the above permissions.  The ACE is explicit, i.e. not inherited, and therefore takes precedence over other permissions.

Additional properties

The preceding example provided the minimum permissions.  Creating a user with nothing more than a DN isn’t really all that helpful.  Additional attributes are generally required.  The sAMAccountName is pretty much mandatory from a provisioning perspective.  It is a mandatory attribute from the perspective of the security accounts manager (SAM) however the directory server will automatically generate one if you don’t provide it (Windows Server 2003 and later).  The user principal name is also a common expectation although it isn’t strictly necessary as users have an implicit UPN (sAMAccountName @ domain DNS name).  The following tables define some additional permissions required for typical account provisioning scenarios.

GAL/ADUC properties

Permission/ Access Right Object type/ Attribute Inherited object type Inheritance
WP c user S
WP co user S
WP company user S
WP countryCode user S
WP department user S
WP displayName user S
WP facsimileTelephoneNumber user S
WP givenName user S
WP initials user S
WP l user S
WP manager user S
WP mobile user S
WP pager user S
WP physicalDeliverOfficeName user S
WP postalCode user S
WP sn user S
WP st user S
WP streetAddress user S
WP telephoneNumber user S
WP title user S

Other attributes

Some additional attributes that are often flowed.

Permission/ Access Right Object type/ Attribute Inherited object type Inheritance
WP employeeID user S
WP employeeType user S

Deploying permissions

The permissions need to be deployed on a per-container basis.  For example, assuming the following OU structure (over and above the default containers which are out of scope):

  • OU=employees, OU=people, DC=corp, DC=contoso, DC=com
  • OU=contractors, OU=people, DC=corp, DC=contoso, DC=com
  • OU=employees, OU=people, DC=corp, DC=contoso, DC=com
  • OU=vip,DC=corp, DC=contoso, DC=com
  • OU=deleted-users,DC=corp, DC=contoso, DC=com

The aforementioned permissions need to be applied to each OU.  It doesn’t make sense to apply the permissions at the root of the naming context (DC=corp, DC=contoso, DC=com) as then they’ll apply to all the other containers not listed above.  We don’t want to delegate permissions throughout the domain.  What if there’s also an OU=privileged-accounts,DC=corp, DC=contoso, DC=com and an OU=service-admins,DC=corp, DC=contoso, DC=com?

Applying the consistent set of permissions means that FIM can create and delete users as well as move users between containers and write the necessary properties.  The only way to set granular permissions in a consistent way is via script.  DSACLS should be the tool of choice.

An example script

Up until recently I’ve just used a CMD script –an extension of the script here.  However recently I’ve been trying to write all scripts and commands in PowerShell to make my deployment documents more consistent so here’s an example PS script that can enable the permissions described above for the containers also listed above.

# UserProvisioningPermissions.ps1 v1.0 
#   Paul Williams (pawill@microsoft.com) Microsoft Services Feb. 2010

PARAM
(
    [Parameter(Mandatory = $true)]
    [String]$Target,

    [Parameter(Mandatory = $true)]
    [String]$Trustee
);

Write-Host "`nTarget:  $Target`nTrustee: $Trustee`n";

[String[]]$attributes = @(
    "c",
    "cn",
    "co",
    "company",
    "countryCode",
    "department",
    "displayName",
    "distinguishedName",
    "facsimileTelephoneNumber",
    "givenName",
    "initials",
    "l",
    "manager",
    "mobile",
    "name",
    "pager",
    "physicalDeliverOfficeName",
    "postalCode",
    "sn",
    "st",
    "streetAddress",
    "telephoneNumber",
    "title"
);

Write-Host "Granting the following permissions...";
Write-Host "Create/Delete user objects (this object)";
[String]$cmd = "dsacls '$Target' /G '`"$Trustee`":CCDC;user;'";
Invoke-Expression $cmd |Out-Null;

Write-Host "Create/Delete user objects (child OUs)";
[String]$cmd = "dsacls '$Target' /I:S /G '`"$Trustee`":CCDC;user;organizationalUnit'";
Invoke-Expression $cmd |Out-Null;

Write-Host '"Reset Password" Control Access Right (CAS)';
[String]$cmd = "dsacls '$Target' /I:S /G '`"$Trustee`":CA;`"Reset Password`";user'";
Invoke-Expression $cmd |Out-Null;

foreach($attr in $attributes)
{
    Write-Host "Write Property (WP) $attr on descendent user objects";
    [String]$cmd = "dsacls '$Target' /I:S /G '`"$Trustee`":WP;$attr;user'";
    Invoke-Expression $cmd |Out-Null;
}

Write-Host "`nScript complete.";

Note

The script defines both “this object only” and the “all descendent organizationalUnit objects” inherited permissions for CC and DC, thus when applying the script to OU=People the resultant permissions are such that users can be created in OU=People or any OU underneath OU=People.

And here’s the command(s) that invoke the script.  In this example the script is called UserProvisioningPermissions.ps1 and I’m invoking it from the current directory.

.\UserProvisioningPermissions.ps1 `
    -Target "OU=people, DC=corp, DC=contoso, DC=com" `
    -Trustee "CORP\ADMAUserProvisioningPermissions";

Wrap up

The intention of this post is to provide you with enough information to define granular, precise permissions for the ADMA and not use some all encompassing group.  In addition to defining the minimum permissions for create, delete and move I also provided some additional attributes often used when provisioning and synchronising with an AD DS domain.  I provided an example script to automate the deployment of the permissions and an example of how to use it.

Given the script in the preceding section and the OUs listed in the section before that we would successfully deploy the permissions in this article by running the script three times –once against each of the following OUs.

  • OU=people, DC=corp, DC=contoso, DC=com
  • OU=vip,DC=corp, DC=contoso, DC=com
  • OU=deleted-users,DC=corp, DC=contoso, DC=com

The following is an example of again using PowerShell to make life easier.

[String[]]$containers = @(
    "OU=people, DC=corp, DC=contoso, DC=com",  
    "OU=vip,DC=corp, DC=contoso, DC=com", 
    "OU=deleted-users,DC=corp, DC=contoso, DC=com"
);

foreach($target in $containers)
{
    .\UserProvisioningPermissions.ps1 `
        -Target $target `
        -Trustee "CORP\ADMAUserProvisioningPermissions";
}
About these ads

About Paul Williams

IT consultant working for Microsoft specialising in Identity Management and Directory Services.
This entry was posted in Active Directory, FIM, FIM 2010, FIM 2010 R2 and tagged , , , , , , , , , , , , , , , . Bookmark the permalink.

3 Responses to Delegating the minimum set of permissions for user provisioning

  1. Pingback: Delegating the minimum set of permissions for mailbox-enabled user and linked mailbox provisioning | Yet another identity management blog

  2. Pingback: Office 365 Exchange Hybrid DIRSYNC write-back attributes and permissions | Yet another identity management blog

  3. Pingback: AD permissions | technology systems info

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s