Yet another identity management blog

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.

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.

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

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

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

Other attributes

Some additional attributes that are often flowed.

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";
}