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

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

Categories: Office365 Tags: , ,
  1. May 21, 2014 at 1:22 am

    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

    • Brian
      June 18, 2014 at 5:58 pm

      Enrico, I am getting the same. Did you hear back about this?

      • June 19, 2014 at 8:00 am

        Hi Brian,

        No I did not hear back, but we decided to add the attribute back to the flow but as an advanced flow with a constant value of “true” (without the quotes). After this, no more errors!

        Cheers,
        Enrico

    • June 24, 2014 at 2:50 pm

      @Enrico, seems like a reasonable fix, but I’ve not tested this.

  1. October 23, 2013 at 7:28 pm
  2. October 29, 2013 at 2:16 pm

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

Follow

Get every new post delivered to your Inbox.

Join 64 other followers

%d bloggers like this: