Cloud Services MDM. Telecom Management Admin Guide

(1)

Cloud Services

10/24/2014

MDM

(2)

TELECOM MANAGEMENT

MDM’s Telecom Management solution allows administrators to configure and assign telecom plans to devices across the mobile fleet. Using telecom management, admin can assign the devices to a telecom plan based on preconfigured criteria (Location Group, User Group, Model, Platform, Carrier, Country, etc.) and automatically associate plans to devices matching specific criteria such as SIM number and telephone number. This solution also allows the administrators to proactively track and monitor plan usage, access the plan and device details, and track the roaming history for the device.

ENABLING TELECOM SETTING

By default, the Telecom Management module is disabled for each customer location group. • To enable this module, navigate to System Settings ► Advanced ► Other and select the

Telecom Enabled checkbox.

(4)

CREATING AND MANAGING TELECOM PLANS

Administrators can create telecom plans, assign plans to both the devices that are enrolled and to the devices that are not yet enrolled. Administrators can also manage, assign, and review all current telecom plans.

Creating a Telecom Plan

1. Navigate to Telecom ► Telecom Management page. 2. Select Plans from the Configuration menu on the left.

3. Select [Add] from the Dashboard options to add a new Telecom Plan.

• Plan name – Enter the name for a plan.

• Country – Select the country of the carrier.

• Carrier – Enter the name of the company providing the carrier plan.

(5)

• Peak Voice Time Interval – Enter the peak voice time interval. o This is typically 6:00am -‐ 9:00pm.

o If a peak interval is not defined, then all minutes are applied to the plan limit. • Usage Reset – Enter the day after which the plan usage resets.

• Plan Effective Date – Enter the earliest date for the plan to be effective. 4. Click [Save] or click [Save and Assign] to assign to the devices.

DYNAMIC ASSIGNMENT

Using Dynamic Assignment, an administrator creates a rule for a specified plan and assigns it to a device that does not have a specified plan. All the criteria in each assignment rule are evaluated based on the designated Rank.

Before assigning a specified plan to the device, the Dynamic Assignment rule checks to see if the particular phone number is already associated with a device, and if a plan has already been assigned.

• If already assigned, disregard dynamic assignment.

• If no assignment is present, check the dynamic assignment rules for a match of the highest rank. Assigning a Rule to a Plan

1. Navigate to Telecom ► Telecom Management.

2. Select Dynamic Assignment from the Configuration menu on the left. 3. Click [Add] to assign rules to the existing plans.

4. Enter the information in each criteria field, as well as the plan for assigning the appropriate

rule(s) to the devices.

NOTE: The very basic criteria by which the devices will be dynamically assigned are Carrier and Country.

(6)

Editing an Assignment

• Select Edit Assignment for a particular plan to reconfigure assignment settings.

• From the Edit Assignment area, administrators can add more assets (devices), remove existing assets, reassign assets accordingly, or change the plan.

NOTE: Current plan indicates whether the device is already assigned to a plan.

DASHBOARD USAGE

MDM collects telecom information from each device and sorts it out appropriately for viewing on the

Telecom Dashboard. Upon completion of plan creation and assignment, the Telecom Dashboard allows

an administrator to proactively perform the following: • Monitor telecom usage in relation to plan limits. • Review compliance to the specified limits. • Access plan details and device information. • Review roaming history for the device.

(7)

Telecom Usage

The Telecom Usage page allows the administrators to track: • Telecom usage by month

• Telecom usage by day • Plan usage details • Roaming details

1. To access the Telecom Usage page, navigate to the Telecom Management area from the main menu:

2. Click a specified plan to view plan usage details in the tray view form.

The Plan Usage Detail view provides an overview of all available device and user information, as illustrated below:

Telecom Roaming

(8)

CERTIFICATE MANAGEMENT OVERVIEW

As digital information exchange evolves and becomes increasingly mobile, the possibilities for information sharing multiply. IT administrators are faced with the challenge of providing employees with convenient access to enterprise resources while overcoming the ever-‐expanding security concerns introduced by mobility and information fluidity. Traditional security technologies and solutions are not sufficient to meet the stricter requirements for information security and data loss prevention. In order to meet growing demands for information accessibility and security, the enterprise needs a multi-‐ faceted and scalable data security solution, and many enterprises have turned to digital certificates and Public Key Infrastructure (PKI) for a resolution to this security dilemma.

Benefits of Using Certificates

There are several key features that make certificates an ideal solution for enterprise security.

• Cross-‐Platform Scalability – Digital certificates can be leveraged to protect data across many different mobile platforms. Just as the same message can be transmitted across email or instant messaging, digital certificates can be used for security across both. The extensibility of

certificate security allows organizations to avoid implementing multiple inferior single point security solutions that ultimately leave data vulnerable as it moves from point to point. • Multifunctional – Once a user or device receives a certificate, it can be utilized across many

different platforms for a variety of purposes.

o Encryption – Certificates can be used to encrypt digital information regardless of the platform. For example, the S\MIME standard leverages certificates for email encryption, while the HTTPS protocol utilizes SSL to provide web page encryption.

o Message Signing – Enterprises in need of digital message signatures can leverage certificates in order to prove message integrity and show that the message originates from an authenticated sender and was not altered by any malicious third party. o Authentication – Lastly, because digital certificates contain identifying information

about both the user and the device that has been certified by a trusted source,

certificates provide secure authentication into a number of systems such as email, Wi-‐Fi, and VPNs.

• High Security – Digital certificates are much more secure than traditional passwords, because they are not susceptible to common password cracking methods such as brute force or dictionary attacks.

(9)

Managing Certificates on the Certificate Dashboard

The Admin Console is a central location for managing certificate authorities, integration and other certificate management needs for managed devices. All of these activities are centralized on the

Certificate Dashboard.

To navigate to the Certificate Dashboard, navigate to Profiles & Policies ► Certificates.

Once a certificate has been issued to a device, administrators can perform the following actions from the Certificates Dashboard:

• Manage Certificate Authorities • Renew Certificates

o To renew a certificate, click the Actions menu next to the certificate and select Renew

Certificate.

• Revoke Certificates

o To revoke a certificate, click the Actions menu next to the certificate and select Revoke

Certificate.

• Send certificate-‐related messages to devices

o To send a push notification to all devices with a selected certificate installed, check the box next to the certificate and click the [Send Message] button at the top of the

Certificates Dashboard.

o Select the application to which to send the message (the selected application must be installed on the device) and fill out the message body.

o Click [Send].

(10)

Certificate Infrastructure Integration

MDM can integrate with the certificate infrastructure in a way that allows the Enterprise to distribute certificates for authentication purposes to devices containing corporate data. There are several options for MDM certificate infrastructure integration, but each requires detailed technical information and therefore it is very important that a Certificate Infrastructure administrator be involved in this integration.

There are two ways in which MDM integrates:

Direct Certificate Authority (CA) integration

• MDM can act as a proxy for certificate distribution.

Simple Certificate Enrollment Protocol (SCEP) integration

• MDM can act as a proxy for certificate distribution. • Can be authenticated from the device.

Direct Certificate Authority Integration

To configure MDM integration with a Direct Certificate Authority (CA) services server, you must first configure the Certificate Authority.

Configuring the Certificate Authority

1. Navigate to Configuration ► System Settings ► Device ► General ► Certificate Authorities. 2. Select [Add] to open the Certificate Authority Form.

Fill in the required fields:

• Name – Refers to the actual name of the instance of the CA on the CA server.

• Allow child location groups to use this certificate authority – Check the box to allow inheritance by child location groups.

(11)

• Authority Type –The type of certificate authority. For Direct CA integration, choose one of the following:

o Microsoft AD CS – Supports a Microsoft Certificate Authority on a Windows Server 2003/2008 server.

o Generic SCEP – Supports an MDM-‐installed certificate service or Generic CA (which supports the standard CA protocol).

For more information on configuring a SCEP certificate authority, see SCEP

Integration.

o Verisign MPKI – Supports VeriSign® Managed PKI for SSL Certificate Service. o Symantec – Supports Symantec PKI integration.

o OpenTrust – Supports OpenTrust PKI integration. o Entrust – Supports Entrust PKI integration.

o Server Hostname/Server URL – The server address of the CA server. The CA server needs to be in IP or domain name format (mycompany.local.com).

3. Enter in any necessary authentication credentials and complete the other remaining fields as needed.

4. Use the [Test Connection] button to check that your settings are correctly configured. 5. Click [Save] (or [Save and Add Template]).

Simple Certificate Enrollment Protocol (SCEP) Integration

The first step in configuring MDM integration with a corporate SCEP services server is to configure the Certificate Authority.

Configuring the Certificate Authority

