none
remove a user from a security group in FIM 2010 R2 RRS feed

  • Question

  • We have a manually managed owner approval required group in FIM2010 R2. These groups flows to AD with membership.

    Users can request to join the group from portal or outlook add in. 

    Now what i want is user should be removed from security group in FIM after 30 days. Prior to this an email needs to sent to user notifying his access to group is going to expire in 7 days . User can extend or do nothing.

    If he extends then request must go to owner of group stating a user wants to extend his membership  . Owner can approve or reject.

    - user expiring in 7 days , there can be set and transition MPR with WF which will trigger email notifying user that his membership will expire in 7 days.

    How to track when user was added to security in FIM ? and when group owner approves extension how to extend his membership in Group in FIM ?

    Please guide me on this.



    AdiKumar

    Wednesday, July 10, 2013 3:43 PM

Answers

  • OK - the default GROUP schema includes no start/end date, and even if it did it would have to apply to ALL members in the group - i.e. your requirement will be to track start/end date for each individual member.

    To do this in FIM you need some OTHER object class (let's call this an "entitlement") which manages each individual user membership in the following relationship:

    group <- ENTITLEMENT -> user

    In the above the "<-" means "has one or more", and "-> means "belonging to one".

    Now in my model I extend this a little further and introduce a ROLE object too - something like this:

    group -> ROLE <- ENTITLEMENT -> user

    Your ROLE schema may be nothing more than a unique name, but in my case I had to support a parent/child hierarchy, so it looked like this:

    • RoleCode (unique string)
    • RoleName (unique friendly name)
    • ParentRoleID (SV reference - optional)

    I then had to extend the default FIM group schema to include a new (single value) binding:

    • RoleID (SV reference)

    ... noting that I can only have one role per group, but multiple groups per role (in my case I have multiple groups, one for domain local, one for global nested within the domain local, to which I attach users via a filter on ROLE).

    I also had to extend the default FIM user schema to include a new (multi-value) binding:

    • Roles (MV reference)

    My ENTITLEMENT schema looked like this:

    • UserID (SV reference)
    • RoleID (MV reference)  ** I allowed multiple roles in the same entitlement to economise on the amount of objects I needed to manage **
    • StartDate (datetime)
    • EndDate (datetime)
    • Comments (optional)

    The idea I have employed is to write FIM policy to manage entitlements rather than groups directly, and use FIM workflow to manage group membership as a by-product of the CURRENT (today falls between start and end date) entitlements, based on Person.Roles.

    The downside of this of course was that the Outlook add-on is of no use to me since I don't allow users to join these groups directly.  However, I had no need of this, because in my model role administrators assign roles to users as "entitlements" and FIM policy generates group membership as a result.

    There may still be a way to allow the users to assign themselves to groups using a variation of the above approach where you don't involve roles at all.


    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    Thursday, July 25, 2013 2:09 AM
  • This is a standard scenario which unfortunately is not supported by the out-of-the-box FIM group management model.  Please see this post and the link therein to my wiki article on extending the FIM schema to achieve this.

    Note that I used custom workflow activities as the building block to this process - you could equally use say a generic PowerShell custom activity and/or scheduled PowerShell scripts to achieve this once you have your FIM schema/policy extensions the way you need them.


    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    Monday, July 15, 2013 3:13 PM

All replies

  • This is a standard scenario which unfortunately is not supported by the out-of-the-box FIM group management model.  Please see this post and the link therein to my wiki article on extending the FIM schema to achieve this.

    Note that I used custom workflow activities as the building block to this process - you could equally use say a generic PowerShell custom activity and/or scheduled PowerShell scripts to achieve this once you have your FIM schema/policy extensions the way you need them.


    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    Monday, July 15, 2013 3:13 PM
  • Furthermore, you may want to look at using BHOLD's group management model which would no doubt support this idea now (via RBAC).

    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    Monday, July 15, 2013 3:14 PM
  • Thanks Bob. Sorry i could not really understand the schema extension for the scenario. Can you please elaborate more with an simple example.

    Thanks in Advance


    AdiKumar

    Wednesday, July 24, 2013 12:24 PM
  • OK - the default GROUP schema includes no start/end date, and even if it did it would have to apply to ALL members in the group - i.e. your requirement will be to track start/end date for each individual member.

    To do this in FIM you need some OTHER object class (let's call this an "entitlement") which manages each individual user membership in the following relationship:

    group <- ENTITLEMENT -> user

    In the above the "<-" means "has one or more", and "-> means "belonging to one".

    Now in my model I extend this a little further and introduce a ROLE object too - something like this:

    group -> ROLE <- ENTITLEMENT -> user

    Your ROLE schema may be nothing more than a unique name, but in my case I had to support a parent/child hierarchy, so it looked like this:

    • RoleCode (unique string)
    • RoleName (unique friendly name)
    • ParentRoleID (SV reference - optional)

    I then had to extend the default FIM group schema to include a new (single value) binding:

    • RoleID (SV reference)

    ... noting that I can only have one role per group, but multiple groups per role (in my case I have multiple groups, one for domain local, one for global nested within the domain local, to which I attach users via a filter on ROLE).

    I also had to extend the default FIM user schema to include a new (multi-value) binding:

    • Roles (MV reference)

    My ENTITLEMENT schema looked like this:

    • UserID (SV reference)
    • RoleID (MV reference)  ** I allowed multiple roles in the same entitlement to economise on the amount of objects I needed to manage **
    • StartDate (datetime)
    • EndDate (datetime)
    • Comments (optional)

    The idea I have employed is to write FIM policy to manage entitlements rather than groups directly, and use FIM workflow to manage group membership as a by-product of the CURRENT (today falls between start and end date) entitlements, based on Person.Roles.

    The downside of this of course was that the Outlook add-on is of no use to me since I don't allow users to join these groups directly.  However, I had no need of this, because in my model role administrators assign roles to users as "entitlements" and FIM policy generates group membership as a result.

    There may still be a way to allow the users to assign themselves to groups using a variation of the above approach where you don't involve roles at all.


    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    Thursday, July 25, 2013 2:09 AM
  • For my test environment , i created schema like below

    Whenever user becomes member of a group in FIM , WF is called and it creates a corresponding Entitlement resource.

    Resource: Entitlement

    Attributes linked : Entitle_end_date ,Entileaccountname , Entitlegroupname

    User1 joing group X , a resource is created with display name of /person in question and 

    Entitle_end_date : currentdate plus 30 days

    Entileaccountname : person account name which is "user1"

    Entitlegroupname : group it joined "X"

    When user1 joins another group , new resource will be created.

    Question:

    1- Do you think this is the right approach ? any suggestions

    2- Say down the line i have 70,000 users in FIM and say 10,000 users are member of atleast 10 group so there will be 10,000 * 10 = 100,000 entitlement objects created. now when FIM evaluates when the resource is expiring it will process 100,000 objects.

    Is there going to be any performance issue ? Will it slow down the expiration evaluation process and put extra load on FIM service ?

    Any suggestions please ? 


    AdiKumar

    Thursday, September 26, 2013 11:31 AM
  • What you have described is the reverse of my design, in which my users don't become members of (role based) groups until an entitlement is created linking them to a role, together with a start and (ideally) an end date.

    In your design you are creating entitlements as a by-product of group membership, and assigning them a 30 day period - but what exactly do you wish to happen when the 30 days is up?  I presume you want them to fall out of the group when the entitlement has expired?  I guess this could work so long as FIM is authoritative for group membership - i.e. when you say "Whenever user becomes member of a group in FIM" you don't mean this happens via the Sync Engine (i.e. some other system is authoritative)?  Obviously FIM has to be authoritative or your group membership will just be reinstated and a new entitlement will be created by your workflow.

    If you are worried about performance, the biggest overhead on FIM that I've had to worry about has always been EREs.  A handful of MPRs and sets such as "all expired entitlements" can be configured to implement your desired FIM policy, and in my experience FIM can be tuned to perform well with the numbers you are expecting.  My current R1 site has similar policy managing the kind of numbers you are talking about.


    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using FIM Event Broker for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM


    • Edited by UNIFYBobMVP Thursday, September 26, 2013 4:00 PM
    Thursday, September 26, 2013 3:56 PM