Let’s talk about assignment strategy. Say you have an environment of 10,000 users. Each user has a mobile device. You want all users to get access to standard settings such as the corporate Wifi, in-house mobile apps, and email. But for about 100 executive users, you want to make sure that they have more privileges on the Wifi, for example for Facebook or Youtube. How do you do make all of this possible? How do you assign the right configurations to the right groups of users?
One way to do it would be through group membership. The above diagram shows a high-level overview of how this can be set up in a hybrid environment. In a hybrid environment, user accounts are synced from on-premise to a cloud-based identity management system. In the cloud there are basically two different types of groups: dynamic and synced. Synced groups are a 1-for-1 duplicate of their respective on-premise counterparts. Dynamic groups are created in the cloud and automatically populated based on account attributes such as being enabled, location, etc. As you can see in the diagram, user accounts can be added to both synced and dynamic groups. This is important because you can assign configuration policies to a group. Doing so gives all the user accounts within that group access to the configuration policy.
Now what policies do you assign, and to what groups? First you will have to decide if you will have a “standard” package of policies. For example, are you confident that literally all of your devices are going to have a passcode policy, or will have access to certain apps? If so, then what you will want to do is assign all of these “global” policies to a dynamic group. This dynamic group will automatically populate with users, and thus automatically grant those users privileges to the standard package of policies. Per our previous example, you can assign in-house apps to a dynamic group, thus giving everybody access to in-house apps without any further administrative action.
But what about policies that you want to assign to only select groups? Well, this is do-able, but what this means is that you will have to create a new group per unique policy. On top of that, if you have unique “packages” then those will need their own unique groups as well. Here’s a grid for demonstration:
|Mail policies:||Western Hemisphere||Eastern Hemisphere||Cloud|
|Wifi policies:||Executive access||Standard access|
This table shows five unique policies that grant different levels of access. If a user must get one mail policy and one wifi policy, this means that there are 3×2= 6 possible groups. Yes, this means that if you want to be granular with your access, you will have to create and manage 6 different groups and their membership.
- In a hybrid environment it’s definitely possible to assign unique policies to segments of users, or a standard package of policies to all users.
- Assign global configuration policies to a dynamically populated group to grant everybody access to the same thing.
- Assign unique policies to unique groups to grant granular access. The more unique policies you have, the more groups you will need.
- The more unique “packages” of policies you have, the more groups you will need.