1. Select Add to open a new Certificate Authority Form (or select Edit from the Actions menu to edit an existing certificate).

2. Fill in all required fields:

• Name – In SCEP integration this field is used by MDM to distinguish these settings. • SCEP Provider – The SCEP provider determines the rest of the configuration and what

challenge options are available.

(12)

SCEP Provider: Basic

Use the Basic option when the provider is not Microsoft, Verisign, Symantec, OpenTrust or Entrust. 1. Select Generic SCEP as the Authority Type.

2. Select Basic from the SCEP Provider drop-‐down.

Selecting the Basic SCEP Provider option requires the following fields:

• Server URL – The web address of the certificate enrollment URL. This is usually in the format of .exe or .dll, depending on the SCEP provider. Below are two examples:

• Challenge Type – Select either No Challenge or Static, depending on the requirements of the certificate.

o Static Challenge – Select this when a singular key or password is required to

authenticate with the certificate enrollment URL. A field displays when Static Challenge is chosen you to enter in the password or challenge key provided by SCEP.

o No Challenge – Select this when no challenge is required. This usually involves unsecured SCEP endpoints and it only applies in rare circumstances.

• Retry Timeout – Enter in the number of minutes for a timeout.

• Max Retries When Pending – Enter the maximum amount of tries a user gets before the system times out. After a timeout, the user waits the number of minutes specified in the above field before logging in.

SCEP Provider: MSCEP

1. If MSCEP is the SCEP provider, select Generic SCEP as the Authority Type. 2. Select MSCEP from the SCEP Provider drop-‐down. The following options display:

• Server URL – The web address of the certificate enrollment URL. This is usually in the format of .exe or .dll, depending on the SCEP provider.

The server should be https://scepserver.mycompany.com/certsrv/mscep/mscep.dll (where

scepserver.mycompany.com is the web address of the SCEP server).

• Challenge Type – Select either No Challenge or Static, depending on the requirements of the certificate.

o Static Challenge – Select this when a singular key or password is required to

authenticate with the certificate enrollment URL. When Static Challenge is selected, a field displays for you to enter the password or challenge key provided by SCEP. o Dynamic Challenge – Uses MDM to pull a challenge key or password from the SCEP

provider.

§ Username Is Required – Check this box to require the Dynamic Challenge web

address to require user authentication for access.

§ Challenge Length – Enter the challenge length provided by the SCEP provider.

§ Challenge URL – This field should contain the web address of the challenge URL:

• For MSCEP 2003, the challenge URL is the same as the web enrollment URL. • For MSCEP 2008 the challenge URL is typically:

https://scepserver.mycompany.com/certsrv/mscep_admin/ (where scepserver.mycompany.com is the web address of the SCEP server).

NOTE: The trailing / (slash) is NOT optional.

(13)

• Username & Password – Username and password to authenticate with the SCEP challenge URL. The username and password need to have the correct permissions for both the SCEP server and the certificate template being used in order to authenticate with them.

SCEP Provider: VeriSign

1. If VeriSign is the SCEP provider, select Generic SCEP as the Authority Type 2. Select Verisign from the SCEP Provider dropdown.

The following options display:

• Server URL – The web address of the certificate enrollment URL. This is usually in the format of .exe or .dll, depending on the SCEP provider.

The server should be set to https://onsiteipsec.verisign.com/cgi-‐bin/pkiclient.exe. • SCEP Challenge Phrase (Static Challenge Only) – Enter the password or key provided by

SCEP.

• Verisign Passcode Post URL (Dynamic Challenge Only) – Enter the dynamic challenge URL. The URL should look like: https://onsite-‐admin.verisign.com/OnSiteHome.htm.

• Verisign DNS Post Fix (Dynamic Challenge Only) – Enter the domain used to register the relevant mPKI account.

o For example, if the domain was registered with mycompany.com, enter ".mycompany.com" in this field.

• Verisign Certificate Name (Dynamic Challenge Only) – This field displays the uploaded certificate used to authenticate with the VeriSign Cloud.

• New Certificate File and Certificate Password (Dynamic Challenge Only) – Upload a new certificate into the SCEP configuration for authentication with the VeriSign Cloud.

o Click [Browse] to upload a new file. o Enter the certificate password.

SCEP Provider: Symantec

1. If Symantec is the SCEP provider, select Symantec as the Authority Type. 2. Select SCEP from the Certificate Retrieval Method radio buttons.

