Join David M. Franklyn for an in-depth discussion in this video Planning and configuring role-based administration, part of Microsoft System Center Configuration Manager Essential Training.
- [Narrator] Now we'll look at planning and configuring role-based administration. So, role-based administration helps ensure that a user who connects by using the Configuration Manager console, or you can also do this in Windows PowerShell, but you can view and modify only those Configuration Manager objects that that user has permission to manage. This will reduce the chance that a user can perform unauthorized actions. Role-based administration also simplifies the auditing of administrative actions, making it easier for you to determine who performed a particular administrative task.
So we start this by going to the Administration workspace. And then you'll note we have the security node within the console tree. We can expand that. And then we see the administrative users that we have. Now right now, we only have the domain administrator, the person we're logged in as in the security role called Full Administrator. But we can see the different security roles that are available, and there are several of these. Each one of them have a particular set of permissions that they have to do various things.
Of course, the full administration can do everything. And all the others will have aspects of some of the full administration. So, you can create your own administrative users. An administrative user includes an Active Directory user or group account, one or more security roles, one or more security scopes, and collections as necessary. Now, the best practice is to create administrative users by specifying an Active Directory security group.
Security roles are collections of permissions to perform administrative tasks. Security groups are groups of securable objects. When you think about this, when I, in a corporate environment, want a particular duty that a person might have to do a specific thing, it would be better for me to create that based on that user's duty than the user inherently themselves. So it could be as simple as we have an IT administrator. We have lots of IT administrators.
We have IT administrators as individual people who come and go, leave the company, get another job, whatever reason, or are new hires. We don't want to recreate these administrative users every time a new person comes in. So by placing them in an Active Directory group and then assigning that group the administrative user role, we don't have to come back and change it, just change the candidates who are in that group. To this end, let's check out the domain and see what we have there.
So here we are, back on the DC1 domain controller which is the forest root, and let's go to the Tools menu in Server Manager and then select the Active Directory Users and Computers. And in this case, we'll expand the domain in the console tree, and we see we have created an actual organizational unit named IT. And in it, we have a Junior IT person security group and a Senior IT person security group.
We also have a user named New IT Person and a user named Veteran IT Person, and they're in each one of these groups. The New IT Person is in the Junior IT group. So now let's go back to the Configuration Manager computer and look at our security roles again. So in this case, suppose we want the Junior IT administrator group, the Junior IT administrators, to be able to do some things but not everything.
Suppose we want them to be a software update manager, we could actually put them in this role. Additionally, when it comes to role-based administration, we can set security scopes which apply to the different objects that they will have permission to. So one, we have the role which is what they're doing. In the security scopes, we have whatever they're doing to. So we're going to go and add a new administrative user here by right-clicking Administrative User and Add User a Group.
And in this case, we're going to use the Junior group we had. Just type that in and click Check Names. And we have Junior IT. That's the name of the group. And we're going to assign a security role to it. And in this case, we could use the Software Update Manager. And once that's done, now the person in that particular role will be able to do anything related to software updates if we so desire to put in that functionality. When we go to the security roles, we now see in the Software Update Manager, it has a user account of one.
We can double-click that. We can see the permissions that are available. When we go through these permissions, each one of these main permissions are actually expandable to see the sub-permissions that are inside of it. So let's click on that. And you can see in this case, for Alerts they can do pretty much everything. But for Boundaries which we'll talk about later, they can read them and that's all. If we go down to Software Updates which really is what this role is going to do, they can create, delete, and do everything including run reports.
We might decide that this person is too junior and we don't want them to do any deletes. So if we do this, we would make a copy of the role and add the person to it. In the security scopes, you can see right now we only have All which is everything and Default which really is everything else. We're not going to make any here. Our goal was simply to make a role-based administrative user. And since we have done that, that completes the demonstration.
- Planning and deploying a standalone primary site
- Ensuring domain and site server prerequisites
- Planning and expanding a standalone primary site
- Planning and deploying a multiple-site hierarchy
- Planning resource discovery and client deployment
- Managing content and replicating data in Configuration Manager
- Configuring Internet and cloud-based client management
- Advanced monitoring
- Upgrading to Configuration Manager current branch