Partager via

Understanding userAccountControl management with FIM.

  • Article

Before we begin lets look at the Attribute userAccountControl in Active Directory.

You may also be interested in understanding the Bit Values for each flag that defines the userAccountControl of a user, the following site details what each flag is and it value.

https://support.microsoft.com/en-us/kb/305144/

Before you can begin to manage an employees status in the FIM Portal you may need to add a custom attribute and bind it to the Person Resource in the FIM Portal for Employee Status. Out of Box Employee Status is not an attribute that is configured within the FIM Portal so I would determine if you want to use another attribute or configure the FIM Portal to include the Employee Status attribute.

  1. Verify that you have already Created a custom Attribute to be used to control Employee Status
    1. The following post can assist in Creating  attributes in the FIM Portal   -        Schema Management - Creating a new attribute
  2. Verify that you have already Bound the Custom Attribute to the Person Resource in the FIM Portal
    1. The following post can  assist in binding attributes in the FIM Portal     -        Schema Management - Binding a New Attribute
  3. Don't forget to verify and apply permissions to all MPRs that will be used to allow management of the Employee Status Attribute.
    1. The following post can assist in Setting the correct MPR Permissions Schema Management - Setting Permissions to manage new attributes.
      1. You would need to verify that permissions were set for the Synchronization Service
  4. Verify that you have created the necessary Attributes in the Metaverse and  updated the FIMMA with the new Custom Attribute to allow synchronization from the Metaverse to the FIM Portal.
    1. The following post can assist in updating the Metaverse - Resource Management - Configure Synchronization Service to manage New Resource.
  5. Verify that you have Updated the FIMMA
    1. The following post can assist in updating - Updating the FIMMA to include Custom Attributes in the FIM Portal.
  6. Verify that you have selected userAccountControl in the "Select Attributes" Section of the Management Agent that will connect to Active Directory.

You could just set the userAccountControl with FIM using a real basic function that sets the userAccountControl with a static value of 512 for enabled or 514 for disabled. The biggest issue with that is not all accounts are created equal. for example

512 is a normal account with no special flags

514 is a normal disabled account with no special flags

66048 is a normal account with the flag set for Password never expires

66050 is a normal disabled account with the flag set for Password never expires

262656 is a normal account with the flag set to require smart card authentication

262658 is a normal disabled account with the flag set to require smart card authentication.

There are a wide array of combinations of flags that would control the value set for the userAccountControl attribute in Active Directory. The on common thread is any account that is disabled has a value of 2 added to its current userAccountValue..

Ideally you would want to have the simplest method to enable or disable all accounts regardless of the types of accounts and flags that have been set for each account. Your environment could consist of only 1 type of account which should ever have a userAccountControl set to 512 for enabled or 514 for disabled in that case you could use the real basic method of setting the userAccountControl attribute, but consider this we live in a fast passed world where Technology and policies are constantly changing and todays best practice could be tomorrows risk.

  • Verify that the attribute userAccountControl has been selected on the Active Directory Management Agent, if this is not selected when you are trying to configure the sync rule to flow a value to the attribute the option for userAccountControl will not be available.

           

  • In the FIM Portal open up the Synchronization Rule Admin Page

           

  • Click onthe Import Synchronization Rule for users

            

  • Click on Inbound Attribute Flow Tab

     

  • Verify that you do not already have an attribute flow for managing the userAccountControl.
  • Click on New Attribute Flow

  • Select CustomExpression under the Source Tab
  • Add the following in the text box.               IIF(Eq(BitAnd(2,userAccountControl),2),"Disabled","Enabled")

  • Click on the Destination Tab
  • Select employeeStatus

  • Click on Ok than submit to save the Sync Rule
  • Back in the Synchronization Rule Admin Page click on the Outbound User Sync Rule you wish to add the attribute flow to handle the userAccountControl attribute.
  • Add the following attribute flow
    • Source Tab
      • Function
        • Function name
          • IIF
      • condition:Boolean
        • customExpression
          • Eq(employeeStatus,"Enabled")
      • ValueTrue:Object
        • customExpression
          • BitAnd(-3,userAccountControl)
      • valueFalse:Object
        • CustomExpression
          • BitOr(2,userAccountControl)
    • Destination Tab
      • userAccountControl

Source Tab

Destination

  • Click on OK and than Submit to save changes to the Sync Rule

 

  • In the  FIM Synchronization Service
  • Run an Import on the FIMMA
  • Set Employee Status attribute to equal precedence
  • Run a Full Sync on the FIMMA
  • Verify Pending Exports

