Azure AD Connect – Using AuthoritativeNull in a Sync Rule

There is a feature in Azure AD Connect that became available in the November 2015 build 1.0.9125.0 (listed here), which has not had much fanfare but can certainly come in handy in tricky situations. I happened to be working on a project that required the DNS domain linked to an old Office 365 tenant to be removed so that it could be used in a new tenant. Although the old tenant was no long used for Exchange Online services, it held onto the domain in question, and Azure AD Connect was being used to synchronise objects between the on-premise Active Directory and Azure Active Directory.
Trying to remove the domain using the Office 365 Portal will reveal if there are any items that need to be remediated prior to removing the domain from the tenant, and for this customer it showed that there were many user and group objects that still had the domain used as the userPrincipalName value, and in the mail and proxyAddresses attribute values. The AuthoritativeNull literal could be used in this situation to blank out these values against user and groups (ie. Distribution Lists) so that the domain can be released. I’ll attempt to show the steps in a test environment, and bear with me as this is a lengthy blog.
Trying to remove the domain listed the items needing attention, as shown in the following screenshots:

This report showed that three actions are required to remove the domain values out of the attributes:

  • userPrincipalName
  • proxyAddresses
  • mail

userPrincipalName is simple to resolve by changing the value in the on-premise Active Directory using a different domain suffix, then synchronising the changes to Azure Active Directory so that the default or another accepted domain is set.
Clearing the proxyAddresses and mail attribute values is possible using the AuthoritativeNull literal in Azure AD Connect. NOTE: You will need to assess the outcome of performing these steps depending on your scenario. For my customer, we were able to perform these steps without affecting other services required from the old Office 365 tenant.
Using the Synchronization Rules Editor, locate and edit the In from AD – User Common rule. Editing the out-of-the-box rules will display a message to suggest you create an editable copy of the rule and disable the original rule which is highly recommended, so click Yes.

The rule is cloned as shown below and we need to be mindful of the Precedence value which we will get to shortly.

Select Transformations and edit the proxyAddresses attribute, set the FlowType to Expression, and set the Source to AuthoritativeNull.

I recommend setting the Precedence value in the new cloned rule to be the same as the original rule, in this case value 104. Firstly edit the original rule to a value such as 1001, and you can also notice the original rule is already set to Disabled.

Set the cloned rule Precedence value to 104.

Prior to performing a Full Synchronization run profile to process the new logic, I prefer and recommend to perform a Preview by selecting a user affected and previewing a Full Synchronization change. As can be seen below, the proxyAddresses value will be deleted.

The same process would need to be done for the mail attribute.
Once the rules are set, launch the following PowerShell command to perform a Full Import/Full Synchronization cycle in Azure AD Connect:

  • Start-ADSyncSyncCycle -PolicyType Initial

Once the cycle is completed, attempt to remove the domain again to check if any other items need remediation, or you might see a successful domain removal. I’ve seen it take upto 30 minutes or so before being able to remove the domain if all remediation tasks have been completed.

There will be other scenarios where using the AuthoritativeNull literal in a Sync Rule will come in handy. What others can you think of? Leave a description in the comments.

Active Directory – What are Linked Attributes?

A customer request to add some additional attributes to their Azure AD tenant via Directory Extensions feature in the Azure AD Connect tool, lead me into further investigation. My last blog here set out the customer request, but what I didn’t detail in that blog was one of the attributes they also wanted to extend into Azure AD was directReports, an attribute they had used in the past for their custom built on-premise applications to display the list of staff the user was a manager for. This led me down a rabbit hole where it took a while to reach the end.
With my past experience in using Microsoft Identity Manager (formally Forefront Identity Manager), I knew directReports wasn’t a real attribute stored in Active Directory, but rather a calculated value shown using the Active Directory Users and Computers console. The directReports was based on the values of the manager attribute that contained the reference to the user you were querying (phew, that was a mouthful). This is why directReport and other similar type of attributes such as memberOf were not selectable for Directory Extension in the Azure AD Connect tool. I had never bothered to understand it further than that until the customer also asked for a list of these type of attributes so that they could tell their application developers they would need a different technique to determine these values in Azure AD. This is where the investigation started which I would like to summarise as I found it very difficult to find this information in one place.
In short, these attributes in the Active Directory schema are Linked Attributes as detailed in this Microsoft MSDN article here:
Linked attributes are pairs of attributes in which the system calculates the values of one attribute (the back link) based on the values set on the other attribute (the forward link) throughout the forest. A back-link value on any object instance consists of the DNs of all the objects that have the object’s DN set in the corresponding forward link. For example, “Manager” and “Reports” are a pair of linked attributes, where Manager is the forward link and Reports is the back link. Now suppose Bill is Joe’s manager. If you store the DN of Bill’s user object in the “Manager” attribute of Joe’s user object, then the DN of Joe’s user object will show up in the “Reports” attribute of Bill’s user object.
I then found this article here which further explained these forward and back links in respect of which are writeable and which are read-only, the example below referring to the linked attributes member/memberOf:
Not going too deep into the technical details, there’s another thing we need to know when looking at group membership and forward- and backlinks: forward-links are writable and backlinks are read-only. This means that only forward-links changed and the corresponding backlinks are computed automatically. That also means that only forward-links are replicated between DCs whereas backlinks are maintained by the DCs after that.