• Server URL – The web address of the certificate enrollment URL.

This is usually in the format of .exe or .dll, depending on the SCEP provider. • Enter authentication credentials as appropriate.

(This could be a username/password combination of client authentication certificates.)

SCEP Provider: OpenTrust

1. If OpenTrust is the SCEP provider, select OpenTrust as the Authority Type. 2. Select SCEP from the Certificate Retrieval Method radio buttons.

(This could be a username/password combination of client authentication certificates).

(14)

SCEP Provider: Entrust

1. If Entrust is the SCEP provider, select Entrust as the Authority Type. 2. Select SCEP from the Certificate Retrieval Method radio buttons.

(This could be a username/password combination of client authentication certificates). 3. Click [Save].

Certificate Template Configuration

After the Certificate Authority is configured, configure the Certificate Template so that MDM can request a certificate from the Certificate Authority. To configure a Certificate Template for Direct Certificate Authority integration:

1. Click Request Templates from the Certificate Authorities page: 2. Click [Add] to open the Certificate Template form. 3. Enter appropriate info in all required fields.

• Distinguished Name – The fully qualified distinguished name of the certificate. This field supports the lookup values used in MDM so that the certificate name can be unique per user/device in MDM (for example, CN={EnrollmentUser}).

o The distinguished name supports both Crypto API and Netscape formats. The only field required to create a certificate is the Common Name (CN). The distinguished name should reflect what the certificate is authenticating against.

• Certificate Authority – Specifies the CA that this template is assigned to in MDM. • The remaining fields are determined by the CA type selected.

(15)

For a Microsoft Certificate Authority

o Template Name – Enter a template name so this certificate template can be used in the future. The Template Name is only used within the Admin Console.

o Automatic Certificate Renewal – Check this box to have MDM automatically renew the certificate. You can specify the number of days for auto renewal.

o Use Existing Key – Enable this option to use the existing private key, rather than creating a new one. The CA and Certificate Template must support this option in order for it to work.

o Additional Attributes – This field serves two purposes when configuring the Certificate Authority:

§ First, the Additional Attributes field specifies the Certificate Template on the Certificate Authority. Use CertificateTemplate to specify which template to use (for example, enter CertificateTemplate:TemplateName, where TemplateName is the name of the template you would like to use).

§ Second, the Additional Attributes field allows you to add relevant additional attributes.

§ When you enter the additional attributes, separate them from the CertificateTemplate with “\n” (backslash n). An example of an additional attribute would be the Subject Alternative Name of the certificate. In order to specify the Subject Alternative Name, you would set the Additional Attributes field to: CertificateTemplate:TemplateName\nSAN:Email

Address={EmailAddress}.

o Private Key Length – The private key length should match the length of the private key on the certificate template being used on the CA.

§ Compatibility note: Shorter lengths are more compatible with older technology and operating systems.

o Private Key Type – Determines the type of private key in direct CA integration. § The standard setting is Signing & Encryption.

o Use Existing Key – Check this box to use an existing key.

o Publish Private Key – Check this box to publish the private key and store it in either your Active Directory Services or in a Custom Web Service.

For a Verisign Certificate Authority

o Use Existing Key – Enable this option to use the existing private key rather than creating a new one. The CA and Certificate Template must support this option in order for it to work.

(16)

§ First, the Additional Attributes field specifies the Certificate Template on the Certificate Authority. Use CertificateTemplate to specify which template to use (for example, enter CertificateTemplate:TemplateName where TemplateName is the name of the template you would like to use).

o Private Key Length – The private key length should match the length of the private key on the certificate template being used on the CA.

§ Compatibility note: Shorter lengths are more compatible with older technology and operating systems.

o Private Key Type – Determines the type of private key in direct CA integration. o The standard setting is Signing & Encryption.

o Use Existing Key – Check this box to use an existing key.

o Publish Private Key – Check this box to publish the private key and store it in either your Active Directory Services or in a Custom Web Service.

For a Symantec Certificate Authority

o Use Existing Key – Enable this option to use the existing private key rather than creating a new one. The CA and Certificate Template must support this option in order for it to work.

(17)

o Click Retrieve Profiles.

o Select the appropriate profile from the drop-‐down list. o Upon profile selection, a list of mandatory attributes displays.

o Enter appropriate lookup values for mandatory attributes. For example: mail_id:

{EmailAddress}.

For an OpenTrust Certificate Authority

