When you create an
Intune tenant within your environment, you execute the creation with an account
which is Global Administrator within Azure Active Directory. And in my work as
an indendent consultant I see a lot of companies which keep using the account
with Global Administator rights to manage their Microsoft Intune environment as
While for initially
setting up some Azure AD functionality Global Administrator rights might be
needed, this is only the case during the setup phase. Once you have implemented
your environment, you hardly ever need the Global Administrator rights and for
most tasks they are not needed perse. Think of the Global Administrator rights
as an equivalalent of the Forest Administrator/Schema Administrator group
within Active Directory.
Disclaimer: This post is written on December 4th 2019 and reflects the state of this functionality at that point in time.
At a customer of mine a issue with Incident Requests in System Center 2012 R2 Service Manager was reported. Some users reported that they received the error:”Failed to execute Submit operation. Fix the reported error before… – The user <domain>\<accountname> does not have sufficient permission to perform the operation.
Full error in the console was:
This blogpost will detail my experiences and insights gained from implementing Role Based Access Control (RBAC) in a System Center 2012 R2 Service Manager environment.
After installing Service Manager a couple of so called User Roles are created:
- Report User
- End User
- Read-Only Operator
- Activity Implementer
- Change Initiator
- Incident Resolver
- Problem Analyst
- Change Manager
- Advanced Operator
In its simplest form you should simply add Active Directory groups to one of the groups above and users member of that group will receive the corresponding rights. Microsoft has outlined what each User Role profile can do in the following article on TechNet: Appendix A – List of User Role Profiles in System Center 2012 – Service Manager – http://technet.microsoft.com/en-us/library/hh495625.aspx
In the first part of this series I outlined what Microsoft changed in ConfigMgr 2012 in order to introduce Role Based Access Control. In the second part I outlined a possible scenario and started building the scenario. In the third part we mapped the business roles to the ConfigMgr roles and configured them in the ConfigMgr console. In this part we are going to see, what the outcome of this mapping has become.
SSC Operations Administrator
The SSC Operations Administrator can manage the whole environment, except for the security. As you can see, when a SSC Operations Administrator opens the ConfigMgr Console, he isn’t able to modify the security under Administrative Users.
In the first part of this series I outlined what Microsoft changed in ConfigMgr 2012 in order to introduce Role Based Access Control. In the second part I outlined a possible scenario and started building the scenario up to the point where the OpCo roles will be mapped to the ConfigMgr roles, this post will discuss the steps taken.
For the purpose of mapping the Customer roles to the ConfigMgr roles I created a spreadsheet to help out. Make sure that you understand what each OpCo needs to be able to do, and try to map this using the default roles. If not create a custom role and integrate this role into the matrix. My matrix turned out something like this:
In the previous post I introduced Role Based Access Control in ConfigMgr 2012 as the new way to delegate administrative access to a ConfigMgr hierarchy. In this post I’m going to walk you through a scenario and show you how we can delegate the access in order to meet the requirements.
The Customer is a very large company, which has a Shared Service Center responsible for the ConfigMgr environment. Each OpCo has its own IT department which manage their own servers and workstations. In the past each OpCo had their own Primary Site, and they should now be able to operate the environment in a similar way, while the Shared Service Center manages the environment. With operating you should think about:
- Create Packages and Applications
- Create Task Sequences
- Specify their own Client Settings
- Create Deployments
- Install Distribution Points
The company wants to facilitate sharing between OpCo’s though, therefore objects created by OpCo’s should be able to be shared
One of the reasons to install multiple primary sites in a System Center Configuration Manager 2007 hierarchy often was due to the fact that Administrative access had to be separated between different departments within a company. Within large companies mostly a Central Primary Site would be installed, not servicing any clients, and under that Central Primary Site, several Primary Child Sites would be installed for each OpCo needing their own administrative boundary within the hierarchy.
With ConfigMgr 2012, this has changed for the better. Because Microsoft wanted to simplify the hierarchy for ConfigMgr 2012, they introduced several techniques to partition a Primary Site for use by multiple administrative departments. I often notice though that I have a hard time to convince people of the fact that for security reasons it’s not necessary anymore to create multiple primary sites within a hierarchy. There are of course reasons to create multiple primary sites and a Central Administration Site (CAS) above them, but they are often “non-technical” or due to scaling.
In ConfigMgr 2007 we used Object Access, where we could give a user or group access to either the entire class of object, like all collections. Or you could give access to only an instance of an object, like the All Windows 7 Computers collection. This was a nightmare to manage though, and quickly became very complex in large implementations. More information can be found in the Classes and Instances for Object Security in Configuration Manager for ConfigMgr 2007 article on Microsoft Technet.