As you have seen, when you directly change permissions on a group for example, they only affect that object; they are not inherited by any objects within that object.
What I find most admins do is they define and then apply ACL Templates to the top level folders by right-clicking and selecting Update Permissions, and then choosing the appropriate ACL Template. When you perform an Update Permissions on a group, it will recurse into all sub-groups updating the permissions of all objects that are encountered.
The only way you can automate this is by using the BLCLI. You could write a simple script which applies ACL Templates to specific folders on a regular basis so that you don't have to do this manually all the time.
The only "gotcha" you need to look out for are nested Smart Groups. Consider this scenario:
- Someone creates a Smart Group in a sub-folder called "All Objects" containing all objects they have read access against.
- You apply your ACL Template at a top level group to recursively update the permissions of all objects within that group
- The Update Permissions gets to the Smart Group and updates the permissions of all objects within that smart group, potentially updating objects that you didn't intend to update
The only place the recursion doesn't seem to hold true is in the property dictionary.
Right after I posted this message, I looked at what I was trying to do again.
I realized that ACL assigments worked as I have expected, but I was just looking at the outcome incorrectly.