o Use Existing Key – Enable this option to use the existing private key rather than creating a new one. The CA and Certificate Template must support this option in order for it to work. o Additional Attributes – This field serves two purposes when configuring the Certificate

Authority:

o Select the appropriate profile from the drop-‐down list. o Upon profile selection, a list of mandatory attributes displays.

{EmailAddress}.

For an Entrust Certificate Authority

o Use Existing Key – Enable this option to use the existing private key rather than creating a new one. The CA and Certificate Template must support this option in order for it to work.

(18)

o Select the appropriate Managed CA profile from the drop-‐down list. o Upon profile selection, a list of mandatory attributes displays.

{EmailAddress}.

4. When finished, click [Save].

UTILIZING CERTIFICATES FOR MDM

Once the certificate authority and certificate templates have been properly configured, certificates can be leveraged within MDM for a number of purposes.

Enterprise Wi-Fi, VPN, EAS Authentication

Advanced Wi-‐Fi, VPN, and EAS configurations can now leverage certificates for authentication in the place of simple passwords to provide stronger security from unauthorized access. MDM can

automatically distribute these authentication certificates down to devices and configure the device for Wi-‐Fi, VPN, or EAS access without any user interaction.

An overview of the process:

1. Ensure that the Certificate Authority and Certificate Templates are properly configured, and then create a profile for your appropriate platform (iOS or Android for these capabilities)

NOTE: If you are using a static SSL certificate that is used for all devices, you may skip this step and simply upload the certificate into MDM for distribution.

(19)

3. From either page, specify all parameters to select the proper certificate to be used for Wi-‐Fi, VPN, or EAS authentication.

4. From the Credentials profile page only:

• If you are using a static SSL certificate that does not depend on the user, choose Upload as the credential source and upload the certificate.

• If you are generating certificates per each user or device from a CA, ensure that your credential source is Defined Certificate Authority and choose the proper certificate template.

5. Once you have completed the Credentials or SCEP profile settings, do not click [Save and Publish]. 6. Select another payload in this profile for Wi-‐Fi, VPN, or EAS, depending on the purpose of the certificate.

7. Specify all settings for the chosen payload.

8. Ensure that the authentication type utilizes a certificate, and that the certificate you deployed in the Credentials or SCEP profile is selected.

NOTE: If authentication to the CA requires a trust (typically for internal certificate authorities), also ensure that you have uploaded and selected to use a CA Root Trust certificate.

(20)

S/MIME Email Signing and Encryption

Secure/Multipurpose Internet Mail Extensions (S/MIME) is a standard for public key encryption and

signing that has become the standard for email signing and encryption. MDM can automatically distribute certificates; MDM can also configure email or Exchange ActiveSync to utilize S/MIME signing and encryption without any user interaction.

An overview of the process is as follows:

1. Ensure that the Certificate Authority and Certificate Templates are properly configured, and then create a profile for your appropriate platform (iOS or Android for these capabilities). • If you are using a static SSL certificate that is used for all devices, you may skip this step and

simply upload the certificate into MDM for distribution.

2. Fill out all general profile settings and then choose either Credentials or SCEP, depending on the type of CA you have previously configured.

3. From either page, specify all parameters to select the proper certificate to be used for Wi-‐Fi, VPN, or EAS authentication.

4. From the Credentials profile page only:

• If you are using a static SSL certificate that does not depend on the user, then select Upload as the credential source and upload the certificate.

• If you are generating certificates per each user or device from a CA, then ensure that your credential source is Defined Certificate Authority and select the proper certificate template. 5. Once you have completed the Credentials or SCEP profile settings, do not click [Save and

Publish].

6. Select another payload in this profile for email, or EAS, depending on your type of email infrastructure.

7. Specify all settings for the chosen payload and ensure that Use S/MIME is checked.

8. Also ensure that the certificate you selected in the credentials or SCEP payload is being used for either signing or encryption, as shown.

9. When complete, click [Save and Publish].

(21)

SECURITY AND COMPLIANCE

MDM uses a customizable compliance engine to allow for robust compliance policy creation and enforcement. The MDM compliance capabilities allow administrators to protect proprietary corporate data from unwanted exposure and to set rules for handling non-‐compliant activity on managed devices. These compliance policies are centrally managed in the Compliance page in the Web Console.

To navigate to the Compliance page, select Profiles & Policies ► Compliance. From here, the administrator can create several different types of compliance policies and establish enforcement criteria:

• Device Policies: Device policies allow the administrator to create customized compliance policies based on device criteria such as operating system, compromised status and application lists. All enforcement actions are customized in Device Policies.

• Email Compliance Policies: Email compliance policies include general rules for accessing

corporate email, as well as enhanced email access policies that only apply to managed devices. For information on email policies, refer to Email Compliance Policies.

NOTE: Email compliance policies only apply when the Secure Email Gateway is installed. • Application Groups: Application policies are created based on custom groups of blacklisted,

whitelisted, and required applications. In order to configure application compliance

enforcement, you can first build lists of applications using Application Groups and then create compliance policies and actions using Device Policies.

Passcode and Restrictions Profiles Overview

In addition to the compliance engine, passcode and device restrictions provide further protection to managed devices.

• Passcode compliance policies include the ability to enforce passcodes, set passcode complexity, and manage auto-‐lock and passcode history settings.

• Restrictions profiles allow the administrator to prohibit and control use of device-‐specific functionality such as app installation, the device camera, and other similar functionality. To set Passcode and Restrictions profiles on individual devices, please refer to Creating Profiles. Building Device Compliance Policies

Device compliance policies allow the administrator to identify device-‐specific compliance policies and instruct MDM to perform administrative actions on managed devices when specific device-‐based criteria are met.

(22)

To create a device compliance policy:

1. Navigate to Profiles & Policies ► Compliance. 2. To create a policy, click Add.

OR

To edit an existing policy, click Edit under the Actions column.

The tabs at the top of the page represent the steps and criteria for creating a compliance policy:

Rules

The first step in creating compliance policies is defining the Rules (located on the Rules tab).

1. From the Match drop-‐down menu at the top of the page, choose whether to match All or Any of the compliance rules (default is All).

2. Choose the compliance area from the drop-‐down menu. The categories include:

• Application List (to determine if apps are Blacklisted, Whitelisted, or Required, you need to first configure Application Groups)

• Compromised Status • Encryption

• Interactive Profile Expiry • Last Compromised Scan • Model

• OS Version • Passcode • Roaming

• SIM Card Change

3. Choose the appropriate rule statement from the middle drop-‐down menu (e.g., Contains

Blacklisted App, Is Compromised, Is Roaming, etc.).

• Available selections in the middle drop-‐down are customized to the different compliance areas; therefore, the drop-‐down menu options differ depending on the selected rule compliance area.

4. If a third piece of information is necessary for the given rule (such as the specific operating system, etc.), select this information from the drop-‐down menu.

(23)

Actions

MDM enables the administrator to designate custom actions to perform to the device when it is initially detected as noncompliant, and escalation options to perform further actions if the device continues to be non-‐compliant.

1. On the Actions tab, select the action from the first drop-‐down menu (Application Compliance,

Command, Notify, or Profile). This will be the first action performed on a non-‐compliant device.

2. Select the specific action to immediately perform (such as Send push notification).

• If you select an action that involves removing any profiles or applications, those resources will be automatically re-‐installed when the device becomes compliant (no end-‐user interaction required).

• Removal of applications only applies to supported devices.

3. If necessary, enter any supporting information (such as the message template or profile type) from the final drop-‐down menu.

• For notifications: Select an existing template, or create a new template in Configuration ►

System Settings ► System ► General ► Message Templates.

4. Click [Next] to proceed to the Assignment step. OR

Click [Add Escalation] to create an escalation policy that defines the next action to take if the user does not comply with the first compliance action.

(24)

Assignment

From this tab, the administrator can select the devices/users to which this policy will be applied. 1. Select the device and user criteria for applying the compliance policy.

2. Click [Next].

Summary

From the Summary tab, the administrator can summarize the compliance policy for reference in the Admin Console (General) and display the number of devices that the policy would affect (Device Summary)

1. On the Summary tab, enter a name and description for the compliance policy.

The Device Summary displays the status of devices in the selected location or User Group.

The compliance policy is complete.

2. To apply the policy, click [Finish and Activate]. To just save the policy, select [Finish].

NOTE: For Application Compliance Policies – Some application compliance policies require the

administrator to define application groups to identify applications that are Blacklisted,

(25)

APPLICATION GROUPS AND POLICIES

Application compliance policies enable the administrator to enforce corporate application compliance by restricting access to unauthorized applications and ensuring that required applications are present on corporate devices. The administrator can designate Blacklisted, Whitelisted, and Required application lists and perform administrative actions if MDM detects a non-‐compliant application list. There are several components within MDM that enable administrators to build and enforce application compliance policies:

