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 minnelli.net 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 onmicrosoft.com 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.

shane_fisher_kloud_telstraid

AAD Connect – Using Directory Extensions to add attributes to Azure AD

I was recently asked to consult on a project that was looking at the integration of Workday with Azure AD for Single Sign On. One of the requirements for the project, is that staff number be used as the NameID value for authentication.

This got me thinking as the staff number wasn’t represented in Azure AD at all at this point, and in order to use it, we will need to get it to Azure AD.

These days, this is fairly easy to achieve by using the “Directory Extensions” option in Azure AD Connect. Directory Extensions allows us to synchronise additional attributes from the on-premises environment to Azure AD.

Launch the AADC configuration utility and select “Customize synchronisation options”

aadc_config_p1

Enter your Azure AD global administrator credentials to connect to Azure AD.

aadc_config_p2

Once authenticated to Azure AD, click next through the options until we get to “Optional Features” and select “Directory extension attribute sync”

aadc_config_p3

There are two additional attributes that I want to make use of in Azure AD, employeeID and employeeNumber. As such, I have selected these attributes from the list.

aadc_config_p4

Completing the wizard will configure AAD Connect to sync the requested attributes to Azure AD. A full synchronisation is required post configuration and can be launched either from the configuration wizard itself, or from powershell using the following cmdlet.

Start-ADSyncSyncCycle -PolicyType initial

Once the sync was complete, I went to validate that my new attributes were visible in Azure AD. They weren’t!

After some digging, I found that my attributes had in fact synced successfully, they just weren’t in the location I wanted them to be. My attributes had synced as follows:

Source AD                                                                    Azure AD

employeeNumber                                                         extension_tenantGUID_employeeNumber

employeeID                                                                    extension_tenantGUID_employeeID

 

So… This wasn’t exactly what I was looking for, but at least the theory works in practice.

Fortunately, this problem is also easy to fix. We can configure AAD Connect to synchronise to a different target attribute using the synchronisation rules editor.

When we configured Directory extensions above, a new rule was created in the synchronisation rules editor for “User Directory Extension”. If we edit this rule, we can see the source and target attributes as they are currently configured, and we are able to make changes to these rules.

Before making any changes, follow the received prompt guiding you not to change the existing rule, but instead clone the current rule and then edit the clone. The original rule will be disabled during the cloning process.

As seen below, I have now configured the employeeNumber and employeeID attributes to sync to extensionattribute5 and 6 respectively.

aadc_config_p6

A full synchronisation is required before the above changes will take effect. We are now in a position to configure Single Sign On settings in Azure AD, using extensionAttribute5 as the NameID value.

I hope this helps some of you out there.

Cheers,

Shane.

AAD Connect – Updating OU Sync Configuration Error: stopped-deletion-threshold-exceeded

I was recently working with a customer on cleaning up their Azure AD Connect synchronisation configuration.

Initially, the customer had enabled sync for all OU’s in the Forest (As a lot of companies do),  and had now come to a point in maturity where they could look at optimising the solution.

We identified an OU with approximately 7000 objects which did not need to be synced.

So…

I logged onto the AAD Connect server and launched the configuration utility. After authenticating with my Office365 global admin account, I navigated to the OU sync configuration and deselected the required OU.

At this point, everything appeared to be working as expected. The configuration utility saved my changes successfully and started a delta sync based on the checkbox which was automatically selected in the tool. The delta sync also completed successfully.

I went to validate my results, and noticed that no changes had been made, and no objects had been deleted from Azure AD. ????

It occurred to me that a full sync was probably required in order to force the deletion to occur. I kicked off a full synchronisation using the following command.

Start-ADSyncSyncCycle -PolicyType initial

When the sync cycle reach the export phase however, I noticed that the task had thrown an error as seen below:

aadc_deletion_error

It would seem I’m trying to delete too many objects. Well that does make sense considering we identified 7000 objects earlier. We need to disable the Export deletion threshold before we can move forward!

Ok, so now we know what we have to do! What does the order of events look like? See below:

  1. Update OU synchronisation configuration in Azure AD Connect utility
  2. Delect the run synchronisation option before saving the AADC utility
  3. Run the following powershell command to disable the deletion threshold
    1. Disable-ADSyncExportDeletionThreshold
  4. Run the following powershell command to start the full synchronisation
    1. Start-ADSyncSyncCycle -PolicyType initial
  5. Wait for the full synchronisation cycle to complete
  6. Run the following powershell command to disable the deletion threshold
    1. Enable-ADSyncExportDeletionThreshold

I hope this helps save some time for some of you out there.

Cheers,

Shane.

Complex Mail Routing in Exchange Online Staged Migration Scenario

Notes From the Field:

I was recently asked to assist an ongoing project with understanding some complex mail routing and identity scenario’s which had been identified during planning for an upcoming mail migration from an external system into Exchange Online.

New User accounts were created in Active Directory for the external staff who are about to be migrated. If we were to assign the target state, production email attributes now, and create the exchange online mailboxes, we would have a problem nearing migration.

When the new domain is verified in Office365 & Exchange Online, new mail from staff already in Exchange Online would start delivering to the newly created mailboxes for the staff soon to be onboarded.

Not doing this, will delay the project which is something we didn’t want either.

I have proposed the following in order to create a scenario whereby cutover to Exchange Online for the new domain is quick, as well as not causing user downtime during the co-existence period. We are creating some “co-existence” state attributes on the on-premises AD user objects that will allow mail flow to continue in all scenarios up until cutover. (I will come back to this later).

generic_exchangeonline_migration_process_flow

We have configured the AD user objects in the following way

  1. UserPrincipalName – username@localdomainname.local
  2. mail – username@mydomain.onmicrosoft.com
  3. targetaddress – username@mydomain.com

We have configured the remote mailbox objects in the following way

  1. mail – username@mydomain.onmicrosoft.com
  2. targetaddress – username@mydomain.com

We have configured the on-premises Exchange Accepted domain in the following way

  1. Accepted Domain – External Relay

We have configured the Exchange Online Accepted domain in the following way

  1. Accepted Domain – Internal Relay

How does this all work?

Glad you asked! As I eluded to earlier, the main problem here is with staff who already have mailboxes in Exchange Online. By configuring the objects in this way, we achieve several things:

  1. We can verify the new domains successfully in Office365 without impacting existing or new users. By setting the UPN & mail attributes to @mydomain.onmicrosoft.com, Office365 & Exchange Online do not (yet) reference the newly onboarded domain to these mailboxes.
  2. By configuring the accepted domains in this way, we are doing the following:
    1. When an email is sent from Exchange Online to an email address at the new domain, Exchange Online will route the message via the hybrid connector to the Exchange on-premises environment. (the new mailbox has an email address @mydomain.onmicrosoft.com)
    2. When the on-premises environment receives the email, Exchange will look at both the remote mailbox object & the accepted domain configuration.
      1. The target address on the mail is configured @mydomain.com
      2. The accepted domain is configured as external relay
      3. Because of this, the on-premises exchange environment will forward the message externally.

Why is this good?

Again, for a few reasons!

We are now able to pre-stage content from the existing external email environment to Exchange Online by using a target address of @mydomain.onmicrosoft.com. The project is no longer at risk of being delayed ! 🙂

At the night of cutover for MX records to Exchange Online (Or in this case, a 3rd party email hygiene provider),  We are able to use the same powershell code that we used in the beginning to configure the new user objects to modify the user accounts for production use. (We are using a different csv import file to achieve this).

Target State Objects

We have configured the AD user objects in the following way

  1. UserPrincipalName – username@mydomain.com
  2. mail – username@mydomain.com
  3. targetaddress – username@mydomain.mail.onmicrosoft.com

We have configured the remote mailbox objects in the following way

  1. mail
    1. username@mydomain.com (primary)
    2. username@mydomain.onmicrosoft.com
  2. targetaddress – username@mydomain.mail.onmicrosoft.com

We have configured the on-premises Exchange Accepted domain in the following way

  1. Accepted Domain – Authoritive

We have configured the Exchange Online Accepted domain in the following way

  1. Accepted Domain – Internal Relay

NOTE: AAD Connect sync is now run and a manual validation completed to confirm user accounts in both on-premises AD & Exchange, as well as Azure AD & Exchange Online to confirm that the user updates have been successful.

We can now update DNS MX records to our 3rd party email hygiene provider (or this could be Exchange Online Protection if you don’t have one).

A final synchronisation of mail from the original email system is completed once new mail is being delivered to Exchange Online.

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 1.1.130.0 released in April 2016 which added support for multi-valued attributes to Directory Extensions, while the version running by the customer was 1.1.110.0 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.

Configuring Proxy for Azure AD Connect V1.1.105.0 and above

My colleague David Ross has written a previous blog about configuring proxy server settings to allow Azure AD Sync (the previous name of Azure AD Connect) to use a proxy server.

Starting with version 1.1.105.0, Azure AD Connect has completely changed the configuration steps required to allow the Azure AD Connect configuration wizard and Sync. Engine to use a proxy.

I ran into a specific proxy failure scenario that I thought I’d share to provide further help.

My Azure AD Connect (v.1.1.110.0) installation reached the following failure at the end of the initial installation wizard:

Installfailure1

The trace log just stated the following:

Apply Configuration Page: Failed to configure directory extension (True). Details: System.Management.Automation.CmdletInvocationException: user_realm_discovery_failed: User realm discovery failed —> Microsoft.IdentityManagement.PowerShell.ObjectModel.SynchronizationConfigurationValidationException: user_realm_discovery_failed: User realm discovery failed


In this environment, I had the following environmental components:

  • The AAD Connect software was going to operate under a service account
  • All Internet connectivity was through a proxy server which required authentication
  • Windows Server 2012 R2 platform
  • Two factor authentication was enabled for O365 Admin accounts

Previously, in order to get authentication working for O365, I set the proxy server settings in Internet Explorer.  I tested browsing and it appeared fine.  I also had to add the following URLs to the Internet Explorer’s ‘Trusted Sites’ to allow the new forms based authentication (which allowed the second factor to be entered) to work properly with the Azure AD connect wizard:

So even though my Internet proxy appeared to be working under my admin. account, and Office 365 was authenticating properly during the O365 ‘User Sign-In’ screen, I was still receiving a ‘User Realm Discovery’ error message at the end of the installation.

This is when I turned to online help and I found this Microsoft article on the way Azure AD Connect now handles proxy authentication.  It can be found here and is by and large an excellent guide.

Following Microsoft’s guidance, I ran the following proxy connectivity command and verified my proxy server was not blocking my access:

Invoke-WebRequest -Uri https://adminwebservice.microsoftonline.com/ProvisioningService.svc

Installfailure2

So that appeared to be fine and not causing my issue.  Reading further, the guidance in the article had previously stated at the start that my ‘machine.config’ file had to be properly configured.  When I re-read that, I wondered aloud “what file?”.  Digging deeper into the guidance, I ran into this step.

It appears that Azure AD connect now uses Modern Authentication to connect to Office 365 during the final part of the configuration wizard, and that the ‘web.config’ file has to be modified with your proxy server settings for it to complete properly.

Since the environment here requires a proxy which requires authentication, I added the following to the end of the file:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config

All new required text are within the ‘<system.net>‘ flags.   NOTE:  The guidance from Microsoft states that the new code has to be ‘at the end of the file’, but be sure to place it BEFORE the text: ‘</configuration>’:

Installfailure4

I saved the file, and then clicked ‘Retry’ button on my original ‘user realm discovery failure’ message (thankfully not having to attempt a completely new install of Azure AD connect) and the problem was resolved.

Hope this helps!

 

Azure AD Connect – “The specified domain does not exist or cannot be contacted” when adding an untrusted AD forest

I ran into a little issue while on site with a customer who required AAD Connect to be configured for use in a multi-forest environment with three forests. There was a forest trust between two of the forests, however the third forest did not have any trusts in place. Prior to implementing this solution, we ran up a test environment to do a run through and document the steps required for an implementation plan.

The test environment consisted of three Windows Server 2012 AD forests all at 2012 functional level – kloudy.net, kloudysky.net and kloudless.net and a single Office 365 tenant, MyHappyKloudTenant.onmicrosoft.com.

I installed the AAD Connect application into the kloudy.net forest, and proceeded to run through the wizard. All was well until I came to adding the untrusted forest, kloudless.net to the “configured directory” list. I could add the trusted forest (kloudysky.net) easily enough, however when I attempted to add kloudless.net I received the helpful little error message “The specified domain does not exist or cannot be contacted”.

“That’s interesting” I thought. I know I created the domain, so it exists. And I can ping the domain using the FQDN, so it’s definitely resolvable and contactable.

Specified domain does not exist

Authenticating to the forest with either the NetBIOS name format, KLOUDLESS\jason or the user principal name (UPN) format, jason@kloudless.net ended up with the same error “The specified domain does not exist or cannot be contacted”. After some poking around (and input from a helpful architect on site) a solution was found.

In the USERNAME field, use the FQDN of the authenticating domain instead of the NetBIOS name, so in my case it was kloudless.net\jason instead of KLOUDLESS\jason

Now, my colleagues have suggested that this issue may be an environmental one relating to name resolution, and I tend to agree.

In my case, each domain had its own integrated DNS with secondary zones for each of the other domain names, so kloudy.net had integrated DNS with secondary zones for kloudless.net and kloudysky.net. And so forth for each of the forests. Name resolution was functional to all domains from all domains.

Either way, in the case of my test environment, using the FQDN of the authenticating forest provides the outcome we were looking for, and I hope that if you happen to come across this issue, I’ve saved you a little bit of time.

Jason

Consideration for multi-forest synchronisation with a resource Exchange forest

Azure AD Connect has come a long way from the early days of DirSync, and multi-forest directory synchronisation is a great step forward, with the ability to synchronise an account forest and Exchange resource forest to Office 365 meeting the needs of many organisations.

Joining linked mailboxes

To provide synchronisation of an account forest and an Exchange resource forest AAD Connect matches accounts across forests using the same attribute used by Exchange, matching the linked mailbox account’s msExchMasterAccount attribute value with the objectSID value of the account in the other forest to join them. I’ve represented this flow here:

Linked mailbox matched with authentication account

This joining process is great for ensuring a single identity is synchronised to Azure AD where you have linked mailboxes going on and this works for most organisations out there.

Houston, we have a problem.

I’m going to draw out a scenario:

AAD Connect is installed and configured to synchronise two AD domains as shown above, and Exchange hybrid is configured with the on-premises Exchange Organisation in the resource forest. All the on-premises mailboxes have been moved to Exchange Online, and an Exchange 2013 server remains on-premises to provide administrative capability(when an account in Azure AD is synchronised from on-premises, the on-premises user object is the source of authority and so it is not possible to update values such proxy addresses in Azure AD).

Now. A new starry-eyed employee joins the organisation, at which point an account is created in the account forest, let’s call it newEmployee@account.local. As part of the on-boarding process, a linked mailbox would have been traditionally created in the resource domain as newEmployee@resource.local.

However, with Exchange Online in place, it doesn’t make sense to create a linked mailbox on-premises, only to move it to the cloud once it’s created. So the account in the resource domain is created as a remote mailbox, either through the Exchange 2013 control panel, or using the Exchange PowerShell cmdlet New-RemoteMailbox.

Then we wait for AAD Connect to work its magic…

…and two accounts appear in Office 365. One with a mailbox, and the other without. The new employee is also unable to connect to their new Exchange Online mailbox as access is denied. This obviously is not a good place to have arrived at!

Looking at the linked mailbox joining process in AAD Connect I discussed earlier, you may be able to see why this is occurring. A remote mailbox is not the same as a linked mailbox. As a result,  Azure AD Connect does not join the accounts newEmployee@account.local and newEmployee@resource.local with the result that two accounts are created in Azure AD.

What are the options?

There are two ways forward for you from here:

  1. Continue to create a linked mailbox on-premises and then move the on-premises linked mailbox to Exchange Online as a second step
  2. Modify the newEmployee@resource.local account through some ADSIEdit jiggery-pokery.

Now I’m going to stop here and recommend you stick with the first approach here. It requires an extra step, but so does the second option. Option 1 is also a solution which allows for account and mailbox creation using your existing administrative tools. Getting at AD object attributes, which used to be hidden in your management tools, is a lot easier these days. That doesn’t make it any safer to do without a good understanding of what it is you’re planning to do.

I was presented with an additional complication recently, where a customer had an incumbent vendor providing a managed service for email and charged extra for every mailbox created in the on-premises Exchange environment. Not wanting to give away more money than they needed to, the customer did not want to create a linked mailbox first when on-boarding new users.

Luckily the customer I was working with has FIM in place allowing them to populate AD user object attributes consistently and correctly (this ain’t something I’d be wanting to do manually).

Given AAD Connect matches accounts with the msExchMasterAccountSID and objectSID values, you can manually update newEmployee@resource.local so that it’s msExchMasterAccountSID equals the objectSID for newEmployee@account.local and all will be good right?

Well, the answer is no…

It turns out that AAD Connect checks that the AD object is a linked mailbox before it attempts to match its msExchMasterAccountSID value. This is done using the recipientTypeDetails attribute (a value of 2 designates a linked mailbox).

Account matching process

So, there are two attributes which need to be updated on the resource forest account, they are:

  1. msExchangeMasterAccountSID with the objectSID of the authentication account
  2. recipientTypeDetails with a value of 2

Once you’ve got these being updated you should be set.

Jason.