The take-out from this is the value in the forward-link can be updated, the member attribute in this case, but you cannot update the back-link memberOf. Back-links are always calculated automatically by the system whenever an attribute that is a forward-link is modified.
My final quest was to find the list of linked attributes without querying the Active Directory schema which then led me to this article here, which listed the common linked attributes:

  • altRecipient/altRecipientBL
  • dLMemRejectPerms/dLMemRejectPermsBL
  • dLMemSubmitPerms/dLMemSubmitPermsBL
  • msExchArchiveDatabaseLink/msExchArchiveDatabaseLinkBL
  • msExchDelegateListLink/msExchDelegateListBL
  • publicDelegates/publicDelegatesBL
  • member/memberOf
  • manager/directReports
  • owner/ownerBL

There is further, deeper technical information about linked attributes such as “distinguished name tags” (DNT) and what is replicated between DCs versus what is calculated locally on a DC, which you can read in your own leisure in the articles listed throughout this blog. But I hope the summary is enough information on how they work.

Azure AD Connect – Multi-valued Directory Extensions

I happened to be at a customer site working on an Azure project when I was asked to cast a quick eye over an issue they had been battling with. They had an Azure AD Connect server synchronising user and group objects between their corporate Active Directory and their Azure AD, used for Office 365 services and other Azure-based applications. Their intention was to synchronise some additional attributes from their Active Directory to Azure AD so that they could be used by some of their custom built Azure applications. These additional attributes were a combination of standard Active Directory attributes as well as some custom schema extended attributes.
They were following the guidance from the Microsoft article listed here. As mentioned in the article, ‘Directory extensions allows you to extend the schema in Azure AD with your own attributes from on-premises Active Directory‘. When running the Azure AD Connect installation wizard and trying to find the attributes in the dropdown list, some of their desired attributes were not listed as shown below. An example attribute they wanted to synchronise was postalAddress which was not in the list.

After browsing the dropdown list trying to determine why some of their desired attributes were missing, I noticed multi-valued attributes were missing, such as the description standard Active Directory attribute which I knew was a multi-valued attribute.

I checked the schema in Active Directory and it was clear the postalAddress attribute was multi-valued.

The customer pointed me back to the Microsoft article which clearly stated that the valid attribute candidates included multi-valued strings and binary attributes. With the time I had remaining, I reviewed their Azure AD Connect implementation and tried a few techniques in the synchronisation service such as:

  • refreshing the schema of the on-premise Active Directory management agent
  • enabled the attribute in the properties of the on-premise Active Directory management agent as by default it was not checked

I next checked the Azure AD Connect release notes (here) and quickly noticed the cause of the issue which had to do with the version of Connect they were using, which was a few releases old. It was from version released in April 2016 which added support for multi-valued attributes to Directory Extensions, while the version running by the customer was from only a couple of months earlier.
After upgrading Azure AD Connect to currently released version, the customer was able to successfully select these multi-valued attributes.

Microsoft are very good at keeping the release notes upto date as new versions of Azure AD Connect are released, currently every 1-2 months. The lessons learned are to check the release notes to view the new features and bug fixes in releases to determine if you need to upgrade the tool.

Azure Active Directory Connect high-availability using ‘Staging Mode’

With the Azure Active Directory Connect product (AAD Connect) being announced as generally available to the market (more here, download here), there is a new feature available that will provide a greater speed of recovery of the AAD Sync component. This feature was not available with the previous AAD Sync or DirSync tools and there is little information about it available in the community, so hopefully this model can be considered for your synchronisation design.

Even though the AAD Sync component within the AAD Connect product is based on the Forefront Identity Manager (FIM) synchronisation service, it does not take on the same recovery techniques as FIM. For AAD Sync, you prepare two servers (ideally in different data centres) and install AAD Connect. Your primary server would be configured to perform the main role to synchronise identities between your Active Directory and Azure Active Directory, and the second server installed in much the same way but configured with the setting ‘enable staging mode’ being selected. Both servers are independent and do not share any components such as SQL Server, and the second server is performing the same tasks as the primary except for the following:

  • No exports occur to your on-premise Active Directory
  • No exports occur to Azure Active Directory
  • Password synchronisation and password writeback are disabled.

Should the primary server go offline for a long period of time or become unrecoverable, you can enable the second server by simply running the installation wizard again and disabling staging mode. When the task schedule next runs, it will perform a delta import and synchronisation and identify any differences between the state of the previous primary server and the current server.

