none
Assigning users to AD groups RRS feed

  • Question

  • In order to assign new users created within FIM to security groups that pre-exist within AD, what must be configured within FIM? FIM currently has no knowledge of the groups, it is not responsible for creating or managing those groups, however it is desired that FIM provision user accounts and assign membership to various groups in that AD instance.

    Thanks!


    • Edited by Osho27 Tuesday, January 15, 2013 7:22 PM
    Tuesday, January 15, 2013 6:55 PM

Answers

  • If you want to manage these groups through FIM you have to put both, groups and members(users) in a FIM, calculate or set (explicit) group membership and then flow it to target data source (AD).

    You can read and test this in a lab (and other articles there):

    http://technet.microsoft.com/en-us/library/ff686261(v=ws.10).aspx

    http://technet.microsoft.com/en-us/library/ff686936(v=ws.10).aspx

    it will give you good overview how it works in principles. 

    In specific how you should do this depends a bit on your environment, in general;

    1. create users and groups in FIM (either through synchronization or other way - powershell script as example)

    2. join exisiting groups to these from FIM (synchronization)

    3. Flow current membership of existing group into FIM or synchronize group membership you will set in fim and look for difference (resolve those)

    So a bit of planning + some FIM work. You can always look for friendly help of nearby FIM consultant :)


    Tomek Onyszko, memberOf Predica FIM Team (http://www.predica.pl), IdAM knowledge provider @ http://blog.predica.pl

    • Marked as answer by Osho27 Tuesday, January 15, 2013 8:01 PM
    Tuesday, January 15, 2013 7:55 PM
  • Dont know about the best practice but, i am fairly sure a Management Agent per OU is NOT recommended, also you dont need to have more than one Management Agent per Domain, per Forest. One MA always suffice.

    • Marked as answer by Osho27 Thursday, January 17, 2013 2:58 PM
    Thursday, January 17, 2013 7:05 AM
  • In your out bound sync rule you have to calculate the OU which the user will reside. The container configuration in the MA configuration is more for restricting FIM to the desired OUs only, for any security reasons that you may have. FIM will only consider these OUs while importing and exporting. However FIM does read the whole AD in full imports regardless of this restriction. Now for the user under an OU provisioning consider a scenrio where the user is to be created under a department OU You will have to create an custom exprerssion outbound attribute mapping in you sync rule as follows Source: "CN="+DisplayName+",OU="+Department+",DC=contoso,DC=com" Destination: dn Initial flow Creating another similar mapping without the initial flow will ensure that when the user deparment changes in the future the user is moved to the right OU in AD. This will only work if the displayname attribute and the department attribute have values in them. Finally using hirarichal provisioning will ensure that the OU is automatically created when its not there in the AD. Hope this is what you were looking for.
    • Marked as answer by Osho27 Thursday, January 17, 2013 6:41 PM
    Thursday, January 17, 2013 3:26 PM
  • The AD MA in FIM can manage a complete AD forest (all AD domains and all OUs) or parts of it. It all depends on what you select/configure in the MA
     
    To provision users in different OUs, the distinguishedName of a user cannot be static, but rather it must be dynamic based upon one or more variables.
    For example the DN configuration could look like: CN=<sAMAccountName>,OU=<objectStatus>,OU=<Department>,DC=Domain,DC=TLD
     
    <sAMAccountName> = based upon the attribute sAMAccountName in AD whereas the FIM Portal uses AccountName
    <objectStatus> = based upon either the values ENABLED or DISABLED and both are derived from the userAccountControl attribute in AD
    <Department> = based upon the attribute department
     
    So if a user changes from department A to B it will change its DN automatically.
     
    In the FIM Portal, you need to configure a DN that will be set as initial only to be used during provisioning and a DN that is NOT set as initial only so that the DN changes accordingly to match the changes in the attributes used as variables in the DN

    Cheers,


    (HOPEFULLY THIS INFORMATION HELPS YOU!)
    Jorge de Almeida Pinto | MVP Identity & Access - Directory Services

    -------------------------------------------------------------------------------------------------------
    * This posting is provided "AS IS" with no warranties and confers no rights!
    * Always evaluate/test yourself before using/implementing this!
    * DISCLAIMER:
    http://jorgequestforknowledge.wordpress.com/disclaimer/
    -------------------------------------------------------------------------------------------------------
    ################# Jorge's Quest For Knowledge ###############
    ###### BLOG URL:
    http://JorgeQuestForKnowledge.wordpress.com/ #####
    #### RSS Feed URL:
    http://jorgequestforknowledge.wordpress.com/feed/ ####
    -------------------------------------------------------------------------------------------------------
    <>

    "Osho27" wrote in message news:491c6a54-3b48-4c65-9ef0-530425337fb7@communitybridge.codeplex.com...

    Tomasz,

    Thank you.  Is it typically a best practice to set up a management agent per OU?  In most of the examples I see on the technet site they use a FIMObjects OU.  And then that OU is coded to create a unique dn, coded in the MA, etc.  This makes me think of the OU as being a management boundary for FIM. Is that the right way to think of it?

    Thanks!


    Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/
    • Marked as answer by Osho27 Tuesday, February 5, 2013 2:38 PM
    Monday, February 4, 2013 1:03 PM

All replies

  • FIM currently has no knowledge of the groups, it is not responsible for creating or managing those groups, however it is desired that FIM provision user accounts and assign membership to various groups.

    How can you manage something, you are not aware of?
    That doesn't really work...

    Cheers,
    Markus

     

    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

    Tuesday, January 15, 2013 7:23 PM
  • I knew you would have a sarcastic response :).

    The answer is because we are phasing in the product and trying to understand the boundaries of the possible.  There are a number of groups already in the test environment, so I don't need to create them.  So back to my question, what must one do to assign group membership?

    Thank you for sharing.

    Tuesday, January 15, 2013 7:32 PM
  • If you want to manage these groups through FIM you have to put both, groups and members(users) in a FIM, calculate or set (explicit) group membership and then flow it to target data source (AD).

    You can read and test this in a lab (and other articles there):

    http://technet.microsoft.com/en-us/library/ff686261(v=ws.10).aspx

    http://technet.microsoft.com/en-us/library/ff686936(v=ws.10).aspx

    it will give you good overview how it works in principles. 

    In specific how you should do this depends a bit on your environment, in general;

    1. create users and groups in FIM (either through synchronization or other way - powershell script as example)

    2. join exisiting groups to these from FIM (synchronization)

    3. Flow current membership of existing group into FIM or synchronize group membership you will set in fim and look for difference (resolve those)

    So a bit of planning + some FIM work. You can always look for friendly help of nearby FIM consultant :)


    Tomek Onyszko, memberOf Predica FIM Team (http://www.predica.pl), IdAM knowledge provider @ http://blog.predica.pl

    • Marked as answer by Osho27 Tuesday, January 15, 2013 8:01 PM
    Tuesday, January 15, 2013 7:55 PM
  • Tomasz,

    Thank you.  Is it typically a best practice to set up a management agent per OU?  In most of the examples I see on the technet site they use a FIMObjects OU.  And then that OU is coded to create a unique dn, coded in the MA, etc.  This makes me think of the OU as being a management boundary for FIM. Is that the right way to think of it?

    Thanks!

    Wednesday, January 16, 2013 3:35 PM
  • Dont know about the best practice but, i am fairly sure a Management Agent per OU is NOT recommended, also you dont need to have more than one Management Agent per Domain, per Forest. One MA always suffice.

    • Marked as answer by Osho27 Thursday, January 17, 2013 2:58 PM
    Thursday, January 17, 2013 7:05 AM
  • So then how are multiple OU's dealt with when it comes to configuring the MA - if I need to actually define the OU to which I am provisioning within the MA wizard, ie Container?

    Thursday, January 17, 2013 3:06 PM
  • In your out bound sync rule you have to calculate the OU which the user will reside. The container configuration in the MA configuration is more for restricting FIM to the desired OUs only, for any security reasons that you may have. FIM will only consider these OUs while importing and exporting. However FIM does read the whole AD in full imports regardless of this restriction. Now for the user under an OU provisioning consider a scenrio where the user is to be created under a department OU You will have to create an custom exprerssion outbound attribute mapping in you sync rule as follows Source: "CN="+DisplayName+",OU="+Department+",DC=contoso,DC=com" Destination: dn Initial flow Creating another similar mapping without the initial flow will ensure that when the user deparment changes in the future the user is moved to the right OU in AD. This will only work if the displayname attribute and the department attribute have values in them. Finally using hirarichal provisioning will ensure that the OU is automatically created when its not there in the AD. Hope this is what you were looking for.
    • Marked as answer by Osho27 Thursday, January 17, 2013 6:41 PM
    Thursday, January 17, 2013 3:26 PM
  • The AD MA in FIM can manage a complete AD forest (all AD domains and all OUs) or parts of it. It all depends on what you select/configure in the MA
     
    To provision users in different OUs, the distinguishedName of a user cannot be static, but rather it must be dynamic based upon one or more variables.
    For example the DN configuration could look like: CN=<sAMAccountName>,OU=<objectStatus>,OU=<Department>,DC=Domain,DC=TLD
     
    <sAMAccountName> = based upon the attribute sAMAccountName in AD whereas the FIM Portal uses AccountName
    <objectStatus> = based upon either the values ENABLED or DISABLED and both are derived from the userAccountControl attribute in AD
    <Department> = based upon the attribute department
     
    So if a user changes from department A to B it will change its DN automatically.
     
    In the FIM Portal, you need to configure a DN that will be set as initial only to be used during provisioning and a DN that is NOT set as initial only so that the DN changes accordingly to match the changes in the attributes used as variables in the DN

    Cheers,


    (HOPEFULLY THIS INFORMATION HELPS YOU!)
    Jorge de Almeida Pinto | MVP Identity & Access - Directory Services

    -------------------------------------------------------------------------------------------------------
    * This posting is provided "AS IS" with no warranties and confers no rights!
    * Always evaluate/test yourself before using/implementing this!
    * DISCLAIMER:
    http://jorgequestforknowledge.wordpress.com/disclaimer/
    -------------------------------------------------------------------------------------------------------
    ################# Jorge's Quest For Knowledge ###############
    ###### BLOG URL:
    http://JorgeQuestForKnowledge.wordpress.com/ #####
    #### RSS Feed URL:
    http://jorgequestforknowledge.wordpress.com/feed/ ####
    -------------------------------------------------------------------------------------------------------
    <>

    "Osho27" wrote in message news:491c6a54-3b48-4c65-9ef0-530425337fb7@communitybridge.codeplex.com...

    Tomasz,

    Thank you.  Is it typically a best practice to set up a management agent per OU?  In most of the examples I see on the technet site they use a FIMObjects OU.  And then that OU is coded to create a unique dn, coded in the MA, etc.  This makes me think of the OU as being a management boundary for FIM. Is that the right way to think of it?

    Thanks!


    Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/
    • Marked as answer by Osho27 Tuesday, February 5, 2013 2:38 PM
    Monday, February 4, 2013 1:03 PM