2nd Jan 2016, continuing with the doing-nothing-while-on-vacation series.
You can assign access Collection access to Administrative Users. However keep in mind the following:
- If your objective is to ensure limited visibility of collection results, then see to it that you do not grant access to the All Systems collection. You have to have what I call a Top-Level Collection in lieu of the default collections (including All Systems). Ensure that the membership of this Top-Level collection is limited to the objects you want the specific admin to see. Use specific conditions, e.g., OU membership, computer name, etc., to populate. Also keep in mind that the objects are still available in Queries, so if you really need to ensure non-visibility of objects, deal with Queries as well.
- Use this Top-Level collection as the limiting collection for all other collections that you would create. Do not use the All Systems collection because if the user account does not have access to All Systems, then the user account will always see 0 membership. Remember: the user does not have access to the Top Level collection (ergo, 0 members) and you created a collection that limits itself to the All Systems collection (again, 0 members), and you’ll get a collection of 0 members!
So for example you want to create an RBAC role to be able to deploy Applications and Patches to machines from the APAC region:
- Create an APAC Top-Level collection, using All Systems as its limiting collection using OU membership as its criteria.
- Create a second collection of with APAC Top-Level as its limiting collection, and add the additional conditions that it is a ConfigMgr client and it is a workstation OS . Let’s call this APAC Clients
- Create an AD Group APAC Deployment
- Add this group in ConfigMgr Administrative Users, and grant access to the APAC Clients collection. Also assign it the RBAC Role nearest to the deployment role you want, or customize the role further to get the actions you want this role to perform.
Screenshots to follow once I’m back in my lab. Too bad I haven’t installed my ConfigMgr lab in Azure yet at this point in time.
jay paloma | 02 jan 2016 | manila
It’s 2 Jan 2016. Happy New Year 2016! I am currently in vacation in my hometown in Manila (am based in Singapore), and to spend some quality time, I want to write another chapter in the ConfigMgr RBAC series.
In continuation of our series on ConfigMgr RBAC, let’s now take a look at some practical applications of Role Based Access Control in ConfigMgr.
First, division and compartmentalization of Responsibilities. To do this, customize RBAC Roles and assign into different AD Groups but having access to all collections.
Secondly, division and compartmentalization of Objects. To do this, you can use some high-access RBAC Role like Operations Admin but ensure that permissions are assigned only to specific collections, and never assign permissions to the All Systems collection. Do note that as a caveat to this, you cannot assign permissions to any collection that use All Systems as its limiting Collection. Therefore you should create a collection that use All Systems as its collection, then use the newly created collection as a Limiting Collection for the collections that you could assign permissions to.
All Systems –> Limiting Collection of CollectionB –> Limiting Collection of CollectionC <– Assign permissions
Thirdly as hybrid division and compartmentalization of both Objects and Responsibilities. This one is just a combination of both. Something like this setup:
- APAC Admins
- APAC Packagers
- APAC Deployment
- EMEA Admins
- EMEA Packagers
- EMEA Deployment
- HQ Admins
- HQ Packagers
- HQ Deployment
You have 3 regions: APAC, EMEA and HQ and you have 9 sets of admins as shown above. So you have at least 3 sets of collections (APAC, EMEA and HQ) and 3 sets of admins for each region (Admins, Packagers and Deployment), and ensure that APAC Packagers can only package apps intended for APAC, and not EMEA and HQ, and cannot perform any other administrative task or deploy stuff.
If you have this kind of setup, do ensure that you thoroughly check the implementation of RBAC. Also, my experience to this is that since your working collection is 3 layers down (All Systems –> CollectionB –> CollectionC in the above example) do not go cheap on your database server.
As I am right now not in my lab, I cannot have screenshots to show. However I will update this document when I get back after vacation.
jay paloma | 2 jan 2016 | manila
Implementing HTTPS on ConfigMgr 2012 R2This video explains how to configure Internet Based Client Management (IBCM) on System Center 2012 R2 Configuration Manager.
An important component on implementing IBCM is to implement HTTPS. I have another video series on Implementing HTTPS on ConfigMgr 2012 R2.
As of the time of posting, I am still figuring out how to switch Internet/Intranet clients without requiring a firewall (just for purposes of demo). However in a nutshell, the absence of the Domain Controller renders the client an “Internet” client. I will update the post when I stumble into a development.
If you have an company-managed iOS, device you better hold off that iOS 9.2 upgrade.
Word has it that it breaks some Mobile Device Management (MDM) capabilities.
I have 3 devices prompting for an iOS upgrade, and this affects me personally. So I will keep this blog post updated with developments as information becomes available.
System Center Configuration Manager helps IT manage PCs and servers, keeping software up-to-date, setting configuration and security policies, and monitoring system status while giving employees access to corporate applications on the devices that they choose. When Configuration Manager is integrated with Microsoft Intune, you can manage corporate-connected PCs, Macs and UNIX/Linux servers along with cloud-based mobile devices running Windows, Windows Phone, iOS, and Android, all from a single management console.
Implementing HTTPS on System Center 2012 R2 Configuration Manager – Part 4 Configuring the ConfigMgr Services for HTTPS
This is Part 4, the last of the video series on Implementing HTTPS on System Center 2012 R2 Configuration Manager. This one explains how to configure MP, DP, SUP and RSP for HTTPS.
Implementing HTTPS on System Center 2012 R2 Configuration Manager – Part 3 Enrolling the Certificates
This is Part 3 of the video series on Implementing HTTPS on System Center 2012 R2 Configuration Manager. This is a very short video on enrolling the certificates.
Remember: your certificate enrollments would now depend on the global group memberships you established in Part 1.