none
How to add users to AD groups with Rule Extension?

    Întrebare

  • Hello,

    I have a question about AD group management with FIM2010. I need to do this with Rule Extension because it would be more simple to customize and portable (now I'm working in a test environment, when I go to the production environment I would like to re-use the same code, without re-implementing the declarative rules on the Portal). Moreover, my situation is a bit complicated (more than 400 AD groups to be managed differently), so I think it’s better to use the code.

    In Active Directory I have many groups located in several OUs (some of them populated with users and groups).

    1. My first question is about the import of groups from AD to MV. I read that to manage groups and members I need to use the same MA for users and groups. In this scenario I would like to import only groups located in the OU=Service Groups, excluding from the import those groups located in the other OUs (those included in the containers selected due to users management). To this aim, should I use the ShouldProjectToMV method in the MAExtension Rule? If so, can you tell me if the following code is correct to my purpose?

    2. The second question is that I want to manage the group membership manually or automatically depending on the group (some are simply associated with the user OUs and can be automatically managed, other need the human intervention). To this aim have I to set the membershipLocked attribute to false or true depending on the specific group?

    3. Finally, the question that I most care about.. how to add members to groups with code! I read that manipulate reference attribute is not allowed through code.. but is there any other way to do this? Particularly, I would like to assign users located in the OU=A to the group “A”, and so on. My first though is to create a provision method in the MVExtensionRule (as I do to change the DN of users) to modify the member attribute.. In the following my code:

    Where in the attribute “userDN” I have the complete path of the users DN (imported from AD).

    If the idea is not wrong I’ll select only users with the groupName contained in the userDN (still I don’t know how.. )..

    Obviously, this code doesn’t work.. the “extension-dll-exception” says “the attribute member is read only[..]”. Is there any way to do this assignment with code?

    Please help me, I need to assign users to so many groups with granularity and without re-implementing the declarative rules in the production environment.

    Please, any suggestion is welcome.

    Thanks in advance.

    Francesca

    11 iunie 2012 16:02

Răspunsuri

  • Just my feedback,

    For group management, we use the ShouldProjectToMV with logic that looks at the attribute on the group rather than it's location (as you may have a requirement that a group be placed somewhere differently). We then manage all users of that group via the portal (with the requirement that all FIM managed groups will only contain members of FIM managed users).

    You could import the DN of the user into a string attribute in the portal, then establish a criteria for a group where that string attribute contains "OU=containerA" for a specific group

    • Marcat ca răspuns de Francesca85 23 iulie 2012 14:23
    12 iunie 2012 14:01

Toate mesajele

  • Francesca-

    #1 - You're correct here. You need to tweak your code though as not all paths return  value.

    #2 - The membershipLocked attribute is only used by the FIM Portal's group management functionality.

    #3 - Doing this in code is not easy. You would be better off either using the native group functionality in the portal, or constructing a SQL table that has the group memberships calculated in it, and then importing that data as references.


    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    11 iunie 2012 16:49
    Moderator
  • Brian, thank you for your answers but I need some clarifications.

    1. Sorry but I didn't understand how to modify the code. The bool parameter has always a value, isn't it? Moreover, if I have just projected the groups in the MV and now I want to exclude them, need I to write similar code in the MapAttributesForJoin method?

    3. Can you tell me, according to you, which is the better method for my scenario (more than 400 groups to be managed manually or automatically)? Can I simply implement very granular rules in the Portal? Is there a way to save declarative rules in the Portale in order to re-use them in a new (other) FIM2010 environment?

    For what concern the SQL approach, can you redirect me to some documentation/guide? Because I didn't understand very well how to proceed..

    Thank you very much.

    Francesca

    11 iunie 2012 19:58
  • For #1, if your catch block gets called, you will never return anything. Given you're just throwing the exception (and incidentally, not preserving the stack), I would just remove the try/catch block.

    #3, the FIM portal will be quite sufficient I expect. You can use the Config Migration scripts (http://technet.microsoft.com/en-us/library/ee534906(WS.10).aspx) as a starter for migrating groups. Just tweak them to only export groups, for example.

    For the SQL approach, a couple starter links are here:

    http://www.wapshere.com/missmiis/generating-reference-attributes-from-string-data

    http://www.wapshere.com/missmiis/who-needs-group-populator-when-you-have-multivalue-tables


    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    11 iunie 2012 20:17
    Moderator
  • Brian thanks,

    unfortunatly my pilot environment is not identical to the production environment.. so according to what I read in the first link I cannot use the configuration migration scripts! In the production envirnment I will have more servers.

    Moreover, I read the other links concerning SQL but I think I'll try to use the Portal (hoping it will be sufficient for my purpose).

    Francesca

    12 iunie 2012 09:04
  • Just my feedback,

    For group management, we use the ShouldProjectToMV with logic that looks at the attribute on the group rather than it's location (as you may have a requirement that a group be placed somewhere differently). We then manage all users of that group via the portal (with the requirement that all FIM managed groups will only contain members of FIM managed users).

    You could import the DN of the user into a string attribute in the portal, then establish a criteria for a group where that string attribute contains "OU=containerA" for a specific group

    • Marcat ca răspuns de Francesca85 23 iulie 2012 14:23
    12 iunie 2012 14:01
  • Hi-

    Sounds like you would need to do some extra work then to be able to port the group definitions back and forth...

    I agree that the portal is likely more than sufficient for your needs.


    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    12 iunie 2012 17:23
    Moderator