Comments

  • Anonymous
    August 09, 2015
    The comment has been removed

  • Anonymous
    August 09, 2015
    I meant to say that everything is working except that status changes are NOT sync-ing to AD.

  • Anonymous
    August 09, 2015
    Bob Cambell, Please be sure that you have correct precedence configured depending on what you would like to be authoritative, in some cases Equal Precedence may be expected. Additionally i re-worded this post to clear up any confusion and added additional links to the postings to assist with setting the proper permissions. Permission Granting MPRs will be needed for any set of users that will require to need to set the Employee Status Attribute. Additionally in order for the Synchronization Service to update this custom Attribute you will need to ensure that the MPR that gives permissions to the Synchronization Service to update Users has been updated to include the Employee Status Attribute. Although i would recommend creating a a duplicate MPR to give permissions to the Synchronization Service and add all custom attributes to that MPR and leave the default Synchronization Service MPR set with only default attributes. also as stated in the updated post you need to verify that you have the attribute in the Metaverse and have refreshed schema on the FIMMA to pull in the new custom attribute from the Portal into the FIMMA.

  • Anonymous
    August 09, 2015
    Leaving this here as it is a useful reference for UAC values: support.microsoft.com/.../305144

  • Anonymous
    August 14, 2015
    I really apologize for the length of this post..... I have done everything that this and other blogs say I should do, but it's not working and I cannot figure out why. I have decided to go with a Boolean representation of the Account Disabled attribute in FIM so that it can be displayed and modified with a checkbox instead of a string of text. Let me explain my setup: Relevant attributes in use: Active Directory - userAccountControl (number) Metaverse - mv_userAccountControl (number) and mv_accountDisabled (boolean) FIM Portal - fm_AccountDisabled (boolean) User Active Directory Sync Rule Inbound Attribute Flow: userAccountControl=>mv_userAccountControl CustomExpression(IIF(Eq(BitAnd(2,userAccountControl),2),"True","False"))=>mv_accountDisabled User Active Directory Sync Rule Outbound Attribute Flow: CustomExpression(IIF(mv_accountDisabled,BitOr(2,mv_userAccountControl),BitAnd(-3,mv_userAccountControl)))=>userAccountControl FIM MA Attribute Flow: fm_AccountDisabled <- mv_accountDisabled (Allow Nulls checked) fm_AccountDisabled -> mv_accountDisabled In the Metaverse Designer, the Attribute Flow Precedence for mv_userAccountControl is EQUAL Our synchronization run profiles that happen every 30 minutes (and take about 6 minutes) are: SQL-MA: EFIDS (irrelevant) FIM-MA: EDIDS AD-MA:  EDIDS FIM-MA: EDIDS SQL-MA: EDS   (irrelevant) FIM-MA: EDIDS AD-MA:  EDIDS (This is probably way excessive, but it's been working for years.) My goal is to set it up so that if an account gets Enabled (or Disabled) in AD, it will sync False (or True) to mv_accountDisabled and the corresponding integer value to mv_userAccountControl in the Metaverse; and then sync False (or True) to FIM. That part is working perfectly, first time every time. The other half of my goal is to set it up so that if an account gets Enabled (or Disabled) in FIM, it will sync False (or True) to mv_accountDisabled in the Metaverse and then sync the corresponding integer value to userAccountControl in Active Directory, and then sync that AD value back to mv_userAccountControl in the Metaverse. That last sync back into the Metaverse is what's not happening. I think that sync-back should be occurring during the first run profile of the AD-MA, but it's not. Here is what is happening during that run: E: 1 Update: modify userAccountControl (The AD account actually gets modified) DI: 1 Update: The changed UAC value is successfully detected. DS: Connectors without Flow Updates: 1 <- Right here is where the FAIL is. FIM has no intention of updating the Metaverse with the new UAC value it found in AD, and it doesn't. What I end up with is: FIM: Account is now Disabled Metaverse: mv_accountDisabled = True, but mv_userAccountControl = 512 AD: Account is now Disabled Synchronizations for this attribute are now completely broken. I have discovered that if I do an AD-MA: FS run that it finally syncs the mismatched attribute, but why doesn't the DS do that? What am I missing here?

  • Anonymous
    October 26, 2015
    Mr. Campbell Forgive me for the late response i been tied up in other projects, What is the Precedence of the attributes that you are having issues with? Can you verify that the Sync Rule Attribute flow for the attribute that is having issues was not set for initial attribute flow only? without seeing you environment i can not determine as the issue is but i would like to discourage the use of a static value to be set for the userAccountControl attribute. unless your environement will only ever have 2 potential userAccountControl values (one for enabled and one for disabled) for example 512 and 514 i would try and use the bit wise function if possible. Additionally did you look at the link that was added in the previous response?

  • Anonymous
    December 28, 2017
    The comment has been removed