Hello,

I have MPRs and sync rules in FIM to disable AD accounts for users who are inactive in ERP and to enable them when they are active. To enable them I flow 512 to useraccountcontrol. Today I turned FIM on for the first time against my production AD and when it was time ran an export to AD. It did what I expected; active users got the "enable active users" ERE and 512 flowed out to AD but LOTS (not all) of my AD accounts got disabled. My own normal account was locked out so I logged in with my admin account and checked out my non-privileged account. Sure enough it had 512 in the uac value.  I've worked in directories a long time including ten years at Microsoft and I can't understand what happened. Can anyone explain why flowing 512 disabled the account? A small clue maybe; the accounts were set to 544 previously. Maybe moving from 544 to 512 doesn't work?

Thanks,

Lee

Can you show the the IIF statement??

Hi Nosh, I could do but I'm not sure it will help. I can see that FIM is writing 512 to the attribute in AD but the accounts are disabled. I opened up aduc and looked at the accounts and saw the useraccountcontrol was 512. Lee.

• Edited by leemar 10 hours 42 minutes ago

Most of the time, devil is in the details.

512 and disabled at the same time, that is not possible.  Enable means 512. Period.

Maybe the account is expired, check Attribute accountExpires, or in ADUC - Account Expires

Hi Nosh, I could do but I'm not sure it will help. I can see that FIM is writing 512 to the attribute in AD but the accounts are disabled. I opened up aduc and looked at the accounts and saw the useraccountcontrol was 512. Lee.

• Edited by leemar Thursday, July 23, 2015 8:41 PM

Hi Nosh, I could do but I'm not sure it will help. I can see that FIM is writing 512 to the attribute in AD but the accounts are disabled. I opened up aduc and looked at the accounts and saw the useraccountcontrol was 512. Lee.

• Edited by leemar Thursday, July 23, 2015 8:41 PM

Hi Nosh, I could do but I'm not sure it will help. I can see that FIM is writing 512 to the attribute in AD but the accounts are disabled. I opened up aduc and looked at the accounts and saw the useraccountcontrol was 512. Lee.

• Edited by leemar Thursday, July 23, 2015 8:41 PM

Hi Nosh, I could do but I'm not sure it will help. I can see that FIM is writing 512 to the attribute in AD but the accounts are disabled. I opened up aduc and looked at the accounts and saw the useraccountcontrol was 512. Lee.

• Edited by leemar Thursday, July 23, 2015 8:41 PM

Do you flow unicodePwd as well? If you dont, this might result in a disabled account.

@Vladimir - This would be true if the user is being provisioned anew, but if the user is existent, as the thread suggests, then this is not required.  You are technically reseting someone's password. 

@Leemar - If this is a newly provisioned account, Vladimir's suggestion is perfectly valid.  You cannot provision an account Active without a password.

Hi,

I think this was caused by trying to flow a unicodepwd to the accounts when enabling them and FIM not being able to as a password already exists. I'm going to re-work my logic around re-enabling accounts to prevent this happening again. Thanks for your suggestions and help.

Lee.

I don't understand. 

1. That would not be the issue.  You can flow the password, as long as it is compliant.

2. That would not disable the account

During a new user provisioning, creation, you need these attributes populated.

1. sAMAccountName ="nmernacaj"

2. unicodePwd ="Compl3X12$121AS"

3. userPrincipalName ="nmernacaj@domain.com"

4. dn= "CN=nmernacaj,OU=Users,DC=Domain,DC=Com"

5. userAccountControl= "512"

During normal synchronization, you do not need to update anything or you can update any or all of the attributes. 

setting unicodePwd during synchronization, resets a user's password. YOU DO NOT WANT TO DO THIS.