RBA on the Folder level
Currently Administrators have the ability to set Role Based Access to Collections but we do not have the ability to block access to specific folders. Currently in my environment we have many different departmental administrators who need to manage only their machines and their collections. each time we add collections we then need to grant them access. if the Role Based Administration gave the ability to grant access on the folder level it would reduce the complexity for area's that have a setup similar to mine.
I have attached a screenshot of how my setup looks.
Gary O'Connor commented
I would absolutely love this feature to be available, it would make sorting previously created content sorted easily without going into each application to change the scope
Scott Kissel commented
This is huge when sharing things like Applications with both Server teams and Workstations teams. For example, if you have a folder called Server Apps, and a folder called Workstation apps, and someone else comes along and creates a folder called Software, no one really knows what goes where anymore because:
1) Someone had the rights to create a new folder they shouldn't have
2) They weren't locked down to a specific folder where they could then see all of their scoped apps (i.e. either server or workstation)
Bob Panick commented
The two security mechanisms, collection scopes for users and machines, and security scopes for most everything else don't work.
In theory you can delegate who has access to different parts using collection scopes. The idea might work where you have nice clean separations in business. But the problem is that rarely seems to quite work out that way. There is also a huge problem with update frequency of those limiting collections. All Systems updates fairly quick, but each collection below that doesn't and incremental updates if enabled cause system resource issues. Further the incremental updates aren't smart enough to do the dependent collections first. Which then causes other collections dependent on picking up the changes fail to pick up a change. Maybe if SCCM were smart enough to look at the collection dependencies and evaluate them first, it might work.
Collection security also ends up being a nightmare trying to scope properly. About the only real use it seems to have is in reporting.
Security Scopes for everything else have to be set by an administrator. Our SCCM system has hundreds of items that we would have to set security scopes on. Further, we don't have an easy way of seeing that something new has been added that doesn't have scope set. Yeah, we could write a query or report, but that's a poor workaround.
What we need is to be able to set security on the folders themselves. If you don't have access to the folder, you can't see child folders, collections, etc... This would work with things that get created, it could be used to control application distribution, and a lot more without a lot of administrative work.
If I wanted to give a business unit access to collections that covered their unit, I could simply create a folder for the BU, and add the collections I want them to have access to. Lets go further and set that they can only use the collections for reporting/read only, or that they can target software distributions to them, etc...
Folder security for everything in the Software Library would be a lot simpler to manage. For instance read and distribution only access to centrally administered objects, and full control to a BU folder for that BU, and read and copy for everyone else.
Or Server and Workstation administration with folder level security to allow the two separate IT teams not to mess up each other's stuff.
Justin King commented
If you create collections _as_ folders then assign RBAC to those you get the desired result.
For example create to root collections: Dev and Prod. Every collection after that should use either of those two as a parent, and you merely place your RBAC roles on said parent collection. It works well, the only downside being you end up with LOTS of collections.
Heck I created a DSC Module to help me build out a default structure for clients. It works well.
Michael Schultz commented
I would rather assign permissions to folders with or without recursive and collections and never have to touch scopes again.
Kara Hoponick commented
It would be great if you could apply a security scope to a folder to prevent accidental deletion, and to also allow that scope to propagated down to objects within the folder
Matt Hawkins commented
This is a needed change. I currently have customers that need to run scripts periodically to change scoping on the contents of folders to get this functionality.
This would save alot of effort and time on locking down environments that have more than administrative group working within the same site. +3 votes here
this will be really helpful and save lot of manual effort for admins
Fabio RINCON commented
+3 on this item, I see huge benefits for RBA on the folder level. We have over 200 sites with numerous collections throughout many locations. Having RBA on the folder would allow us to keep their containers locked down even further.
Jason Kellar commented
to explain better i would like to see permissions to the folder in combination with or replacing collection level permissions. i needed to delete old wsus collections and to do this i had to first remove access from all other roles. this took up a large amount of time and could easily be avoided.
Rube Rahman commented
+1 on this. This gets very cumbersome since RBAC allows you to onboard multiple IT teams into SCCM but then you face this burden of keeping them there.
Allowing folders to be securable objects would be a tremendous improvement for large environments.
marc graham commented
I concur on this as it would also make securing applications/packages down as well which is useful when both development and production are being managed in the same CM environment.