You need to identify what object types the role will need permissions on and what level of access. once you do that, you can create an ACL Template that contains all of those permissions and then use the acl template to recursively assign acls to objects for example you can right-click on a folder and choose 'update permissions' and this will recursively apply acls to all objects in that folder.
Thanks for the response Bill. I've been pouring over videos and documentation on the web to try to understand what is going on. Here is what I've come up with.
In the BSA 8.5 Documentation, on Page 241, entitled RBAC Permissions for Patch Management. I would like to give our operators access to do the third row of options, which is "Perform all operations related to Patch Autoremediation Jobs (Patch Analysis and Patch Remediation)"
Here is what I think I need to do, and correct me if I'm wrong.
1) Create the Role
2) Create a Authorization Profile Matching Authorizations listed in the document
3) Assign that Auth Profile to the Role from Step 1
4) Assign the user(s) needing that auth profile to that role
Now is when things get tricky...
5) I need to create a ACL Template, containing all the Authorizations found in the document, assigning them to the role I created in Step 1
6) Go to each object that this role will need to touch and apply that template to it recursively (meaning appending all the permissions with this ACL Template).
I think I have that right. I tried to update the permissions on one of the Patch Catalog Smart Groups and it took a LONG time.
Last question, I want to be able to "shrink the world" (tips hat to you guys for throwing out this analogy in the webinars) the Operators are able to see. For instance, if I'm going to store all the Remediation Artifacts a couple layers down in the folder structure, I obviously have to give them read to all the layers above, right? And if they don't have read on any layer of the tree, it won't appear at all in the console, correct? (I know, I slipped an extra question in there...)
Thanks again for all the help you have given me over the past couple months. I know I have had a ton of questions.
1 of 1 people found this helpful
for #5 you can use the same authprofile to drop those permissions into the template.
one thing you can do, if you know that when you create objects as one role, you always want some other role to have some level of permissions on those roles is to create an acl template that grants the permissions you want and then in the creating role you can set this template as the 'default object permission template' so everytime the creating role creates something it will grant whatever auths to the other role(s) on the new object.
but for existing objects that don't have the right acls, applying the acls is the only option.
so w/ the view - right - they'd need read down to the folder location. in blasadmin theres a setting called 'ShowNoAccessNodes' in the 'ConfigManagerUI' section - if you set that to false, that will hide the locked folder icons so the user would only see what they have read on.
Thanks for the response. I have one question about applying the default ACL template to the role creating the patching artifacts. In my case, the roles would belong to the BLAdmins role, and they would be creating those artifacts to be opened by another role, lets just called it OpsPatching for now. In the ACL template, would I have to put BLAdmins in to get basically all the .* auths, as well as the OpsPatching role to get my Auth Profile, so that once the packages are created BLAdmins still has right to it, or since they created it, does that give access by default.
Was a little confused on how that worked, because I would have to assign the default ACL to my BLAdmins role, which all my sysadmins use on a daily basis, so I thought if I gave the additional access to the OpsPatching role, basically everything they created would also be given to the OpsPatching role as well.
I hope this makes sense.
the role creating the object should get * on the new object even that's not in the 'default opt'. and it would mean that every time BLAdmins creates a patching job (for example) it would assign the patching role some level of permission to it - assuming the default opt for BLAdmins only has like PatchingJob.blah in it. but you are right - the default opt affects everything. otherwise the role creating the objects would need to remember to set the perms during the creation in one of the object creation wizard panes.
I think I'm getting closer to the end goal here. I've worked through many of the permissions, (I let the Window Patch Catalog Permissions push over the weekend, it took quite a few hours to go through all that.) and it seems to be getting there.
I've turned off the ShowNoAccessNodes and that seems to be working well. I'll tell you, I didn't know so many things had permissions on them until you start working with a role that doesn't have BLAdmins. I tried to reboot a server as the limited user and realized I couldn't see any of my custom commands. I figured that one out on my own though.
Now it's just a matter of going back through all the things we've created since the beginning and determining what they do and don't need access to.
Ran across a interesting problem related to this, and I was wondering if you (or someone else) may have some insight on what to do.
3 months ago, I pushed permissions to our Patch Catalog and all the underlying smart groups. All is working well, and we're beginning to push some duties to our Operations Team. However, today, I found an issue. All the patches which have been added to the catalog since I pushed permissions have default permissions applied. If the Operations team runs an analysis, it comes back with 0 patches missing. If I (as BLAdmins) run the same job against the same server, it comes back with 5 missing. Obviously, the patches which are new do not have permissions allowing them to scan them, so it's coming back with 0.
How would I be able to fix this issue without having to push permissions every time the catalog is updated, as that process takes upwards to 12 hours to complete.
in the catalog there is a 'rbac acl policy' selection. create an acl policy that grants the perms you want and associate it here.
Well, would you look at that! Another problem solved! Thanks Bill!