Some other items you might want to consider with this design.

  • Configure the task schedule on the second server so that it runs soon after the primary server completes. By default the task schedule runs every 3 hours and launches at a time which is based on when it was installed, therefore the second server task schedule can launch up to a few hours after the primary server runs. Based on the average amount of work the primary server takes, configure the task schedule on the second server to launch say 5-10 minutes later
  • AAD Sync includes a tool called CSExportAnalyzer which displays changes that are staged to be exported to Active Directory or Azure Active Directory. This tool is useful to report on pending exports while the server is in ‘staging mode’
  • Consider using ‘custom sync groups’ which are located in your Active Directory domain. The default installation of the AAD Sync component will create the following groups locally on the server: ADSyncAdmins, ADSyncOperators, ADSyncBrowse and ADSyncPasswordSet. With more than one AAD Sync server, these groups need to be managed on the servers and kept in sync manually. Having the groups in your Active Directory will simplify this administration.

    NOTE: This feature is not yet working with the current AAD Connect download and this blog will be updated when working 100%.

The last two items will be detailed in future blogs.

AADSync – AD Service Account Delegated Permissions

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:

[code language=”PowerShell”]
import-module ActiveDirectory
$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


<# Switches used in cmds /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
#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



Use DSACLS to validate your settings
dsacls “\\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”]
$Account = "mydomain\svc_aadsync"


&lt;# Switches used in cmds /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



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”]

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


&lt;# Switches used in cmds /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



Run dsacls “\\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


Add your credentials for the service account



ADSync Cmdlets

I really enjoyed the later versions of DirSync which included a native PowerShell Module to execute sync engine tasks and show some global configuration settings. Now that we are looking at moving over to the new tool AADSync there is a new module installed but with very little reference to it available on the web at time of writing this blog. I’ve outlined the name of the cmdlets below but the ‘Get-Help’ doesn’t offer any description or examples as yet so I’ve included some in this post.



From browsing over these cmdlets we can see that there is much more functionality available to use then there was in the DirSync module equivalent. If we take nothing else away from this list it’s that we can now not just run the engine but configure the tool itself.


Here are some nice examples of what we can achieve now that ADSync Module is available

Example 1

Scenario: Create a custom rule to not sync users with X121Address=NoSync

[code language=”PowerShell”]
#Get the AD Connector
$ADConnector = (Get-ADSyncConnector | ? {$_.Type -eq "AD"})
#Create the Scope Filter Object
$scopefilter = New-Object Microsoft.IdentityManagement.PowerShell.ObjectModel.ScopeCondition
$scopefilter.Attribute = "x121Address"
$scopefilter.ComparisonValue = "NoSync"
$scopefilter.ComparisonOperator = "EQUAL"
#Create the Attribute Flow
$AttributeFlowMappings = New-Object Microsoft.IdentityManagement.PowerShell.ObjectModel.AttributeFlowMapping
$AttributeFlowMappings.Source = "True"
$AttributeFlowMappings.Destination = "cloudFiltered"
$AttributeFlowMappings.FlowType = "constant"
$AttributeFlowMappings.ExecuteOnce = $False
$AttributeFlowMappings.ValueMergeType = "Update"
#Add the Scope Filter to a Scope Group
$scopefiltergroup = New-Object Microsoft.IdentityManagement.PowerShell.ObjectModel.ScopeConditionGroup
#Create the Rule
$GUID = $ADConnector.Identifier.Guid
Add-ADSyncRule -Connector $GUID -Name "In from AD – User DoNotSyncFilter" -SourceObjectType user -TargetObjectType person -Direction inbound -AttributeFlowMappings $AttributeFlowMappings -LinkType Join -Precedence "1" -ScopeFilter $scopefiltergroup

Example 2

Scenario: Add Additional Attributes to be imported from Active Directory

[code language=”PowerShell”]$ADConnector = (Get-ADSyncConnector | ? {$_.Type -eq "AD"}) | Add-ADSyncConnectorAttributeInclusion -AttributeTypes employeeID[/code]

Example 3

Scenario: Adjust the attribute flow of UPN so that AD Mail Attribute flows to UPN in Office 365

[code language=”PowerShell”]
#Define the Flow Mapping
$Mapping = New-object Microsoft.IdentityManagement.PowerShell.ObjectModel.AttributeFlowMapping
$Mapping.Source = "mail"
$Mapping.Destination = "userPrincipalName"
$Mapping.FlowType = "Direct"
$Mapping.ExecuteOnce = $false
$Mapping.Expression = $null
$Mapping.ValueMergeType = "update"
#Get the AD Connector
$ADConnector = (Get-ADSyncConnector | ? {$_.Type -eq "AD"})
$GUID = $ADConnector.Identifier.Guid
#Create the Rule with higher precedence
Add-ADSyncRule -Connector $GUID -Direction Inbound -Name "In From AD – User UPN Flow" -SourceObjectType user -TargetObjectType person -AttributeFlowMappings $Mapping -Description "Map Mail to UPN in the Metaverse" -LinkType Join -Precedence 99

Here is the user sync’d to the Metaverse without Attribute Flow Transformation. (Note the UPN value)


We run the PowerShell and preview the results


Commit the change and check with a Metavere search


Let’s check Azure Active Directory. It has the prefix.

Happy days!

Some of these cmdlets seem to still need a little TLC. I found that they didn’t give the desired results although committing in the shell. We all love agile, so give it time and they should get fixed up, and there is always the GUI if you really have too.

Follow ...+

Kloud Blog - Follow