Configuring an MDM profile

The MDM profile specifies the extent to which every device that connects to the SafeLinx Server through the profile must comply with selected MDM requirements. Update an MDM profile to finish configuring a recently created profile, or to customize the settings of an existing profile.

About this task

The MDM profile specifies several types of information:
  • Account and network information that is needed to connect to the MDM server.
  • How the SafeLinx Server enforces compliance with the MDM.
  • The organizational unit in which the resource is defined.

When you run the wizard to create an MDM resource, the profile that is created is configured to use the default settings. Update the profile to modify the current settings.

After you apply updates to an active profile, SafeLinx Server sends a notification to other SafeLinx Server servers that use the profile. In general, the other SafeLinx Servers put the changes into effect immediately. However, there might be a delay before enforcement settings are applied to mobile devices that authenticated recently. The amount of delay depends on the length of the validity period, which by default is four hours.

After you add and enable an MDM profile, the SafeLinx Server queries the MDM service during device authentication to verify the compliance of connecting devices. You can configure the extent to which the SafeLinx Server enforces compliance with the MDM policies, and the length of time that the SafeLinx Server considers information retrieved from the MDM to be valid. You can also specify how the SafeLinx Server handles MDM authentication requests when the MDM service cannot be reached.

Some fields are populated automatically with the values that you provided when you created the profile.

Procedure

  1. In the SafeLinx Administrator Resources pane, expand the OU where the MDM profile is located, right-click MDM Integration, and then click Open.
  2. In the MDM integration window, select the MDM configuration that you want to configure and click Properties.
  3. Update enforcement settings.

    You can specify several settings that define how the MDM profile interacts with the MDM server to enforce compliance for mobile devices.

    After a mobile device authenticates through the primary authentication method, for example, LDAP or RADIUS, the SafeLinx Server queries the MDM server for the device status. By default, the SafeLinx Server checks whether the device is registered with the MDM. You can modify the default settings to require the following additional levels of compliance checking:

    • Confirm that the device user is the user that is registered by the MDM system for that device.
    • Confirm that the device is in compliance with applicable MDM policies and rules. The specific compliance capabilities for a profile vary depending upon the MDM service type of the MDM profile, such as MaaS360®, midpoints, or MobileIron.
    1. Click the General tab.
    2. In the Enforce results (or policies) section, choose one of the following options:
      Log results only
      MDM policy enforcement is disabled. The SafeLinx Server queries the MDM service to determine the compliance status of connecting devices and reports the results in the log file, but no enforcement occurs.
      Choose this option to test the integration and assess the number and status of the mobile devices that request authentication. Log entries are assigned to one of the following log levels: ERROR, WARNING, DEBUG, LOG, and S-AUTH. The S-AUTH category contains the entries for devices that are determined to be out of compliance. All SafeLinx Server MDM log messages are logged in the SafeLinx Server log file, which is named wg.log by default. Example log messages for a failed user authentication: 
      