• Create Application Groups to specify Blacklisted, Whitelisted, and Required applications. • Build device compliance policies to designate actions for application non-‐compliance • Deploy application restriction profiles (to supported Android devices) to enforce application

restrictions and requirements Application Groups

Application policies are created and managed according to groups (lists) of applications. To create or edit a list of Blacklisted, Whitelisted, and Required applications:

1. On the Compliance page, select Application Groups from the sidebar on the left of the page:

2. To create a new application group, select Add Group (or, to edit an existing application group, select the Actions icon at the end of the row and choose Edit).

3. Select or fill in the application information fields on the List and Assignment tabs:

• Type – The type of application compliance policy:

o Blacklist – Applications not allowed on the device. o Whitelist – Applications allowed on the device.

(26)

• Platform – The device platform to which the application compliance policy applies. Currently, the only platform options are iOS and Android.

• Name – The name of the policy for reference in the Admin Console (for example, Apple

Blacklisted Games).

• Application Name – The name of the application for which you are creating a compliance rule. 4. Enter the Application ID and enter the application Version (optional).

Specifying the application ID allows MDM to more accurately detect devices that have the blacklisted application installed by identifying applications by the exact bundle ID, rather than simply searching for the application name as entered in the Application Name field.

5. To specify any version of the app, enter an asterisk (*) wildcard in the Version field. 6. Click [Add Application] to add applications to the list.

7. Click [Next] to proceed to the Assignment step.

8. On the Assignment tab, select the device and user criteria for the application list (for example, you may wish to apply stricter application policies to corporate-‐owned devices).

• Device Ownership – Specifying a device ownership type (Corporate-‐Dedicated, Corporate-‐

Shared, or Employee Owned) limits deployment to only the devices that belong to the

specified device ownership group. Distinguishing between corporate-‐ and employee-‐owned devices allows for maximum privacy and protection.

• Model – (optional) Designate specific device models to which the application group policy will be deployed.

• Operating System – (optional) Designate specific operating systems to which the application group policy will be deployed.

• Managed By – Select the Location Group level that will be able to manage this Application Group.

• Location Groups – Enter the Location Groups to which this application group is assigned. • User Groups – (optional) Select User Groups (if you are leveraging User Groups in MDM) as

(27)

You may create additional application groups, if needed, and then apply the application policies to devices and users by Building Device Compliance Policies and deploying Android Application Restriction

Profiles.

ANDROID APPLICATION RESTRICTION PROFILES

There are certain application restrictions for supported Android devices that are enforced through an application restriction profile. Device compliance policies can be used in addition to these restrictions, but the profile controls the ability to perform the specific actions controlled by these restrictions. The following settings are enabled or disabled through the application control profile:

• Prevent installing (or automatically remove) blacklisted apps on SAFE and 3LM Android devices. • Prevent un-‐installing required apps on SAFE and 3LM devices.

In order to enforce these restrictions:

• Define the application blacklist or required list by creating Application Groups.

• Create the application control profile by navigating to Profiles ► Add Profile ► Android ►

Application Control.

• Ensure the appropriate checkboxes are checked and [Save] or [Save and Publish] the profile.

SECURE CHANNEL CERTIFICATE

The secure channel certificate allows encrypted communication between the console and device. Enabling this option allows all the communication (such as device details, device status, and support information) to happen in a secured way, thus ensuring an extra layer of security for your data. To enable this option, navigate to Configurations ► System Settings ► System ► Advanced. By default, the secure channel certificate is part of the MDM installation. This certificate is inherited from the Global location group and cannot be edited at any of the child location groups. It is activated only if the Block Non-‐Secure Channel Device Access checkbox is enabled on the console.

Platforms supported:

Cloud Services MDM. Telecom Management Admin Guide

Cloud Services

MDM

CONTENTS

TELECOM MANAGEMENT

ENABLING TELECOM SETTING

CREATING AND MANAGING TELECOM PLANS

DYNAMIC ASSIGNMENT

DASHBOARD USAGE

CERTIFICATE MANAGEMENT OVERVIEW

UTILIZING CERTIFICATES FOR MDM

SECURITY AND COMPLIANCE

APPLICATION GROUPS AND POLICIES

ANDROID APPLICATION RESTRICTION PROFILES

SECURE CHANNEL CERTIFICATE