Figure 14 CVD Use Policies
These groups can be extended to the MDM such that members are issued profiles that complement their level of network access. As an example, Table 3 shows some arbitrary policies that can be established and enforced based on the CVD use cases.
Table 3 | Policies Based on CVD Cases |
| |
|
|
|
|
Ownership |
| User Group | Restrictions |
|
|
| |
Domain Users | Internet Only, personal devices are not | ||
Device |
|
| required to |
|
|
|
|
|
| BYOD_Partial_Access | Fairly restrictive policy that isolates |
|
|
| corporate data into containers. Restrictions |
|
|
| prevent users from disabling the policy. |
|
|
|
|
|
| BYOD_Full_Access | Trusted users are offered a slightly less |
|
|
| restrictive policy. Corporate data is still |
|
|
| isolated in containers. |
|
|
| |
All Users classes | Very restrictive device policy disabling | ||
Device |
|
| |
|
|
| the game center. |
|
|
|
|
Domain_Users is the default AD group. By definition, every user defined in the directory is a domain user. While it is possible to create the reciprocal group on the MDM, it is not needed. The CVD treats
MDM profiles and ISE AuthZ rules are fundamentally different with respect to AD Groups. ISE policy may include the AD group match as a condition for establishing a specific and single policy. MDM profiles are not a singular result. Most devices will be provisioned with multiple profiles based on various attributes. Members of the BYOD_Full_Access and Domain_Users can each be configured for a specific profile. But if a user happens to have membership in both BYOD_Partial_Access and BYOD_Full_Access, then that user’s device is provisioned with both profiles. In addition, everyone will be provisioned with basic security restrictions. ISE will check the device to ensure these restrictions are meet before granting network access. These restrictions establish ISE compliance and are defined here as required PIN lock, encrypted storage, and
Integrating Fiberlink MaaS360 with Cisco Identity Services Engine | 21 |
|
|