Note: This applies to Azure AD Connect, previously referred to as AAD Sync or DirSync.

***UPDATED (04/07/2016): Includes Exchange Hybrid Object ‘msDS-ExternalDirectoryObjectID’ for Exchange 2016 environments. Thanks Dave Young.

***UPDATED (29/10/2015): Included two lines for Password Write-back as per Chris Lehr Comment

When you configure Azure AD Sync (AADSync), you need to provide credentials of an account that is used by AADSync’s AD DS Management Agent to connect to your on-premises Active Directory. In previous versions of DirSync this was achieved via running the configuration wizard as a ‘Enterprise Admin’ and thus allowing the installer to create a service account and apply permissions to the Directory on your behalf. The account could have any of these following permissions to your AD DS based on your choices for purpose of the sync:

  1. Write Access to User, Contact, Groups Attributes – Hybrid Exchange Deployment
  2. Password Changes – Password Synchronisation
  3. Write Access to Passwords – Password Write-back (AAD Premium)

There has been a lot of talk lately about new tools to help you configure synchronisation of your directory with ‘(this) many clicks’. While these new tools do some great pre-req checks and wrap everything into a nice shiny wizard that helps guide you through your experience, it currently puts the burden of creating this service account and applying AD DS permissions back on you. It is now your responsibility to raise a change with the Active Directory team, in which you will need explain how you are going to splatter permissions all over their directory.

So we should re-assure the Active Directory team that we can create a service account and appy LEAST permissions on the directory for this account using the following script(s).

Apply all that are appropriate to your scenario:

Exchange Hybrid Deployment:

For rich co-existence between your on-premises Exchange infrastructure and Office 365 you must allow the service account to write-back attributes to your on-premises environment. Please check the link for additions HERE.

Configure Hybrid Write-back:

import-module ActiveDirectory
###--------variables
$DN = "OU=Users,OU=Company,DC=mydomain,DC=com"
$Account = "mydomain\svc_aadsync"

###--------Bind to AD

$sc = (Get-ADRootDSE).SchemaNamingContext
$ob = "CN=ms-Exch-Schema-Version-Pt," + $sc
$ExchangeSchemaVersion = (Get-ADObject $ob -pr rangeUpper).rangeUpper

###--------variables

<# Switches used in cmds http://technet.microsoft.com/en-us/library/cc771151.aspx /I:S = Specifies the objects to which you are applying the permissions.'S' - The child objects only /G = Grants the permissions that you specify to the user or group WP = Write to a property Permission #>

###---Update Attributes

if ($ExchangeSchemaVersion -ge 15317)
    {
    #Object type: user
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msDS-ExternalDirectoryObjectID;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchArchiveStatus;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchBlockedSendersHash;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchSafeRecipientsHash;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchSafeSendersHash;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchUCVoiceMailSettings;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchUserHoldPolicies;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;proxyAddresses;user'"
    Invoke-Expression $cmd

    #Object type: group
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;proxyAddresses;group'"
    Invoke-Expression $cmd
    #Object type: contact
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;proxyAddresses;contact'"
    Invoke-Expression $cmd
    }
else
    {
    #Object type: user
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchArchiveStatus;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchBlockedSendersHash;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchSafeRecipientsHash;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchSafeSendersHash;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchUCVoiceMailSettings;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;msExchUserHoldPolicies;user'"
    Invoke-Expression $cmd
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;proxyAddresses;user'"
    Invoke-Expression $cmd

    #Object type: group
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;proxyAddresses;group'"
    Invoke-Expression $cmd
    #Object type: contact
    $cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;proxyAddresses;contact'"
    Invoke-Expression $cmd
    } 

 

Validate

Use DSACLS to validate your settings
dsacls “\DCHostname.mydomain.com\OU=Users,OU=Company,DC=mydomain,DC=com”

Your output should resemble:

Inherited to user
 Allow BUILTIN\Pre-Windows 2000 Compatible Access
                                       SPECIAL ACCESS for Group Membership   <Inherited from parent>
                                       READ PROPERTY
 Allow MYDOMAIN\svc_aadsync           SPECIAL ACCESS for msExchSafeSendersHash
                                       WRITE PROPERTY
 Allow MYDOMAIN\svc_aadsync           SPECIAL ACCESS for msExchArchiveStatus
                                       WRITE PROPERTY
 Allow MYDOMAIN\svc_aadsync           SPECIAL ACCESS for msExchUCVoiceMailSettings
                                       WRITE PROPERTY
 Allow MYDOMAIN\svc_aadsync           SPECIAL ACCESS for msExchBlockedSendersHash
                                       WRITE PROPERTY
 Allow MYDOMAIN\svc_aadsync           SPECIAL ACCESS for msExchSafeRecipientsHash
                                       WRITE PROPERTY
 Inherited to contact
 Allow MYDOMAIN\svc_aadsync           SPECIAL ACCESS for proxyAddresses
                                       WRITE PROPERTY
 Inherited to user
 Allow MYDOMAIN\svc_aadsync           SPECIAL ACCESS for proxyAddresses
                                       WRITE PROPERTY
 Inherited to group
 Allow MYDOMAIN\svc_aadsync           SPECIAL ACCESS for proxyAddresses
                                       WRITE PROPERTY

