I have a custom boolean attribute, called "AccountDisabled", for which I configured the "Use equal precedence" checkbox in the MV designer. The attribute is determined by the AD and the FIM management agents. The mapping type is direct from FIM, while it is calculated from AD (using a bit mask over the userAccountControl attribute). My problem is that the changes done in FIM seem to be ignored. The value taken from AD is always used, not only when the result of the expression would imply a change. Is this the normal behavior when an expression is implied in an attribute with equal precedence, and equal precedence should be configured only on attributes with direct mappings only? More in general, how do you handle the enable/disable account through FIM scenario? I wanted to use the "AccountDisabled" boolean attribute to have the users edit a checkbox through the portal, rather than editing the userAccountControl bits by hand... Thanks, PaoloPaolo Tedesco - http://cern.ch/idm

Hi Paolo, We ran into this same issue just recently - I'm betting that in your Advanced IAF you are doing one of the following: adding a second attribute (like <dn>) to ensure your flow gets executed not throwing the DeclineMappingException when you should (attribute has not changed, but Adv IAF will write the value anyway, changing its precedence) For the later, see: http://www.identitychaos.com/2008/01/throw-new-declinemappingexception.html You probably need to check to see if the value you want to contribute is the same as the value currently there, and if so, throw the DeclineMappingException which will leave the FIM MA as the last contributing MA.Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com

I would try to calculate a value using FIM Inbound rule for AD MA not using any dll code - in my case it solved the same problem. You can turn provisioning off in this Inbound rule. so there will be only 1 attribute calculation in this rule and other attributes will be set up in AD MA as usual. I can see MAs extension rules in DLL always win over FIM MA rules and FIM Inbound/Outbound sync rules.

Hi Brad, thanks for the post about the DeclineMappingException, it is very interesting. Anyway, I'm not using any extensions, the attribute is just calculated with this custom expression: "Eq( BitAnd(2,userAccountControl), 2 )". In this way, if the result of the bitwise and between userAccountControl and 2 (the "account disabled" flag) equals 2, then the account is disabled. Maybe this is a bug? I think that in this case FIM should realize that the value has not changed and not write it over.Paolo Tedesco - http://cern.ch/idm

So, in my current solution I am: Contributing userAccountControl to a Number attribute in the MV via an Inbound SR userAccountControl is set to equal precedence There are no flows in the FIM MA for userAccountControl - it is GNDN (Goes Nowhere Does Nothing, old ST:TNG joke) Enforcing active status using the following flow in an Outbound SR: BitAnd(9223372036854775805,userAccountControl) -> userAccountControl In my Deprovisioning SR I contribute userAccountControl like so: BitOr(2,userAccountControl) -> userAccountControl See this excellent writeup Markus did: http://social.technet.microsoft.com/wiki/contents/articles/using-fim-to-enable-or-disable-accounts-in-active-directory.aspx This should be very simliar to what you are doing without the boolean logic and I'm not having any issues with precedence. Do you perhaps have a flow in the FIM MA that is causing this behavior? You shouldn't need to contribute the existing value all the way to the portal, it's just needed in the MV for the SR.Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com

Hi Brad, I'm using the boolean value in the portal to show the users something comprehensible, i.e. a check box rather than a text box with a number. Then I also use transitions in that value to trigger the MPRs that enable or disable accounts. Then I'm reading back the boolean value with the formula in my previous post. How do you decide if an account should be enabled or disabled? Maybe I should just not read the value back, but then I would not realize if someone disables or enables an account directly in AD. Thanks for the link, I had seen Markus's article, and apart from the detail of the extra boolean attribute I'm doing the same. Actually, I think that "BitAnd(9223372036854775805,userAccountControl) -> userAccountControl" should be "BitAnd(-3,userAccountControl) -> userAccountControl". FIM integers are 64 bits signed integers, therefore 9223372036854775805, being positive, has the first bit set to 0, while -3 has all the bits to 1 but the second. Is it right? Cheers, Paolo Paolo Tedesco - http://cern.ch/idm

So, the attribute in AD actually is only 4 bytes and not all of the bits are allocated. Markus' solution works despite the fact that the most significant bit is a 0: 0111111111111111111111111111111111111111111111111111111111111101 Changing the MSB to a 1 makes this a -3, so both work, but I actually like your method better since I'm more apt to remember -3 than 9223372036854775805. :) The calculator in Windows 7 actually has a Programmer feature that I've only just discovered. In this mode it will show you to bitmask even when you are Hex, Dec, or Oct which is really cool. The coolest feature is that you can use this mode to flip individual bits on and off just by clicking on the digit - very handy! It also does logic, so I can do -3 AND 514 = 512!Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com

Markus's value has nothing wrong, my only point was that -3 is easier to remember :) It is also independent from the number of bits, so if you have 8, 16, 32, 64 or 128 bits, the number with all bits set but the second is always -3 By the way, I think that I'll just renounce reading back the 'disabled' bit from AD and make FIM authoritative for the account's status. Thanks again for the help, Paolo Paolo Tedesco - http://cern.ch/idm

For the above to work, does this means you gues extend the MV schema with a "userAccountControl" attribute for the person object? because you guys do like IFF(BitOr(userAccountControl,...... ) -> userAccountControl. So I would assume you both have the value in the connectorspace and the metaverse as it appears on both side of the -> Regards, Thomas

Hi Thomas, yes, you have to add userAccountControl to the person's attributes in the MV, it's not there by default. Cheers, PaoloPaolo Tedesco - http://cern.ch/idm