18th of December, 2014 / Arran Peterson / 26 Comments

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:

Write Access to User, Contact, Groups Attributes – Hybrid Exchange Deployment
Password Changes – Password Synchronisation
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:

[code language=”PowerShell”]
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

###—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

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:

[code language=”PowerShell”]
###——–variables
$Account = "mydomain\svc_aadsync"

###——–variables

<# 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. #>

$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

[/code]

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

[code language=”PowerShell”]

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

###——–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 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. #>

###—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

[/code]

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

Open the ‘Synchronization Service’
Choose ‘Connectors’
Select the Connector with Type ‘Active Directory Domain Services’
Right-Click ‘Properties’
Configure Directory Partitions
Select the radio button below

Add your credentials for the service account

Category:

FIM, Identity and Access Management, Office 365

Tags:

AAD, AADSync, hybrid exchange

Join the conversation! 26 Comments

Graham Lindsay
11th of March, 2015 at 8:02 am

Amazing, you’ve really helped me out here
Chris Blackburn
16th of July, 2015 at 8:02 am

I’ve got this one bookmarked out of several on your site. Thanks for the great info!
- Simon Waight
  16th of July, 2015 at 8:49 am
  
  Thanks for the positive feedback Chris!
petersdahl
16th of September, 2015 at 8:02 pm

Hi Simon,

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

Thanks
- Arran Peterson
  6th of October, 2015 at 2:26 pm
  
  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.
Kishore
20th of October, 2015 at 8:00 pm

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’
- Arran Peterson
  22nd of October, 2015 at 9:20 pm
  
  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
- Arran Peterson
  22nd of October, 2015 at 9:29 pm
  
  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.
Chris Lehr (@chrislehratx)
28th of October, 2015 at 9:17 am

FYI, your password writeback is missing two options:
https://msdn.microsoft.com/en-us/library/azure/dn903642.aspx?f=255&MSPPError=-2147217396#BKMK_e

https://social.msdn.microsoft.com/Forums/en-US/4556b08e-103a-4c99-9f97-bba243e6987f/azure-ad-sync-version-1004940501-failing-with-failed-getting-registry-value?forum=WindowsAzureAD

Write Permissions on“lockoutTime”, and Write Permissions on “pwdLastSet”.
Chris Lehr (@chrislehratx)
29th of October, 2015 at 1:10 am

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
- Arran Peterson
  29th of October, 2015 at 12:08 pm
  
  Thanks Chris! I will update the blog post. Password Writeback was still in preview when I wrote this and didn’t get to test it extensively.
Rasmus
12th of November, 2015 at 4:38 am

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.
John Q
9th of December, 2015 at 2:33 am

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…
- Arran Peterson
  9th of December, 2015 at 9:12 am
  
  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.
John Q
9th of December, 2015 at 9:31 am

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…
Drew
27th of February, 2016 at 2:51 am

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.
- Arran Peterson
  29th of February, 2016 at 9:16 am
  
  Hi Drew, I have an upgrade to the new version in the works atm. I will upgrade and add to the script.
  
  Thanks
- Arran Peterson
  20th of March, 2016 at 9:07 pm
  
  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
Michał Patrzałek
2nd of September, 2016 at 4:52 pm

The correct syntax to validate settings with dsacls is:
dsacls \\DCHostname.mydomain.com\OU=Users,OU=Company,DC=mydomain,DC=com
Mike
2nd of June, 2017 at 11:48 pm

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
- Tom Anderson
  30th of June, 2017 at 12:43 pm
  
  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!
  - David Roux
    7th of July, 2017 at 3:04 am
    
    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..
Simon Payne
27th of July, 2017 at 5:39 pm

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
- petersedahl
  16th of November, 2017 at 10:52 pm
  
  Adding some more information to the post. It would be nice, if Arran updated the post with the latest changes 🙂
  
  Granting your Azure AD Connect Service Account permissions to write to the mS-DS-ConsistencyGuid attribute see:
  https://dirteam.com/sander/2017/08/24/azure-ad-connect-objectguid-vs-ms-ds-consistencyguid-part-2/
Allan
17th of November, 2017 at 5:18 am

Thanks for the information you’ve published here, it’s been a great reference point for Azure AD Connect permissions for the past few years!

I’ve just been working through the password write back stuff and noticed that I needed these additional permission for the management agent credentials: Read account restrictions, Read logon information, and Read group membership.

May be a case of previous configuration gone wrong for AD permissions, or something changed very recently that it needed additional read rights.

Just contributing back incase anyone get’s stuck on the self-service password reset setup!
petersedahl
3rd of January, 2018 at 7:32 pm

Aaron Guilmette from Microsoft posted a script with all the required settings:

https://gallery.technet.microsoft.com/AD-Advanced-Permissions-49723f74

AAD Connect Advanced Permissions
Use this script to configure advanced AAD Connect permissions for the following features: Device WriteBack Exchange Hybrid WriteBack Office 365 Group WriteBack Password Hash Sync (Replicating Directory Changes / Replicating Directory Changes All) Password WriteBack ms-DS-Consis

Comments are closed.