The new role based administration feature in ConfigMgr 2012 is no doubt one of the best features and a major reason to
upgrade, sorry, migrate to 2012. There are a few caveats to using RBA successfully and I wanted to note some of those things here.
High-level Overview of Role Based Administration
Administrative Users – The users or groups that you granting access to. Groups are always recommended as a best practice.
Security Roles - The actions that can be performed on securable objects.
Security Scopes – The collections and securable objects.
- From a high-level general process, you add the user/group, then pick the security roles they will have access to, then assign the security scope and collections.
- Use groups instead of individual users.
- You cannot add a user/group from another forest/domain unless you have a two-way trust with that domain. If you cannot validate the group and get the SID, you cannot add it from the console. It might be possible to add the group through the SDK.
- You can copy the existing security roles and create custom roles. These can be exported or imported, this is a great opportunity for the community to develop common roles that are not included by default.
- If you don’t need all the permissions in the default security roles, then create a custom one that fits your needs.
- Don’t forget to assign your custom security scopes to your Site and Distribution Points/DP Groups if you are using custom scopes.
- These are inherited by default on new objects. We don’t need an inheritance script like was commonly used in ConfigMgr 2007.
- Only assign the limiting collection, you don’t need to add any collection that is limited to the limited collection as you will already have rights to that collection. Example: If you give someone access to "All Systems" then they automatically have access to "All Desktop and Server Clients".
- You can combine security by using the "Associate assigned security roles with specific security scopes and collections". It is possible to grant rights to collections and security scopes, but grant an entirely different set of rights to another security scope and collection. So you could give someone Read-Only Analyst to the All Systems collection to prevent them from deploying to it, even if they are a Application Administrator to other collections.
Folders don’t have security scopes, it’s a all or nothing deal. If you give someone access to folders, then they will see all folders. (Modify Folder permission)
- Even if you can’t see the objects in the folder, for example the collections, you can still see the folder.
- You can place your collections in someone else’s folder, they won’t see it unless their security scope allows them to see the object.
- Instead of using Folders for collection organization, use the search feature.
- If you need to use folders, then use a common set of folders that multiple groups can work with, again they will only see the collections/objects they have access to.
- Site read permission is required for the site to show up in the Client Push wizard. "Install the client from a specified site", the security scope also has to be defined on the Site if you are using custom scopes.
- You need to remember to assign the security scope to your Distribution Points and Distribution Point Groups in order to select them in the Create Deployments wizards.
- You need "Modify Folder" permissions to create Collections (confirmed bug)