Sign in
 
HomeLibraryWikiLearnGalleryDownloadsSupportForumsBlogs
Resources for IT Professionals >
> 
> 
> 
Change Primary Group of a newly provisioned AD Account

Traitée Change Primary Group of a newly provisioned AD Account

  • Tuesday, January 22, 2013 12:19 AM
     
     
    Sign In to Vote
    0
    I have been given the task of changing the primary group of a newly provisioned AD account from the Domain Users default group to a custom group called Web Users.  Of course,  the new account will need to be a member of this group before changing its primary group attribute.   After changing the primary group I then need to remove the account from the Domain Users group. Is this possible via FIM?
     

All Replies

  • Tuesday, January 22, 2013 10:00 AM
     
     Answered
    Sign In to Vote
    0

    Well. I guess the classic approach would be to create a FIM set to Transition into when the SID of the newly Created AD account is returned to FIM.

    An MPR is triggered by this which calls a Workflow containing a POWERSHELL driving Custom Action.

    The powershell script can modify the AD account, to change the primary group. Indeed the PS script can do basically anything you want it to. Just make the FIMService account a member of Account Operators builtin group as you will need that right to hack the primary group change.

    All these bits and pieces are findable in Technet.

     
  • Wednesday, January 23, 2013 9:04 AM
     
     Answered
    Sign In to Vote
    0
    If you want to do some PS in a Management Agent, you can use this - http://blog.goverco.com/p/powershell-management-agent.html

    Regards, Soren Granfeldt
    blog is at http://blog.goverco.com | twitter at https://twitter.com/#!/MrGranfeldt

     
  • Tuesday, February 19, 2013 8:04 PM
     
     
    Sign In to Vote
    0

    Hi Harold,

    Thanks for the suggestion.  I have been able to create a powershell script that updates an AD user's primary group.  I have also been able to set up the FIM portal such that I cna now add powershell workflow activities.  The issue I am now having is how to pass the identifier (Object SID, sAMAccountName, etc.) of the new AD user to the workflow activity.  I am using the FIM PowerShell Workflow Activity from CodePlex, which exposes the FIM request details in a $fimwf variable.  This may be obvious but I haven't been able to figure it out yet. Any suggestions how how to get info about the new AD user from the FIM request details?


    thanks

    • Edited by ocannada Tuesday, February 19, 2013 8:09 PM
    •  
     
  • Sunday, February 24, 2013 5:06 AM
     
     Answered
    Sign In to Vote
    1
    I have a client that needed this sort of thing, and what we did was configure the objectSID to flow into the metaverse. Then, we had a custom flow rule that flipped the primary group on the export out. FIM separates the group update and the user create into two atomic actions. Users are always going to be created in FIM with a primary group of "Domain Users". There is nothing you can do about that. Note: this solution will mean that the default group will be set to "Domain Users" until a stage and sync and an export occurs on AD following the export that created the account in the first place.
     
  • Monday, February 25, 2013 7:56 PM
     
     Answered
    Sign In to Vote
    0
    Well, you could just write a different value to the primaryGroupId attribute in AD--this would be the primary group's RID.  I'm not aware of any reason this couldn't be set during provisioning.  Just bear in mind that changing the primary group ID is a somewhat unconventional approach and could result in trouble down the line; most customers leave primary group ID alone and simply use regular security groups to control access.

    Steve Kradel, Zetetic LLC SMS OTP for FIM | Salesforce MA for FIM

     
  • Friday, March 22, 2013 6:21 PM
     
     
    Sign In to Vote
    0

    Sorry for leaving this thread for so long.  I had to switch focus to another project for a bit. 

    I have set up the sync process using Harold's suggestion of the PowerShell driven custom action and am able to set the Primary Group of a newly provisioned user account.  However, I have run into an issue where after the primary group of the user is changed the AD Mgmt Agent thinks the user is no longer a member of this group. An import action run against the ADMA will indicate that the user has been deleted from the group membership.  However, the member database (SQL Server) where the group membership is determined still reports that the user is a member of the group (data flows from the member DB to AD).   This results in FIM trying to update the Member attribute of the group in the ADMA by adding the user to the group.  When an export is run against the ADMA the error "cd-existing-object - Either the specified user account is already a member of the specified group or the specified group cannot be deleted because it contains a member"  is raised.  

    I have been able to work around this by excluding the group that I am using as the primary group for AD accounts from FIM synchronization.   The PowerShell custom action is now fully responsible for managing membership in this group.  That said, can some help me understand why the ADMA thinks an AD user is removed from a group when that group is set at the primary group of the user?