none
Disabling Active Directory account based on HR attribute - On Import or on Export? RRS feed

  • Question

  • Hi everyone,

    i have a very basic but fundamental question regarding the MIM sync engine. We have successfully launched MIM company-wide and are very happy with the results. However, we recently did a code review for all our Rules Extensions (Import and Export) and found that there is some kind of inconsistency:

    Sometimes we use Export-Flow to do a specific task in one MA and then an Import-Flow for the same task in another MA. Thats something we want to fix asap.

    I give you an example:

    If we want to disable an Active Directory Account based on the employement-state which is coming from our HR-MA, we have two options:

    Option 1: Set "userAccountControl" (CS-Attribute) on the Export-Flow of the AD-MA
    In this szenario, we are checking the mventry["employementState"] during export-run and set the csentry["userAccountControl"]-Attribute. Next time the Import from AD-MA would then write the "userAccountControl"-Attribute into the "userAccountControlADMA1"-Attribute in the Metaverse.

    Option 2: Set "userAccountControlADMA1" (Metaverse-Attribute) on the Import-Flow of the HR-MA
    This time, we set the Metaverse-Attribute "userAccountControlADMA1" based on the csentry["employementState"] inside the import-run of our HR-MA. This would simply export the new "userAccountControl"-Value to the AD-MA on the next export-run.

    From what i understand, both are options that should work fine. However, what is the best practice option here? Check the Metaverse on Export to AD-MA or set the Metaverse-Attribute on Import from HR-MA?

    Many of you should have done this in either one of those ways. What are your experiences and suggestions? 
    Or am i not getting something fundamental here? :)

    Regards,

    Timo

    Monday, April 25, 2016 6:26 AM

Answers

  • In our environment we import/calculate an EmployeeStatus attribute from the HR MA view and push that to the Metaverse.

    The MV attribute is then used in a extension on an attribute export flow rule on the AD Management Agent to calculate and set the userAccountControl value.

    Since userAccountControl (unlike EmployeeStatus) is a Microsoft AD-specific attribute that I can't imagine ever needing to send to another application or system, we don't bother to track it directly in the Metaverse. Should we ever need to look at it, it's easy enough to view and/or reference it in the connector space entry for an individual.

    HR-MA -> MV -> AD-MA

    (HR MA) EmployeeStatus -> (MV) EmployeeStatus -> (AD-MA) UAC

    Hope that helps.

    Al

    Monday, April 25, 2016 8:42 PM

All replies

  • We usually only use two MV attributes here:

    - userAccountControl (Inbound)

    - employeeStatus (or employmentState in your case)

    Then we use BitAnd / BitOr to set the userAccountControl on the employeeStatus -> userAccountControl export flow.


    Did my post help? Please use "Vote As Helpful", "Mark as answer" or "Propose as answer". Thank you!

    Monday, April 25, 2016 7:41 AM
  • Timo-

    I think you'll find there's no "right" answer to this question. I'd lean towards Option 1, not knowing anything else about your deployment. That said, I'm not sure why you're flowing the userAccountControlADMA1 attribute back in. If there's no need for that data elsewhere, you don't need to do this.


    Thanks,
    Brian

    Consulting | Blog | AD Book

    Monday, April 25, 2016 2:56 PM
    Moderator
  • In our environment we import/calculate an EmployeeStatus attribute from the HR MA view and push that to the Metaverse.

    The MV attribute is then used in a extension on an attribute export flow rule on the AD Management Agent to calculate and set the userAccountControl value.

    Since userAccountControl (unlike EmployeeStatus) is a Microsoft AD-specific attribute that I can't imagine ever needing to send to another application or system, we don't bother to track it directly in the Metaverse. Should we ever need to look at it, it's easy enough to view and/or reference it in the connector space entry for an individual.

    HR-MA -> MV -> AD-MA

    (HR MA) EmployeeStatus -> (MV) EmployeeStatus -> (AD-MA) UAC

    Hope that helps.

    Al

    Monday, April 25, 2016 8:42 PM
  • Thanks for your reply.It seems logical to do this on the export run. I think we will rewrite our code to have it consistent throughout our environment. :)
    Tuesday, April 26, 2016 5:58 AM
  • Hi Brian,

    in our case, we actually display the userAccountControl-Value in a custom web application. This application is used to give employees from other departments a quick look inside the metaverse. But other than just displaying the value, we dont do anything else with it. Setting the UAC (meaning disable and enable AD-Accounts) is only relevant inside the Active Directory itself. Thats why i'm starting to lean towards Option 1, too. From the 3 replys so far, everyone seems to use the Export flow for similar scenarios.

    - Timo

    Tuesday, April 26, 2016 6:03 AM
  • Thank you Al.

    You pretty much summed it up perfectly. Your environment seems to be working much like ours. Since you also do the calculation on the Export run, i start to lean towards Option 1. We will discuss this internaly but all of you made some really good points for doing it on the Export instead of the Import run. :)

    Tuesday, April 26, 2016 6:07 AM