During last week’s System Center Universe Asia Pacific, there was a question raised during the Ask the Experts portion on how Microsoft can address BYOD while ensuring that corporate security is still maintained, the Experts in the panel were not really able to address the required architecture.
I was formerly connected with Citrix, and right there I immediately thought of Citrix XenDesktop. However being in a Microsoft event I decided to keep my mouth shut and just decided to share the solution by writing about it. So here it is!
The solution is to allow the personal devices to connect to VMs. These VMs are connected to the corporate network, while the personal devices are in some sort of protected network which is separate from the corporate network, and is only allowed to use the protocols necessary to allow the client to connect to the VMs.
Since the solution requires VMs. using Hyper-V is the way to go. No discussion here.
For this solution to work, there must be some technology that does VM provisioning. This is where the Citrix XenDesktop product comes in. You can dynamically provision VMs as needed.
The VMs can be shared VMs deployed with the same apps, or app deployment can be performed dynamically as the VM is being provisioned using either Citrix XenApp, or using Configuration Manager.
Just to be sure, some sort of health checking is prudent before the personal devices can be connected to the personal devices network. Also, they have to be enrolled to allow for authentication and encryption.
So does this solution work? Yes it does, and one great experience I had with Citrix is that BYOD and non domain joined devices are the norm!
This blog post is about my personal gotchas! in implementing Role Based Access Control in System Center 2012 R2 Configuration Manager.
When implementing Role Based Access Control in Configuration Manager, I personally recommend that the consultant come up with conditions in the whole RBAC space and ensure thorough testing of these RBAC roles, with very specific success criteria.
Perhaps the first potential issue I would emphasize to the consultant is that Reporting Services would probably be the first collateral damage in implementing RBAC, so ensure that this one is your primary test criteria. Why? If we limit the RBAC roles, especially Security Scopes, to objects that directly affect the client (e.g., applications, DP, etc.), then Reporting Services will not work. I will write a separate blog post on this issue, but the quick solution is to ensure that a Security Scope is created that includes the Site container, and should be given also to all RBAC roles that require reporting.
If your primary RBAC requirement is that exclusive visibility to client computers for different client admins, your RBAC focus is on Collections. Your first move is to ensure that the client-administering RBAC roles do not have access to All Systems (which contain, of all things, all your servers that have installed CM client). But doing so would mean you cannot use All Systems as the Limiting Collection of all other collections required by these admins (the resulting collection will not contain any objects). Therefore, you need to create one collection each for the client-administering groups, and this collection should contain all the computers that the said group can administer, and should not contain any computer that should not be administered by that group. This collection will now be used as the Limiting Collection of all other collections that these admins will create.
- EUROPE Client Admins – Collection that only contain EUROPE computers
- APAC Client Admins – Collection that only contain APAC computers
- EMEA Client Admins – Collection that only contain EMEA computers
It is highly recommended that you use Incremental Updates on these collections so that the memberships update every 5 minutes by default.
Security roles in Configuration Manager answer the question Where could the operation be done?
There are two built-in security scopes: All and Default. All is not assignable to any object. Default is initially assigned to new objects. It can be removed later on if the object is assigned another security scope.
You can assign security scopes to the following objects:
- Alert subscriptions
- Boot images
- Boundary groups
- Configuration items
- Custom client settings
- Distribution points and distribution point groups
- Driver packages
- Global conditions
- Migration jobs
- Operating system images
- Operating system installation packages
- Software metering rules
- Software update groups
- Software updates packages
- Task sequence packages
- Windows CE device setting items and packages
Examples of security scope applications
- Security scopes for test and production applications.
- Security scopes for different groups in the organization that are administered by a different team.
- If different Sites are intended to be administered by different teams, create a security scope per site, and assign it to the respective teams.
Security scopes can be customized based on how they are intended to be applied. Ensure that your security scope design is simple as possible so as not to subject unnecessary load onto the Configuration Manager databases
Security roles in Configuration Manager answer the question What operation could be done?
The following are the default Security Roles available in Configuration Manager 2012 R2
- Application Administrator – Grants permissions to perform both the Application Deployment Manager role and the Application Author role. Administrative users who are associated with this role can also manage queries, view site settings, manage collections, edit settings for user device affinity, and manage App-V virtual environments.
- Application Author – Grants permissions to create, modify, and retire applications. Administrative users who are associated with this role can also manage applications, packages, and App-V virtual environments.
- Application Deployment Manager – Grants permissions to deploy applications. Administrative users who are associated with this role can view a list of applications, and they can manage deployments for applications, alerts, templates and packages, and programs. Administrative users who are associated with this role can also view collections and their members, status messages, queries, conditional delivery rules, and App-V virtual environments.
- Asset Manager – Grants permissions to manage the Asset Intelligence Synchronization Point, Asset Intelligence reporting classes, software inventory, hardware inventory, and metering rules.
- Company Resource Access Manager – Grants permissions to create, manage and deploy company resource access profiles such as Wi-Fi, VPN and certificate profiles to users and devices.
- Compliance Settings Manager – Grants permissions to define and monitor Compliance Settings. Administrative users associated with this role can create, modify, and delete configuration items and baselines. They can also deploy configuration baselines to collections, and initiate compliance evaluation, and initiate remediation for non-compliant computers.
- Endpoint Protection Manager – Grants permissions to define and monitor security policies. Administrative Users who are associated with this role can create, modify and delete Endpoint Protection policies. They can also deploy Endpoint Protection policies to collections, create and modify Alerts and monitor Endpoint Protection status.
- Full Administrator – Grants all permissions in Configuration Manager. The administrative user who first creates a new Configuration Manager installation is associated with this security role, all scopes, and all collections.
- Infrastructure Administrator – Grants permissions to create, delete, and modify the Configuration Manager server infrastructure and to perform migration tasks.
- Operating System Deployment Manager – Grants permissions to create operating system images and deploy them to computers. Administrative users who are associated with this role can manage operating system installation packages and images, task sequences, drivers, boot images, and state migration settings.
- Operations Administrator – Grants permissions for all actions in Configuration Manager except for the permissions that are required to manage security, which includes managing administrative users, security roles, and security scopes.
- Read-only Analyst – Grants permissions to view all Configuration Manager objects.
- Remote Tools Operator – Grants permissions to run and audit the remote administration tools that help users resolve computer issues. Administrative users that are associated with this role can run Remote Control, Remote Assistance and Remote Desktop from the Configuration Manager console. In addition, they can run the Out of Band Management console and AMT power control options.
- Security Administrator – Grants permissions to add and remove administrative users and to associate administrative users with security roles, collections, and security scopes. Administrative users who are associated with this role can also create, modify, and delete security roles and their assigned security scopes and collections.
- Software Update Manager – Grants permissions to define and deploy software updates. Administrative users who are associated with this role can manage software update groups, deployments, deployment templates, and enable software updates for Network Access Protection (NAP).
For details on each RBAC role, download the Matrix of Role-Based Administration Permissions for ConfigMgr 2012.
To copy an existing Security Role to a custom one
1. In Configuration Manager Console > Administration workspace > Overview > Security > Security Roles, right-click the security role you want to customize, and click Copy
2. in Specify details for the customized copy of the selected security role, add a name and description, and modify the permissions as necessary. Click OK.
HAPPY NEW YEAR 2015! Role based access control (RBAC) has gone a long way in Configuration Manager 2012 R2. Some find it too complicated. In this series, let’s break RABC down into its more basic components so we could understand it better.
- Part 1: Understanding RBAC in Configuration Manager
- Part 2: Configuration Manager RBAC – Security Roles
- Part 3: Configuration Manager RBAC – Security Scopes
- Part 5: Configuration Manager RBAC – Collections
- Part 6: Configuration Manager RBAC – Implementation
- Part 7: Configuration Manager RBAC – Testing and Potential Issues
- Part 8: Configuration Manager RBAC – Practical Applications
Role based access control in Configuration Manager 2012 R2 requires understanding on these three
- Active Directory Groups are used to grant the Security Roles in Configuration Manager. Although User Accounts can be used as well, the best practice is that Active Directory Groups are assigned the permissions, and meanwhile user accounts can be added or removed from the AD Groups according to the needs of Configuration Manager
- Security Roles assigns permitted operations on specific Configuration Manager objects.
- Security Scopes are used to assign which instance of a specific object are the operations un Security Roles be performed. For example, without Security Scopes, a Security Role that could manage Distribution Points has the ability to perform the required operations on all DPs. However with Security Scopes, the operations could be limited to specific Distribution Points
If you’re implementing Configuration Manager in an enterprise network environment, you probably would have had the need to take a look at the Technical Reference for Ports Used in Configuration Manager. That is a very concise source of all the ports that you need. However, in my personal experience one still tends to miss out on the details of the ports needed. Also there are things that one may overlook. Allow me to summarize the more important ports needed.
Remember that all your CM servers, whether they are site servers, database servers, etc., are domain members. Therefore you need to ensure their connectivity with your Active Directory services. These include DNS, Kerberos, LDAP, Global Catalog, etc. Details in this post Active Directory and Active Directory Domain Services Port Requirements.
CAS to External WSUS
- CAS > WSUS TCP 8530, TCP 8530 (TCP 80, TCP 443 if this option is selected)
If you are using a WSUS server which is not installed with Configuration Manager, your CAS should have TCP8530, TCP8531 connectivity. Needless to say your WSUS should be connected to the Internet.
- Site Servers > Database Servers: TCP 1433
- Database Servers < > Database Servers: TCP 1433, TCP 4022
Your Site Servers and your Management Points should connect to your SQL Server database servers using TCP 1433. If you’re using CAS, all your Site Servers should be able to connect to the CAS database.
All your database servers need to replicate with each other,
Between Site Servers
- SIte Servers < > Site Servers: TCP 445, TCP and UDP 135, UDP137-138, Dynamic Ports
I emphasize that these are bi-directional.
Between Site Servers and Site Systems
- SIte Servers > Site Systems: TCP 445, TCP and UDP 135, UDP137-138, Dynamic Ports
Note that all your server roles are Site Systems (database, MP, DP, FSP, etc.) During the Site System role installation, there is an option to Require the site server to initiate connections to this site server, which is enabled by default. If you prefer this option, then the traffic is one way from Site Server to Site System. My take is that your site servers/site systems within your datacenter should be bi-directional. If you do have DPs that are not within your central datacenter (i.e., remote DP), make this uni-directional to avoid the Configuration Management Console from working from an external source.
Client to Site Server
- Client > Site Server: TCP 80, TCP 443, TCP 10123, TCP 8530, TCP 8531
Do note that all your Configuration Manager servers may have been installed with CM client, maybe for patching.
Configuration Management Console
- CM Console > SMS Provider: TCP and UDP 135, Dynamic Ports
- CM Console > Application File Share: TCP 445
To my personal experience, these FW ports are overlooked a lot of times because admins usually administer from the CM console while connected to a Site Server either physically or via RDP. However if you implemented a CM Console on another machine which is not running any other CM role, then these ports are required.
The second bullet point is one gotcha! that I discovered because it is not included in the Microsoft list of ports. It is always assumed that the console is running on a site server, and that the file share source is on one of the Site Servers, probably the CAS. If in case the CM Console being used or the file share is not on a SIte Server, and if TCP 445 is not available from the Console to the file share where the application bits are stored, then our software library will be empty because we won’t be able to create anything (applications, packages, OS, software updates), since they require to be saved to a file share.