DirSync and Disabled Users: The BlockCredential Attribute [Part 2]

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:
$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.

8 thoughts on “DirSync and Disabled Users: The BlockCredential Attribute [Part 2]

  1. Pingback: DirSync and Disabled Users: The BlockCredential Attribute [Part 1] | Mike Crowley's Whiteboard
  2. Pingback: DirSync and Disabled Users: The BlockCredential Attribute [Part 2] - Office 365 MVPs
  3. Hi Mike,

    great article and just what I was looking for, however since I’ve removed the attribute flow for AccountEnabled from the Azure MA I’m getting an increasing amount of errors on the export run job: UserAccountEnabledMissing

    Does this ring a bell and do you have any suggestions? I was thinking about adding the attribute back and just populate it with “true”, but I’m not sure if that’ll work with a boolean value.

    Best regards,
    Enrico Klein

  4. I ran into the same problem as Enrico, and would implement his fix, but I assume that would mean we would not be able to manually set the account status to “blocked” because every time ADSync synchronizes, it will overwrite that attribute. Is there any way around this?

    • I wrote this over a year ago, and at the rate things change in Azure, I would not be sure any of this still works! Having said that, deleting the attribute flow, would not repeatedly disable a user. It means it flows no change whatsoever. BTW, look at AADSync instead. It’s a lot more flexible, and if I were to write an update to this article, I’d work with that instead of DirSync.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s