• State Verified Answer
  • Locked Locked
  • Replies 8 replies
  • Subscribers 62 subscribers
  • Views 6816 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Primary / Secondary Owners inheritance

jwheele9
over 5 years ago

I'm looking to automate the primary/secondary owners of Security Groups - based on the primary/secondary owners of the OU that the Security Group is contained within.

Security Groups (top ou)

--Application Groups (sub ou)

-- --Application Team1 (sub ou)

Application Team1 OU will have a primary owner (the manager of the application team1 "team")

Application Team1 OU will have a secondary owner (the security group Application Team1)

I want all groups created in the Application Team1 OU to be auto populated with the primary/secondary owner from the parent OU. If the manager is ever replaced, we could change the owner of the Application Team1 OU and it will automatically update all the security groups below it.

 

Hopefully that makes sense. Seems like it would be easy to do, but I'm struggling a little bit.

Thanks

  • +1 over 5 years ago
    IMO, the solution consists of two parts:

    1) The initial population could easily done by a property generation & validation rule within a group provisioning policy that applies these values at group provisioning time.

    2) For updates, I would setup an AR workflow that watches for changes in these values on the parent OU (start condition) and then finds all the groups in the OU (search activity) and updates the owner attributes (update activity).
  • 0 over 5 years ago
    #1 - I figured there was a way to do this with a group provisioning policy - took me a bit to figure out how but now it completely makes sense. Works like a champ.

    #2 - Having a hard time wrapping my head around the workflow part.

    Created new workflow
    - Operation Conditions (I think this is correct) - Modify Properties of type Organizational Unit - managedby and edsvaSecondaryOwners properites

    -Initiator Conditions (I think this is where my problem lies)
    Initiator - Any User
    Container - I'm assuming this is the OU that I want the workflow to "watch" for modification? or is this the OU for the "initiator users" ?
  • +1 over 5 years ago
    -- Initiator is a way to filter by who made the change, Any User is just that, any use that makes the change will trigger the workflow as long as it meets the scope of the other filters.
    -- Container is the location of the objects you are monitoring for the changes -NOT the Users Making the Changes.

    Hope this helps!
  • 0 over 5 years ago
    Thanks, definitely helps.

    I actually configured the "search" and "update" - it worked ONCE. I made a change and now I have no idea how to get it to work again. The more I read, the more confused I seem to get.

    Search Activity - Search in the OU or container - find Groups - IN Parent OU of Workflow Target. Retrieve any objects held in OU or Container (I think all this is fine??)

    Update Activity - This is where it gets a bit confusing. I'm completely new to workflows, so don't be afraid to treat me like a 3 year old.
    Activity target - Found object ("Search for objects")
    Target properties - property "managedBy" set Value Found Object (search for objects")/Parent OU/Manager

    Obviously this doesn't work, but am I at least on the right track?
  • +1 over 5 years ago
    Sounds like you probably are.

    The Update Activity has to be a "child" of the Search - it has to live right in the Search's extended gray box in the workflow workspace area. (Can be hard to see on some screens) When physically positioned that way, you are telling the Activity to act upon each of the objects returned by the Search.

    The internals of your Update activity sound right.
  • 0 over 5 years ago

    OMG - I found my problem. I feel so dumb now.

     

    My workflow Start Conditions is configured to Any User - Container "domain.org/Domain Groups/Access/Applications" - which is looking at OUs under that location. I was changing the Applications OU directly - and wondering why the groups in /Applications were not updating

    When I update any OU under Applications - it works perfectly fine.

    Thanks for all the help and patience. I think this one is working as expected now.

  • 0 over 5 years ago
    Follow up question - still relating to my current scenario

    New groups created - works perfectly fine from the policy, managedby and secondary owner are inherited from the parent OU

    Modification of the OU managedby and secondary owner - workflow kicks in on edit and updates all of the contained groups

    What about moving a group from one OU to another OU? When I move group1 from OU1 to OU2, I do a "check policy" and it comes up as violation. I'm assuming this would be another workflow, triggered by group move?
  • 0 over 5 years ago
    For your move workflow I would suggest the following:

    Trigger on the group move

    ** After the group has been moved **

    Save the object properties of the new OU (Save properties activity - new parent container of workflow target)

    Apply the saved properties from the previous activity to the Workflow Target (i.e. the group)