Skip to main content
McAfee MVISION Cloud

Create a Cloud Access Policy

To create a Cloud Access Policy:

  1. Go to Policy > Access Control > Access Policies.
    cloud_access_policies.png
  2. Click Create Policy.
  3. Name. Enter a name for the Cloud Access Policy. 
  4. Description. Enter an optional description of the policy. 
  5. ON or OFF. Toggle to turn the policy ON or OFF. 
  6. Monitor Only Mode. Select monitor only mode to have your rule create incidents only. The policy action is not taken. 
  7. Conditions. Policies are built around conditions (rules) and actions. Conditions are used with IS or IS NOT arguments to define the specific situation when a policy should be enacted. You can build out policies that contain several rules that include the following conditions:
    • Service
    • User Group
    • Device
    • Activity
    • SAML Expression
    • Device Type
    • IP Address Range
    • Request Classifier
    • User Domain
    • Agent
    • IP Location
    • Instance
    • User Policy Dictionary
    • Service Group
      cloud access policy conditions.png

NOTE: If you apply the conditions as User Group in the Cloud Access Policy, then the following parameter should be added in the MVISION Cloud Admin portal. 

  • Under Addition config in TenantConfig page, add the following in the ADDITION CONFIG section. To add these parameter, contact MVISION Cloud Support.
    {"common": {"usergroup_key":"ad_userprincipalname"}} 
  1. Actions.  Actions then determine what happens when a policy is enacted. Options include:
    cloud access policy actions.png
    • Allow Access. 
    • Block Access.
    • Check Cert Proxy Manage, Block Unmanaged. This binary policy for browser-based clients allows managed devices to access CSPs via the MVISION Cloud reverse proxy. Unmanaged devices are blocked.
    • Step-Up Authentication. Provides access to another authentication mechanism you define.
    • Check Cert: Proxy All. This binary policy for browser-based clients allows CSP access to both managed and unmanaged devices post-authentication, but controls operations from unmanaged devices. For example, you can block downloads from unmanaged devices.
    • Check Cert: Redirect Managed, Block Unmanaged. This binary policy for native clients allows managed devices to access CSPs via the MVISION Cloud reverse proxy. Unmanaged devices are blocked. MVISION Cloud is bypassed post-authentication for managed devices and redirected to CSP.
    • Register DRM (Passthrough). Forces users to go through DRM registration before accessing a CSP.  
    • Skip Cert Check: Redirect All. Skips authentication and redirects both managed and unmanaged devices to CSPs.
  2. Click Save

Known Issue for Intune Mobile Device Management (MDM) for New User Enrollment or with iOS 13.x

Users on iPhones or iPad devices on iOS cannot enroll through the Intune Mobile Device Management application; they are getting a blank page. The user is requesting a new Intune application for the following reasons:

  • A new user is enrolling a new device, or the service desk resets the device.
  • An existing user wants to reset the password and tries to log in again to the company portal.

Prior to iOS 12.4.6, for new users using Intune, or users not using Intune or any MDM, to determine that traffic or a session are from Native Apps, you used the "PKeyAuth" string in the useragent, or looked for an additional header "x-ms-pkeyAuth". This is based on the Native Apps that you have defined in the Cloud Access Policy. But from iOS 12.4.6, 13.x, and later, those strings and headers are not present, so the Cloud Access Policy is failing. 

For example, in iOS 12.4.6 and 13.1, the case useragent string is "Mozilla/5.0 (iPhone; CPU iPhone OS 13_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Mobile/15E148 Safari/604.1". This does not include the PKeyAuth string, and no additional header is available to detect the native app. Also, in the case of Intune MDM, it doesn't support the ability to inject attributes, which can detect native apps.

So, the workaround is to:

  • Add the users who need to be enrolled for Intune in the user dictionary, and define the skip certificate check in the Cloud Access Policy. Or define, for example, the CASB bypass group in AD with the skip certificate check in the Cloud Access Policy.
  • Use MobileIron or some other MDM that supports injecting attributes to detect native apps.

Once the users are enrolled in Intune, then remove the users from the user dictionary or CASB bypass group in AD.

For more information on request headers, see Microsoft documentation 3.1.5.1.1 Request. Also, see Action Required: Evaluate and update Conditional Access policies after new iPadOS release

  • Was this article helpful?