Office 365 Exchange Hybrid DIRSYNC write-back attributes and permissions

Those of you implementing the DIRSYNC appliance or the Forefront Identity Manager (FIM) multi-forest directory synchronisation solution might need to implement the write-back of attributes into the Active Directory Domain Services (AD DS) forest for the purpose of Exchange Hybrid, a.k.a. Rich Coexistence.  There are several sources that cite the attributes that require updating however I have yet to see a correct table listing what attributes of what object types are updated.  Nor have I seen details of what permissions are required and where.  That’s not to say this information isn’t out there.  Regardless, it’s here now too.

Exchange hybrid mode

The following table details the AD DS attributes that are updated by the DIRSYNC appliance according to object type.  In short, proxyAddresses for all three object types and the Exchange attributes for user objects only.

Update: I updated this post on 6th March, 2014 to include the msExchUserHoldPolicies added in one of the builds in ~Q4 CY13.  More info. on the changes can be found in this post.

Object Type (objectClass) Property (LDAP attribute name)
contact proxyAddresses
group proxyAddresses
user/inetOrgPerson msExchArchiveStatus
msExchBlockedSendersHash
msExchSafeRecipientsHash
msExchSafeSendersHash
msExchUCVoiceMailSettings
msExchUserHoldPolicies
proxyAddresses

Note.  I don’t specifically list the object type inetOrgPerson throughout this post.  If you are actually using inetOrgPerson objects in place of, or in addition to, user objects then consider user and inetOrgPerson synonymous and apply any guidance related to user objects to inetOrgPerson objects too.

DIRSYNC permissions

The DIRSYNC appliance runs with a user with considerable permissions throughout the directory and does not require groups and delegated permissions setup – if you require delegated permissions as opposed to the god-like rights that the DIRSYNC appliance has you probably shouldn’t be using DIRSYNC.  For those of you using DIRSYNC consider this post information on what attributes are written to what objects – as per the above table.  For those of you implementing or considering implementing full FIM, e.g. those of you with complex environments such as multiple account forests and a resource forest, or atypical immutable ID requirements, the next section discusses permissions and least privilege.

FIM flows and permissions

When you implement the Azure Active Directory (AAD) Connector, a.k.a. the Office 365 (O365) connector, you have the choice of whether or not you configure export flows to your Exchange forest via the Active Directory Management Agent (ADMA).  If you are running Exchange hybrid you need to configure export flow rules.  You should actually configure four advanced flows and three direct (or advanced) flows.  Figure 1 is an example of my configuration.

FIM DirSync ADMA EAF

Figure 1: Export attribute flow: user (mail forest)

All of my flows are advanced because I use an element in my configuration XML to determine whether or not hybrid write-back is enabled.

The other object types: contact and group only have one export flow: proxyAddresses.  Figure 2 illustrates this.

image

Figure 2: Export attribute flow: group (mail forest)

I’m afraid I cannot post my code at this point in time.  The primary purpose of this post is twofold: identify what attributes of what object type need to be written (hence the illustrations of export flow rules to cement this point); and permissions and least privilege  – not to provide the whole solution.  The next section describes the permissions.

Minimum permissions

In order to grant the AD DS Management Agent (MA) permissions to modify these attributes you need to do one of three things:

  1. Apply Write Property (WP) permissions to each container that houses objects that will require updating.
  2. Apply WP permissions to the domain naming context (NC) head and propagate throughout the AD directory tree.
  3. Grant far more permissions than required.

I vote for option 1, but in some cases option 2 might be simply easier from both a deployment and operational perspective.  I’ll fight against option 3 every time.

Using the preceding table and the DSACLS nomenclature, like I have throughout this blog when describing permissions, the following table defines the minimum set of permissions required at an individual container (or the NC head) level.

Note. 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)
Permission/ Access Right Object type/ Attribute Inherited object type Inheritance
WP proxyAddresses contact S
WP proxyAddresses group S
WP msExchArchiveStatus user S
WP msExchBlockedSendersHash user S
WP msExchSafeRecipientsHash user S
WP msExchSafeSendersHash user S
WP msExchUCVoiceMailSettings user S
WP msExchUserHoldPolicies user S
WP proxyAddresses user S

Scripting permissions

The following script is a modification of the one posted in the section “an example script” here.


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

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

    [Parameter(Mandatory = $false)]
    [Switch]$ForReal = ![Switch]::Present
);

Write-Host "`nMsoDirSyncHybridPermissions.ps1 v1.0ps1 Paul Williams (pawill@microsoft.com) Dec 2012`n";
Write-Host "Target:  $Target`nTrustee: $Trustee`n";

[String[]]$objectTypes = @(
    "contact",
    "group",
    "user"
);

[String[]]$exchHybridWriteBackAttributes = @(
    "msExchSafeSendersHash;user",
    "msExchBlockedSendersHash;user",
    "msExchSafeRecipientsHash;user",
    "msExchArchiveStatus;user",
    "proxyAddresses;all",
    "msExchUCVoiceMailSettings;user",
    "msExchUserHoldPolicies;user"
);

if($ForReal.IsPresent)
{
    Write-Host "Granting the following permissions...";
}
else
{
    Write-Host `
        "Running in informational mode.  To actually submit changes use the -ForReal switch.`n" `
        -ForegroundColor Yellow;
}

foreach($objectClass in $objectTypes)
{
    Write-Host "Object type:" $objectClass;
    foreach($attribute in $exchHybridWriteBackAttributes)
    {
        [String[]]$scopedAttrs = $attribute.Split(";", [StringSplitOptions]::None);
        [String]$attr = $scopedAttrs[0];
        [String]$ttype = $scopedAttrs[1];

        if( ($ttype.ToLower() -eq $objectClass.ToLower()) -or
            ($ttype.ToLower() -eq "all"))
        {
            Write-Host "`tWrite Property (WP) $attr on descendent user objects";
            [String]$cmd = "dsacls '$Target' /I:S /G '`"$Trustee`":WP;$attr;$objectClass'";
            if($ForReal.IsPresent)
            {
                Invoke-Expression $cmd |Out-Null;
            }
        }
    }
}

Write-Host "`nScript complete.`n`n";

Usage

The script has two mandatory parameters and one optional parameter:

  • Target.  The LDAP distinguished name (DN) of the target container, e.g. OU=Managed People,DC=corp,DC=contoso,DC=com.
  • Trustee.  The security principal to grant the permissions to, e.g. CORPSG_DIRSYNC_ACCESS.
  • ForReal.  Switch to signify that you do wish to execute the script against the directory service.

Here’s examples of both usages – illustrative and real (before the update, hence missing msExchUserHoldPolicies):

image

The idea with the illustrative mode is to output the permissions for easy viewing.

Logging is highly limited.  I pipe the DSACLS commands to NULL.  Change this to Out-File fileName.log.txt -Append if you want to see the output.

Hopefully this is informative and helpful.  Smile

Advertisements

About Paul Williams

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

4 Responses to Office 365 Exchange Hybrid DIRSYNC write-back attributes and permissions

  1. Pingback: Windows Azure Active Directory Connector part 2: multi-forest directory synchronization | Yet another identity management blog

  2. Pingback: Changes to hybrid write-back export attribute flow in FIM-based directory synchronization solutions | Yet another identity management blog

  3. strongline says:

    Line 55, change it to “Write-Host “`tWrite Property (WP) $attr on descendent $objectClass objects”;” will make output more sense

  4. Raghuram P says:

    Can you also please add the attribute msDS-ExternalDirectoryObjectID (Ex2016) to the script. Thanks for the script.

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