[LOG] MDM_MaaS360 ::authenticate: (entry)
[S-AUTH]MDM: result=failed:1, apiRc=0, flags=0x1 [MDM Test#MDM_MaaS360:
imcuser->Appl_NNN_YYY]
[LOG] MDM_MaaS360 ::authenticate: (return), rc=1
      Policy enforcement
      MDM policy enforcement is enabled. The SafeLinx Server queries the MDM service to determine the compliance status of connecting devices and grants access to protected resources only to devices that comply with the configured policies. By default, this option is selected.

      If a device fails any enabled compliance checks, it is denied access to the HTTP access service for which the authentication profile includes the MDM profile.

    3. If you enabled policy enforcement, choose a setting for Authentication behavior if MDM Service is unavailable.

      If the MDM server becomes unresponsive as a result of a network outage or other problems, the SafeLinx Server cannot process device verification requests. You can establish special rules for handling device verification requests when the MDM server is unavailable. These rules specify whether to prevent device access entirely or allow limited device access when the SafeLinx Server cannot connect to the MDM server.

      Select one of the following options:
      Fail-closed
      The SafeLinx Server temporarily rejects all authentication requests and returns a Permission denied (HTTP 403) response to the mobile device.
      Pass-open
      The SafeLinx Server temporarily allows all authentication requests. If you choose this option, the setting applies until the server is unavailable for the interval that is specified in the Acceptance time-out field. If the server remains unavailable at the end of the acceptance timeout interval, mobile devices that attempt to authenticate receive an HTTP 403 response.
      Pass-recently valid
      The SafeLinx Server temporarily allows authentication requests from any device for which there is a record of a previously successful authentication through this MDM profile. Users who do not have a history of a successful authentication, including new users, are denied access. By default, this option is selected.

      This setting applies until the period of server unavailability exceeds the interval that is specified in the Acceptance time-out field. If the server remains unavailable at the end of the acceptance timeout interval, mobile devices that attempt to authenticate receive an HTTP 403 response.

      Note: SafeLinx defines a validity period during which the verification status of a device is assumed to remain valid. During the defined period, the SafeLinx Server does not query the MDM service to evaluate device status. Thus, when an MDM server is unavailable, devices that successfully passed MDM authentication within the validity period are allowed to connect.
    4. If you select one of the Pass options in the previous step, specify a value in the Acceptance time-out field. Specify a value from 5 – 99999 or enter 0 to configure an unlimited acceptance interval. The default value is 240, which is 4 hours.

      This value defines how long the SafeLinx Server allows pass-open and pass-recently valid authentications to occur after the MDM service becomes unavailable.

      Note: If you restart a SafeLinx Server, the acceptance time-out interval is restarted.
    5. In the Validity period (minutes) field, specify how long the status for a device that passes verification remains valid. Enter a value between 60 and 999999.

      The default value is 240, which is 4 hours. Higher values limit MDM server load by reducing device queries against the server.

      When the MDM server assigns a successful compliance status to a mobile device, a new validity period begins for that device. During the validity period, a device's compliance status is assumed to be unchanged, and the SafeLinx Server does not query the MDM service to reevaluate the device's status. Verification queries to the MDM server for that device resume the next time that the device sends an authentication request after the validity period ends.

    6. In the Out of compliance retry interval field, specify the minimum time before an authentication request from an out-of-compliance device triggers a query from the SafeLinx Server to the MDM server to reevaluate the status of the device. Specify a value from 5–999999. The default value is 60, which is 1 hour. It is best to avoid values less than 60 minutes.

      The SafeLinx Server queries the MDM server for the status of a device that fails a compliance check only after the out of compliance retry interval. To enable devices that fail compliance checks to be reevaluated sooner than is allowed by the currently defined Validity period, specify a value that is less than the value in the Validity period field. Values that are greater than the value in the Validity period field are ignored.

    7. Select User to device validation to require the credentials of the SafeLinx user to match the credentials of the user that is registered to use the device. By default, this option is not selected.

      If the SafeLinx Server user credentials do not match the credentials of the last user that logged in to the MDM system from a device, authentication fails.

    8. Click the MDM service tab for MaaS360®, midpoints, or MobileIron.
      Specify the following settings:
      • Parse URI for device ID

        Allow access for applications that are not integrated with the MDM client software but pass the client device identification in the service request URI. SafeLinx Server parses the device information from the URI and validates the device with the MDM service.

        For example, an Apple iOS native mail application is synchronizing to HCL Verse. The mail client is not integrated with MDM client software, but passes the MDM device ID in the HCL Verse client request URI. When the Parse URI for device ID option is enabled, SafeLinx Server checks the device request URI for the deviceId= pair specified as one of the URI query strings. The value for this query string is used as the device ID for MDM verification.

      • How to handle unmanaged devices

        Specify how SafeLinx Server should handle devices that are not managed by the MDM service or device applications that are not integrated with the MDM client software. This option specifies if unmanaged devices pass authentication and are allowed access to SafeLinx Server applications.

        An unmanaged device is identified if the authentication request does not include a MDM device ID. This is true for devices that are not registered or do not have MDM client software installed. This includes authentications from device applications that are not MDM aware, such as a standard web browser.
        • Deny

          Block access to all non-managed devices and block access for any applications that are not MDM aware.

        • Allow

          Grant access to all non-managed devices and allow access for applications that are not MDM aware.

        • Allow if user is enrolled

          Grant access to non-managed devices and non-MDM aware applications only if the SafeLinx authentication user also exists as a valid MDM user.

          Selecting Allow or Allow if user is enrolled allows all authentication requests that do not supply a MDM device ID. However, if the device ID is present the device is verified per the enabled MDM profile configuration. A managed device that is not compliant fails, where an unmanaged device can be allowed. Allowing unmanaged devices can help during a transition to SafeLinx MDM device validation in an existing deployment. It can also be utilized to allow personal device access while ensuring full validation of corporate devices.

  4. Update account information.
    1. Click the Server tab.
      You can update the following account fields:
      • Server URL
      • Administrator ID
      • Password
    2. Click the MaaS360 tab to update the account information for the MaaS360 service.
      You can update the following account fields:
      • Billing identifier
      • Platform identifier
      • Application identifier
      • Application version
      • Application access key
      • Validate policy
      • Validate rules

      MaaS360® evaluates compliance to rules and to policies separately. For more information about the differences between rules and policies, see the IBM MaaS360 documentation.

      For more information about the preceding fields, seeAdding a Mobile Device Management (MDM) profile.

    3. Click the midpoints tab to update the account information for the midpoints service. You can update the following account fields:
      • Requester identifier
      • Connection token
      • Application version
      For more information about the preceding fields, see Adding a Mobile Device Management (MDM) profile.
    4. Click the MobileIron tab to update the account information for the MobileIron service. You can update the following account fields:
      • Validate security policy compliance
      • Validate quarantined status
      • Validate ActiveSync status

        MobileIron security policy generally includes the quarantined status and ActiveSync status compliance. For more information about the compliance status, see the MobileIron documentation.

    Note: After you change enforcement settings, devices that do not comply with the new settings might continue to pass authentication for some time. Delayed changes can occur for devices that authenticated successfully within the previously configured validity period. To force immediate device validation, create and apply a new MDM profile.
  5. Update network information.
    1. Click the Server tab.
    2. To enable SafeLinx Server to communicate with an MDM service that uses an untrusted SSL certificate, select Accept untrusted certificates from internal servers.
      By default, this setting is disabled. Select this option if you are using an MDM service with a self-signed certificate, or if the MDM server certificate authority (CA) issued certificate does not reside within a configured SafeLinx Server key database.
      Note: It is preferable for the administrator to add the MDM server CA signers to the SafeLinx Server key database.
    3. In the File name of key database field, specify the name and location of the key database that the SafeLinx Server uses in secure authentications with the MDM server. By default, the key file cm.trusted.kdb is in the SafeLinx Server installation directory on the SafeLinx Server. If you change the name or location of the file, specify the full path of the file.

      The key file cm.trusted.kdb contains a limited set of signer certificates that allow SafeLinx Server to authenticate with the default MDM servers. Adding additional signer certificates or a different key file might be required for custom MDM servers or certificate changes to the configured server.

  6. To change the organizational unit in which the MDM profile is defined, click the OU tab, click the name of an organizational unit, and then click Apply.
    The SafeLinx Administrator Resources tab now displays an MDM Integration resource within the OU that you designated.