Password Synchronisation:

For granting permissions to the service account for reading password hashes from your on-premises AD DS you must allow the special permission of Replicating Directory Changes & Replicating Directory Changes ALL.

Configure Password Synchronisation:

###--------variables
$Account = "mydomain\svc_aadsync"

###--------variables

&lt;# Switches used in cmds http://technet.microsoft.com/en-us/library/cc771151.aspx /G = Grants the permissions that you specify to the user or group CA = Control access If you do not specify {ObjectType | Property} to define the specific extended right for control access, this permission applies to all meaningful control accesses on the object; otherwise, it applies only to the specific extended right for that object. #&gt;

$RootDSE = [ADSI]"LDAP://RootDSE"
$DefaultNamingContext = $RootDse.defaultNamingContext
$ConfigurationNamingContext = $RootDse.configurationNamingContext

###---Update Attributes

#Object type: user
$cmd = "dsacls '$DefaultNamingContext' /G '`"$Account`":CA;`"Replicating Directory Changes`";'"
Invoke-Expression $cmd
$cmd = "dsacls '$DefaultNamingContext' /G '`"$Account`":CA;`"Replicating Directory Changes All`";'"
Invoke-Expression $cmd

Validate

The output of the cmdlet if completed successfully you will find:

Allow mydomain\svc_aadsync           Replicating Directory Changes

 

Password Write-back:

To grant the service account password write-back permission on the directory you must allow the special permissions of Reset Password & Change Password extended rights.

Configure Password Write-back


###--------variables
$DN = "OU=Users,OU=Company,DC=mydomain,DC=com"
$Account = "mydomain\svc_aadsync"

###--------variables

&lt;# Switches used in cmds http://technet.microsoft.com/en-us/library/cc771151.aspx /I:S = Specifies the objects to which you are applying the permissions.'S' - The child objects only /G = Grants the permissions that you specify to the user or group CA = Control access If you do not specify {ObjectType | Property} to define the specific extended right for control access, this permission applies to all meaningful control accesses on the object; otherwise, it applies only to the specific extended right for that object. #&gt;

###---Update Attributes

#Object type: user

