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:
- 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.
- 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.
Mike Crowley's Whiteboard 
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
Enrico, I am getting the same. Did you hear back about this?
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
@Enrico, seems like a reasonable fix, but I’ve not tested this.
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.
Hi Mike, hopefully i would get response to my question. I have been looking for this for a long time until today that I stumbled on your post. It a very useful and informative articles. However, with the latest AADSync though more simplified but it’s confusing as under Metaverse-> Person-> AccountEnabled. This is nothing that tells which of the connector that is associated with but i assume it would be for both connector.
Using the Synchronization Rule Editor-> Outbound-> User Identity-> AccountEnabled. deleting this value does not change AADSync default behavior. Could please direct us to the corresponding location and attribute that needs to be edited.
you could update the post using AADSync as you mentioned in you your last reply.
Thank you so much as you help those of us in need.
With AADConnect an enabled user will satisfy the filter in the “In from AD – AccountEnabled” rule. Therefore the rule’s transformations will be applied. One of those transformations is to flow “True’ to the metaverse “accountEnabled” attribute. In turn, the “Out to AAD – User Identity” rule flows that attribute from the metaverse to Azure.
If a user is disabled, they will no longer satisfy that filter.
Other rules toggle the AccountEnabled attribute between true and false with a transformation like this
IIF(BitAnd([userAccountControl],2)=0,True,False)
(read about IIF here: https://technet.microsoft.com/en-us/library/ff800820(v=ws.10).aspx)
Unlike the rule mentioned above, a disabled user isn’t always excluded from a rule, but instead the attribute itself is flipped.
If you’re trying to disable (i.e. “break”) this behavior, just change each rule’s flow type for the account enabled attribute from “expression” to “constant” and type in “True”. or better yet, create a new rule with a higher precidence that does the same thing. that way you’re not messing with the default rules (Microsoft advises against this)
Proceed at your own risk! Or email me if you’d like to engage our services for support. 🙂
Hi Mike,
Thanks a lot for the prompt response. Based on your reply I would like to confirm a few things and I really appreciate your help.
I can tried to create an identical (In From AD – User AccountEnabled for local AD) rule under Inbound with precedence of 50 but disabled users are still denied access to o365 services. I don’t really know what I am doing wrong. Also, before creating a new rule I reviewed the existing rule and saw that the Metaverse set for the AccountDisabled was already a constant value of true and another rule with the name (In From AD – User Common) already have the IIF value for AccountEnabled. Could you please assist with a few step to create a rule that would with higher priority is it not too much to ask. I would really appreciate if you could help.
Our organization policy state that all users going on leave must me denied access to on-premise resources but must have full access to office 365 services. Currently, what we do is to move the user out of the synced OU which deletes the user in the cloud. We would then go to the portal to restore the user. This have been working for us until recently when top users with large mailboxes where went on leave, we lost a lost of important mails while accounts were in the deleted status.
PLEASE HEEELLLLPPPPP.