Last week, I began working with a customer that was experiencing what appeared to be a significant amount of updates to a certain group of objects in the local Active Directory. These objects were being imported from another forest as contacts, yet found themselves being updated very frequently by the local AAD Connect instance.
Why could this be?
Many organizations need to share contact objects so that users can locate others across organizations. One of the more common tools to do this is GALSync.
When contacts are synchronized between Active Directory forests and those forests are synchronized to Office 365, one of the things that falls out is the Office 365 stamps a cloud x500 address (x500:o=ExchangeLabs) on objects. Exchange has been using the x500 address for routing…
Now, that being said, the goal of AAD Connect is to synchronize objects. The idea of synchronization is that the objects are–you guessed it–synchronous. They’re the same on both sides. You put a change in one spot, and it gets replicated to the other spot.
Where this becomes tricky is objects that are being touched by autonomous systems outside of AAD Connect and the local directory service operations. When it comes to synchronized identity, AAD Connect is synchronizing the local changes you make in your directory up to Azure AD, and then bringing down any of the common write-back attributes (including proxyAddresses), if you selected the Exchange Hybrid checkbox in AAD Connect setup.
AAD Connect does this black magic by maintaining a stateful table of object properties and their current states (as it knows them). On its sync cycle, it looks at the directory API for changes since the time it last executed and then processes updates for only the objects and specific attributes that have changed.
GALSync also does this same stateful inspection process, capturing changes, on the objects that it is maintaining. The result? Two directory engines constantly at war with changes the other is making.
When this scenario happens, you’ll frequently see AAD Connect attempting an add operation on the proxyAddresses attribute for contact objects located in the organizational unit that the GALSync operation is writing contacts.
Fortunately, there’s a pretty simple fix to this this–exclude the OU where GALSync objects are stored from being written back.
Things you’ll need:
- administrative Access to the Azure AD Connect Server, which only makes sense as this is an AAD Connect post
- the full distinguishedName value of the organizational unit where the GALSync contacts from the remote forest are stored, in the form of OU=GALsync OU,dc=domain,dc=tld. You can find this by launching Active Directory Users and Computers and looking on the Attribute Editor tab of the properties sheet for the attribute distinguishedName. Double-click and copy this value.
Here we go!
Clone the default Out-to-AD Contact Exchange Hybrid rule
In this step, we’re going to duplicate the original AAD connect rule that governs this particular writeback and scope out the GALSync OU.
- Launch the AAD Connect Synchronization Rules Editor.
- Under Direction, select Outbound. Under Connector, select your local AD Domain where the contact objects are stored–NOT the onmicrosoft.com domain.
- Select the rule Out to AD – Contact Exchange Hybrid and click Edit.
- Select Yes to disable the original rule and create a new, editable copy. If you don’t do this, your change will be wiped out during the next AAD Connect upgrade cycle.
- Edit the Precedence for the rule, making it a lower number than where the original rule exists (you’ll likely need to pick something in the low 100’s or high 90’s). The precedence value cannot be already in use by an existing rule (either enabled or disabled). In this example, I’m choosing 95. Click Next to advance to the Scoping filter page.
- Click Add group.
- Select Add clause, and then from the drop-downs select:
Value: distinguishedName value for the GALSync OU. Copy and past the DN value exactly as it is in ADUC.
- Click Save.
- If prompted, click OK.
What you’ve effectively done is exclude the GALSync OU in your forest from AAD Connect writeback.
Start a full sync
Finally, you’ll want to run a full AAD Connect cycle to trigger the rules to take effect. If you didn’t see the prompt above about the next cycle triggering a full sync, you’ll want to do this part manually.
- Launch an elevated PowerShell prompt.
Start-ADSyncSyncCycle -PolicyType Initial
- Wait for magic.