$cmd = "dsacls '$DN' /I:S /G '`"$Account`":CA;`"Reset Password`";user'"
Invoke-Expression $cmd
$cmd = "dsacls '$DN' /I:S /G '`"$Account`":CA;`"Change Password`";user'"
Invoke-Expression $cmd
$cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;pwdLastSet;user'"
Invoke-Expression $cmd
$cmd = "dsacls '$DN' /I:S /G '`"$Account`":WP;lockoutTime;user'"
Invoke-Expression $cmd

Validate

Run dsacls “\DCHostname.mydomain.com\OU=Users,OU=Company,DC=mydomain,DC=com” once again to find your entry:

Allow mydomain\svc_aadsync           Reset Password

 Check your AD MA credentials

  1. Open the ‘Synchronization Service’
  2. Choose ‘Connectors’
  3. Select the Connector with Type ‘Active Directory Domain Services’
  4. Right-Click ‘Properties’
  5. Configure Directory Partitions
  6. Select the radio button below

ADMA_SetCredentials

Add your credentials for the service account

ADMA_SetCredentials2

 

Category:
FIM, Identity and Access Management, Office 365
Tags:
, ,

Join the conversation! 24 Comments

  1. Amazing, you’ve really helped me out here

    Reply
  2. I’ve got this one bookmarked out of several on your site. Thanks for the great info!

    Reply
  3. Hi Simon,

    Does this still apply to Azure AD Connect or have things changed?

    Thanks

    Reply
    • Hi Peter,

      I believe that AAD Connect doesn’t create you an domain account with sufficient priviledges to the directory. So it will still be needed. It uses installers account for connection to AD DS Management Agent. You should still follow the above to add alternate creds and permissions. Please let me know if you have found otherwise. I have only done a very quick test in a lab with AAD Connect.

      Reply
  4. Hi Simon,

    Thanks for the article.

    In our organization planning to deploy the AAD connect and need to assign write permission for whole organization. I tried to run the command but it’s failed with “The parameter is in correct.

    DSACLS “DC=DOMAIN, DC=COM” /I:S /G'”Domain\account”:wp;proxyAddresses;user’

    Reply
    • Hi Kishore,

      This would just be a syntax error. This cmdlet is very temperamental, which is why I’ve provided it in a script to copy and paste with variables to replace with your ‘DN’ and ‘Service account’.

      In your above cmd it is missing a space between /G and the final parameter.
      It would literally translate to one big block of string
      /GDomain\account:wp;proxyAddresses;user
      instead of
      /G Domain\account:wp;proxyAddresses;user

      DSACLS ‘DC=Domain,DC=com’ /I:S /G ‘”Domain\Account”:wp;proxyAddresses;user’

      The script produces the best results.

      Arran

      Reply
    • PS – Copy/Paste out of the comment above powershell directly rather then using the script block, will use the incorrect curled double quoates which will not parse in powershell. So you would have to replace with straight quotes.

      Reply
  5. The password Writeback needs two additional lines:

    $cmd = “dsacls ‘$DN’ /I:S /G ‘`”$Account`”:WP;pwdLastSet;user'”
    Invoke-Expression $cmd
    $cmd = “dsacls ‘$DN’ /I:S /G ‘`”$Account`”:WP;lockoutTime;user'”
    Invoke-Expression $cmd

    Reply
  6. Hi Arran,
    thanks for the scripts, I was about to translate the docs to something similar when I found these. They saved a lot of time.

    Reply
  7. In the script for “Configure Hybrid Write-back”:

    $DN = “OU=Users,OU=Company,DC=mydomain,DC=com”

    Is that supposed to be the OU that the service account lives in? Or is this the OU that the service accounts needs permissions to? I’m not sure if I should just do DC=mydomain,DC=com in that case if the service account needs permissions to all of those potential mailboxes that will live in a variety of different OUs…

    Reply
    • Hi John,

      This variable is the for the the upper most point of your directory structure that you want the permission to apply to. You can do it from the root of your directory which would be DC=mydomain,DC=com for the simplest solution.

      Reply
  8. Oh ok great, thanks so much.

    Yeah I am using “Azure AD Connect”, and found that the Express install creates an MSOL account in AD, but doesn’t appear to grant it any permissions. I guess I’m supposed to run this script for that account so that the Directory Sync can occur…
    Although an O365 Fast Track advised this article/script was for AAD “Sync” and not “Connect”, but I cannot find documentation that suggest permissions are any different…

    Reply
  9. In the latest release it appears that there is a new attrib that the sync account needs access to.
    msDS-ExternalDirectoryObjectID

    After upgrading to the latest version, I was getting a permission error on the write-back of this attrib and adding the DACL fixed that problem.

    Reply
    • Hi Drew, I have an upgrade to the new version in the works atm. I will upgrade and add to the script.

      Thanks

      Reply
    • Hi Drew,

      Bit slow on the reply. This attribute writeback became available in December 2014 version (1.0.475.1202) of AAD Connect! The attribute msDS-ExternalDirectoryObjectID adds support for Office 365 applications using OAuth2 to access both, Online and On-Premises mailboxes in a Hybrid Exchange. Exchange 2013/16-only hybrid deployments configure OAuth authentication when using the Hybrid Configuration Wizard for Message Rights Management, Exchange In-place eDiscovery and Exchange In-place Archiving.

      Hybrid deployments of 2010/2007 still use the federation trust process by default.

      I’ll update the script.

      Thanks

      Reply
  10. The correct syntax to validate settings with dsacls is:
    dsacls \\DCHostname.mydomain.com\OU=Users,OU=Company,DC=mydomain,DC=com

    Reply
  11. Hi Mark,
    We did a custom installation and used a domain user service account we created.
    We then give the service account “Replicating Directory Changes” and “eplicating Directory Changes all” permission in AD on the domain.
    Now when we sync we get an error permission error and the msds-consistencyguid is empty

    Reply
    • I’m having this also. I can’t even find an option to add permission on that attribute in the GUI. I’ve had to give the ‘write all directory attributes’ permission, which isn’t ideal!

      Reply
      • Same issue here.

        After enabling msDS-ConsistencyGuid as sourceAnchor, writebacks to AD fail. This is understandable, since permission was never explicitly granted to the AD sync user to update the msDS-ConsistencyGuid attribute.

        What I can’t fathom is how to grant this permission since it is not exposed in the AD Users and Computers UI..

  12. For msDS-ConsistencyGuid……

    $accountName = “DOMAIN\svc_ADSync”
    $ForestDN = “DC=DOMAIN,DC=local”
    $cmd = “dsacls ‘$ForestDN’ /I:S /G ‘`”$accountName`”:WP;ms-ds-consistencyGuid;user'”
    Invoke-Expression $cmd

    Reply

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

%d bloggers like this: