In this two-part article, I have laid out a scenario in which DirSync sets the Azure “BlockCredential” attribute of disabled Active Directory users. In Part 1, I explained how the Windows Azure Active Directory Sync tool (DirSync) causes this to happen. Part 2 (below) discusses how to change this behavior.

—

Last time, we saw that magic a rules extension prevents a user from logging into Office 365 if their on-premises Active Directory account was disabled. Below, I’ll show you how to override this attribute flow, but first a note on Microsoft Support:

NOTE: Changing the behavior of DirSync means that you may wander into “unsupported” terrain, but in my experience, unless an unsupported change is likely the cause for a given problem, Microsoft’s support staff have been understanding and have yet to terminate a support case without cause. Having said this, you should not expect Microsoft to incorporate your changes into their upgrade path, so be sure to document, backup, and plan upgrades accordingly.

As you’ll recall, the existing attribute flow is:

userAccountControl à Rules Extension à accountEnabled à Metaverse
Metaverse à accountEnabled à BlockCredential

We will adjust it to the following:

userAccountControl à Rules Extension à accountEnabled à Metaverse à <Nowhere>

In essence, we are allowing the rules extension to update the Metaverse, but not allowing the Azure MA to flow to the BlockedCredential attribute.  This ensures changes in the on-premises Active Directory (such as disabling accounts) will not prevent login to Office 365 (be sure this is actually what you want before you proceed).  Fortunately it also does not necessarily prevent an administrator from setting BlockedCredential manually on Office 365 users.

With our game plan, let’s begin by firing up the trusty miisclient.exe; usually located here:

C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe 

1) Click Management Agents. 2) Open the “Windows Azure Active Directory Connector” MA. 3) Click “Configure Attribute Flow” and expand “Object Type: User”. 4) Select the accountEnabled attribute.
5) Click “Delete”. 6) Click “OK” until you are back on the main screen.

We’re almost done!  Two tasks remain:

1. Test our change by:
   • Creating a new AD user, ensure they sync to Office 365 and that they can log in
   • Disable the user’s AD account, run another sync and ensure they can still log in.
2. Determine how to update users that were disabled before our change.  If you simply want to re/enable all currently disabled accounts, the below PowerShell sample might work well:

Connect-MsolService
$BlockedUsers = Get-MsolUser -EnabledFilter DisabledOnly -All
$i= 1
$BlockedUsers | ForEach-Object {
 Write-Host ($_.UserPrincipalName + " (" + $i + " of " + $BlockedUsers.count + ")" )
 Set-MsolUser -UserPrincipalName $_.UserPrincipalName -BlockCredential $false
 $i = $i + 1
 }

Thanks to William Yang for his advice on this post.

In this two-part article, I will describe a scenario in which DirSync sets the Azure “BlockCredential” attribute of disabled Active Directory users. In Part 1 (below) I explain how the Windows Azure Active Directory Sync tool (DirSync) causes this to happen. Part 2 discusses how to change this behavior.

—

As I’ve been discussing, DirSync can be more complicated than it appears. Even if you are familiar with the miisclient.exe console, some of FIM’s logic is hidden in “Rules Extension” DLL files such as “MSONLINE.RulesExt.dll“. These files can be reverse-engineered to some degree, however it can be very difficult.

That’s why it’s good to know you can avoid them all together if necessary! For example, imagine that I don’t want DirSync to prevent my disabled users from logging into Office 365. Perhaps you need to limit access to on-premises resources for a group of people, while still allowing everyone access to Office 365.

If this restricted group is only a handful of users, and you don’t need password synchronization, you might be best off creating them manually within the Office 365 portal. However if automation and password sync are important, this scenario presents a few credentialing challenges:

• Because ADFS authenticates against local domain controllers, the accounts Must be enabled.
• DirSync will sync passwords for disabled users, but as mentioned above, it also disables them in Office 365 (by setting their BlockCredential attribute).

The first bullet point is simply how ADFS works, therefore ADFS is out. This 2^nd option, however, can actually be explored. WHY does DirSync do this? As far as I can tell, Microsoft hasn’t documented this part of the attribute flow, so let’s take a look ourselves.

Launch miisclient.exe and select the Management Agents tab. Double-click the “Active Directory Connector” MA and select “Configure Attribute Flow”, then expand to this section:

What we can see here is that FIM is reading the Active Directory attribute “userAccountControl” (where the disabled state is recorded) and updating the “Metaverse” attribute “accountEnabled” based on logic within the rules extension. For the sake of argument, why don’t we call this rules extension “magic”, because I have no idea what’s inside it – but let’s keep going.

Now let’s look at the “Windows Azure Active Directory Connector” MA in the same spot:

Well, that’s pretty simple. It’s taking the accountEnabled attribute OUT of the Metaverse and sending it to Azure. The type “Direct” means no magic. After some testing, I have determined that this attribute directly toggles the BlockCredential attribute I mentioned earlier.

userAccountControl à Magic à accountEnabled à Metaverse

Metaverse à accountEnabled  à BlockCredential

(AD / Azure)

Clear as mud, right? J

Here’s an example to be sure:

1) A user has just been disabled.
2) Later, DirSync runs, updating the “userAccountControl” value in the AD MA. 3) The magic within the rule extension reads this and decides the “accountEnabled” Metaverse attribute needs to be updated to “false” which is then exported to Azure.
4) More magic within Azure, decides the user’s BlockCredential attribute needs to be updated. You can view this in the Office 365 Admin Portal or within PowerShell.
5) The user can no longer log into Office 365.Note: This behavior is described in KB 2742372

As you can see, this won’t work in our scenario. Fortunately, FIM is very flexible and we can change this behavior!

Continue on to Part 2 if you’d like to see how.