If you are new to System Center 2012 Configuration Manager and learning the new Role Based Authentication (RBA) model you may not initially grasp the concept that you grant a user a role and scope to define their security access. I find this gets people a little confused some times. The role is the set of abilities a user is given. To compare to some thing people are more familiar with, Administrator role means you can do things in AD like crate accounts, stop services, etc. That’s fine, but then the question is WHERE you can do these actions. A local administrator has a different set of objects they can affect compared to a Domain Administrator. This is their scope (local or domain). In ConfigMgr you grant a user a scope to define what objects in the hierarchy the user is allowed to exercise their actions against.
Said one more time for clarity, a security role defines the actions you can take, the scope defines on what objects you can take those actions.
Now, the scenario I recently hit with a customer was where they had a CAS and a primary site. They created a scope, called Pri1, and tagged the primary site object to be part of this scope. They then granted a user the Full Administrator security role, but only on the Pri1 scope. This let the user administer and run the primary site, but not touch the configuration on the CAS. We got down to setting client settings from the Primary, and couldn’t see them. They are considered a part of the CAS site, where no rights were granted. Now, how do we let the user at the primary access these client settings but not have full permissions over the CAS? If we simply added them to the CAS scope, they would combine that with their full administrator permissions and be able to do far more than desired. The answer is in this screen shot:
The names used in this screen shot are different, but the key is the use of the 3rd radio button, and not the 1st or 2nd. We want to Associate the assigned security roles with SPECIFIC security scopes. To follow on from my earlier example, we need to add the read permission to the CAS site, leaving the Full Admin permission attached only to the Pri1 scope and specific collections.
For some of you this might be enough for the “lite bulb to go on,” but in case you weren’t so lucky, here are the steps you should be taking to set up this user in this scenario: