advertisement
▼
Scroll to page 2
of 465
Symantec™ Mobility: Suite 5.2 Administration Guide Documentation version: 5.2 Legal Notice Copyright © 2015 Symantec Corporation. All rights reserved. Symantec, the Symantec Logo, the Checkmark Logo and are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners. This Symantec product may contain third party software for which Symantec is required to provide attribution to the third party (“Third Party Programs”). Some of the Third Party Programs are available under open source or free software licenses. The License Agreement accompanying the Software does not alter any rights or obligations you may have under those open source or free software licenses. Please see the Third Party Legal Notice Appendix to this Documentation or TPIP ReadMe File accompanying this Symantec product for more information on the Third Party Programs. The product described in this document is distributed under licenses restricting its use, copying, distribution, and decompilation/reverse engineering. No part of this document may be reproduced in any form by any means without prior written authorization of Symantec Corporation and its licensors, if any. THE DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. SYMANTEC CORPORATION SHALL NOT BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS DOCUMENTATION. THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS SUBJECT TO CHANGE WITHOUT NOTICE. The Licensed Software and Documentation are deemed to be commercial computer software as defined in FAR 12.212 and subject to restricted rights as defined in FAR Section 52.227-19 "Commercial Computer Software - Restricted Rights" and DFARS 227.7202, et seq. "Commercial Computer Software and Commercial Computer Software Documentation," as applicable, and any successor regulations, whether delivered by Symantec as on premises or hosted services. Any use, modification, reproduction release, performance, display or disclosure of the Licensed Software and Documentation by the U.S. Government shall be solely in accordance with the terms of this Agreement. Symantec Corporation 350 Ellis Street Mountain View, CA 94043 http://www.symantec.com Technical Support Symantec Technical Support maintains support centers globally. Technical Support’s primary role is to respond to specific queries about product features and functionality. The Technical Support group also creates content for our online Knowledge Base. The Technical Support group works collaboratively with the other functional areas within Symantec to answer your questions in a timely fashion. For example, the Technical Support group works with Product Engineering and Symantec Security Response to provide alerting services and virus definition updates. Symantec’s support offerings include the following: ■ A range of support options that give you the flexibility to select the right amount of service for any size organization ■ Telephone and/or Web-based support that provides rapid response and up-to-the-minute information ■ Upgrade assurance that delivers software upgrades ■ Global support purchased on a regional business hours or 24 hours a day, 7 days a week basis ■ Premium service offerings that include Account Management Services For information about Symantec’s support offerings, you can visit our website at the following URL: www.symantec.com/business/support/ All support services will be delivered in accordance with your support agreement and the then-current enterprise technical support policy. Contacting Technical Support Customers with a current support agreement may access Technical Support information at the following URL: www.symantec.com/business/support/ Before contacting Technical Support, make sure you have satisfied the system requirements that are listed in your product documentation. Also, you should be at the computer on which the problem occurred, in case it is necessary to replicate the problem. When you contact Technical Support, please have the following information available: ■ Product release level ■ Hardware information ■ Available memory, disk space, and NIC information ■ Operating system ■ Version and patch level ■ Network topology ■ Router, gateway, and IP address information ■ Problem description: ■ Error messages and log files ■ Troubleshooting that was performed before contacting Symantec ■ Recent software configuration changes and network changes Licensing and registration If your Symantec product requires registration or a license key, access our technical support Web page at the following URL: www.symantec.com/business/support/ Customer service Customer service information is available at the following URL: www.symantec.com/business/support/ Customer Service is available to assist with non-technical questions, such as the following types of issues: ■ Questions regarding product licensing or serialization ■ Product registration updates, such as address or name changes ■ General product information (features, language availability, local dealers) ■ Latest information about product updates and upgrades ■ Information about upgrade assurance and support contracts ■ Information about the Symantec Buying Programs ■ Advice about Symantec's technical support options ■ Nontechnical presales questions ■ Issues that are related to CD-ROMs, DVDs, or manuals Support agreement resources If you want to contact Symantec regarding an existing support agreement, please contact the support agreement administration team for your region as follows: Asia-Pacific and Japan [email protected] Europe, Middle-East, and Africa [email protected] North America and Latin America [email protected] Contents Technical Support ............................................................................................... 4 Section 1 Setting up Symantec Mobility: Suite ............... 15 Chapter 1 Deploying Symantec Mobility: Suite ............................... 16 About Symantec Mobility: Suite modular solutions ............................... About Symantec Mobility Manager ................................................... About the Symantec Mobility Manager Dashboard ........................ Accessing the Mobility Manager Inbox ........................................ Administering Symantec Mobility: Suite on the go using the Admin Hub ..................................................................................... Chapter 2 16 18 23 26 28 Licensing Symantec Mobility: Suite ................................ 32 Licensing Symantec Mobility: Suite .................................................. 32 Symantec Mobility: Suite module licenses ......................................... 33 Monitoring your Symantec Mobility: Suite license status ....................... 36 Chapter 3 Setting up Symantec Mobility: Suite main components .................................................................... 38 Setting up Symantec Mobility: Suite main components ......................... Branding the Mobility Manager ........................................................ Setting up your Symantec Mobility: Suite Work Hub ............................. Differences between the iOS and Android Work Hubs .................... Branding your in-house Work Hub ............................................. Building your in-house iOS Work Hub ......................................... Building your in-house iOS Work Hub in your OS X environment .................................................................... Building your in-house iOS Work Hub in Mobility Manager .............. Rebuilding the in-house iOS Work Hub ....................................... Building the Android Work Hub .................................................. Rebuilding your Android Work Hub ............................................ Setting up notifications .................................................................. Configuring email notifications ................................................... Types of notification emails ....................................................... 38 40 42 43 44 47 48 50 53 53 54 54 55 55 Contents Configuring push notifications ................................................... Sending email notifications when push notifications are unavailable ..................................................................... Setting up and customizing the User portal ........................................ Customizing your app store ............................................................ Creating groups ........................................................................... Creating a private group ................................................................ Assigning roles ............................................................................ Creating a custom administrator role .......................................... Creating and storing text in other languages ...................................... Customizing and sending user invitation emails in other languages ....................................................................... Chapter 4 57 57 58 60 61 63 64 67 70 71 Setting up Symantec Mobility: Suite trust and authentication certificates .......................................... 73 Managing authentication certificates in Symantec Mobility: Suite ............ 73 Managing the iOS app and MDM certificates used by Symantec Mobility: Suite ........................................................................ 75 Creating an iOS App ID for use with Symantec Mobility: Suite .............................................................................. 77 Installing the iOS Provisioning Profile and iOS push certificate for Symantec Mobility: Suite .................................................... 79 Creating and installing the mobile device management (MDM) certificate for iOS devices in Symantec Mobility: Suite .............. 80 Creating the iOS Distribution Provisioning Profile for Symantec Mobility: Suite .................................................................. 81 Uploading the Distribution (code-signing) certificate to Symantec Mobility: Suite .................................................................. 82 Using dynamic authentication certificates in Symantec Mobility: Suite .................................................................................... 83 Specifying a Certificate Authority (CA) for dynamic certificates ............... 85 Configuring a Certificate Template in Symantec Mobility: Suite ............... 87 Specifying SCEP and dynamic certificates in iOS device policies ........... 90 Using SCEP with Mobility Suite ................................................. 93 Required SCEP, NDES, and ADCS settings and permissions ..................................................................... 96 Allowed characters and values in Symantec Mobility: Suite dynamic certificates ............................................................................ 98 Installing the Symantec ADCS Communication Service to provision MSCA certificates within Symantec Mobility ................................ 99 Adding LDAP certificates .............................................................. 101 Creating self-signed certificates ..................................................... 101 8 Contents Chapter 5 Setting up user authentication and adding users to Symantec Mobility: Suite ...................................... 103 Setting up user authentication and adding users to Symantec Mobility: Suite .................................................................................. Setting up the Mobility Suite local identity provider ............................. Configuring the local identity provider (IDP) ................................ Adding users with the local identity provider (IDP) ....................... Setting up Active Directory/LDAP authentication ............................... Configuring Active Directory/LDAP as an external identity provider (IDP) ............................................................................ Setting up SAML authentication ..................................................... Configuring SAML as an external identity provider (IDP) ............... Configuring Symantec Identity: Access Manager as your SAML identity provider .............................................................................. Adding users with the external identity provider (IDP) ......................... Permitting enterprise single sign-on (SSO) for iOS devices .................. Enabling Cisco ISE integration ...................................................... Setting up two-factor authentication ................................................ Logging onto Mobility Manager or Admin Hub using two-factor authentication ................................................................ Logging onto Mobility Manager and Admin Hub when you don't have access to the VIP Access app .................................... Renewing two-factor authentication when a certificate expires ......................................................................... Establishing an iOS Work Hub PIN policy ........................................ Establishing an Android offline PIN policy ........................................ Chapter 6 Setting up an app proxy for Symantec Mobility: Suite ............................................................................... About restricting app access to your intranet with an app proxy ............ Setting up Secure App Proxy ........................................................ Secure App Proxy deployment model ............................................. Setting up Secure App Proxy in Mobility Manager .............................. Installing Secure App Proxy .......................................................... Upgrading Secure App Proxy ........................................................ Using Symantec Secure Web to test Secure App Proxy installation ........................................................................... Uninstalling Secure App Proxy ...................................................... Secure App Proxy command line tools ............................................ Secure App Proxy default file locations ............................................ Troubleshooting Secure App Proxy ................................................ 104 104 105 110 114 115 120 121 126 130 132 133 135 140 142 143 145 147 149 149 150 151 154 157 162 163 164 165 169 170 9 Contents Chapter 7 Chapter 8 Setting up an email proxy for Symantec Mobility: Suite ............................................................................... 171 Secure Email Proxy workflow ........................................................ Introduction to Secure Email Proxy ................................................. Installing Secure Email Proxy ........................................................ Creating Secure Email Proxy clusters ............................................. Adding a Secure Email proxy to your Secure Email cluster ................. Enabling Push email notifications for your iOS Work Mail app .............. Testing Secure Email Proxy .......................................................... Configuring the Work Mail app for use with Secure Email Proxy ........... Blocking email access for non-compliant devices .............................. Monitoring Secure Email Proxy health ............................................. Upgrading, Uninstalling or Unregistering Secure Email Proxy ............... Secure Email Proxy command line tools .......................................... Secure Email Proxy default file locations ......................................... Troubleshooting Secure Email Proxy .............................................. 172 175 183 187 191 195 202 205 217 218 222 227 229 230 Setting up Symantec Secure Email ................................ 237 Setting up Symantec Work Mail in Symantec Mobility: Suite ................ Creating a device policy for Symantec Work Mail .............................. Viewing reports about devices running Symantec Work Mail ................ Creating Symantec Work Mail app configurations .............................. Chapter 9 Setting up the Apple Volume Purchase Program (VPP) ............................................................................... 244 About using the Apple Volume Purchase Program - Managed Distribution (VPP) with Symantec Mobility: Suite ......................... Setting up Apple Volume Purchase Program - Managed Distribution (VPP) ................................................................................. Enabling app license management ................................................. Configuring VPP settings in Symantec Mobility: Suite ......................... Monitoring VPP license usage ....................................................... Reclaiming VPP licenses .............................................................. Chapter 10 237 238 241 241 244 245 247 248 250 251 Setting up Windows Phone 8.1 ...................................... 253 Support for Windows Phone 8.1 in Symantec Mobility: Suite ................ Windows Phone 8.1 setup procedures ............................................ Enrolling a Windows Phone device ................................................. After device enrollment ................................................................ 253 254 266 274 10 Contents Section 2 Using Symantec Mobility: Suite ........................ 280 Chapter 11 Inviting users to enroll in Symantec Mobility: Suite ............................................................................... 281 Types of Symantec Mobility: Suite user invitation emails ..................... Sending and re-sending invitation emails ......................................... Tracking user invitations ............................................................... Customizing user invitation emails .................................................. 281 282 283 284 Chapter 12 Using Symantec Mobility: Device Management .......... 286 Restricting device enrollment ........................................................ Managing the mobile devices enrolled with Symantec Mobility: Suite .................................................................................. Setting default mobile device management (MDM) values for new device policies ..................................................................... Viewing device details and settings ................................................ Mobile Device Management (MDM) reporting in Symantec Mobility: Suite .................................................................................. Enabling and restricting device inventory collection, and viewing device inventory ............................................................................. Controlling the collection of personally identifiable information (PII) in Symantec Mobility: Suite ........................................................ Locking, wiping, resetting passwords, and issuing other commands to managed devices ................................................................. Locating a lost or stolen device ...................................................... Viewing a device's command history ............................................... Creating device policies ............................................................... Sharing settings between different device policies ............................. Prioritizing device policies ............................................................. Assigning and unassigning device policies ....................................... Applying MDM to groups in Symantec Mobility: Suite ......................... About Samsung KNOX support ..................................................... Chapter 13 287 288 290 294 296 297 299 300 303 303 304 306 309 309 310 312 Using Symantec Mobility: Threat Protection ............... 315 Securing mobile devices with Symantec Mobility: Suite ....................... Mobile security implementation workflow ......................................... Inviting users to enroll in Norton Mobile Security ............................... Downloading and installing Norton Mobile Security (NMS) manually ............................................................................. Symantec Mobility: Suite Mobile Security: User experience ................. 316 316 317 319 320 11 Contents Remediating false-positive malware alerts ....................................... Threat Protection settings for device policies .................................... Using Symantec Mobility: Suite device compliance rules ..................... Creating and managing compliance rules ........................................ Associating a compliance rule with a device policy ............................. Mobile security commands ........................................................... Checking the status of sent Mobile Security commands ...................... Tracking device compliance in Symantec Mobility: Suite ..................... Threat protection reporting in Symantec Mobility ............................... Chapter 14 321 322 324 325 327 327 328 329 329 Using Symantec Mobility: Application Management ................................................................. 331 Adding apps to Symantec Mobility: Suite ......................................... Symantec Mobility: Suite app types .......................................... Adding a native app to Symantec Mobility: Suite ......................... Adding a web app to Symantec Mobility: Suite ............................ Adding a secure web app to Symantec Mobility: Suite .................. Adding a store pointer app to Symantec Mobility: Suite ................. Adding a Symantec Sealed app to Symantec Mobility: Suite .......... Adding a VPP app to Symantec Mobility: Suite ........................... Entitling apps to users and groups ............................................ Using App Polices to manage apps in Symantec Mobility .................... App policy basics .................................................................. Creating and managing app policies ......................................... App policy configuration options ............................................... Re-wrapping apps ................................................................ Commonly used Symantec Mobility app policies ............................... Creating app policies to control network access .......................... Creating app policies that permit single sign-on (SSO) ................. Making an app so that it is required and managing required apps ............................................................................ About defining and managing app configurations in Symantec Mobility: Suite .................................................................................. Defining key-value pairs for app configurations in Symantec Mobility: Suite ................................................................ Accessing the App Configuration Manager in Symantec Mobility: Suite ............................................................................ Assigning an app configuration to a group or user ....................... Creating custom app and content metadata fields .............................. Customizing wrapped app badging ................................................. Publishing apps .......................................................................... Rescinding (un-publishing) and updating (replacing) apps ............. 331 333 335 336 338 340 342 343 344 345 345 346 349 357 358 358 360 362 366 367 370 372 373 375 376 383 12 Contents Using Symantec Sealed apps ........................................................ 383 Making your workforce more productive using the Symantec Sealed apps provided with Symantec Mobility: Suite .............. 383 The WorkSpace and using Symantec Sealed apps with Mobility Suite ............................................................................ 384 Chapter 15 Chapter 16 Chapter 17 Using Symantec Mobility: Workforce Apps .................. 388 About Symantec Mobility: Workforce Apps ....................................... Setting up Symantec Work File ...................................................... Workforce Apps: First tasks .......................................................... Managing Workforce apps ............................................................ 388 390 390 391 Managing media content in Symantec Mobility: Suite ............................................................................... 392 Adding and managing content ....................................................... Creating and assigning content policies ........................................... Creating and removing content categories ....................................... Updating, editing, re-publishing, and deleting content files ................... 392 394 396 397 Symantec Mobility: Suite reporting ............................... 398 Running reports in Symantec Mobility: Suite ..................................... 398 Symantec Mobility: Suite reports .................................................... 399 Section 3 Maintaining and Troubleshooting Symantec Mobility: Suite ................................ 405 Chapter 18 Updating, resetting, and migrating Symantec Mobility: Suite components and device clients ............................................................................. 406 Resetting the in-house iOS Work Hub ............................................. 406 Removing Mobility Suite and MDM profiles from iOS devices ............... 407 Database recommendations and setup for Symantec Mobility: Suite .................................................................................. 408 Chapter 19 MDM Core configuration and troubleshooting ........... 413 Configuring and troubleshooting the MDM core ................................. 413 13 Contents Chapter 20 Renewing and reissuing Symantec Mobility: Suite trust and authentication certificates ...................... 423 Replacing an expired SSL certificate in Symantec Mobility: Suite .......... Renewing the MDM certificate ....................................................... Reissuing authentication certificates in Symantec Mobility: Suite .......... Viewing a device's certificates in Symantec Mobility: Suite .................. 423 426 427 427 Section 4 Reference ........................................................................ 429 Chapter 21 Device Policy settings and descriptions ....................... 430 Access through Email Proxy policy settings ...................................... Certificate Authority policy settings ................................................. Certificate Template policy settings ................................................. Device Restriction policy settings ................................................... Enrollment restriction policy settings ............................................... Kiosk Mode policy settings ............................................................ Native Email policy settings .......................................................... Password policy settings .............................................................. Resources policy settings ............................................................. SSO policy settings ..................................................................... VPN policy settings ..................................................................... WiFi policy settings ..................................................................... Work Mail policy settings .............................................................. Chapter 22 430 431 432 432 436 436 440 442 443 443 444 444 446 MDM commands and features ....................................... 450 Commands that can be sent to mobile devices ................................. 450 Mobile Device Management (MDM) settings by Work Hub type ............ 454 Chapter 23 System and device requirements ................................... 457 Symantec Mobility: Suite system requirements ................................. Determining which version of Symantec Mobility: Suite you're using .................................................................................. Gathering required information for a Symantec Mobility: Suite installation ........................................................................... Sending Symantec your feedback about Symantec Mobility: Suite .................................................................................. 457 460 462 464 14 Section 1 Setting up Symantec Mobility: Suite ■ Chapter 1. Deploying Symantec Mobility: Suite ■ Chapter 2. Licensing Symantec Mobility: Suite ■ Chapter 3. Setting up Symantec Mobility: Suite main components ■ Chapter 4. Setting up Symantec Mobility: Suite trust and authentication certificates ■ Chapter 5. Setting up user authentication and adding users to Symantec Mobility: Suite ■ Chapter 6. Setting up an app proxy for Symantec Mobility: Suite ■ Chapter 7. Setting up an email proxy for Symantec Mobility: Suite ■ Chapter 8. Setting up Symantec Secure Email ■ Chapter 9. Setting up the Apple Volume Purchase Program (VPP) ■ Chapter 10. Setting up Windows Phone 8.1 Chapter 1 Deploying Symantec Mobility: Suite This chapter includes the following topics: ■ About Symantec Mobility: Suite modular solutions ■ About Symantec Mobility Manager ■ Administering Symantec Mobility: Suite on the go using the Admin Hub About Symantec Mobility: Suite modular solutions Symantec Mobility: Suite consolidates Symantec’s mobile technologies into a single-vendor solution for enterprise mobility. Mobility Suite offers a modular approach that lets you deploy modules individually or in combination. Mobility Suite is accessible from a central console called Mobility Manager. Contact your Symantec sales representative to obtain additional licenses or to upgrade to the Mobility Suite. See “Symantec Mobility: Suite module licenses” on page 33. Table 1-1 describes the Mobility Suite modules. Table 1-1 Symantec Mobility: Suite modular solutions Solution Description Symantec Mobility: Suite Provides app management, device management, and threat protection capabilities. Deploying Symantec Mobility: Suite About Symantec Mobility: Suite modular solutions Table 1-1 Symantec Mobility: Suite modular solutions (continued) Solution Description Symantec Mobility: Application Management ■ ■ ■ Secure data in corporate apps, regardless of device. Wrap a layer of security and policy management around any app. Distribute apps by user role from a customizable enterprise app store. See “Adding apps to Symantec Mobility: Suite” on page 331. See “Creating and managing app policies” on page 346. See “About restricting app access to your intranet with an app proxy” on page 149. Symantec Mobility: Device Management ■ ■ Enable devices to access key corporate assets, such as email and Wi-Fi. Apply advanced security settings to ensure corporate compliance. See “Creating device policies” on page 304. See “Introduction to Secure Email Proxy” on page 175. Symantec Mobility: Threat Protection ■ ■ ■ Guard mobile devices against malware and prevent vulnerabilities. Apply security policies for jail broken/rooted devices or by OS. App screening and reputation analysis with Norton Mobile Insight technology. See “Securing mobile devices with Symantec Mobility: Suite” on page 316. Symantec Mobility: Productivity Suite ■ ■ Includes the following workforce apps: ■ Symantec Work File ■ Symantec Work Mail ■ Symantec Work Web Provides limited app store and app policy functionality. See “About Symantec Mobility: Workforce Apps” on page 388. 17 Deploying Symantec Mobility: Suite About Symantec Mobility Manager Table 1-1 Symantec Mobility: Suite modular solutions (continued) Solution Description Symantec Mobility: Suite Trial Provides all Symantec Mobility: Suite functionality for evaluation purposes. More information See “Licensing Symantec Mobility: Suite” on page 32. See “Symantec Mobility: Suite module licenses” on page 33. About Symantec Mobility Manager Symantec Mobility Manager is the user interface that you use to configure Symantec Mobility: Suite features and monitor users and devices. The following are some other components of Mobility Manager that you'll find helpful: See “About the Symantec Mobility Manager Dashboard” on page 23. See “Accessing the Mobility Manager Inbox” on page 26. See “Setting up and customizing the User portal” on page 58. See “Determining which version of Symantec Mobility: Suite you're using” on page 460. See “Sending Symantec your feedback about Symantec Mobility: Suite” on page 464. Table 1-2 shows the left navigational pane options that are available for each Mobility Suite module. Features that your module doesn't support do not appear in Mobility Manager. For example, if you have the Symantec Mobility: Device Management module, the Content tab does not appear in the left pane of Mobility Manager. Likewise, you also only see sub-tabs based on the module that you have. For example, if you have the Symantec Mobility: Device Management module, the Content policies option does not appear under Policies and rules on the left navigation pane. Your module may also provide you with functionality, but on a restricted basis. For example, if you have the Workforce Apps module, you can only add store pointer apps. 18 Deploying Symantec Mobility: Suite About Symantec Mobility Manager Note: For all modules except the Workforce Apps, applying a Mobility Suite license does not end your trial license period. As long as your trial license is valid, you retain access to all Symantec Mobility: Suite functionality despite which type of license you subsequently apply. When your trial license does expire, you only have Mobility Manager access to the functionality for which your module entitles you. However, when you apply a Workforce Apps license, the trial license is cancelled, and you only have access to the features available for that module. Click the following links to get more details about which features are available for each Mobility Suite module. See “Symantec Mobility: Suite module licenses” on page 33. See “About Symantec Mobility: Suite modular solutions” on page 16. Table 1-2 If you have this module Symantec Mobility: Suite Mobility Manager tabs per module You have access to the following Mobility Manager tabs 19 Deploying Symantec Mobility: Suite About Symantec Mobility Manager Table 1-2 If you have this module Symantec Mobility: Application Management Mobility Manager tabs per module (continued) You have access to the following Mobility Manager tabs 20 Deploying Symantec Mobility: Suite About Symantec Mobility Manager Table 1-2 If you have this module Symantec Mobility: Device Management Mobility Manager tabs per module (continued) You have access to the following Mobility Manager tabs 21 Deploying Symantec Mobility: Suite About Symantec Mobility Manager Table 1-2 If you have this module Symantec Mobility: Threat Protection Mobility Manager tabs per module (continued) You have access to the following Mobility Manager tabs 22 Deploying Symantec Mobility: Suite About Symantec Mobility Manager Table 1-2 If you have this module Mobility Manager tabs per module (continued) You have access to the following Mobility Manager tabs Symantec Mobility: Workforce Apps More information See “Licensing Symantec Mobility: Suite” on page 32. About the Symantec Mobility Manager Dashboard The Symantec Mobility Manager Dashboard page gives you a visual snapshot of the activity occurring with your Symantec Mobility: Suite. Hover over a graphic to view additional information. 23 Deploying Symantec Mobility: Suite About Symantec Mobility Manager Table 1-3 Dashboard panels Panel Description Users Shows the number of users who were sent enrollment invitations and the total number of registered users. 24 Deploying Symantec Mobility: Suite About Symantec Mobility Manager Table 1-3 Dashboard panels (continued) Panel Description Top 5 High/Low Alerts Shows the number of high priority and low priority alerts in your mailbox. High Priority: An action is required to continue service. Low Priority: An important event occurred, a threat is detected on a device, or an action is required to prevent a stop in service. Click an low or high alerts to view a dialog box that contains a list of alerts and the dates they occurred. The dialog box also has a link to your inbox. Note: Users must clear threats from their devices. Threats cannot be cleared from devices through Mobility Manager. Once the threat is cleared from a device, threats can take up to 15 minutes to show up as removed in Mobility Manager. Use the Devices > [device] > Details page to view threats on individual devices. See “Viewing device details and settings” on page 294. Users Added in Last 7 Days Shows a bar chart of the number of users who were added for each of the last 7 days. Jailbroken/Rooted Devices Shows the percentage of devices that are jailbroken/rooted compared to total number of devices. Devices Shows the total number of devices, a breakdown of devices by platform, and color-coded indicators for corporate and personal devices. Latest Apps Published Shows the last five apps that were released and their number of downloads. Note: This panel only appears for Symantec Mobility: Suite, Symantec Mobility: Application Management, and trial licenses. More information See “About Symantec Mobility Manager” on page 18. See “Symantec Mobility: Suite module licenses” on page 33. See “Accessing the Mobility Manager Inbox” on page 26. 25 Deploying Symantec Mobility: Suite About Symantec Mobility Manager Accessing the Mobility Manager Inbox Access your Mobility Manager Inbox to view messages about the events that occur with your Mobility Manager. For example, messages can consist of notifications from Symantec of product upgrades or device enrollment violations. Access the Mobility Manager Inbox ◆ Click the envelope link in the top right banner of the Mobility Manager (which appears regardless of which page in the interface you're on). 26 Deploying Symantec Mobility: Suite About Symantec Mobility Manager View messages in your inbox 27 Deploying Symantec Mobility: Suite Administering Symantec Mobility: Suite on the go using the Admin Hub ◆ Optionally, do any of the following tasks: Gets details about a message Click on the message to view more details about the incident. Filter messages Click the All drop-down menu and select the types of messages that you want to view. View more messages To view additional messages that do not appear on the screen, click the right or left arrow beside the <n> - <n> of <n> items. Mark messages as read or unread Check the box beside the message or messages that you want to mark, click the More drop-down option and select Mark as read or Mark as unread. Tip: You can also check the box beside the Delete option to select or unselect all of the messages that appear on the screen. Delete a message Check the box beside the message or messages that you want to delete, and click Delete. Tip: You can also check the box beside the Delete option to select or unselect all of the messages that appear on the screen. More information See “About Symantec Mobility Manager” on page 18. See “About the Symantec Mobility Manager Dashboard” on page 23. Administering Symantec Mobility: Suite on the go using the Admin Hub You can monitor Symantec Mobility: Suite and perform the most commonly required tasks on the go through a mobile browser-optimized interface — the Admin Hub. Table 1-4 describes what's contained on each tab of the Admin Hub. 28 Deploying Symantec Mobility: Suite Administering Symantec Mobility: Suite on the go using the Admin Hub Mobility Suite Admin Hub Table 1-4 Tab Description Dashboard A Dashboard shows the device distribution by ownership and OS, percentage of jailbroken and rooted devices, the number of registered and unregistered users, and the amount of storage that is used and still available. Devices The Devices tab contains a list of all registered devices (and you can search for a device). Select a device to view the following details: ■ ■ ■ ■ Device owner Tapping this item navigates you to the Users tab. Device information: ■ Device name ■ MAC address ■ IMEI ■ Serial number ■ Jailbroken or rooted Device compliance: ■ MDM ■ Apps ■ Work Mail ■ Native Email Work Hub information: ■ Date enrolled ■ Last connected You can also perform the most common commands for devices: locate, lock, de-provision, and wipe (wipe command does not deprovision the user). No confirmation message appears indicating whether the command was successfully executed. 29 Deploying Symantec Mobility: Suite Administering Symantec Mobility: Suite on the go using the Admin Hub Mobility Suite Admin Hub (continued) Table 1-4 Tab Description Users The Users tab contains a list of all registered users (and you can search for a user). Select a user to view the following details: ■ All of the groups in which the user is included ■ All of the registered devices that are associated with the user Tap on the device to go to the Devices tab. You can also perform the most common commands for users: reset password, revoke (when you revoke a user, you wipe and deprovision all of the user's devices — you cannot revoke a specific device), delete, and invite the user to download the Work Hub and register with Mobility Suite. No confirmation message appears indicating whether the command was successfully executed. Account View details about your account to include your user name, first and last name, and email address. You can also log out of the Admin Hub from this tab. You must have ALL of the following permissions to view the Admin Hub: ■ View the dashboard with the admin console ■ View All Devices ■ View Devices ■ View All Users ■ View Users 30 Deploying Symantec Mobility: Suite Administering Symantec Mobility: Suite on the go using the Admin Hub See “Assigning roles” on page 64. The Admin Hub is accessible through any of the following supported mobile browsers: ■ Android: Chrome 26.0.1410.58 or higher ■ iOS: Safari 8536.25 or higher Note: The Admin Hub is not currently supported for Windows Phone. Access the Admin Hub 1 On any of the supported mobile browsers, go to the following URL: https://[mobilitysuiteURL]/adminhub For example, if you access the Mobility Manager at the following URL: https://acme.appcenterhq.com/admin You would access the Admin Hub at the following URL: https://acme.appcenterhq.com/adminhub 2 Type your user credentials. If your administrator has enabled two-factor authentication, you must also enter your VIP access security code. See “Logging onto Mobility Manager or Admin Hub using two-factor authentication” on page 140. See “Logging onto Mobility Manager and Admin Hub when you don't have access to the VIP Access app” on page 142. 3 Bookmark this URL or add it to your home screen for easy access. 31 Chapter 2 Licensing Symantec Mobility: Suite This chapter includes the following topics: ■ Licensing Symantec Mobility: Suite ■ Symantec Mobility: Suite module licenses ■ Monitoring your Symantec Mobility: Suite license status Licensing Symantec Mobility: Suite Symantec Mobility: Suite is available as both a hosted software-as-a-service (SaaS) deployment and an on-premises deployment. Hosted deployment licenses are subscription licenses. Both subscription licenses and perpetual licenses are available for on-premises deployments. Your license permits a certain number of users or devices, but you can purchase an additional license to expand the number of users and devices. With a hosted deployment, your license allows for 4 GB of storage. You can purchase an additional license to expand storage space in 10-GB increments. You follow the same procedure to renew or add a license as you do to install a new one. Note: You don't need to register a trial license. The trial license is automatically registered for you when you set up your trial version. Licensing Symantec Mobility: Suite Symantec Mobility: Suite module licenses Install a license 1 In Mobility Manager, click your account name in the upper right corner, and then click Licenses. 2 Click Add License. 3 In the Serial Number field, type or copy/paste the license serial number. 4 Click Add. 5 Repeat steps 2 - 4 to install additional licenses. Mobility Manager shows which features are licensed. More information See “Symantec Mobility: Suite module licenses” on page 33. See “Securing mobile devices with Symantec Mobility: Suite” on page 316. See “Monitoring your Symantec Mobility: Suite license status” on page 36. Symantec Mobility: Suite module licenses Table 2-1 describes the features that are available with each Symantec Mobility: Suite module license. 33 Licensing Symantec Mobility: Suite Symantec Mobility: Suite module licenses Note: Features that your module license doesn't support do not appear in Mobility Manager. For example, if you have the Symantec Mobility: Device Management module license, the App Policy, Content, and Content Policy tabs don't appear in Mobility Manager. Table 2-1 Mobility Suite module licenses Modules Trial Suite Application Management Device Threat Management Protection Workforce Apps 250 users Per user subscription license Per user subscription license Per user subscription license Per user subscription license Per user subscription license 4 GB 4 GB (increasable (increasable in in 10-GB 4 GB 10-GB increments) (increasable increments) in 10-GB increments) 4 GB (increasable in 10-GB increments) 4 GB (increasable in 10-GB increments) 4 GB (increasable in 10-GB increments) 250 users Per user subscription and perpetual license Per user subscription and perpetual license Per user subscription and perpetual license Features SaaS 60 days from registration On-premises 60 days from installation Per user Per user subscription subscription and and perpetual perpetual license license App store See “Adding apps to Symantec Mobility: Suite” on page 331. Limited functionality App policy See “Creating and managing app policies” on page 346. Content store See “Adding and managing content” on page 392. Limited functionality 34 Licensing Symantec Mobility: Suite Symantec Mobility: Suite module licenses Table 2-1 Mobility Suite module licenses (continued) Modules Trial Features Content policy See “Creating and assigning content policies” on page 394. Device policy See “Creating device policies” on page 304. Secure Email Proxy See “Introduction to Secure Email Proxy” on page 175. Secure App Proxy See “About restricting app access to your intranet with an app proxy” on page 149. Threat protection (Norton Mobile Security app integration) See “Securing mobile devices with Symantec Mobility: Suite” on page 316. This feature is only available for the SaaS trial version. Suite Application Management Device Threat Management Protection Workforce Apps 35 Licensing Symantec Mobility: Suite Monitoring your Symantec Mobility: Suite license status Table 2-1 Mobility Suite module licenses (continued) Modules Trial Features Suite Application Management Device Threat Management Protection Workforce Apps Mobile device agent (Work Hub) See “Setting up your Symantec Mobility: Suite Work Hub” on page 42. Reporting/ Dashboard See “Running reports in Symantec Mobility: Suite” on page 398. See “About Symantec Mobility Manager” on page 18. More information See “About Symantec Mobility: Suite modular solutions” on page 16. See “Licensing Symantec Mobility: Suite” on page 32. See “About Symantec Mobility Manager” on page 18. See “About Symantec Mobility: Workforce Apps” on page 388. Monitoring your Symantec Mobility: Suite license status You monitor the status of your Symantec Mobility: Suite licenses on the same page on which you install your licenses. The License page shows which licenses are registered, their expiration dates, and serial numbers. It also shows the amount of storage available and being used. And it shows the number of users allowed and registered. 36 Licensing Symantec Mobility: Suite Monitoring your Symantec Mobility: Suite license status When a license is about to expire or expired, a message appears in a banner across the top of the Mobility Manager Dashboard page to alert the administrator. And an email notification is sent if you enabled the Licensing Issues notification on the Settings > Mobility Manager configuration > Notification emails page. Monitor your Mobility Suite license status ◆ In Mobility Manager, click your account name in the upper right corner, and then click Licenses. More information See “Licensing Symantec Mobility: Suite” on page 32. See “Symantec Mobility: Suite module licenses” on page 33. See “Configuring email notifications” on page 55. 37 Chapter 3 Setting up Symantec Mobility: Suite main components This chapter includes the following topics: ■ Setting up Symantec Mobility: Suite main components ■ Branding the Mobility Manager ■ Setting up your Symantec Mobility: Suite Work Hub ■ Setting up notifications ■ Setting up and customizing the User portal ■ Customizing your app store ■ Creating groups ■ Creating a private group ■ Assigning roles ■ Creating and storing text in other languages Setting up Symantec Mobility: Suite main components After you install Symantec Mobility: Suite, you set up Mobility Suite main components, based on your organization's preferences: ■ Install your license key. See “Licensing Symantec Mobility: Suite” on page 32. Setting up Symantec Mobility: Suite main components Setting up Symantec Mobility: Suite main components Click the link below to view a video about Licensing your Symantec Mobility: Suite. http://www.symantec.com/tv/community/details.jsp?vid=2330399722001 ■ Import your iOS certificates so that you can develop and distribute iOS apps. This requires that you have an Apple Development and Distribution Provisioning Profile. See “Managing the iOS app and MDM certificates used by Symantec Mobility: Suite” on page 75. ■ Configure a Work Hub. The Work Hub is the app that launches your Mobility Suite on your end users' devices. See “Setting up your Symantec Mobility: Suite Work Hub” on page 42. ■ Identify and configure your identity provider (IDP). You can use either a local identity provider or configure an external identity provider to enroll and authenticate users. See “Setting up user authentication and adding users to Symantec Mobility: Suite” on page 104. ■ Create your roles and groups. Roles define what users have permission to do in Mobility Suite. Mobility Suite is installed with a default set of roles that are assigned a default set of permissions. You can create custom roles and assign them the permissions that you want. Groups let you combine Mobility Suite users that have something in common. If you want to give members of the group permission to perform specific tasks, you can assign one or more roles to the group. See “Creating groups” on page 61. ■ Set up notifications. You can set up the following types of notifications in Mobility Suite: push notifications, administrative notifications, and licensing notifications. See “Setting up notifications” on page 54. ■ Brand your Mobility Suite. Mobility Suite lets you apply your organization's brand to your custom Mobility Suite and mobile clients, such as adding your logo, creating a title, and so on. Note: It is important that you set up the From Email address as soon as you set up your Mobility Suite. If not, users will not receive the password reset emails because the default address is [email protected]. So even if you delay branding your Mobility Suite until a later time, ensure that you at least configure the From Email email address right away. 39 Setting up Symantec Mobility: Suite main components Branding the Mobility Manager See “Branding your in-house Work Hub” on page 44. ■ Enhance your Mobility Suite to provide more features to your end users' when logged into your Mobility Suite. See “Customizing your app store” on page 60. ■ Enable a browser-based end-user portal. This lets your end users view apps and content across all supported device platforms from any browser. See “Setting up and customizing the User portal” on page 58. ■ Configure your default language. See “Creating and storing text in other languages” on page 70. Branding the Mobility Manager Symantec Mobility: Suite lets you customize the Mobility Manager browser sign-in pages. You can also customize the Mobility Manager header. Mobility Manager contains preview screens so you can see how these items will appear before you implement your changes. Brand the Mobility Manager 1 In Mobility Manager on the left pane, click Settings > Mobility Manager configuration > Mobility Manager branding. 2 Configure the branding options in Table 3-1. 3 Click Header preview or Sign in preview to see what your custom branding will look like to your users. 4 Optionally, click Restore Default Branding to restore all the default settings and graphics. 5 When you've finished making all your changes, click Save. Your changes immediately appear. Table 3-1 Option Branding options Description Display names and email Mobility Manager This name is the name that appears in the Mobility Manager header and console name browser sign-in page. Click EN to change the language for all of the settings in Mobility Manager. 40 Setting up Symantec Mobility: Suite main components Branding the Mobility Manager Branding options (continued) Table 3-1 Option Description "From" email address This address is the address that appears on email messages to users. "From" email name This name is the name that appears in emails to users. Logos and colors Header logo This logo appears in the header of Mobility Manager. The logo graphic must be in .png or .jpg format. The minimum size is 60 (height) x 350 (width) pixels. The maximum size is 120 (height) x 400 (width) pixels. For best results, use a graphic size 400 x 400 pixels with a transparent background. This option is available for the Mobility Manager and device browser screens. Sign in logo This logo appears on the browser sign-in page for Mobility Manager. The graphic must be in .png or .jpg format. The maximum size is 400 x 400 pixels. For best results, use a graphic 120 (height) x 400 (width) pixels with a transparent background. Header This color is the header background color for device browser screens background color (Sign-in and download Work Hub screens for both Android and iOS). You must upload your own header logo to modify the header background color. This option is only available for the Mobility Manager. Text color This color is the text color for your Mobility Manager header. You must upload your own header logo to modify the header text color. This option is only available for the Mobility Manager. More information See “Branding your in-house Work Hub” on page 44. See “Customizing wrapped app badging” on page 375. See “Symantec Mobility: Suite system requirements” on page 457. 41 Setting up Symantec Mobility: Suite main components Setting up your Symantec Mobility: Suite Work Hub Setting up your Symantec Mobility: Suite Work Hub Mobile device users in your organization install the Symantec Mobility: Suite mobile device client — called the Work Hub — on their mobile devices. Depending on the device platform, the Work Hub connects devices to your Mobility Suite, applies and enforces policies, and lets users browse and download apps and content from your Mobility Suite app store. Device users typically download and install the Work Hub when they enroll with your Mobility Suite. Note: Available features vary by device platform. See “Differences between the iOS and Android Work Hubs” on page 43. Table 3-2 Work Hubs by device platform Platform Description How to set up Android Mobility Suite provides a default Work Hub for Android. See “Building the You can brand and configure the client to suit your Android Work Hub” needs. on page 53. The Android Work Hub controls mobile application management (MAM). If you enable mobile device management (MDM), the Work Hub installer detects whether the device runs a supported version of Samsung KNOX. If it does, the installer installs the Corporate Access for Samsung client. If not, the installer installs a generic client called Corporate Access. Users can't perform any tasks from this client; however, it is imperative that it remain on their device for MDM functionality. See “About Samsung KNOX support” on page 312. iOS In-house Work Hub See “Building your in-house iOS Work The in-house Work Hub for iOS provides full Mobility Hub” on page 47. Suite feature support. You must build the Work Hub app through a Mobility Manager tool. An iOS Distribution Provisioning Profile is required to build the app and upload it to your Mobility Suite. See “Creating the iOS Distribution Provisioning Profile for Symantec Mobility: Suite” on page 81. 42 Setting up Symantec Mobility: Suite main components Setting up your Symantec Mobility: Suite Work Hub Table 3-2 Work Hubs by device platform (continued) Platform Description How to set up Windows Phone Windows Phone 8.1 devices do not use a dedicated Work Hub, but instead use native services to communicate with Mobility Suite. See “Support for Windows Phone 8.1 in Symantec Mobility: Suite” on page 253. Note: To take full advantage of continual product improvements, Symantec recommends that your Work Hub is kept current with the same version as your Mobility Suite instance. More information See “Rebuilding your Android Work Hub” on page 54. See “Branding your in-house Work Hub” on page 44. Differences between the iOS and Android Work Hubs Table 3-3 describes the differences in Symantec Mobility: Suite Work Hub functionality. Note the following: ■ Windows Phone 8.1 devices do not use a dedicated Work Hub, but instead use native services to communicate with Mobility Suite. See “Support for Windows Phone 8.1 in Symantec Mobility: Suite” on page 253. ■ The features that are available to your Mobility Suite and your Work Hub are based on the features that are available per your license. See “Symantec Mobility: Suite module licenses” on page 33. Table 3-3 iOS and Android Work Hub supported functionality iOS Work Hub Feature Apps Content Android Work Hub Non-Samsung Samsung KNOX KNOX 43 Setting up Symantec Mobility: Suite main components Setting up your Symantec Mobility: Suite Work Hub Table 3-3 iOS and Android Work Hub supported functionality (continued) iOS Work Hub Feature Android Work Hub Non-Samsung Samsung KNOX KNOX PIN policy Note: Offline PIN Note: Offline PIN only. only. Change password Refresh screen by swiping Report a problem (send logs) Configure language About the Work Hub details Custom branding More information See “Setting up your Symantec Mobility: Suite Work Hub” on page 42. See “About Samsung KNOX support” on page 312. Branding your in-house Work Hub Symantec Mobility: Suite lets you customize your in-house Work Hub with your own logos, branding colors, and text colors. You can also brand the mobile browser page where users download the Work Hub. Mobility Manager contains preview screens so you can see how your Work Hub will appear to your users. After you 44 Setting up Symantec Mobility: Suite main components Setting up your Symantec Mobility: Suite Work Hub finish customizing your Work Hub, you must rebuild your Work Hub. In-house Work Hub customization is supported for iOS and Android. Brand your Work Hub 1 On the Mobility Manager left pane, click Settings > Device Configuration > Work Hub Branding. 2 Configure the branding options in Table 3-4. 3 Click iOS preview or Android preview to see what your custom branding will look like to your users. 4 Optionally, click Restore Default Branding to restore all the default settings and graphics. 5 When you've finished making all your changes, click Save. 6 A reminder appears that you must rebuild your Work Hub. Click Dismiss to make the reminder window disappear. Table 3-4 Option In-house Work Hub branding options Description Display names, emails, and support Only the Work Hub name is a required field. All other settings are optional. Work Hub name This is the name of the icon that appears on your users' mobile devices. Support email address The support email address that is used for the Android client only. Support URL On the page where users download the Work Hub, this is the link users are directed to when they click on support in the "Contact support if you need any assistance" text. Also available on Mobility Manager console pages at the bottom of the screen. Support portals should use a URL (e.g., https://support.acme.com). Email support should use a “mailto” address (e.g., “mailto:[email protected]”). 45 Setting up Symantec Mobility: Suite main components Setting up your Symantec Mobility: Suite Work Hub Table 3-4 In-house Work Hub branding options (continued) Option Description FAQ This text or URL link appears on the page where users download the Work Hub. Logos, icons, and colors Mobility Suite resizes your icon, logo mark, and menu logo. However, for optimal affect, use the recommended pixel size. Mobility Suite supports graphics in the following format: .png and .jpg. App icon This is the icon that users tap to open the Work Hub on their mobile devices. The recommended optimal pixel size is 512 x 512. Logo mark The logo mark is only supported for iOS devices. This logo appears when loading the Work Hub and as a "splash" screen when the user opens the Work Hub. The recommended optimal pixel size is 1000 x 1000. For best results, use a .png file that has a transparent background. See also Brand color. Menu logo This is the logo that appears in the Work Hub at the top of the navigation menu. The recommended optimal pixel size is 1000 x 250. For best results, use a .png file that has a transparent background. App colors To customize colors, you must first upload your own app icon, logo mark, and menu logo. Brand color For Android, this is the color for screen headers and select menu options (for example, if Home is selected, then Home is in the Brand color. For iOS, it's the background color for your "splash" screen. See also Logo mark. 46 Setting up Symantec Mobility: Suite main components Setting up your Symantec Mobility: Suite Work Hub Table 3-4 In-house Work Hub branding options (continued) Option Description Text color This is the text color for the action buttons, such as Sign In, Sign Out, and Install. For Android, this color is also used for the screen's header text and search text color. See Detail color for background color of action buttons. Navigation color This is the slide menu background color. Navigation text color This is the slide menu text color. Detail color This is the color for the action buttons (e.g., Sign In, Sign Out, Install). See also Text color for the action button text color. Detail color is also used for the Category box and the Account box for both iOS and Android. More information See “Building your in-house iOS Work Hub” on page 47. See “Building the Android Work Hub” on page 53. See “Branding the Mobility Manager” on page 40. See “Customizing wrapped app badging” on page 375. Building your in-house iOS Work Hub You can build your iOS Work Hub using one of the following options ■ In-Browser Builder You can build your iOS Work Hub in Mobility Manager. To do so, you must upload your Apple code-signing certificate to Mobility Manager. If you do not want to upload this certificate, use the OS X Application builder (a.k.a. "Mac builder"). See “Building your in-house iOS Work Hub in Mobility Manager” on page 50. ■ OS X Application builder (a.k.a. "Mac builder") You can build your iOS Work Hub on a Mac computer by downloading the builder to your local OS X environment. See “Building your in-house iOS Work Hub in your OS X environment” on page 48. What you'll need ■ Your iOS Distribution Provisioning Profile Work Hub 47 Setting up Symantec Mobility: Suite main components Setting up your Symantec Mobility: Suite Work Hub ■ Your Apple code-signing certificate See “Creating the iOS Distribution Provisioning Profile for Symantec Mobility: Suite” on page 81. More information See “Differences between the iOS and Android Work Hubs” on page 43. See “Resetting the in-house iOS Work Hub” on page 406. See “Setting up your Symantec Mobility: Suite Work Hub” on page 42. Building your in-house iOS Work Hub in your OS X environment Re-building the Work Hub updates it to include any new functionality that is distributed with an upgrade to the Mobility Suite tenant. After you rebuild the Work Hub, registered devices receive a push notification indicating that a newer version of the Work Hub is available to download. Building or re-building the Work Hub using the Work Hub builder follows the same process. What you'll need ■ Access to a system running OS X with Xcode 4.4 or greater ■ A Mobile Provisioning Profile from the Apple Development iOS Provisioning Portal TIP: If you do not have your Mobile Provisioning Profile at hand, you can download it from the Apple Development iOS Provisioning Portal. https://developer.apple.com/account/ Build an in-house iOS Work Hub using the Download Builder 1 On the Mobility Manager left pane, click Settings > Device Configuration > iOS client. 2 Under iOS client, click Use in-house Work Hub. 3 Under Policy, configure the following: ■ Check Authentication if you want to permit access to downloaded content when the in-house Work Hub is offline. ■ Check Content storage and specify the on-device storage limit of downloaded content. ■ Check Usage restrictions if you want to destroy app-related data and disable the Work Hub on jailbroken devices. This option is enabled by default. 48 Setting up Symantec Mobility: Suite main components Setting up your Symantec Mobility: Suite Work Hub Note: You must configure these policy settings before you build the Work Hub. 4 Under Work Hub Builder, select OS X Application, and then click Download builder. Open the file. 5 Double-click WorkHubBuilder.app. 6 Click Import Enterprise or Ad Hoc Distribution Profile and select your Mobile Provisioning Profile. If the import was successful, your profile information appears. 7 In the Symantec Mobility Manager URL: https:// field, type the FQDN of your Mobility Manager. 49 Setting up Symantec Mobility: Suite main components Setting up your Symantec Mobility: Suite Work Hub 8 Click Generate and upload iOS Work Hub App. 9 You are prompted to enter Mobility Manager credentials. These credentials must belong to a member of the Mobility Manager Administrators groups. The process of building your Work Hub begins. A message appears indicating if the Work Hub was successfully built. 10 Click OK. More information See “Building your in-house iOS Work Hub in Mobility Manager” on page 50. See “Installing the iOS Provisioning Profile and iOS push certificate for Symantec Mobility: Suite” on page 79. See “Building your in-house iOS Work Hub” on page 47. See “Rebuilding the in-house iOS Work Hub” on page 53. See “Resetting the in-house iOS Work Hub” on page 406. See “Branding your in-house Work Hub” on page 44. Building your in-house iOS Work Hub in Mobility Manager Symantec Mobility: Suite lets you build the in-house iOS Work Hub with a browser-based app builder. The browser-based method is more streamlined than the iOS Work Hub build method. Be careful! When you rebuild the in-house iOS Work Hub, the BundleID must be the same as your original Work Hub. The Distribution Provisioning Profile and the Distribution Certificate each have their own expiration dates. Be sure that the expiration date is valid for both before you add the Distribution Provisioning Profile. If the Distribution Provisioning Profile is expired, you must create a new one. Be sure to use the same AppID as the original Distribution Provisioning Profile you 50 Setting up Symantec Mobility: Suite main components Setting up your Symantec Mobility: Suite Work Hub replace. If the Distribution/Code-Signing Certificate is expired, you must obtain an updated Distribution/Code-Signing Certificate from your administrator. Note: Rebuilding the in-house iOS Work Hub uses the same Distribution Profile as the original. In some cases, however, you may want to apply a different Distribution Profile and reset any database associations to the in-house iOS Work Hub. To do this, reset the in-house iOS Work Hub. See “Resetting the in-house iOS Work Hub” on page 406. What you'll need ■ The following certificates: ■ Push certificate ■ Code-signing certificate MDM certificate (optional) The MDM certificate is not required to build the in-house iOS Work Hub, but it is highly recommended. The MDM certificate is required to enable all of the Mobility Suite MDM features. Tip: These certificates are found on the Settings > Certificates > Apple/iOS certificates page. ■ ■ Apple Distribution Provisioning Profile See “Managing the iOS app and MDM certificates used by Symantec Mobility: Suite” on page 75. Build the in-house iOS Work Hub in Mobility Manager 1 On Mobility Suite left pane, click Settings > Device configuration > iOS client. 2 Under iOS client, click Use in-house Work Hub. 3 Under Policy, configure the following: ■ Check Authentication if you want to permit access to downloaded content when the in-house Work Hub is offline. ■ Check Content storage and specify the on-device storage limit of downloaded content. ■ Check Usage restrictions if you want to destroy app-related data and disable the Work Hub on jailbroken devices. This option is enabled by default. Note: You must configure these policy settings before you build the Work Hub. 51 Setting up Symantec Mobility: Suite main components Setting up your Symantec Mobility: Suite Work Hub 4 Under Work Hub Builder, click In-browser. 5 Click Upload Distribution Profile..., and then browse and select your Distribution Profile. The Distribution Profile section displays the expiration date and Bundle Identifier that are associated with your Distribution Provisioning Profile. The Distribution Provisioning Profile is comprised of an AppID and the Distribution/Code-Signing certificate. Similarly, the AppID is comprised of the Bundle Seed and BundleID. See “Creating the iOS Distribution Provisioning Profile for Symantec Mobility: Suite” on page 81. 6 Click Build iOS Work Hub. The Mobility Suite Builder closes upon completion. The status of the build appears under the Mobility Suite Builder heading along with the date and time. More information See “Rebuilding the in-house iOS Work Hub” on page 53. 52 Setting up Symantec Mobility: Suite main components Setting up your Symantec Mobility: Suite Work Hub See “Managing the iOS app and MDM certificates used by Symantec Mobility: Suite” on page 75. See “Branding your in-house Work Hub” on page 44. Rebuilding the in-house iOS Work Hub You may need to periodically rebuild your in-house iOS Work Hub (for example, after you upgrade to a new version of Symantec Mobility: Suite). Rebuilding an in-house iOS Work Hub updates the app to include any new functionality that is distributed with an upgrade. You follow the same procedure to rebuild the app as you do when you build it. After you rebuild the app, device users are notified that a newer version is available to download. See “Building your in-house iOS Work Hub in your OS X environment” on page 48. Note: Rebuilding the in-house iOS Work Hub uses the same Distribution Profile as the original. In some cases, however, you may want to apply a different Distribution Profile and reset any database associations to the in-house iOS Work Hub. To do this, you reset the in-house iOS Work Hub. See “Resetting the in-house iOS Work Hub” on page 406. Building the Android Work Hub Symantec Mobility: Suite is installed with a default Work Hub for Android devices. Users must download the Work Hub to their devices, which they typically do when they enroll. Users can then launch the Work Hub and browse and download the apps to which they're entitled. The default Android Work Hub is installed with an icon and a short title. However, you can brand the Work Hub so that it appears the way that you want on your users' devices. See “Branding your in-house Work Hub” on page 44. By default, the Work Hub automatically destroys data and disables itself on any device that it detects as rooted. But you can disable this function. 53 Setting up Symantec Mobility: Suite main components Setting up notifications Build the Android Work Hub 1 On the Mobility Manager left pane, click Settings > Device configuration > Android client. 2 Uncheck Destroy data and disable client on rooted devices to prevent Mobility Suite from destroying any app-related data on the devices that are detected as rooted. 3 Click Build Android Work Hub. More information See “About Samsung KNOX support” on page 312. See “Rebuilding your Android Work Hub” on page 54. See “Setting up your Symantec Mobility: Suite Work Hub” on page 42. See “Branding your in-house Work Hub” on page 44. Rebuilding your Android Work Hub You may need to periodically rebuild your Android Work Hub (for example, after you upgrade to a new version of Symantec Mobility: Suite). Rebuilding a Work Hub updates the app to include any new functionality distributed with an upgrade. After you rebuild the Work Hub, users who installed it are notified that a newer version is available to download. Rebuild your Android Work Hub 1 Click Settings > Device configuration > Android client. 2 Click Rebuild Android Work Hub. The date and time that the Work Hub was built appears. More information See “Building the Android Work Hub” on page 53. See “Setting up your Symantec Mobility: Suite Work Hub” on page 42. Setting up notifications Symantec Mobility: Suite uses the following types of notifications: ■ Email notifications- These are email messages generated by Mobility Suite components and sent to the email addresses you specify in Mobility Manager on the Settings > Mobility Manager configuration > Notification emails page. See “Configuring email notifications” on page 55. 54 Setting up Symantec Mobility: Suite main components Setting up notifications ■ Push notifications- These are OS-based notifications sent to enrolled mobile devices through the OS's notification system (APNs for iOS, and GCM for Android). See “Configuring push notifications” on page 57. Configuring email notifications You can set up a default email address to which all notification emails are sent. You can also specify a different email address (or a distribution list address if multiple people should receive notification) for a specific type of notification. For example, the administrator who monitors device compliance may be different than the administrator who monitors license renewals. Mobility Suite also lets you create custom subject prefixes and message suffixes to notification emails. Configure Mobility Suite email notifications 1 Click Settings > Mobility Manager configuration > Notification emails. 2 Under Default settings, type an email address. Optionally add a subject prefix and a message suffix. When you specify a default email address, this address is automatically pre-populated into the various notification type email address fields. 3 Click On to enable the notification emails you want to be sent. 4 To specify recipients other than the default recipient, click the + icon next to the notification type and type the email address of the alternative recipient. You can also use an email distribution list ("DL") address. 5 Click Save. More information See “Setting up notifications” on page 54. See “Types of notification emails” on page 55. Types of notification emails Table 3-5 describes the types of notification emails that Symantec Mobility: Suite can send. 55 Setting up Symantec Mobility: Suite main components Setting up notifications Table 3-5 Notification email types Symantec Mobility: Suite Description notification email type Operations Messages Scheduled SaaS maintenance periods, system outages, and support tickets. Licensing Issues A product license is about to expire or has expired. Or storage space or user count is about to reach its limit or has reached its limit. See “Licensing Symantec Mobility: Suite” on page 32. Important: You must enable this notification to receive the email notifications that app licenses usage has reached a percentage of its total. See “Configuring VPP settings in Symantec Mobility: Suite” on page 248. Norton Mobile Security A threat is detected on a registered device. Note: This type of notification is not available in Symantec Mobility: Application Management or Symantec Mobility: Device Management versions. See “Securing mobile devices with Symantec Mobility: Suite” on page 316. Certificates Expiration A certificate is about to expire or has expired. See “Renewing the MDM certificate” on page 426. See “Reissuing authentication certificates in Symantec Mobility: Suite” on page 427. Registration Restrictions A device that was enrolled did not meet registration restrictions. See “Restricting device enrollment” on page 287. Administrative A registered device is not compliant. See “Managing the mobile devices enrolled with Symantec Mobility: Suite” on page 288. More information See “Setting up notifications” on page 54. See “Sending email notifications when push notifications are unavailable” on page 57. 56 Setting up Symantec Mobility: Suite main components Setting up notifications Configuring push notifications Symantec Mobility: Suite sends notifications to users when new applications or updates are available. For most devices, notifications are delivered from Mobility Suite to the mobile device through the OS's notification service: Google GCM for Android devices or Apple Push Notification Service (APNS) for iOS devices. Table 3-6 Push notification Description Android push notifications Mobility Suite configures itself to communicate with Google GCM and uses a site-wide account and self-signed certificates. The GCM account is embedded in the Android Work Hub too. iOS push notifications Mobility Suite does not automatically configure itself to communicate with Apple APNS. APNS requires special certificates to enable communication from Mobility Suite to the user's device through APNS. APNS certificates are created at the Apple Developer Provisioning Portal (http://developer.apple.com). You typically create the APNS "push" certificate when you create the mobile provisioning files for the iOS version of the Work Hub (the mobile client). More information See “Installing the iOS Provisioning Profile and iOS push certificate for Symantec Mobility: Suite” on page 79. See “Sending email notifications when push notifications are unavailable” on page 57. See “Configuring email notifications” on page 55. Sending email notifications when push notifications are unavailable Certain Android devices don't support push notifications. In particular, those devices without the Google Market App or those that have not been configured with a Google Account. However, you can configure Symantec Mobility: Suite to send email notifications to users advising them of new or updated apps when push notifications are unavailable. The email address Mobility Suite uses is the one associated with the user on the Users > {user name} page. See “Setting up user authentication and adding users to Symantec Mobility: Suite” on page 104. 57 Setting up Symantec Mobility: Suite main components Setting up and customizing the User portal Sending email notifications when push notifications are unavailable 1 Click Settings > Mobility Manager configuration > Notification emails. 2 Scroll down to the bottom and check Send notification email if push notifications are unavailable. 3 Click Save. More information See “Setting up notifications” on page 54. Setting up and customizing the User portal Symantec Mobility: Suite lets you enable a self-service User portal where your users can view apps and content from any non-mobile device browser (such as a personal computer). The User portal displays apps and content across all supported device platforms. You can also display your own billboard on the User portal. This can either be in the form of a text description or a URL can be used to source the content. And you can add additional tabs for custom content. Note: The Enhanced store must be enabled to enable the User portal. See “Customizing your app store” on page 60. To enable the User portal, you must have a valid Symantec Mobility: Suite or Symantec Mobility: App Management license installed. Users access the User portal at the following URL: https://<my_url>.appcenterhq.com/portal where <my_url> is the name of your Mobility Suite tenant. 58 Setting up Symantec Mobility: Suite main components Setting up and customizing the User portal Enable the User portal 1 Click Settings > Mobility Manager configuration. 2 On the User portal page, next to Web portal, check Users can browse apps in a web browser. When you check this option, additional options appear. Customize the User portal (optional) 1 Check Users can view their devices in the User portal to let users view details about their own devices. 2 Check Users can run commands on their devices in the User portal to let users run commands on their own devices. 3 In the Billboard Text type information that you want to appear on the home page of the User portal. When this box is blank, no message appears. 59 Setting up Symantec Mobility: Suite main components Customizing your app store 4 In Billboard URL, type a URL address. This setting is the URL for the optional sub-page (iframe) to appear. For example: https://intranet.acme.com/internal_news. When this box is blank, no message appears. The billboard page should be served by HTTPS (SSL), and for best viewing results, the billboard page should be 320px high by 865px wide. 5 Optionally, in the Tab Name box, type the name of an extra tab to add to the User portal. The content for this tab is directly sourced using the Tab URL (below), and the Tab Name is shown as the selectable tab on the left-hand panel of the User portal. 6 If you added a new tab, type the Tab URL. 7 At the top of the page, click Save. Customizing your app store You can customize the way your app store appears to your users when they access it through their Symantec Mobility: Suite Work Hub on their devices, or through their User portal on a web browser. When logged into your app store, users can do the following by default: ■ View new and popular apps and content ■ View apps and content by category ■ Search for apps and content by some specified text ■ Select apps that they are interested in ■ View apps that are required by your enterprise ■ View information about their enrolled devices You can customize your app store to allow users to: ■ View and request access to apps and content to which they are not entitled These are apps and content that are assigned to groups to which a user does not belong. A user can view these apps and content, but cannot install or download them. However, when viewing them, a user can request access to these apps or content. When a user does so, an email request is sent to the app's publisher. ■ See the names of users who have reviewed apps User reviews appear when a user selects an app 60 Setting up Symantec Mobility: Suite main components Creating groups As an admin, you can: ■ Add or remove app and content categories You can assign a new category when you subsequently add or edit an app or content. See “Adding apps to Symantec Mobility: Suite” on page 331. See “Adding and managing content” on page 392. Customize the Enhanced store 1 Click Settings > Mobility Manager configuration > Enhanced store. 2 Under Options, click Enabled to enable the User portal. Note: This option does not enable or disable any of the other options listed on the Enhanced store page. It is used strictly to enable or disable the User portal. See “Setting up and customizing the User portal” on page 58. 3 Click User can see all apps, even if not entitled to let your users view all your apps, even those to which they are not entitled. 4 Click Expose reviewer identity to display the names of users who have reviewed apps. 5 Under App categories, click Add to add a new app category, or Remove to delete an existing category. 6 Under Content store, click User can see all content, even if not entitled to let your users view all content, even content to which they are not entitled. 7 Under Content categories, click Add to add a new content category, or Remove to delete an existing category. 8 Click Save. More information See “Setting up and customizing the User portal” on page 58. See “Branding your in-house Work Hub” on page 44. Creating groups Groups let you combine Mobility Suite users who have something in common. If you want to give members of the group permission to perform specific tasks, you can assign one or more roles to the group. Once you set up a group, you can easily assign app policies, manage devices, control content, etc., based on those groups. 61 Setting up Symantec Mobility: Suite main components Creating groups For example, you might create a group called "Finance" that consists of all of the registered Mobility Suite users who work in the Finance department. You can create apps that for solely for use by the Finance department and assign those policies just to the "Finance" group. Users in groups fall into one or more of the following categories: ■ Users who develop and publish apps, manage devices and content, and perform administrative tasks within Mobility Suite. After you have defined your roles, you can assign those roles to groups. For example, you can assign the Publishers role to the Publishers group. Everyone in the Publishers group can perform all the tasks that you defined for the Publishers role. ■ End users who access Mobility Suite to download content and apps and whose devices you want to secure and manage. Creating groups for your end users makes it easier to define what policies apply to these users. For example, you can create a group called Finance. Then you can create app policies that only members of the Finance group can access. Mobility Suite installs with default groups that correspond with the default roles (i.e., administrators, developers, publishers, and managers). There is also the default groups all, which consists of all of the users who have registered with Mobility Suite. A single user can be in multiple groups. You should set up your groups in Mobility Suite before you configure your identity provider (IDP) so that when you configure the IDP, you can map users to the Mobility Suite groups that you created. Thereafter, you can create, delete, or modify groups as needed. You set up and manage groups in the same manner regardless of which IDP you use. See “Setting up user authentication and adding users to Symantec Mobility: Suite” on page 104. As you create a group, you can specify what roles (if any) you want to apply to the group. After you create a group, you can apply policies to the group, set up device management policies, and so on. When you configure an external IDP, you can map the IDP's groups to your Mobility Suite groups. This way, you do not have to individually add members to groups. See “Assigning roles” on page 64. See “Creating a private group” on page 63. To create a group 1 In Mobility Manager, click Users. 2 On the right pane, click Create Group. 3 In the Group name field, type the name for the new group. 62 Setting up Symantec Mobility: Suite main components Creating a private group 4 Click the Group permissions box and select all of the roles that you want to assign to your new group. 5 In the Members box, type the name of a user that you want to add to this group, and then click Add. Repeat this step for each user that you want to add. Tip: As you begin typing, Mobility Manager suggests user names. If you use an external IDP, you can map the IDPs groups to your Mobility Suite groups. Users automatically are added to the appropriate groups based on the group mappings when they enroll with Mobility Suite. 6 To limit the members of the new group to viewing just the devices and/or users in a specific subgroup, click the Admins who can manage this group box and select the subgroup. You must have selected a role that includes View Devices and/or View Users. For example, you want the members of this new group to be able to view only the East Coast Managers devices. So you select a role that includes the rights to View Devices and in the Admin Scope box, you select the group East Coast Managers. See “Creating a custom administrator role” on page 67. 7 Click Save. See “Setting up the Mobility Suite local identity provider” on page 104. See “Setting up Active Directory/LDAP authentication” on page 114. See “Setting up SAML authentication” on page 120. Creating a private group You can create a private group of users who do not fall into one of your already established categories of groups. For example, you can create a private group of select users to beta test apps. This group can be called Beta Testers and would include certain administrators and developers who can test an app that is being developed. You must have administrator rights or the Edit App Assignments Roles & Permissions (under Apps) selected to see the Create Private Group option when you edit the app. See “Assigning roles” on page 64. 63 Setting up Symantec Mobility: Suite main components Assigning roles To create a private group 1 Upload an app through Mobility Manager. See “Adding apps to Symantec Mobility: Suite” on page 331. 2 Save the app without any entitlement. 3 On the right pane, click Edit to edit the app you just saved. 4 Under Associated users, click Create private group. 5 In the Group Name box, type a name for the new private group. 6 In the Members box, start typing the name of a member you want to add to the group. When the name that you want to add appears, select it . Repeat this step to add all the members to the group. 7 Click Save, and then click Save on the Edit [app] page. 8 On the right pane, click Edit for the version of the app that you want associated with the private group you just created. 9 Under Entitlements click the Group box to show the list of all available groups, and select the private group you just created. 10 Click Save. Assigning roles Roles define what users have permission to do in Symantec Mobility: Suite. Mobility Suite installs with pre-defined roles that are assigned a default set of permissions (see Table 3-7). You can edit the permissions in the default roles or create custom roles and assign them the permissions that you want. Once you establish your roles, you can assign one or more roles to a group. The roles that you assign to your groups determine the tasks that the groups' users can perform, as well as the features that they can access in Mobility Manager. Despite which roles you assign a user, if you want to require a user to use two-factor authentication to access the Mobility Manager or the Admin Hub, the user must have the following minimum permissions: ■ Change device management settings ■ Can add app policy ■ Can change app policy ■ Can delete app policy ■ Can add content policy 64 Setting up Symantec Mobility: Suite main components Assigning roles ■ Can change content policy ■ Can delete content policy ■ Lock Device ■ Ping Device ■ De-provision Device ■ Reset Device Password ■ Revoke Device ■ Wipe Device ■ Can add device policy ■ Can change device policy ■ Can delete device policy Table 3-7 Default roles Role Description Administrator Has full administrative permissions throughout Mobility Manager. Publisher Has limited access to Mobility Manager with the following permissions to: Manager ■ Do everything a developer can do. However, they can do this only for the apps and content for which they have been assigned as Publisher — not just the apps or content that they upload. ■ Approve or deny publish requests from Developers for apps for which that they are Publisher Only Administrators can assign a Publisher permission to a certain app or content. Has limited access to Mobility Manager with the following permissions to: ■ ■ Change group membership (that is, entitlements) for apps and content. Manage any apps or content for which they are assigned as Manager. Managers cannot upload, replace, or delete any apps or any content. Only Administrators can give a Manager permission to manage an app or content. 65 Setting up Symantec Mobility: Suite main components Assigning roles Table 3-7 Default roles (continued) Role Description Developer Has limited access to Mobility Manager with the following permissions to: Device Manager ■ Upload apps. ■ Replace or delete apps that they previously uploaded. ■ Determine which groups can install developer. ■ Request a Publisher publish their app as production as beta. Has limited access to Mobility Manager with the following permissions to: ■ Policy Editor Access mobile device management (MDM). They can see a list of devices and execute device options such as revoke the Work Hub. Has limited access to Mobility Manager with the following permissions to: ■ Define and edit content policies, app policies, and MDM policies. ■ Assign device policies. Policy Editors cannot, however, assign content or app policies. To assign roles 1 In Mobility Manager, click Settings > Authentication and roles > Roles and permissions. 2 Do one of the following: 3 ■ To create a new role, click Add Role and then type the name of the role. ■ To create a role from an existing role, select the existing role, and then click the Duplicate role icon. Type the name of the role. Note: If you duplicate a role, the new role is assigned the same permissions as the role from which it was duplicated. 66 Setting up Symantec Mobility: Suite main components Assigning roles 4 Check each permission that you want to grant to this role. When you grant a role to add a certain permission, you should also grant the corresponding role to change that permission. However, you can grant a role to change a permission without granting the role to add the permission. For example, if you check Can add device policy, you should also check Can change device policy. However, you can just check Can change device policy without checking Can add device policy. 5 Click Save. More information See “Creating groups” on page 61. See “Creating a custom administrator role” on page 67. See “Setting up two-factor authentication” on page 135. Creating a custom administrator role Symantec Mobility: Suite lets you create groups and assign roles to these groups that allow the group members to see only the users and/or devices for the specific groups that you specify. When you select the permissions View Devices and/or View Users in a role and then assign that role to a group, you can restrict the group's members to being able to view just the devices and/or users for the subgroup that you specify. Note: You must uncheck View All Devices and/or View All Users for this feature to work as designed. See “Creating groups” on page 61. For example, assume that you want to let only a few administrators be able to view all of the users and devices in their specific region. So you create a new role called "Regional Admins." And in that role, you select the permissions View Devices and View Users. You already have setup groups for "all users - East Coast" and "all users - West Coast." Now you create a new group called "East Coast Admins," and in that group you add the administrators who will manage the East Coast users and their devices. When you configure this new group, in the Admin Scope you select all users - East Coast. This means that the members of the "East Coast Admins" group can only view the users and devices for the members of the "all users - East Coast" group. They cannot, for example, view users or their devices for the "all users - West Coast" group. 67 Setting up Symantec Mobility: Suite main components Assigning roles While you can use this feature with any identity provider, it is better suited for larger organizations that integrate with Active Directory and/or LDAP. When you integrate with Active Directory/LDAP, you can use Mobility Suite's group mapping feature to map Active Directory/LDAP groups to Mobility Suite groups. When you are ready to create a new Mobility Suite User group, the Active Directory/LDAP groups and subgroups that you have mapped automatically appear in Mobility Manager on the Users > Create Group page. See “Configuring Active Directory/LDAP as an external identity provider (IDP)” on page 115. You do the following tasks to set up custom administrators: ■ Create a custom administrator role ■ See “Create a custom administrator group” on page 69. To complete this workflow, you must have first configured and enabled your identity provider and configured your group mappings. See “Setting up user authentication and adding users to Symantec Mobility: Suite” on page 104. Create a custom administrator role 1 In Mobility Manager, click Settings > Authentication and roles > Roles and permissions. 2 In the right pane, click Add Role. 3 In the right pane, type a name for the role. 4 Make sure View Devices and/or View Users is checked. You can check one or the other or both. 68 Setting up Symantec Mobility: Suite main components Assigning roles 5 Make sure View All Devices and/or View All Users is unchecked. If you checked only View Devices, then make sure View All Devices is unchecked. If you checked View Users, make sure View All Users is unchecked. This feature does not work as designed if the corresponding "All" option is checked. 6 Check any of the tasks that you want this role to have permissions to do, and uncheck any roles that you don't want users to have permission to do. 7 Click Save. Create a custom administrator group 1 In Mobility Manager, click Users. 2 In the right pane, click Create Group. 3 In the Group name box, type the name for your new group. 4 Click Group permissions and select the new role that you just created. See “Create a custom administrator role” on page 68. 5 Click Admins who can manage this group and select one or more groups that this new user group should have limited access to view all devices or users (based on the roles that you selected). 6 Click Save. 69 Setting up Symantec Mobility: Suite main components Creating and storing text in other languages Creating and storing text in other languages You can create and store text in languages other than your default language for some of the features in Symantec Mobility: Suite. Typically, this is text that you want to appear to users who have different native languages and are using devices that support those languages. This might include the text that appears in your email invitations, or in the User portal. If text is not available in another language for these features, it appears in your default language. Table 3-8 Features that support multi-language text Settings > Mobility Manager configuration > Branding Settings > Mobility Manager configuration > Enhanced Store Settings > Mobility Manager configuration > User portal Settings > Device configuration > Device management Users > Invite templates Settings > Metadata > App notes Apps (edit and version edit) Settings > Users > Invite templates Set your default language 1 In Mobility Manager, click Settings > Mobility Manager configuration > Language settings. 2 Under Default language, select your default language. 3 Click Save. Create multi-language text on a supported Mobility Manager page 1 On any of the Mobility Manager pages listed above, type the text initially in your default language. 2 At the top of the page in the banner, click the drop-down menu of your default language and specify another language. 3 Type the text in that language. The localized text appears on the devices and User portal configured for that language. If localized data is not available, the content appears in the default language. See “Customizing and sending user invitation emails in other languages” on page 71. 70 Setting up Symantec Mobility: Suite main components Creating and storing text in other languages Customizing and sending user invitation emails in other languages Symantec Mobility: Suite is installed with default email invite templates in multiple languages. You can customize these templates to suit your needs, and then send them to your users in their local languages to enroll their devices. To customize an email invite template in another language 1 In Mobility Manager, click Users > Invite templates. 2 On the top-right menu bar, click the language drop-down menu and select the language. 3 Select the invite template: ■ Work Hub Invite ■ NMS Invite ■ Apple VPP Invite The email invite appears in the language that you selected. 4 Click the Edit icon. On the Edit Invite screen, type or edit the content for the email invite. Use the toolbar to format the invitation message. Note: To replace or add images, place the cursor where the image is to appear and then click the Image icon (next to the Toggle HTML switch). Enter the URL for the image and then click OK. 5 Click Save. To send an email invite in another language 1 In Mobility Manager, click Users > Invite users. 2 On the top-right menu bar, click the language drop-down menu and select the language. 3 Under Invite users, select the email invite: ■ Work Hub Invite ■ NMS Invite ■ Apple VPP Invite The email invite appears in the language that you selected. 4 Enter the email addresses and select the groups for the users you want to send the invite, and then click Send Invite. 71 Setting up Symantec Mobility: Suite main components Creating and storing text in other languages Note: To ensure that email invitations are properly receive, it is recommended that you add the following IP address and FQDN to your mail server's whitelist: ■ 208.115.239.221 ■ o1.email.symantec.appcenterhq.com See “Customizing user invitation emails” on page 284. See “Creating and storing text in other languages” on page 70. 72 Chapter 4 Setting up Symantec Mobility: Suite trust and authentication certificates This chapter includes the following topics: ■ Managing authentication certificates in Symantec Mobility: Suite ■ Managing the iOS app and MDM certificates used by Symantec Mobility: Suite ■ Using dynamic authentication certificates in Symantec Mobility: Suite ■ Specifying a Certificate Authority (CA) for dynamic certificates ■ Configuring a Certificate Template in Symantec Mobility: Suite ■ Specifying SCEP and dynamic certificates in iOS device policies ■ Allowed characters and values in Symantec Mobility: Suite dynamic certificates ■ Installing the Symantec ADCS Communication Service to provision MSCA certificates within Symantec Mobility ■ Adding LDAP certificates ■ Creating self-signed certificates Managing authentication certificates in Symantec Mobility: Suite Authentication certificates play several important roles in Symantec Mobility: Suite. For managing iOS devices, iOS apps, and iOS notifications, a series of certificates Setting up Symantec Mobility: Suite trust and authentication certificates Managing authentication certificates in Symantec Mobility: Suite are required to establish chains of trust between Apple, iOS devices, iOS apps, and Mobility Suite. Services such as Exchange ActiveSync, VPN, and Wi-Fi use certificates to establish chains of trust between iOS mobile devices and secure network infrastructure. Certificates, ID's, and profiles for iOS apps and MDM The certificates you need to manage iOS devices in Mobility Suite are a combination of certificates you obtain from a Certificate Authority (CA) and Apple. To take full advantage of Mobility Suite’s Mobile Device Management (MDM) capabilities for iOS devices, and iOS app wrapping, you need the full complement of iOS certificates, an App ID, and a Mobile Provisioning Profile. See “Managing the iOS app and MDM certificates used by Symantec Mobility: Suite” on page 75. Authentication certificates for secure network services There are two options for managing the certificates that secure EAS, VPN, and WiFi. You can manage them yourself, or you can use a managed public key provider (“MPKI”, for Managed Public Key Infrastructure). An MPKI provider handles the functions of Certificate Authority, repository, distributor, and certificate auditor for you. Mobility Suite is currently integrated with Symantec's Managed PKI service. Users with a Symantec Managed PKI account can set up Mobility Suite device policies to request certificates from the CA, as needed (called dynamic certificates). Authentication certificate for two-factor authentication Certificates that are used for two-factor authentication also appear on the Settings > Certificates > Authentication certificates page. If you are a SaaS tenant, an authentication certificate is created for you when you request two-factor authentication setup. Symantec Mobility renews this certificate before expiration. So there's no requirement for you to obtain and upload a new certificate when the current one expires. If you are an on-premises tenant, you must have a valid certificate to request and use two-factor authentication. The file must be in .p12 file format. You can use a certificate that a certificate authority (CA) issues or a self-signed certificate that your server issues. See “Creating self-signed certificates” on page 101. Before certificate expiration, you must re-register two-factor authentication and upload a new certificate. Otherwise, two-factor authentication is automatically disabled when the certificate expires. Setting up two-factor authentication can take several days. So as a best practice, you should enable the Certificate Expiration notification email setting to remind you in sufficient time to re-register. 74 Setting up Symantec Mobility: Suite trust and authentication certificates Managing the iOS app and MDM certificates used by Symantec Mobility: Suite See “Renewing two-factor authentication when a certificate expires” on page 143. The status of authentication certificates appear as follows: ■ Requested An on-premises certificate has been uploaded and two-factor authentication setup has been requested. ■ Approved The authentication certificate is valid and two-factor authentication setup is approved (but not enabled). ■ In-use The authentication certificate is valid and two-factor authentication is enabled. ■ Expired The authentication certificate that is used for two-factor authentication is expired. More information See “Using dynamic authentication certificates in Symantec Mobility: Suite” on page 83. See “Setting up Symantec Work Mail in Symantec Mobility: Suite” on page 237. See “Native Email policy settings” on page 440. See “Mobile Device Management (MDM) settings by Work Hub type” on page 454. See “Setting up two-factor authentication” on page 135. See “Configuring email notifications” on page 55. Managing the iOS app and MDM certificates used by Symantec Mobility: Suite To secure ("wrap") iOS apps and enable iOS mobile device management (MDM) in Symantec Mobility: Suite, you add iOS-specific certificate/key pairs to your Mobility Suite instance. You obtain these certificate files from the Apple iOS provisioning portal (in the case of push notifications and MDM functions) or a qualified certificate vendor (in the case of the Distribution certificate). You import the certificate files to your local Mac computer with the Apple 'Keychain Access' application (Applications > Utilities > Keychain Access). The certificate files must be in .P12 format, and you can use Keychain Access to convert other formats to .P12. You secure Exchange ActiveSync, VPN, and Wi-Fi for iOS devices with authentication certificates, which differ from app certificates. See “Managing authentication certificates in Symantec Mobility: Suite” on page 73. 75 Setting up Symantec Mobility: Suite trust and authentication certificates Managing the iOS app and MDM certificates used by Symantec Mobility: Suite Note: The workflows in the linked How to articles require access to the Apple Developer Portal and your instance of Symantec Mobility: Suite. Most of the workflows have you perform actions at both locations during the same work session. If you are not familiar with the Apple licensing and app development processes and protocols, we strongly recommend that you take some time to review the Apple web pages linked in the About iOS certificates and Apple licensing policy topic, below. Some of the following items are dependent upon others; the suggested order for creating and/or installing these items proceeds as follows: Distribution Certificate How to upload Also known as a code-signing certificate. The certificate is needed if you: ■ Distribute the native iOS Work Hub. ■ Wrap (secure) apps This certificate is provided to you by the person in your organization who manages your Apple Enterprise Account. Click the How to upload link for more information. This certificate establishes a chain of trust between the key owner (your company), the app code, and the end user (the device owner). App ID How to create Mobile Provisioning Profile How to create How to install MDM Certificate How to create and install Used for the Push Certificate (for APNS) and Mobile Provisioning Profile. Provides a unique ID for each app. A Provisioning Profile is required for any distributed native app or Secure Web App, including the Work Hub (mobile device agent). An App ID and a Distribution Certificate are required to create a Mobile Provisioning Profile. The How to links to the left provide more information. Required if you want to use the iOS mobile device management (MDM) features in Mobility Suite. The certificate is used to secure the relationship between the Mobility Suite server and the iOS device. About iOS certificates and Apple licensing policy Per Apple’s licensing policy, apps that are available from the Apple App Store may not be distributed through any other means, including Mobility Suite. Mobility Suite performs checks prior to uploading an app to make sure that the .ipa file is valid for redistribution. Make sure that you are compliant with the terms of the Apple License Agreement. Review the steps that must be completed and other information at: 76 Setting up Symantec Mobility: Suite trust and authentication certificates Managing the iOS app and MDM certificates used by Symantec Mobility: Suite https://developer.apple.com/library/ios/navigation/ To distribute apps within your organization, you must: ■ Sign up for the iOS Developer Enterprise Program. http://developer.apple.com/programs/ios/enterprise ■ Follow the process for distributing apps to your enterprise. http://developer.apple.com/library/ios/#featuredarticles/ FA_Wireless_Enterprise_App_Distribution/ Introduction/Introduction.html Creating an iOS App ID for use with Symantec Mobility: Suite Apple requires an App ID to provision the native iOS Work Hub. You also configure the App ID for the Apple Push Notification Service (APNS), which allows you to push notifications to iOS devices from Mobility Suite. To acquire an App ID, you or your team must have an Apple Enterprise Developer Account. See the Apple iOS Developer program information for details about Apple Developer accounts. This workflow generates the App ID, configures it for APNS, and produces the SSL certificate that is required by Mobility Suite. The workflow to generate an App ID and configure it for APNS, steps between the Apple Developer Portal and your local Mac computer. The workflow proceeds as follows: ■ Create the App ID for Mobility Suite ■ Configure the App ID for APNS ■ Generate a Certificate Signing Request (CSR) ■ Generate and download the production certificate Create the App ID 1 Go to http://developer.apple.com. 2 Select iOS Dev Center and log in. 3 Follow the instructions at the Apple Developer website to create the App ID for your instance of Mobility Suite. Configure the App ID for APNS On the Apple App ID page, locate your new App ID and elect to configure the App ID. Apply the following configuration choices: ■ Enable for Apple Push Notification Service ■ Elect to configure the Production Push SSL Certificate 77 Setting up Symantec Mobility: Suite trust and authentication certificates Managing the iOS app and MDM certificates used by Symantec Mobility: Suite When you are asked to provide the Certificate Signing Request (CSR), you use your Mac computer to generate the CSR. See the next procedure for instructions. Note: Leave the browser window open to the Apple Developer website as you'll need to come back to this window to finish the workflow. Generate the certificate signing request (CSR) 1 On a Mac computer, open Key Chain Access and on menu bar, select Key Chain Access > Certificate Assistance > Request a Certificate from a Certificate Authority. 2 In the request form, enter the following information: ■ Your email address ■ A name for your private key ■ Select the Saved to disk option Tip: No CA email address is required (even though the dialog says that it is) because you're saving the file locally. 3 Click Continue. 4 When prompted, save the CSR to a convenient location. Generate the certificate 1 At the Apple Developer website, complete the process to configure the Production Push SSL Certificate. 2 When asked, select the CSR you downloaded in Step 4 of the previous procedure and then generate the certificate. 3 Download the certificate to your local computer. Convert the .CER file to the required .P12 format 1 On a Mac, double-click the .CER file to open it in Key Chain Access. 2 Right-click the .CER file and select Export. 3 Select .P12 and a location for the file, then click Export. The certificate is ready for use. You use the certificate when you configure push notifications in Mobility Suite. You use the App ID when you create your Apple Provisioning Profile. See “Managing the iOS app and MDM certificates used by Symantec Mobility: Suite” on page 75. 78 Setting up Symantec Mobility: Suite trust and authentication certificates Managing the iOS app and MDM certificates used by Symantec Mobility: Suite Installing the iOS Provisioning Profile and iOS push certificate for Symantec Mobility: Suite Apple requires that iOS apps, including the iOS Work Hub, are associated with a distribution profile. Additionally, to push notifications to iOS devices, a push certificate is required. This workflow uploads the necessary certificates to distribute the native iOS Work Hub, and to push notifications to iOS devices. The workflow consists of three main steps: ■ Associate your iOS Provisioning Profile with the native iOS Work Hub. ■ Generate and upload the Work Hub for iOS. ■ Add the push certificate (also called the Production Push Certificate) to Mobility Suite. To complete these steps, you'll need to have your Distribution Provisioning Profile and your push SSL certificate. If you need to create these entities, see the following topics: ■ Creating an iOS App ID for use with Symantec Mobility: Suite ■ Creating the iOS Provisioning Profile for Symantec Mobility: Suite Add the push certificate to Mobility Suite 1 In Mobility Manager, click Settings > Certificates > Apple / iOS Certificates and scroll down to the Push Certificate section. 2 Click Choose file and select the production push certificate you downloaded in the workflow Creating an iOS App ID for use with Symantec Mobility: Suite. Associate your iOS Provisioning Profile with the native iOS Work Hub 1 Click Downloads and then click Download iOS Work Hub Builder. 2 Open Work Hub Builder. 3 Select Import Enterprise or Ad Hoc Distribution Profile and choose the mobile distribution provisioning profile you created for use with Mobility Suite. If you haven't created an Enterprise Provisioning Profile for Mobility Suite, see and complete the instructions in Creating the iOS Provisioning Profile for Symantec Mobility: Suite, and then return to and complete this step. 4 In Symantec Mobility Manager URL, type your Mobility Suite FQDN. 5 Click Generate and upload iOS Work Hub. 6 When prompted, enter your Mobility Suite administrator credentials. 79 Setting up Symantec Mobility: Suite trust and authentication certificates Managing the iOS app and MDM certificates used by Symantec Mobility: Suite Depending on your use of Mobility Suite, other certificates may be required by Apple or Mobility Suite. For more information, see Managing the iOS certificates used by Symantec Mobility: Suite. Creating and installing the mobile device management (MDM) certificate for iOS devices in Symantec Mobility: Suite To enable and use all of the iOS MDM features in Symantec Mobility: Suite, you must upload an MDM Certificate that establishes a trusted relationship between Mobility Suite and the managed iOS devices in your environment. Depending on your Mobility Suite instance, the MDM certification process is slightly different. SaaS Generate the MDM signing request in Mobility Suite and then submit the CSR to Apple directly. On-premises First submit your CSR to Symantec who in-turn returns a validated CSR to you, which you then submit to Apple. The work flows for both instances are: 1. Download the MDM CSR. 2. Create the MDM certificate. 3. Upload the MDM certificate. Download the MDM CSR 1 In the Mobility Manager, click Downloads, select iOS MDM CSR, and then click Download. 2 For on-premises instances only, email the CSR to [email protected]. Symantec will return your validated CSR. When you have the validated CSR, continue with this workflow. 3 Go to the Apple Push Certificates Portal at: https://identity.apple.com/pushcert and sign in with your Apple ID. 4 On the portal home page, click Create a Certificate. 5 When prompted, browse to and select the MDM CSR you generated in step 1 (or step 2 for on-premises instances), and then click Upload. 6 When the page refreshes, click Download to retrieve your MDM Certificate. 7 In Mobility Manager, go to Settings > Certificates > Apple iOS / Certificates > MDM Certificate and click Upload new. 8 Select the MDM Certificate you downloaded in step 6, and then click Save. 80 Setting up Symantec Mobility: Suite trust and authentication certificates Managing the iOS app and MDM certificates used by Symantec Mobility: Suite The MDM Certificate is now in place and you can enable MDM functionality in Mobility Suite. See “Setting default mobile device management (MDM) values for new device policies” on page 290. There are other certificates associated with iOS that you may need to provide to Mobility Suite or Apple. See “Managing the iOS app and MDM certificates used by Symantec Mobility: Suite” on page 75. Creating the iOS Distribution Provisioning Profile for Symantec Mobility: Suite Apple requires that iOS apps created for distribution are associated with a Distribution Provisioning Profile. The provisioning profile contains a name (for reference only), a code-signing certificate, and an App ID. You must have the last two items in-hand before you can create a Distribution Provisioning Profile. ■ See, Creating an iOS App ID for use with Symantec Mobility: Suite at: www.symantec.com/docs/HOWTO83976 ■ See Uploading the iOS Distribution Certificate to Symantec Mobility: Suite at: www.symantec.com/docs/HOWTO83967 The Provisioning Profile expires after one year, and must be renewed for your organization to continue to distribute iOS apps, including the native iOS Work Hub (the mobile agent). See the Apple Developer Portal for more information about Provisioning Profiles. Note: Except for the final step, this workflow takes place at the Apple Developer Portal. You'll need your account credentials to complete this workflow. The workflow to create the Distribution Provisioning Profile proceeds as follows: ■ Create a Distribution Provisioning Profile at the Apple Developer Portal ■ Associate your App ID and Distribution certificate with the new profile ■ Download the profile The following procedures detail each part of the workflow: 81 Setting up Symantec Mobility: Suite trust and authentication certificates Managing the iOS app and MDM certificates used by Symantec Mobility: Suite Create the iOS Distribution Provisioning Profile 1 Log into the Apple Developer Portal with your account credentials and on the left side of the portal home page, click Provisioning, and then click the Distribution tab. 2 Click New Profile. 3 Select the In House distribution method. Associate your App ID and Distribution certificate with the new profile 1 Locate and select your App ID. 2 Locate and select your Distribution Certificate 3 Click Submit. 4 Wait 30-60 seconds and refresh the page to see that the profile is active. Download the profile 1 Download the now active profile to your local computer. 2 You may proceed to upload the profile to Mobility Suite. See Uploading the iOS Distribution Certificate to Symantec Mobility: Suite at: www.symantec.com/docs/HOWTO83976 Other certificates may be required by Apple or Symantec Mobility: Suite. For more information, see the article, Managing the iOS certificates used by Symantec Mobility: Suite at www.symantec.com/docs/HOWTO83806 Uploading the Distribution (code-signing) certificate to Symantec Mobility: Suite The Distribution (a.k.a., code-signing) certificate is required if you want to use the native iOS Work Hub (mobile agent) or use Symantec Mobility: Suite to "wrap" (secure) your company's iOS applications. The certificate is used to associate an iOS app with the owner of the certificate key (your company), establishing a trust relationship between your company, the app code, and the end user. Apple requires that iOS apps are signed in this manner, and wrapping an app "resets" the requirement to sign the app code. An Apple Enterprise Developer account lets you use the single certificate with an unlimited number of apps. The certificate does have a limited validity time frame, however, and must be renewed prior to expiration to avoid interruption to your mobile device app management processes. The workflow to add the Distribution (code-signing) certificate proceeds as follows: 82 Setting up Symantec Mobility: Suite trust and authentication certificates Using dynamic authentication certificates in Symantec Mobility: Suite Step 1- The person or department that manages your Apple Enterprise Account provides you the Distribution certificate. In cases where you require assistance procuring the certificate, a link is provided in Mobility Manager under Settings > Certificates > Apple/iOS Certificates. Note: Mobility Suite requires that the code-signing certificate/key file is in .P12 format. Files in .CER format must be converted to .P12. On a Mac computer, double-click to open the .CER file and then right-click the file and choose to export the file as .P12. Step 2 - Once you have the certificate in-hand, upload it to Mobility Suite using the following procedure: Uploading the Distribution certificate 1 In Mobility Manager, click Settings > Certificates > Apple/iOS Certificates. 2 In the right pane, scroll down to Code signing certificates. 3 Next to Upload New, click Browse, and browse for and select the code-signing certificate file. Optionally, use the link provided in Mobility Manager to learn how to obtain the certificate. 4 In the upper right corner, click Upload. 5 Click Save. There are other certificates related to iOS that you may also need to provide to Mobility Suite or Apple. For more information, see the article, Managing the iOS certificates used by Symantec Mobility: Suite at http://www.symantec.com/docs/HOWTO83806. Using dynamic authentication certificates in Symantec Mobility: Suite Symantec Mobility: Suite integrates the services of a Certificate Authority (CA) to dynamically provision EAS, VPN, and WiFi authentication certificates for iOS devices. You specify these dynamic certificates in Mobility Suite device policies. 83 Setting up Symantec Mobility: Suite trust and authentication certificates Using dynamic authentication certificates in Symantec Mobility: Suite Note: Currently, Symantec Managed PKI and Microsoft Certificate Authority are supported in Mobility Suite. The following workflows assume that you already have an account at one of these authorities. For more information about Symantec Managed PKI, visit https://www.symantec.com/verisign/managed-pki-service. For information about Microsoft Certificate Authority, see the Microsoft article, Designing a Public Key Infrastructure at http://technet.microsoft.com/en-us/library/b1ee9920-d7ef-4ce5-b63c-3661c72e0f0b Basic workflow to specify dynamic authentication certificates 1 At the CA/MPKI provider, create certificate policies for each service you want to secure. Configure these policies with the settings and values to meet your iOS device management goals. Refer to your CA/MPKI provider for instructions to create the certificate profiles. 2 In Mobility Suite, specify the CA. The CA profile provides the authentication information required to communicate with the CA/MPKI provider. See “Specifying a Certificate Authority (CA) for dynamic certificates” on page 85. 3 In Mobility Suite, create one or more Certificate Templates. The Certificate Template provides the information required to generate specific kinds of certificates. See “Configuring a Certificate Template in Symantec Mobility: Suite” on page 87. 4 In Mobility Suite, create device policies that reference Certificate Templates (one cert template per policy). Device policies control the behavior and connectivity of enrolled mobile devices. See “Creating device policies” on page 304. 5 Assign and distribute the device policies to mobile devices enrolled with Mobility Suite. See “Assigning and unassigning device policies” on page 309. 84 Setting up Symantec Mobility: Suite trust and authentication certificates Specifying a Certificate Authority (CA) for dynamic certificates Specifying a Certificate Authority (CA) for dynamic certificates In Symantec Mobility: Suite, you create a Certificate Authority (CA) profile that provides the authentication information and credentials required for Mobility Suite to exchange data with your CA. Symantec Managed PKI and Microsoft Certificate Authority (MSCA) are supported. Instructions for both are provided below. For Symantec Managed PKI Use this procedure to specify Symantec Managed PKI (mPKI) as the CA for dynamic certificates. Before you begin This procedure requires that you have the Symantec mPKI Registration Authority (RA) certificate and optionally, a Root Certificate. Refer the Symantec mPKI documentation and user portal for instructions to request these certificates. Important note The RA certificate must be in either .PFX or .P12 format before it is imported to Mobility Suite. You can use the Apple Keychain Access utility in Mac OS-X to convert a. CER formatted RA certificate to .P12, or an open-source utility such as Open SSL to convert the certificate to .PFX format. Refer to the utility's documentation for instructions to perform the conversion. Create a CA profile for Symantec Managed PKI 1 Click Policy and rules > Device profiles. 2 On the Device profiles list go to Certificate Authority and click “+”. 3 Provide a useful name and description for this CA. Note: The CA Type defaults to Symantec mPKI and the Base URL is pre-populated. 4 Under Settings > New registration authority certificate, click Browse…, then locate and select the .PFX or .P12 formatted RA certificate for this CA. 85 Setting up Symantec Mobility: Suite trust and authentication certificates Specifying a Certificate Authority (CA) for dynamic certificates 5 Optionally, enter a pass-phrase for the RA cert. Warning: Because this certificate uses a private key, it is strongly recommended that you use a pass-phrase to protect access to this certificate. 6 Optionally, add a root certificate. Next to New root certificate, click Browse…, then locate and select the Root Certificate for this CA. 7 Save the profile. For Microsoft Certificate Authority Use this procedure to specify Microsoft Certificate Authority (MSCA) as the CA for dynamic certificates. Before you begin This procedure requires that you have Active Directory Certificate Services installed. Several resources for MSCA and related topics are available from Microsoft: Microsoft Active Directory Certificate Services web page at http://technet.microsoft.com/en-us/windowsserver/dd448615.aspx. ActiveDirectory Certificate Services Step-by-Step Guidehttp://technet.microsoft.com/en-us/library/cc772393%28v=ws.10%29.aspx Installing and configuring a CA http://technet.microsoft.com/en-us/library/cc756120%28v=ws.10%29.aspx Create a CA profile for MSCA 1 Click Policy and rules > Device profiles. 2 On the Device profiles list go to Certificate Authority and click “+”. 3 Click the Type drop-down menu and select Microsoft Certificate Authority 4 Under Settings, enter the Domain Name and Hostname. Note: These must match the values specified in the Active Directory Certificate installer. 5 To verify that Symantec Mobility can connect to the certificate service, click Test Connection. A green checkmark appears when the connection is verified. A red checkmark indicates a problem with the connection, or that the connection has timed-out. 86 Setting up Symantec Mobility: Suite trust and authentication certificates Configuring a Certificate Template in Symantec Mobility: Suite 6 Optionally, provide a Root Certificate. Click Choose File and select the Root Certificate for the CA. Note: The Root Certificate must be .CER, .CRT, .DER, or .PEM format. 7 Save the profile. See “Using dynamic authentication certificates in Symantec Mobility: Suite” on page 83. Configuring a Certificate Template in Symantec Mobility: Suite Note: The procedures in this topic are part of the workflow for using dynamic authentication certificates in Mobility Suite. See “Using dynamic authentication certificates in Symantec Mobility: Suite” on page 83. To have your CA dynamically provision certificates to Symantec Mobility: Suite, you configure Certificate Templates. The templates provide re-usable configurations that do the following: ■ Specifies the CA to provision the certificate. ■ Provides for the selection of certificate profiles from your CA account portal. ■ Populates the attributes and variables tables for the certificate template, based on the selected CA Certificate Policy. You create a Certificate Template for each service that uses a dynamically generated certificate; EAS, VPN, and WiFi. Prerequisites Certificate templates require the following: ■ At least one Certificate authority profile. See “Specifying a Certificate Authority (CA) for dynamic certificates” on page 85. ■ Certificate profiles set up at your CA/Managed PKI provider for the services you are securing (EAS, VPN, or WiFi). See your provider's documentation for details. 87 Setting up Symantec Mobility: Suite trust and authentication certificates Configuring a Certificate Template in Symantec Mobility: Suite Create a Certificate Template for Symantec mPKI Use the following procedure and table to create a certificate template for Symantec mPKI 1 Go to Policies and rules > Device profiles and in the Device profiles list, click the “+” next to Certificate Template. 2 Enter a name and description for this authority setting template. 3 Under Settings, use the drop-down menu to select a Certificate Authority. The settings that follow change depending on which CA you use. See “Specifying a Certificate Authority (CA) for dynamic certificates” on page 85. 4 Under Policy, enter the OID of the Certificate Profile you created at the CA/Managed PKI provider for this service, and then click Get Details. The attributes and variables tables are populated with data provided by the Managed PKI service. For instance, if you're creating a template for securing VPN, you enter the OID of the certificate profile you created at the CA/MPKI for securing VPN. 5 Under Policy Details > Certificate Template Variables, provide the required values. You can also insert tokens in place of actual values. See Table 4-1 on page 88. Note: You determine which values are required when you configure the certificate policies at your CA/MPKI provider. 6 Save the template. Table 4-1 Acceptable certificate template tokens Token ("Value") Type {user.email} User {user.username} User {user.first_name} User {user.id} User {user.last_name} User {device.unique_identifier} Device {device.name} Device 88 Setting up Symantec Mobility: Suite trust and authentication certificates Configuring a Certificate Template in Symantec Mobility: Suite Table 4-1 Acceptable certificate template tokens (continued) Token ("Value") Type {device.product_string} Device {device.serial_number} Device {device.platform} Device {device.device_class} Device {device.IMEI} Device {device.udid} Device Note: Symantec Managed PKI inserts two variables: seat_id and mail_email. These are used by MPKI to define the MPKI end-user, and so must be unique for each Mobility Suite user. The value of these two variables does not appear in any certificate generated by the template. Create a Certificate Template for Microsoft Certificate Authority (MSCA) Use the following procedure to create a certificate template for MSCA: 1 Go to Policies and rules > Device profiles and in the Device profiles list, click the “+” next to Certificate Template. 2 Enter a name (required) and description (optional) for this authority profile. 3 Under Settings, from the Certificate authority drop-down menu, select Microsoft Certificate Authority. See “Specifying a Certificate Authority (CA) for dynamic certificates” on page 85. 4 Under Settings, provide the Domain name (required) and Hostname (optional). Note: Domain name and hostname must match the values specified in the Active Directory Certificate Services installer. See “Installing the Symantec ADCS Communication Service to provision MSCA certificates within Symantec Mobility ” on page 99. 89 Setting up Symantec Mobility: Suite trust and authentication certificates Specifying SCEP and dynamic certificates in iOS device policies 5 Optionally, browse to and select an appropriate root certificate (.cer, .crt, .der, or .pem format). When you provide a root certificate, the certificate Subject Name, Issuer, and validity date are displayed. 6 Save the template. See “Using dynamic authentication certificates in Symantec Mobility: Suite” on page 83. LDAP tokens Any value that can be queried in LDAP can be tokenized. Use the format{ldap.attributename}, where attributename is the name of the queried attribute. See “Adding LDAP certificates” on page 101. Specifying SCEP and dynamic certificates in iOS device policies If you have a Symantec Managed PKI or Microsoft Certificate Authority account, you can elect to use dynamic certificates in iOS device policies for Native Email (Exchange ActiveSync), VPN, and Wi-Fi. Using SCEP Starting with the 5.2 release of Mobility Suite, if you have SCEP and MSCA configured, you can specify that certificates are provisioned via SCEP. To use SCEP, in the procedures below, instead of specifying Dynamically Generated Certificate, select SCEP and then select the SCEP profile you want to use from the SCEP profile drop-down menu. See “Using SCEP with Mobility Suite” on page 93. Note: This procedure is part of the workflow for using dynamic certificates in Mobility Suite, and requires that you first configure certificate policies at your CA/MPKI provider. See “Using dynamic authentication certificates in Symantec Mobility: Suite” on page 83. Certificate-type options In Mobility Suite iOS device policies, for EAS, VPN, and Wi-Fi security, there are four certificate type options: ■ None- no certificate is used. 90 Setting up Symantec Mobility: Suite trust and authentication certificates Specifying SCEP and dynamic certificates in iOS device policies ■ Static Certificate- uses a certificate you obtain independently from a CA or a self-signed certificate issued from your server. Note: The same static certificate is sent to all devices receiving the device policy. ■ Dynamically Generated Certificate- uses certificates generated as-needed from a CA/Managed PKI provider. Dynamically generated certificates are sent to the device from Mobility Suite, along with the Device Policy. ■ SCEP- uses SCEP to provision certificates from MSCA. See “Using SCEP with Mobility Suite” on page 93. See “Creating device policies” on page 304. Note: For security reasons, Mobility Suite does not retain the certificate keys for Dynamically Generated Certificates. The certificate is created each time that the policy is sent to a device. Specifying a dynamic certificate for VPN When you create a device policy for VPN, you select from one of three connection types: ■ IPSec (Cisco) ■ Cisco AnyConnect ■ Juniper SSL When IPSec (Cisco) is selected, Machine Authentication includes the option to use a Dynamically Generated Certificate. Similarly, when Cisco AnyConnect or Juniper SSL are selected, User Authentication includes the option to use a Dynamically Generated Certificate. Specifying a dynamic certificate for VPN 1 In the left pane, select Policies and rules > Device policy and click New Policy. You can also edit an existing policy; select the policy and then click the Edit icon. 2 Under Device Settings > VPN Configurations, click New. 3 Provide a name and optionally, a description for this policy. On the Connection Type drop-down menu, select the connection type. 4 On the Machine Authentication drop-down menu, select Dynamically Generated Certificate. 91 Setting up Symantec Mobility: Suite trust and authentication certificates Specifying SCEP and dynamic certificates in iOS device policies 5 In the Dynamic Certificate Template drop-down menu, select the certificate template you want to use for this VPN policy. 6 Click Save. Specifying a dynamic certificate for iOS Native Email (Exchange ActiveSync) When you create an iOS Device Policy to manage native email connections to EAS, you can specify a dynamic certificate for authentication. Specifying a dynamic certificate for EAS 1 In the left pane, select Policies and rules > Device policy and click New Policy. You can also edit an existing policy; select the policy and then click the Edit icon. 2 Under Email Settings > Native Email Configurations, click New. 3 Provide a name and optionally, a description for this policy. 4 Under iOS Specific Settings, on the Certificate Type dropdown menu, select Dynamically Generated Certificate. 5 In the Dynamic Certificate Template dropdown menu, select the certificate template you want to use for this email policy. 6 Click Save. Specifying a dynamic certificate for Wi-Fi When you create an iOS Device Policy to manage Wi-Fi connections, you can specify a dynamic certificate for authentication. In the policy, when you select any Enterprise-level Security Type, the Certificate Type drop-down menu provides the option to use a Dynamically Generated Certificate. Security types supporting dynamically generated certificates ■ WEP Enterprise (iOS Only) ■ WPA/WPA2 Enterprise (iOS Only) ■ Any Enterprise (iOS Only) In all cases, when the Dynamically Generated Certificate option is selected, the option to select a Certificate Template is provided to you as a drop-down menu. Specifying a dynamic certificate for Wi-Fi 1 In the left pane, select Policies and rules > Device policy and click New Policy. You can also edit an existing policy; select the policy and then click the Edit icon. 2 Under Device Settings > Wi-Fi Configurations, click New. 92 Setting up Symantec Mobility: Suite trust and authentication certificates Specifying SCEP and dynamic certificates in iOS device policies 3 Provide a name and optionally, a description for this policy. 4 Under Security Settings, on the Security Type dropdown menu, select one of the three types supporting dynamic certificates (see the list at the beginning of this topic). 5 Under Authentication > Password, from the drop-down menu, select Dynamically Generated Certificate. 6 On the Dynamic Certificate Template drop-down menu, select the certificate template you want to use for this wi-fi policy. 7 Click Save. See “Configuring a Certificate Template in Symantec Mobility: Suite” on page 87. Using SCEP with Mobility Suite Mobility Suite supports the Simple Certificate Enrollment Protocol (SCEP). SCEP defines the communication between devices and Registration Authority, in this case, Microsoft Certificate Authority (MSCA). When SCEP is used, the mobile device can request certificates directly from MSCA. After you create a SCEP profile, you can specify SCEP-delivered certificates to secure EAS, VPN, and WiFi connections. Note: Currently, only iOS devices are supported for SCEP in Mobility Suite Prerequisites Note: This topic assumes you are familiar with MSCA and ActiveDirectory Certificate Services (ADCS). Before you begin, make sure the following are available: ■ Your SCEP server (the server URL is required to create the SCEP Profile) ■ The NDES role is set up in ADCS See “Installing the Symantec ADCS Communication Service to provision MSCA certificates within Symantec Mobility ” on page 99. See also: http://social.technet.microsoft.com/wiki/contents/ articles/9063.network-device-enrollment-service-ndes-in-active -directory-certificate-services-ad-cs.aspx ■ SCEP, NDES, and ADCS settings and permissions are in place. See “Required SCEP, NDES, and ADCS settings and permissions” on page 96. ■ Certificate profiles set up in MSCA to support your security requirements . 93 Setting up Symantec Mobility: Suite trust and authentication certificates Specifying SCEP and dynamic certificates in iOS device policies Workflow Use the following workflow to enable SCEP for delivering certificates. Table 4-2 SCEP implementation workflow Step Description 1 Create SCEP profile 2 Create a device policy that specifies SCEP Create a SCEP profile To use SCEP inMobility Suite, you create a SCEP profile. Create SCEP profile 1 Go to Policies and rules > Device profiles. 2 Next to SCEP, click "+" 3 Enter a name and optionally, a description. 4 Under Settings, provide the following information: ■ The URL to your SCEP server (required) ■ Challenge password- select one of the following: Warning: For security reasons, it is strongly recommended that you generate unique challenges on a per-request basis whenever possible. ■ None- no action required Note: This option requires that the EnforcePassword registry key value on the SCEP server is set as 0. ■ Generate per request- challenge password is generated automatically ■ Master challenge password- Admin must enter the password Note: Only one Master challenge can be used per profile. It is recommended that you use the Generate per request option to dynamically generate the challenge for each profile. ■ Optionally, adjust the Retry count and Retry period for the password. 94 Setting up Symantec Mobility: Suite trust and authentication certificates Specifying SCEP and dynamic certificates in iOS device policies ■ Optionally, enter the fingerprint of the CA root certificate. ■ Certificate template- use one of the following methods: ■ None- manually enter the certificate Subject (required), SAN type, Subject alternative name, Key usage, and Key strength. Note: Key usage and key strength must be same as that of the certificate template used for SCEP. ■ Certificate template- assumes you've created at least one certificate template for MSCA. Upon selecting the certificate template specifying MSCA, the other information is automatically populated Note: Key usage and key strength are not dependent on Certificate template selection. See “Configuring a Certificate Template in Symantec Mobility: Suite” on page 87. 5 Click Save. Specify SCEP in a device policy When you create a device policy for iOS VPN, Wi-Fi, or EAS, you have the option to select a SCEP profile to manage the certificate delivery. Create a device policy that specifies SCEP 1 In the left pane, click Policies and rules > Device policies and at the top of the right pane, click New Device Policy. 2 Enter a name and description for the policy. 3 To specify SCEP for WiFi, EAS, or VPN, do the following: ■ For WiFi ■ Under Device Settings, next to the WiFi configuration, click New ■ From the OS drop-down menu, select iOS/Windows ■ Under Security Settings, choose the Security type Note: The security type must be WEP enterprise, WPA/WPA2 enterprise, or Any enterprise 95 Setting up Symantec Mobility: Suite trust and authentication certificates Specifying SCEP and dynamic certificates in iOS device policies ■ ■ 4 ■ In the Authentication section, from the Password > certificate for authentication drop-down menu, select SCEP. ■ From the SCEP profile drop-down menu, select the SCEP profile you want to use. ■ Click Save. For VPN ■ Under Device Settings, next to the VPN configuration, click New ■ Under Machine authentication, choose the SCEP ■ From the SCEP profile drop-down menu, select the SCEP profile you want to use. ■ Click Save. For EAS ■ Under Email settings, next to Native email configurations, click New. ■ Under iOS settings, from the Certificate type drop-down menu, select SCEP Profile. Click Save. Note: You can configure other settings at this time or at a later time. See “Creating device policies” on page 304. Additional information See “Specifying SCEP and dynamic certificates in iOS device policies” on page 90. Required SCEP, NDES, and ADCS settings and permissions Before you can use SCEP to provision certificates in Mobility Suite, you must configure the following: ■ The domain user running the Symantec ADCS Comms. Service must have permission to call the/certsrv/mscep_adminpage on the NDES machine. ■ The domain user running the Symantec ADCS Comms. Service must have Read and Enroll permissions on the templates used by NDES. The template names are in the Registry on the NDES machine underHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP and are called EncryptionTemplate, GeneralPurposeTemplate, and 96 Setting up Symantec Mobility: Suite trust and authentication certificates Specifying SCEP and dynamic certificates in iOS device policies SignatureTemplate. After you verify the names, you must set the permissions for the template(s) on the CA machine. Note: The installer for the Symantec ADCS Communication Service has been updated with a new NDES Challenge URL field. This field is optional (in case NDES is not used), but is needed if you want to obtain SCEP challenges. See “Installing the Symantec ADCS Communication Service to provision MSCA certificates within Symantec Mobility ” on page 99. SCEP Challenge Queues By default, challenges are eight bytes long, expire after 60 minutes, and only five unexpired challenges may be outstanding at one time. Challenges will also expire if you reboot IIS on the NDES machine, reboot the NDES machine, or if they are used (successfully or unsuccessfully) to obtain a certificate. These settings can be changed in the Registry on the NDES machine. The registry key is HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\MSCEP. Each of the following keys and value names do not exist by default, so an administrator must create them in order to change the defaults. They are: ■ PasswordMax – maximum number of outstanding challenges ■ PasswordValidity – number of minutes the challenge is valid ■ PasswordLength – length of the challenge ■ UseSinglePassword – when set to false (0), prevents the use of a one-time certificate enrollment password. Warning: For security reasons, setting to True (1) is not recommended. ■ EnforcePassword – when set to True (1), enforces the use of a certificate enrollment password. Warning: For security reasons, setting to False (0) is not recommended. These settings should be set according to number of devices in your environment, and how Mobility Manager sends the SCEP payloads to devices. For example, if you have 100 devices and Mobility Manager sends all the devices a SCEP payload at once, the value ofPasswordMax should be at least 100. If the devices could take up to 4 hours to check in, the value ofPasswordValidityshould be at least 240. 97 Setting up Symantec Mobility: Suite trust and authentication certificates Allowed characters and values in Symantec Mobility: Suite dynamic certificates See “Using SCEP with Mobility Suite” on page 93. Allowed characters and values in Symantec Mobility: Suite dynamic certificates When you specify values for dynamically generated certificates, certain character and value restrictions apply: ■ GUID- must be hex value. No other format or characters are allowed. ■ Registered ID- must be dotted OID, e.g. 1.2.3.4.5. No alpha characters are allowed. ■ DNS- must be a host name or IP address. ■ Email- the length is 255 characters max. The allowed characters are those that are standard for email addresses and use standard email address formatting (e.g., [email protected].) Also, mail_email must be standard email address format. ■ Country- must be valid country code: country-name-alpha, max 2 characters; country-name-numeric, max three characters. ■ Serial number- limited to 64 characters. Can be HEX or number/integer. ■ otherNameHostGUID-must be HEX value (it must be a real GUID). No other format or characters are allowed. ■ Common Name- This is a default variable for Symantec Managed PKI certificates. However, it is converted to two variables by the web service that transports the certificate data: mail_firstName and mail_lastName. To use a single Common Name variable, in the MPKI certificate policy, delete the default Common Name variable and then re-add it. ■ UTF-8 characters are allowed. Note: If the CA/MPKI service cannot correctly validate the values for a certificate, it will return an error. In such cases, the device policy citing this certificate will also error-out and the policy is not sent to the device. See “Using dynamic authentication certificates in Symantec Mobility: Suite” on page 83. 98 Setting up Symantec Mobility: Suite trust and authentication certificates Installing the Symantec ADCS Communication Service to provision MSCA certificates within Symantec Mobility Installing the Symantec ADCS Communication Service to provision MSCA certificates within Symantec Mobility To use Microsoft Certificate Authority (MSCA) with Symantec Mobility, you must install the Symantec ADCS Communication Service on a server that belongs to the same domain as your MSCA server. Before installing, make sure your installation meets the follow requirements: Table 4-3 Symantec ADCS Communication Services Server Requirements Component Requirement Machine OS Windows 2008 Server or later. Note: The machine must be in the same domain as the MSCA server, but does not need to reside on the MSCA server. Machine membership Must be a member of the same domain that the MSCA server is joined to. Framework .NET Framework 4 Rights and permissions A domain user must be running the Service 1 This user must have Read and Enroll permissions for the MSCA certificate templates you want to use. 2 This user's permissions should be restricted to only those required. For instance, the user is not a domain admin, or have access to other templates. Additional settings are required: See “Required SCEP, NDES, and ADCS settings and permissions” on page 96. 99 Setting up Symantec Mobility: Suite trust and authentication certificates Installing the Symantec ADCS Communication Service to provision MSCA certificates within Symantec Mobility Table 4-3 Symantec ADCS Communication Services Server Requirements (continued) Component Requirement Message broker RabbitMQ 1 Must be accessible by the ADCS Service. 2 Traffic passes on port 5672 (can be re-configured if needed) 3 Recommended: Do not use the RabbitMQ user credentials (guest/guest). 4 Communications are only encrypted if you use SSL/TLS with RabbitMQ. Symantec ADCS Communication Services installation The Symantec ADCS Communication Services installer prompts you for a folder location, a service user, the RabbitMQ server, and the MSCA server. The MSCA setup includes the Domain Name and the CA hostname. These values must match the same MSCA values in Mobility Manager. The hostname is optional. Note: The installer for the Symantec ADCS Communication Service has been updated with a new NDES Challenge URL field. This field is optional (in case NDES is not used), but is needed if you want to obtain SCEP challenges. See “Required SCEP, NDES, and ADCS settings and permissions” on page 96. Downloading and installing ADCS 1 On the Symantec Mobility Admin Console, in the left pane, select Downloads. 2 Scroll down and select ADCS. 3 Save the file and move it to the server you've designated to run the Symantec ADCS Communications Service. 4 Follow the installer prompts to complete the installation. Related topics See “Using dynamic authentication certificates in Symantec Mobility: Suite” on page 83. See “Specifying SCEP and dynamic certificates in iOS device policies” on page 90. See “Using SCEP with Mobility Suite” on page 93. 100 Setting up Symantec Mobility: Suite trust and authentication certificates Adding LDAP certificates Adding LDAP certificates Symantec Mobility: Suite lets you add signed certificate authority LDAP SSL certificates to the Mobility Suite trust store so that you can securely connect to your LDAP server. You must include all certificates in a chain up to the root level. The Settings > Certificates > LDAP Certificates page shows the certificates that are uploaded to Mobility Suite. This page provides details about the issuer and expiration date. Expired certificates are highlighted, and a red indicator appears in the header of the LDAP Certificates page. The indicator also appears on the center and left pane of the Mobility Manager to alert you that a certificate is expired. Uploading LDAP SSL certificates is optional. If you already have LDAP set up as your external identity provider (IDP) without any certificates and are migrating to a newer version, LDAP continues to work the same as it did before the migration See “Configuring Active Directory/LDAP as an external identity provider (IDP)” on page 115. Add LDAP certificates 1 Click Settings > Certificates > LDAP Certificates. 2 Click Browse and locate the certificate that you want to add. Certificates can be in any of the following supported formats: ■ PKCS7 DER (.p7b) You can load multiple certificates in this format at the same time. ■ X.509 DER ■ X.509 PEM You can load multiple certificates in this format at the same time. Remove LDAP certificates 1 To delete a certificate, scroll down the page and locate the certificate that you want to remove. 2 Click the "x" icon to the right of the certificate. 3 Click Yes, Delete Certificate to confirm that you want to delete the certificate. Creating self-signed certificates There are instances in Symantec Mobility: Suite in which you can use self-signed certificates, such as two-factor authentication. Generate self-signed certificates from the command terminal on a computer that has Openssl installed. Self-signed certificates are generated in .p12 file format. 101 Setting up Symantec Mobility: Suite trust and authentication certificates Creating self-signed certificates Generate CSR and private key ◆ Type the following command: openssl req -newkey rsa:2048 -nodes -keyout domain.key -out domain.csr Generate self-signed certificate ◆ Type one of the following commands: For a new certificate openssl req -newkey rsa:2048 -nodes -keyout domain.key -x509 -days 365 -out domain.crt For an existing key openssl req -key domain.key -new -x509 -days 365 -out domain.crt For an existing CSR and a key openssl x509 -signkey domain.key -in domain.csr -req -days 365 -out domain.crt Generate a .p12 file from crt and key file ◆ Type the following command: openssl pkcs12 -inkey domain.key -in domain.crt -export -out domain.p12 More information See “Setting up two-factor authentication” on page 135. See “Renewing two-factor authentication when a certificate expires” on page 143. 102 Chapter 5 Setting up user authentication and adding users to Symantec Mobility: Suite This chapter includes the following topics: ■ Setting up user authentication and adding users to Symantec Mobility: Suite ■ Setting up the Mobility Suite local identity provider ■ Setting up Active Directory/LDAP authentication ■ Setting up SAML authentication ■ Configuring Symantec Identity: Access Manager as your SAML identity provider ■ Adding users with the external identity provider (IDP) ■ Permitting enterprise single sign-on (SSO) for iOS devices ■ Enabling Cisco ISE integration ■ Setting up two-factor authentication ■ Establishing an iOS Work Hub PIN policy ■ Establishing an Android offline PIN policy Setting up user authentication and adding users to Symantec Mobility: Suite Setting up user authentication and adding users to Symantec Mobility: Suite Setting up user authentication and adding users to Symantec Mobility: Suite Symantec Mobility: Suite lets you use an identity provider (IDP) to add and authenticate users to Mobility Suite. Mobility Suite can handle group management through the local IDP or you can manage groups through the external IDP. All IDPs (local and external) provide access to the Mobility Manager, the End-User Portal, the Work Hub, and any wrapped apps that require authentication. IDPs not only provide authentication, they also provide for application single sign-on. Mobility Suite supports for the following IDPs: Local By default, Symantec Mobility: Suite provides a simple, local IDP that you can use for authentication. The local IDP is easy to use, requires no integration, and is ideal for small user environments or trials. See “Setting up the Mobility Suite local identity provider” on page 104. Active Directory Mobility Suite supports using Active Directory (AD) to authenticate users. See “Setting up Active Directory/LDAP authentication” on page 114. LDAP Mobility Suite supports AD as an IDP through LDAP and also can support any other type of IDP that exposes an LDAP interface. See “Setting up Active Directory/LDAP authentication” on page 114. SAML Mobility Suite supports using SAML to authenticate users. See “Setting up SAML authentication” on page 120. A user's email address should only appear in one IDP at a time. For example, if you have the same user's email address in the local IDP and Active Directory, the user may have problems authenticating. For more information, refer to the following knowledge base article: http://www.symantec.com/docs/TECH205087 Setting up the Mobility Suite local identity provider Symantec Mobility: Suite provides a simple, local identity provider (IDP) that can authenticate your users. Table 5-1 describes the workflow steps and provides links to instructions. 104 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up the Mobility Suite local identity provider Table 5-1 Mobility Suite local IDP implementation workflow Phase Task Description 1 The local IDP is ideal for smaller environments or trial users because it is easy to use and requires no integration. The local IDP provides authentication for access to the Mobility Manager, the End-User Portal, the Work Hub, and any wrapped apps that require authentication. The local IDP not only provides authentication, it also provides for application single sign-on. Configure the local IDP. See “Configuring the local identity provider (IDP)” on page 105. 2 Add users. Mobility Suite offers several methods that you can use to add users: ■ Email invitation ■ Manually adding a user in the Mobility Manager Adding multiple users at once using a comma-separated values (CSV) file ■ Note: A user's email address should only appear in one IDP at a time. For example, if you have the same user's email address in the local IDP and Active Directory, the user may have problems authenticating. For more information, refer to the following knowledge base article: http://www.symantec.com/docs/TECH205087 See “Adding users with the local identity provider (IDP)” on page 110. More information See “Setting up user authentication and adding users to Symantec Mobility: Suite” on page 104. Configuring the local identity provider (IDP) By default, Symantec Mobility: Suite provides a simple, local identity provider (IDP) for user authentication. The local IDP is ideal for smaller environments or trial users because it is easy to use and requires no integration. The local IDP provides authentication for access to the Mobility Manager, the User portal, the Work Hub, and any wrapped apps that require authentication. The local IDP not only provides 105 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up the Mobility Suite local identity provider authentication, it also provides for application single sign-on. Mobility Suite can also handle group management through the local IDP. See “Creating app policies that permit single sign-on (SSO)” on page 360. See “Creating groups” on page 61. The password policies that you configure in Mobility Suite only apply when you use the local IDP. If you have enabled an external IDP for authentication, the external IDP enforces its password policies. The ability to change or reset password is only available for the local IDP. You should set up your roles and groups in Mobility Suite before you configure your IDP so that when you configure the IDP, you can map users to the Mobility Suite groups that you created. Thereafter, you can create, delete, or modify roles and groups as needed. Table 5-2 describes the workflow for configuring the local IDP. Configuring the local IDP workflow Table 5-2 Phase Description 1 Configure the user authentication settings. See “To configure the user authentication settings for the local IDP” on page 107. 2 Specify password lockout criteria. See “To specify password lockout criteria for the local IDP” on page 108. 3 Set the administrator password policy. If you enable either MDM or an app policy for the administrator, all of the options on the Admin Password Policy page are checked. The minimum password length is set to 8 characters. All of the controls on this page become disabled in the following instances: ■ If you use app policies ■ If you enable Mobile Device Management (MDM) In both instances, Mobility Suite sets the policy and cannot be modified by an administrator. See “To set the admin password policy for the local IDP” on page 108. 4 Set the user password policy. See “To set the user password policy for the local IDP” on page 109. 106 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up the Mobility Suite local identity provider Table 5-2 Configuring the local IDP workflow (continued) Phase Description 5 Specify a Work Hub PIN policy. The iOS Work Hub PIN policy applies to the Work Hub, the WorkSpace, sealed, and wrapped apps for online and offline use. See “Establishing an iOS Work Hub PIN policy” on page 145. The offline Android PIN policy is enforced when the user selects an offline PIN in the Work Hub. The PIN is used for the Work Hub and applications that have offline authentication permitted in their app policy. See “Establishing an Android offline PIN policy” on page 147. Mobility Suite only supports Latin letters, digits, and punctuation characters for the offline PIN. To configure the user authentication settings for the local IDP 1 Click Settings > Authentication and roles > User Authentication. 2 Check Use email address as user name to let users login with their email addresses. This eliminates the need for users to remember their user names. If you already have an external IDP enabled, this option does not appear. 3 Check Mobile sign in screens remember user names to let users mobile devices remember their user names. This setting only remembers the user's login name — not the user's password. 4 Check Allow client download without authentication to let anonymous users download the Work Hub without authentication. Some organizations are comfortable with anonymous users downloading their Work Hub since the clients themselves perform user authentication. Enabling this feature lets any user visit the Mobility Suite URL and download the Work Hub client without the user being authenticated. If Allow client download without authentication is enabled for an on-premises installation, you can only download the native iOS Work Hub. This issue does not occur with an SaaS installation. 5 Specify the Password reset requests expire after <n> days. 107 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up the Mobility Suite local identity provider 6 Check Use ReCAPTCHA for increased security in password resets if you want users to input a security word or phrase to verify the user is a human and not a bot. 7 Click Save. To specify password lockout criteria for the local IDP 1 Click Settings > Authentication and roles > Password lockout. 2 To lockout a user, check Lockout user after <n> failed login attempts in <n> minutes, and specify the number of failed attempts and the number of minutes. 3 In the Lockout user for <n> minutes field, specify how long to lock out the user after the failed login attempts that you configured in step 2. 4 Click Save. To set the admin password policy for the local IDP 1 Click Settings > Authentication and roles > Admin authentication. 2 Specify the Minimum password length. 3 Check Max pass lifetime enabled to enable the password lifetime feature. 4 Specify the Max pass lifetime. 5 Check Pass history depth enabled to restrict how frequently a user can reuse a password. 6 Specify the Password history depth. 7 Specify the password criteria by checking the following options that you want to enforce when administrators create their passwords: ■ Prohibit user name and email Prohibits the user from using their email address or user name in the password. ■ Require uppercase At least one uppercase character is required. ■ Require lowercase At least one lowercase character is required. ■ Require number At least one number is required. ■ Require non-alpha At least one non-alphanumeric character is required (e.g., $#@). ■ First three unique 108 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up the Mobility Suite local identity provider Requires that the first three characters of the password are unique (e.g., the same character isn't duplicated in the first three characters). 8 Click Save. To set the user password policy for the local IDP 1 Click Settings > Authentication and roles > User password policy. 2 Specify the Minimum password length. 3 Check Max pass lifetime enabled to enable the password lifetime feature. 4 Specify the Max pass lifetime to specify the number of days after which a password expires. 5 Check Pass history depth enabled to restrict how frequently a user can reuse a password. 6 Specify the Password history depth. 7 Specify the password criteria by checking the following options that you want to enforce when users create their passwords: 8 ■ Prohibit user name and email Prohibits the user from using their email address or user name in the password. ■ Require uppercase At least one uppercase character is required. ■ Require lowercase At least one lowercase character is required. ■ Require numbers At least one number is required. ■ Require non-alpha At least one non-alphanumeric character is required (e.g., $#@). ■ First three unique Requires that the first three characters of the password are unique (e.g., the same character isn't duplicated in the first three characters). Click Save. Now you are ready to enroll your users in Mobility Suite. See “Adding users with the local identity provider (IDP)” on page 110. 109 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up the Mobility Suite local identity provider Adding users with the local identity provider (IDP) If you use the local identity provider (IDP), you can add users in Symantec Mobility: Suite using any one of the following methods: Adding users using email invitations Use this method when you want to add one or more users and let them create their own user names and passwords to access Mobility Suite. The simplest way to add new users in Mobility Suite is to send them an email invitation that contains instructions on how to create their accounts and a link to Mobility Suite. You can customize this email invitation. If a user has already enrolled with Mobility Suite and you send another email invitation, the default invitation message appears in the invitation. When users tap the link in your message, they are prompted to create an account and set up their own user name and password. When users create their accounts, they are then prompted to install the Work Hub on their devices. Users are allowed to specify their own user names and passwords. However, they are not prompted to provide their first and last names. An administrator must edit the users' account information after they are added. Additionally, invited users cannot be assigned to groups until they have created their accounts. An administrator can verify the status of an email invitation. Warning: The user's email address must already exist when you send the invitation; otherwise, the address is added to a bounce list. If you subsequently attempt to resend the invitation after the email address is created, the email cannot be delivered because it on the bounce list. See “To add users using email invitations” on page 112. See “To verify the status of an email invitation” on page 112. 110 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up the Mobility Suite local identity provider Adding a single user Use this method when you want to add a single user, but you want to specify the user's user name and password. As an administrator, you can add a user in Mobility Suite by manually creating an account that includes the user's email address, user name, and password. You can assign the user to a group at the time that you create the account. When you manually create a new user account, Mobility Suite does not automatically notify the user of the new account. So you must communicate the user's credentials to them so that they can log into Mobility Suite and complete the enrollment and download the Work Hub. Sending user name and password credentials by email is not recommended. See “To add a single user” on page 113. Adding multiple users Use this method when you want to add many users at once. You can add a maximum of 5,000 users at one time using a comma-separated values (CSV) file. The .csv file must contain a header row, and the first four column headings must be: Username, First Name, Last Name, Email. An optional fifth column is: Group. When you upload the .csv file, Mobility Suite adds any user that does not already exist in the all users group and any other group that you specify. If you do not use the Group column, all users are added to the all users group. Rows that do not match the specified format are ignored. For files with international characters, the file must be encoded in UTF-8 character encoding. Communication to users about their user names and the requirement to reset passwords should be handled in a separate email instruction. Users can optionally be sent a Reset Password email since their newly created accounts do not have passwords. This email is turned off by default because it can cause confusion absent any other communication about user names or Mobility Suite in general. See “To add multiple users” on page 113. See “Configuring the local identity provider (IDP)” on page 105. If you haven't done so already, you should set up your roles and groups in Mobility Suite before you add your users so that you can map users to the appropriate groups. You must have also configured the Work Hubs that your users will download and install on their mobile devices. See “Creating groups” on page 61. 111 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up the Mobility Suite local identity provider Note: A user's email address should only appear in one IDP at a time. For example, if you have the same user's email address in the local IDP and Active Directory, the user may have problems authenticating. For more information, refer to the following knowledge base article: http://www.symantec.com/docs/TECH205087 To add users using email invitations 1 In Mobility Manager on the left pane, click Users. 2 On the right pane under Invite via Email, type the email addresses of the users that you want to add separated by a comma. 3 Optionally, under Customize the invite message below, you can modify the text that you want to appear in the email invitation. Click Save message as template to save your changes. You can also modify the email invitation message from the Settings > Mobile User Invitation Email page. Changes that you make and save to either page are automatically propagated to the other page. See “Customizing user invitation emails” on page 284. 4 Click Send invite. Note: To ensure that you receive email invitations properly, it is recommended that you configure you mail server's whitelist with the following IP address and FQDN: ■ 208.115.239.221 ■ o1.email.symantec.appcenterhq.com To verify the status of an email invitation 1 On the left pane, click Users. 2 In the list of groups, click invited. If an invited user has not yet created an account, the administrator can either resend the invitation or revoke it. An administrator can also resend the link to a user who has already created an account. If an invited user has created an account, the administrator can edit the account as well as add the user to a group. 112 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up the Mobility Suite local identity provider To add a single user 1 In Mobility Manager on the left pane, click Users. 2 Do either of the following: 3 ■ In the center pane under Users, click Add a New User. ■ On the right pane under Manually Add User, click Add a New User. ■ On the center pane, select the group into which you want to add the new users, and then click Add New User. On the New User page, type the following information for the user: ■ Username ■ First Name Optional ■ Last Name Optional ■ Email ■ Password ■ Confirm Confirm the password that you typed. 4 Under Groups, check the groups to which the user belongs. 5 Click Save. To add multiple users 1 In Mobility Manager on the left pane, click Users. 2 Do either of the following tasks: ■ On the center pane, click Upload Users CSV. ■ On the Create Users page under Mass Import with CSV, click Upload Users CSV. 3 Click Browse, locate the .csv file, and select it. 4 Click Upload Users (Step 1 of 2). 5 Verify the rows that will be imported. Invalid rows may consist of the header row, duplicates, or rows that do not match the specified format. 6 Check Send email notification to User(s). 7 Click Add Users (Step 2 of 2). 113 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up Active Directory/LDAP authentication See “Setting up your Symantec Mobility: Suite Work Hub” on page 42. Setting up Active Directory/LDAP authentication Symantec Mobility: Suite lets you add and authenticate users using Active Directory/LDAP as your external identity provider (IDP). As a best practice, you should configure a local IDP administrator account so that if your external IDP fails, you can still access the Mobility Manager using local IDP credentials. See “Setting up the Mobility Suite local identity provider” on page 104. Table 5-3 describes the workflow to add and authenticate users using Active Directory/LDAP. Table 5-3 Active Directory/LDAP IDP setup workflow Phase Description 1 Add a signed certificate authority LDAP SSL certificate to the Mobility Suite trust store so that you can securely connect to your LDAP server. Optional but recommended This task is optional and can be performed at any time. However, Symantec recommends that you add the LDAP certificate before you begin the integration to ensure that your connection with your LDAP server is secure. See “Adding LDAP certificates” on page 101. 2 Configure Active Directory/LDAP as the external IDP. You can integrate Mobility Suite with Active Directory/LDAP and use it as the source to authenticate users to access the Mobility Manager, the End-User Portal, the Work Hub, and any wrapped apps that require authentication. Active Directory/LDAP not only provides authentication, it also provides for application single sign-on. See “Configuring Active Directory/LDAP as an external identity provider (IDP)” on page 115. 3 Add your end users. End users access the Mobility Suite URL from their mobile devices to add in Mobility Suite and download the Work Hub. Note: A user's email address should only appear in one IDP at a time. For example, if you have the same user's email address in the local IDP and Active Directory, the user may have problems authenticating. For more information, refer to the following knowledge base article: http://www.symantec.com/docs/TECH205087 See “Adding users with the external identity provider (IDP)” on page 130. 114 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up Active Directory/LDAP authentication See “Setting up user authentication and adding users to Symantec Mobility: Suite” on page 104. Configuring Active Directory/LDAP as an external identity provider (IDP) Symantec Mobility: Suite supports using Active Directory as an external identity provider (IDP). It also supports using Active Directory through LDAP as an external IDP. In fact, Mobility Suite supports any other type of IDP that exposes an LDAP interface. You can integrate Mobility Suite with Active Directory/LDAP and use it as the source to authenticate users to access the Mobility Manager, the User portal, the Work Hub, and any wrapped apps that require authentication. Active Directory/LDAP also supports single sign-on for wrapped apps. See “Creating app policies that permit single sign-on (SSO)” on page 360. This workflow assumes you have met the following prerequisites: ■ Roles and groups are set up. You should set up your roles and groups in Mobility Suite before you configure your identity provider (IDP) so that when you configure the IDP, you can map users to the Mobility Suite groups that you created. Thereafter, you can create, delete, or modify roles and groups as needed. See “Creating groups” on page 61. ■ You have added signed certificate authority LDAP SSL certificates to the Mobility Suite trust store. This task is optional. If you choose to do it, it can be done at any time. However, Symantec recommends that you add the LDAP certificate before you begin the integration to ensure that your connection with your LDAP server is secure. See “Adding LDAP certificates” on page 101. ■ Active Directory or LDAP (whichever you intend to use for your IDP) already exists within your organization. ■ That you already have AD domain controllers (DCs) (or other IDP) with LDAP enabled. ■ To complete this workflow, you need the server URI (URL) and the Bind User name and password. Symantec recommends that you create an external IDP account with only enough privilege to perform the needed LDAP queries. You don't need an administrator user, but you do need a Bind User that is able to execute queries against users and groups. Then use the user name and password from that external IDP account in this configuration. 115 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up Active Directory/LDAP authentication ■ If you intend to use Active Directory/LDAP groups within Mobility Suite, the best practice is to create the needed groups within Active Directory/LDAP before you configure Active Directory/LDAP as the IDP. Create corresponding Active Directory/LDAP security groups specifically for Mobility Suite that you can map to Mobility Suite groups. You can always add more group mappings later, but having the initial set of groups already created in Mobility Suite makes configuration more straightforward. Often the corporate IDP has many more groups (hundreds or thousands) than are needed to implement app or device policy. To make group management less cumbersome, Mobility Suite imports Active Directory/LDAP groups and lets you map these Active Directory/LDAP groups to Mobility Suite groups. In the end, Active Directory/LDAP groups can be used to drive policy, which can be much easier to manage through Mobility Suite. Table 5-4 describes the workflow to configure Active Directory/LDAP as an IDP. Table 5-4 Configuring Active Directory/LDAP as an IDP workflow Phase Description 1 Set up the server configuration. See “To set up the server configuration for Active Directory/LDAP” on page 117. 116 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up Active Directory/LDAP authentication Table 5-4 Configuring Active Directory/LDAP as an IDP workflow (continued) Phase Description 2 Configure the authentication options. Active Directory/LDAP and Mobility Suite have slightly different naming conventions to identify the same attributes. For example, Mobility Suite has an attribute EMailAddress, which contains the user's full email address. In Active Directory, the same value uses the attribute mail. Your Active Directory/LDAP implementation may vary slightly. However, these are the same attributes — they just use a different moniker. Mobility Suite requires four attributes: Username, FirstName, LastName, and EMailAddress. You can map any attribute from Active Directory/LDAP to the Mobility Suite's Username attribute, but the data for that attribute must be unique. For example, you would not want to map the sn attribute in Active Directory to the Mobility Suite Username attribute, because you are likely to have more than one person with the same last name. Depending on your corporate policy, your employees may be assigned user names that they use to log onto your corporate network. So your Active Directory/LDAP configuration would already have a user name attribute (in more recent versions of Active Directory, this attribute is: sAMAccountName). So you can map this attribute to the Mobility Suite's Username attribute. Otherwise, you might want to use the email address attribute (in Active Directory, this attribute is: mail) since this attribute typically contains unique values. See “To configure the authentication options for Active Directory/LDAP” on page 118. 3 Specify group options. If you want Active Directory/LDAP groups to drive policy within Mobility Suite, then you need to import LDAP groups and then map some of the LDAP groups to Mobility Suite groups. See “Specify group options for Active Directory/LDAP” on page 119. 4 Enable the external IDP. See “Enable the external IDP” on page 120. To set up the server configuration for Active Directory/LDAP 1 In Mobility Manager, click Settings > External IDP > Server configuration. 2 Under Server Configuration, click the Type drop-down menu and select Active Directory or LDAP. 117 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up Active Directory/LDAP authentication 3 In the Server URL field, type the server URL address. Note that SSL is enabled by default. Symantec recommends that you use the default setting. 4 Check Use SSL to use SSL. 5 In the User name field, type a valid Bind User name that has access to the Server URL that you specified. 6 In the Password field, type the password. 7 Click Save. To configure the authentication options for Active Directory/LDAP 1 In Mobility Manager, click Settings > External IDP > Authentication options. 2 In the Search base DN field, type the search base distinguished name for the active directory that you are using. For example: OU=employees, OU=Domain Controllers, DC=acme DC=co 3 In the User name attribute field, type the Active Directory/LDAP attribute that corresponds with the Mobility Suite's Username attribute. The default value is sAMAccountName. 4 In the First name attribute field, type the Active Directory/LDAP attribute that corresponds with the Mobility Suite's FirstName attribute. The default value is givenName. 5 In the Last name attribute field, type the Active Directory/LDAP attribute that corresponds with the Mobility Suite's LastName attribute. The default value is sn. 6 In the Email attribute field, type the Active Directory/LDAP attribute that corresponds with the Mobility Suite's EMailAddress attribute. the default value is mail. 7 In the upper right corner, click Test to test that your integration with Active Directory/LDAP works. 8 Type a user's name and password and click Test again. If the test was successful, a green light and the words “authentication verified” appear at the bottom of the page. 9 If the test is successful, click Save. 118 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up Active Directory/LDAP authentication Specify group options for Active Directory/LDAP 1 In Mobility Manager, click Settings > External IDP > Group options. 2 To enable user groups, check Enable user groups. 3 To allow only those users who are a part of a group access Mobility Suite, click Allow only mapped group members to authenticate to Mobility Manager. 4 In the Search base DN field, type the search base distinguished name that you want to use. For example: OU=employees, OU=Domain Controllers, DC=acme, DC=co 5 In the Group type attribute field, type the group type attribute. 6 In the Group type field, specify the group type. 7 To map groups, under Group mappings in the Group search criteria field, type the group search criteria. Note the syntax as follows: (CN=group_name) You must include the parenthesis. 8 Check all of the boxes to the right of the Group search criteria to select the Mobility Suite groups to which the members of the Active Directory/LDAP group belong. 9 To test that your group mapping works, click Test. If the test is successful, the message "Found groups within search base" appears. 10 (Optional) To add new Group Search Criteria, click Add New Mapping and repeat steps 7 through 9. 11 (Optional) To delete a Group Search Criteria, click Delete. 12 To create subgroups for your organization units, under Subgroups by OU, do the following: ■ In the OU column, type the name of the organizational unit. ■ In the Subgroup name column, type the name for the subgroup. 13 (Optional) To delete a subgroup, click Delete. 14 (Optional) To add a new subgroup, click Add New Subgroup OU and repeat step 12. 15 Click Save. You are automatically returned to the Group options page. 119 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up SAML authentication Enable the external IDP ◆ Click Settings > External IDP > Configure IDP, and then click Start. Now you are ready to enroll your users in Mobility Suite. See “Adding users with the external identity provider (IDP)” on page 130. Setting up SAML authentication Symantec Mobility: Suite can use a SAML server to authenticate users for access the Mobility Manager, the End-User Portal, the Work Hub, and any wrapped apps that require authentication. SAML provides Web-based authentication and authorization and single sign-on (SSO) capabilities. Note: You must enable the end user portal if you plan to use SAML authentication. See “Setting up and customizing the User portal” on page 58. As a best practice, you should configure a local IDP administrator account so that if your external IDP fails, you can still access the Mobility Manager using local IDP credentials. See “Adding users with the local identity provider (IDP)” on page 110. Table 5-5 describes how to use SAML to add and authenticate users. Table 5-5 SAML implementation workflow Phase Description 1 The way you set up a basic SAML server configuration depends on whether or not your SAML server requires specific information from Mobility Suite for the integration. If it does, you download an XML file from Mobility Suite that contains this information and provide it to your SAML server provider. Your SAML server provider in turn provides you with the required IDP metadata file that you upload into Mobility Suite. The metadata file must be in ASCII characters. See “Configuring SAML as an external identity provider (IDP)” on page 121. The way you set up the server configuration varies based on the deployment that you use. However, the way you configure authentication options and enable the IDP are the same for all deployment options. 120 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up SAML authentication Table 5-5 SAML implementation workflow (continued) Phase Description 2 Add your end users. End users access the Mobility Suite URL from their mobile devices to add in Mobility Suite and download the Work Hub. Note: A user's email address should only appear in one IDP at a time. For example, if you have the same user's email address in the local IDP and SAML, the user may have problems authenticating. For more information, refer to the following knowledge base article: http://www.symantec.com/docs/TECH205087 See “Adding users with the external identity provider (IDP)” on page 130. 3 Assign your added users to the appropriate groups. See “Creating groups” on page 61. See “Setting up user authentication and adding users to Symantec Mobility: Suite” on page 104. Configuring SAML as an external identity provider (IDP) Symantec Mobility: Suite supports using the Security Assertion Markup Language (SAML) protocol to act as an external IDP. Mobility Suite can use the SAML server to authenticate users to access the Mobility Manager, the End-User Portal, the Work Hub, and any wrapped apps that require authentication. SAML provides Web-based authentication and authorization and single sign-on (SSO) capabilities. See “Creating app policies that permit single sign-on (SSO)” on page 360. When you configure Mobility Suite to use SAML, Mobility Suite acts as a service provider. The user connects to Mobility Suite. Mobility Suite causes the user’s browser or native app to redirect to the SAML server. Once the SAML server has authenticated the user, the server forwards the user back to Mobility Suite. This whole process is transparent to the user. Note: The password reset feature is only available if you use the local identity provider. However, if you use SAML as the external identity provider, the password reset option appears on the Mobility Manager logon page so that administrators can change or reset their passwords. This workflow assumes you have met the following prerequisites: ■ Roles and groups are set up. 121 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up SAML authentication You should set up your roles and groups in Mobility Suite before you configure your IDP so that after users enroll, you can assign them to the appropriate Mobility Suite groups. See “Creating groups” on page 61. ■ Your organization already has the SAML server configured. Table 5-6 describes how to configure SAML as an external IDP. Table 5-6 Configuring SAML as an external IDP workflow Phase Description 1 Set up the server configuration. The way you set up your server configuration depends on whether or not your SAML server requires specific information from Mobility Suite for the integration. If it does, you download an XML file from Mobility Suite that contains this information and provide it to your SAML server provider. Your SAML server provider in turn provides you with the required IDP metadata file that you upload into Mobility Suite. The metadata file must be in ASCII characters. See “To set up the server configuration if your SAML server does not require specific information from Mobility Suite ” on page 124. See “To set up the server configuration if your SAML server requires additional information from Mobility Suite” on page 124. 122 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up SAML authentication Table 5-6 Configuring SAML as an external IDP workflow (continued) Phase Description 2 Configure the authentication options. Your SAML Server's User Store and Mobility Suite have slightly different naming conventions to identify the same attributes. For example, Mobility Suite has an attribute EMailAddress, which contains the user's full email address. In a User Store, the same value might use the attribute mail. Your SAML implementation may vary slightly. However, these are the same attributes — they just use a different moniker. Mobility Suite requires four attributes: Username, FirstName, LastName, and EMailAddress. Optionally, if you want to do group mapping, you also need the Group attribute. You can map any attribute from your User Store to the Mobility Suite's Username attribute, but the data for that attribute must be unique. For example, you would not want to map the sn attribute in a User Store to the Mobility Suite Username attribute, because you are likely to have more than one person with the same last name. Depending on your corporate policy, your employees may be assigned user names that they use to log onto your corporate network. So your User Store configuration would already have a user name attribute. So you can map this attribute to the Mobility Suite's Username attribute. Otherwise, you might want to use the email address attribute since this attribute typically contains unique values. See “To configure authentication options for SAML” on page 125. 3 (Optional) You have the option to configure group mapping from your SAML server to Mobility Suite. See “To configure group options” on page 125. 4 Enable the external IDP. After you enable SAML as the IDP, all URL requests to https://[mytenant].appcenterhq.com are redirected to the SAML provider for authentication. To log in using the local IDP, you must use the following URL: https://[mytenant].appcenterhq.com/admin See “To enable the identity provider” on page 126. To complete this workflow, you need the following: ■ A SAML metadata file Each SAML server distributes its information through a single file typically referred to as the metadata file. This file is in XML format and contains all the information 123 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up SAML authentication needed to connect to it as well as any information needed to authenticate and parse the SAML replies. Obtain this metadata file from the SAML server. ■ SP Partner ID Some SAML servers need extra information in the SAML request forwarded to them. If your SAML server requires this additional information, obtain the SP Partner ID before you begin this workflow. ■ SP Entity ID Some SAML servers require extra information be included in the URL used to forward the request. Know the SP Entity ID before you begin this workflow. The service provider entity ID must be written exactly the same as it is in the metadata file. ■ Know the names of the attributes in your SAML User Store that you want to map to the corresponding Mobility Suite attributes: Username; FirstName, LastName, and EMailAddress To set up the server configuration if your SAML server does not require specific information from Mobility Suite 1 Click Settings > External IDP > Server configuration. 2 On the Server configuration page, click the Type drop-down list and select SAML. 3 In the Name box, type a name for the configuration. 4 Beside IDP metadata, click Browse. 5 Browse to and select the SAML metadata file. 6 Leave the SP partner ID field blank. 7 In the SP entity ID field, provide the service provider entity ID. Your SAML provider will provide you with this ID. It must be typed exactly as given to you by the provider. 8 Click Save. To set up the server configuration if your SAML server requires additional information from Mobility Suite 1 Click Settings > External IDP > Server configuration. 2 On the Server configuration page, click the Type drop-down list and select SAML. 3 In the Name box, type a name for the configuration. 124 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up SAML authentication 4 In the SP partner ID field, type a partner ID. Some SAML servers need extra information in the SAML request forwarded to them. Type this information here. 5 In the SP entity ID, provide the service provider entity ID. Your SAML provider will provide you with this ID. It must be typed exactly as given to you by the provider. 6 Click Download SP metadata file. Provide this file to your SAML provider. 7 If you need to leave this page before you are able to complete this procedure, click Save to save your changes. 8 When you have an IDP metadata file from your SAML provider, save it to a location that you can access from the Mobility Manager. 9 Beside IDP metadata, click Browse. 10 Browse to and select the SAML metadata file. 11 Click Save. To configure authentication options for SAML 1 Click Settings > External IDP > Authentication options. 2 Click the User name attribute drop-down list and select the corresponding attribute. You can map any attribute from your User Store to the User name attribute, but the data for that attribute must be unique. For example, you would not want to map the sn attribute in a User Store to the Mobility Suite's User name attribute, because you are likely to have more than one person with the same last name. 3 Click the drop-down menus and select the corresponding attributes. 4 Click Save. To configure group options 1 Click Settings > External IDP > Group Options. 2 To enable user groups, check Enable user groups. 3 To allow only those users who are a part of a group to access Mobility Suite, click Allow only mapped group members to authenticate to Mobility Manager. 4 To map groups, under Group mappings in the Group search criteria field, type the group search criteria. 125 Setting up user authentication and adding users to Symantec Mobility: Suite Configuring Symantec Identity: Access Manager as your SAML identity provider 5 Check all of the boxes to the right of the Group search criteria to select the Mobility Suite groups to which the members of the group belong. 6 (Optional) To add new Group Search Criteria, click Add New Mapping and repeat steps 4 through 5. 7 (Optional) To delete a Group Search Criteria, click Delete. 8 Click Save. You are automatically returned to the Group options page. To enable the identity provider ◆ On the Settings > External IDP > Configure IDP page, click Start. Now you are ready to enroll your users in Mobility Suite. See “Adding users with the external identity provider (IDP)” on page 130. Configuring Symantec Identity: Access Manager as your SAML identity provider Symantec Mobility: Suite lets you configure a SAML identity provider (IDP) that integrates with Symantec Identity: Access Manager (Access Manager). Pre-requisites: ■ You must have Access Manager installed and configured on-premises or in a hosted environment. ■ You must have the User portal enabled. See “Setting up and customizing the User portal” on page 58. The workflow for this task is as follows: Download a metadata file > Configure the server configuration > Configure authentication options > Configure group options > Enable the identity provider 126 Setting up user authentication and adding users to Symantec Mobility: Suite Configuring Symantec Identity: Access Manager as your SAML identity provider Download a metadata file 1 On the Mobility Manager left pane, click Settings > External IDP > Server Configuration. 2 Configure the following settings: Type Click the drop-down menu and select SAML. SP partner ID Provide the service provider partner ID. SP entity ID Important: Remember the IDs that you specify in this step. They must match exactly when Provide the service provider entity you upload the metadata file you ID. receive from the Access Manager administrator. 3 Click Download SP metadata file, and save the metadata file that you download. 4 Do one of the following: Access Manager Provide the metadata file to your Access Manager administrator. is on-premises Access Manager Your Access Manager contact can provide you with details about is hosted what to do with the metadata file that you download. A different metadata file is returned to you, which you upload to configure your Mobility Manager in the following procedure. Note: You cannot save your changes to this page until you upload an IDP metadata file (SAM-Metadata.xml). So for now, discard your changes. You'll repeat the first two steps when you receive the metadata file to upload. Don't forget to write down the partner ID and entity ID before you discard your changes. They must match exactly when you upload the metadata file you receive. Configure the server configuration Perform this task when you receive the .xml file. 127 Setting up user authentication and adding users to Symantec Mobility: Suite Configuring Symantec Identity: Access Manager as your SAML identity provider 1 On the Mobility Manager left pane, click Settings > External IDP > Server Configuration. 2 Do the following: Type Click the drop-down menu and select SAML. Name Type a name for this IDP instance. IDP metadata Click Browse and browse to and select the metadata file you received. SP partner ID Type the service provider partner Important: These IDs must ID. match the IDs that you specified when you downloaded the Type the service provider entity metadata file in step 2 in the ID. procedure Download a metadata file. SP entity ID 3 At the top-right of the page, click Save. You are automatically directed to the Authentication options page. 128 Setting up user authentication and adding users to Symantec Mobility: Suite Configuring Symantec Identity: Access Manager as your SAML identity provider Configure authentication options 1 Click the User name attribute drop-down list and select the corresponding attribute. You can map any attribute to the User name attribute, but the data for that attribute must be unique. For example, you would not want to map the sn attribute to the Mobility Suite User name attribute, because you are likely to have more than one person with the same last name. Depending on your corporate policy, employees may be assigned user names that they use to log onto your corporate network. If so, your User Store would already have a user name attribute. So you can map this attribute to the Mobility Suite's User name attribute. Otherwise, you might want to use the email address attribute since this attribute typically contains unique values. 2 Click the drop-down menus and select the remaining corresponding attributes. 3 Click Save. You are automatically directed to the Group options page. Configure group options 1 2 To enable user groups This option is enabled by default. Proceed to step 2. To disable user groups Uncheck Enable user groups. When you disable user groups, no other options are available in Group options. Proceed to step 7. To allow only those users who are a part of a group access Mobility Manager, click Allow only mapped group members to authenticate to Mobility Manager. 129 Setting up user authentication and adding users to Symantec Mobility: Suite Adding users with the external identity provider (IDP) 3 To map groups, under Group mappings in the Group search criteria field, type the group search criteria. Note the syntax as follows: (CN=group_name) You must include the parenthesis. For example: (cn=acdevelopers,ou=usa,dc=goacme,dc=com) 4 Check all of the boxes to the right of the Group search criteria to select the Mobility Suite groups to which the members of the group belong. 5 (Optional) To add new Group search criteria, click Add New Mapping and repeat steps 3 through 4. 6 (Optional) To delete a Group search criteria, click Delete. 7 Click Save. You are automatically directed to the Configure IDP page. Enable the identity provider ◆ At the top-right of the page, click Enable IDP. Adding users with the external identity provider (IDP) After you configure Symantec Mobility: Suite for your external IDP, you can send an email invitation to your users inviting them to enroll their devices. Afterwards, you can verify the status of an email invitation and verify which users have enrolled. Note: A user's email address should appear in only one IDP at a time. For example, if you have the same user's email address in the local IDP and Active Directory, the user may have problems authenticating. For more information, refer to the following knowledge base article: http://www.symantec.com/docs/TECH205087 Warning: The user's email address must already exist when you send the invitation; otherwise, the address is added to a bounce list. If you subsequently attempt to resend the invitation after the email address is created, the email cannot be delivered because it on the bounce list. What's more, if the user's email address is not associated with the user, you will be unable to modify the user's roles and permissions. This task assumes that you have met the following prerequisites: 130 Setting up user authentication and adding users to Symantec Mobility: Suite Adding users with the external identity provider (IDP) ■ You have configured the Work Hubs that your users will download and install on their mobile devices. See “Setting up your Symantec Mobility: Suite Work Hub” on page 42. ■ Roles and groups are set up. If you haven't done so already, you should set up your roles and groups in Mobility Suite before you add your users so that you can map users to the appropriate groups. See “Creating groups” on page 61. ■ You have configured and enabled your external IDP. Because you have integrated Mobility Suite with an external IDP, the IDP handles the authentication process when you add users. See “Configuring Active Directory/LDAP as an external identity provider (IDP)” on page 115. See “Configuring SAML as an external identity provider (IDP)” on page 121. See “To add users” on page 131. See “To verify the status of an email invitation” on page 131. See “To verify a user was added” on page 132. To add users 1 In Mobility Manager, click Users > Invite users. 2 Under Invite users, click Invite users to Work Hub. 3 In the Users box, type the email address of the user that you want to invite. For multiple users, separate the email addresses with a comma. 4 In the text box, type the message that you want to appear in the email invitation. You can use the buttons in the menu bar to: ■ Format the page ■ Format the text ■ Embed a graphic (for example, your logo), YouTube URL, or other URL ■ Specify text as your invite link 5 In the lower left corner, click Send Invite. 6 (Optional) Click Save message as template if you want to use the text and formatting in this invitation for future invitations. To verify the status of an email invitation 1 In Mobility Manager, click Users > Track invites. 2 In the Type drop-down list, select the type of invite that you want to verify: 131 Setting up user authentication and adding users to Symantec Mobility: Suite Permitting enterprise single sign-on (SSO) for iOS devices 3 4 ■ Work Hub ■ NMS In the Status drop-down list, select the status type of invite(s) that you want to verify: ■ All ■ Sent ■ Failed In the From and to fields, specify the date range that you want to verify based on the date the invitation was sent. The invitations appear for the date range you specified. If an invited user has not yet created an account, the administrator can either resend the invitation or revoke it. An administrator can also resend the link to a user who has already created an account. If an invited user has created an account, the administrator can edit the account as well as add the user to a group. To verify a user was added 1 Mobility Manager, click Users > Users and groups. 2 Under Users and groups, do one of the following: 3 ■ In the Search for users box, type the name of the user you want to verify. ■ Click the name of the group to display all the users associated with that group. Verify that the user appears and is in the correct group. If the user does not appear in the correct group(s), there may be an error with your IDP group mapping. Go back and re-verify your group mapping on the Settings > External IDP > Group options page. See “Setting up your Symantec Mobility: Suite Work Hub” on page 42. Permitting enterprise single sign-on (SSO) for iOS devices Symantec Mobility: Suite provides an enterprise single sign-on (SSO) feature for iOS 7 and later applications that use the Kerberos authentication protocol. This feature lets your end users authenticate once to the protected URL prefixes that access your corporate resources. When your end users open an app with enterprise SSO configured, iOS requires that they authenticate. However, no additional 132 Setting up user authentication and adding users to Symantec Mobility: Suite Enabling Cisco ISE integration authentication is required when they launch the subsequent apps that access the same protected URL prefixes. When you configure enterprise SSO, you specify which URL prefixes are protected, which apps can use SSO, and other parameters. You can then create device policies with those settings. This feature is supported for wrapped and unwrapped apps. Apps can be MDM-managed, but do not have to be. You can configure enterprise SSO in either of the following ways: ■ Through a device profile. Policies and rules > Device Policy > Device profiles > SSO See “Sharing settings between different device policies” on page 306. See “SSO policy settings” on page 443. ■ When you configure a device policy. Policies and rules > Device Policy > New Policy | Device Settings | SSO See “Creating device policies” on page 304. The enterprise SSO is an MDM feature. But Mobility Suite also offers a mobile app management (MAM) SSO. Table 5-7 explains the difference between the enterprise SSO and the app SSO. See “Creating app policies that permit single sign-on (SSO)” on page 360. Table 5-7 Differences between Enterprise and App SSO Consideration Enterprise SSO (MDM) App SSO (MAM) Place of authentication Controls app access to network services. So when a user uses any app that connects to a protected URL, the user is prompted for credentials. Controls app access on the device. So when user clicks on the app, Mobility Suite intercepts the access and prompts for credentials. Type of authentication Allows only Kerberos-based Allows local, Active authentication. Directory/LDAP, or SAML authentication methods. Applicability of apps Applies to any app on the device. Applies to only wrapped apps (internal and sealed). Enabling Cisco ISE integration Symantec Mobility: Suite supports integration with Cisco® Identity Services Engine (ISE) version 1.2 when you use the Work Hub and MDM is enabled. Devices that MDM manages can be reported onto the Cisco ISE system. 133 Setting up user authentication and adding users to Symantec Mobility: Suite Enabling Cisco ISE integration For communication and connectivity to occur, you must open ports 443 between ISE server and the Mobility Suite server. When you combine the Cisco ISE with Mobility Suite's MDM solution, you enable posture compliance assessment and network access control of mobile endpoints that attempt to access your network. The integration also performs ongoing posture checks to ensure compliance and the correct network access level is maintained. Cisco ISE profiles devices as they attempt to access the network. This discovery process provides you with the first step of network visibility. Once you configure ISE to control network access, only managed and/or approved devices are allowed access based on the rules that you set up in ISE and the information gathered from Mobility Suite about devices. Cisco ISE enforces access policy based on the posture status reported by Mobility Suite's MDM. Access policy may be constructed on specific attributes within Cisco ISE or at a global level of “in compliance” or “not in compliance” within the Mobility Manager. For further information about Cisco ISE and configuring Cisco ISE, please see the following documentation: ■ Cisco ISE Overview: http://www.cisco.com/en/US/prod/collateral/vpndevc/ps5712/ps11637/ ps11195/at_a_glance_c45-654884.pdf ■ Cisco ISE FAQ: http://www.cisco.com/en/US/prod/collateral/vpndevc/ps5712/ps11637/ ps11195/qa_c67-658591.pdf ■ Cisco ISE End-User Guides: http://www.cisco.com/en/US/products/ps11640/products_user_guide_list.html To enable Cisco ISE integration 1 In the Mobility Manager, click Settings > Device configuration > Device management. 2 Scroll down to the bottom of the page. 3 Under Cisco ISE, check Enable Cisco ISE support. 4 A user name and password are automatically pre-generated, but you can click Generate authentication keys to create a new API key in Mobility Suite that has permissions to access the Cisco ISE API. 134 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up two-factor authentication 5 Uncheck Allow Cisco ISE to execute actions on devices to prevent ISE from executing commands on devices. If you disable actions from ISE, ISE still works properly with Mobility Suite for network admission, but ISE isn't able to perform actions on devices. For example, an administrator can inadvertently change settings and cause ISE to run actions on devices that Mobility Suite would permit, such as wiping or locking devices. When you disable this option, ISE is unable to lock or wipe a device. 6 In the upper right corner, click Save. See “Setting default mobile device management (MDM) values for new device policies” on page 290. Setting up two-factor authentication About two-factor authentication Use two-factor authentication to create an additional layer of security for access to the Symantec Mobility: Suite Mobility Manager and Admin Hub. Two-factor authentication works with any of the supported authentication identity providers (IDP) and Symantec VIP Access. A user with the Administrator role or administrator-equivalent permissions can initiate the setup request for two-factor authentication and enable this feature. The process to set up two-factor authentication varies slightly for SaaS and on-premises tenants due to different certificate requirements. Figure 5-1 is a diagram of the setup workflows. Table 5-8 describes the certificate requirements. 135 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up two-factor authentication Two-factor authentication setup workflows Figure 5-1 On-premises Tenant Symantec Mobility SaaS Tenant Begin setup Upload certificate Begin setup Request setup Process request Request setup Receive email with verification key Send approve/ rejected/ success email Receive success email Enter verification key and validate Rejected Approved Email your users of new login workflow Email your users of new login workflow Enable feature Enable feature Table 5-8 Two-factor authentication certificate requirements Tenant Certificate requirements SaaS tenant setup If you are a SaaS tenant, an authentication certificate is created for you and automatically sent along with your request to Symantec Mobility to set up two-factor authentication. Symantec Mobility renews this certificate before expiration. So there's no requirement for you to obtain and upload a new certificate when the current one expires. You can view authentication certificates on the Settings > Certificates > Authentication certificates page. 136 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up two-factor authentication Table 5-8 Two-factor authentication certificate requirements (continued) Tenant Certificate requirements On-premises tenant setup You must upload a valid certificate, and it must be valid for at least 30 days¹ after the date you submit it. The file must be in .p12 file format. If your certificate is invalid, Symantec Mobility denies your request to set up two-factor authentication. You must re-request setup and upload a new, valid certificate. You can use a certificate issued by a certificate authority (CA) or a self-signed certificate issued from your server. See “Creating self-signed certificates” on page 101. Before certificate expiration, you must re-register two-factor authentication and upload a new certificate. Otherwise, two-factor authentication is automatically disabled when the certificate expires. Setting up two-factor authentication can take several days. So as a best practice, you should enable the Certificate Expiration notification email setting to remind you in sufficient time to re-register. You can view and manage authentication certificates on the Settings > Certificates > Authentication certificates page. See “Renewing two-factor authentication when a certificate expires” on page 143. ¹ If Symantec Mobility sends you a success message but the certificate that you uploaded expired before you validate the verification key, an error message appears. You must repeat the setup process. See “Managing authentication certificates in Symantec Mobility: Suite” on page 73. The Mobility Manager shows the current status of VIP Configuration. States include: Set up requested, Completed, and Rejected. When this feature is enabled, it applies to users who have access to the Mobility Manager and Admin Hub and have certain administrator privileges. See “Assigning roles” on page 64. These users must download the Symantec VIP Access app onto a mobile device and perform a one-time setup with VIP Access. Thereafter, each time they log into Mobility Manager or the Admin Hub, they first type their IDP credentials. Users then have the option to either authenticate through VIP Access using push notification or they can enter a VIP Access security code. See “Logging onto Mobility Manager or Admin Hub using two-factor authentication” on page 140. 137 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up two-factor authentication SaaS tenant setup Setup two-factor authentication for SaaS tenant 1 On the Mobility Manager left pane, click Settings > Authentication and roles > Admin authentication. 2 On the right pane under Two-factor authentication, click Begin setup. 3 Click Request setup. Your request is automatically sent to the Symantec Mobility team. In 3 - 5 days, an email notification is sent to the Mobility Manager Inbox and to the email address listed for Operations Messages notifications indicating your setup request is successful. See “Configuring email notifications” on page 55. 4 Contact the people in your organization who must use two-factor authentication with instructions about how register with VIP and how to log onto Mobility Manager and the Admin Hub using two-factor authentication. See “Logging onto Mobility Manager or Admin Hub using two-factor authentication” on page 140. 5 When you receive the email notification from Symantec Mobility that two-factor authentication setup is successful, on the Mobility Manager left pane, click Settings > Authentication and roles > Admin authentication. 6 On the right pane under Two-factor authentication, click Off to enable the feature. When you click Off, On appears. This indicates the feature is enabled. 138 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up two-factor authentication On-premises tenant setup Setup two-factor authentication for on-premises tenant 1 On the Mobility Manager left pane, click Settings > Authentication and roles > Admin authentication. 2 On the right pane under Two-factor authentication, click Begin setup. 3 Click Browse and browse to and select the certificate. A valid certificate authority must issue the certificate. The file must be in .p12 file format. You can view and manage this certificate on the Settings > Certificates > Authentication certificates page. See “Managing authentication certificates in Symantec Mobility: Suite” on page 73. 4 Optionally, type a pass phrase for the certificate and click Save. Your request is automatically sent to Symantec Mobility team. In 3 - 5 days, an email notification that contains a verification key is sent to the primary administrator and to the administrator who requested the two-factor authentication setup. This email indicates if your setup request was approved or rejected. 5 Contact the people in your organization who must use two-factor authentication with instructions about how register with VIP and how to log onto Mobility Manager and the Admin Hub using two-factor authentication. See “Logging onto Mobility Manager or Admin Hub using two-factor authentication” on page 140. 6 When you receive the email notification from Symantec Mobility, on the Mobility Manager left pane, click Settings > Authentication and roles > Admin authentication. 139 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up two-factor authentication 7 Type the verification key and click Validate. If your verification key is rejected or if you get a success message but the certificate that you uploaded expired before you validate the verification key, repeat the process beginning with step 2. If your verification key is successful, proceed with the next step. Note: If you have previously set up two-factor authentication and you receive notification from Symantec Mobility that the new certificate is invalid, you can revert back to a previous certificate that has not yet expired. That way your organization can continue to use two-factor authentication until you can successfully complete the re-setup process. 8 On the right pane under Two-factor authentication, click Off to enable the feature. When you click Off, On appears. This indicates the feature is enabled. Logging onto Mobility Manager or Admin Hub using two-factor authentication To provide an additional layer of security, your organization has implemented a two-factor authentication process to access the Symantec Mobility: Suite Mobility Manager and Admin Hub. Initially, you must install the Symantec VIP Access app onto a mobile device. Then, the next time you log into Mobility Manager, you register your credentials with Symantec VIP Access. Thereafter, each time you log onto Mobility Manager or the Admin Hub, first type your IDP credentials as you have previously done. You can then either sign-in with VIP Access through a push notification or you can use a VIP Access security code. 140 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up two-factor authentication Initial setup 1 On a mobile device, download VIP Access by Symantec and open the app. You'll need the Credential ID and Security Code from the app to register with VIP Access in a subsequent step. The app is supported on iOS, Android, and Windows devices, so you can download it from the respective app stores. You can also download the app through Mobility Suite if your administrator has added it to your organization's app store. 2 Access Mobility Manager, type your IDP credentials, and click Sign In. 3 Click Register Credentials, and then click Continue. You are re-directed to the VIP Self-Service Portal. 4 Click Register. 5 In the Credential Name field, type a name that distinguishes this VIP Access account from other registered access accounts. For example, you may want to use the name Mobility Suite to distinguish this registration from other products that you've registered for. 6 Enter the Credential ID and the Security Code that appears in your VIP Access app. 7 Click Submit. If your registration has been successful, the Manage your Credentials page appears. 141 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up two-factor authentication 8 Click Log in with Registered Credential. 9 In the Confirm your Identity dialog box, type the security code that appears in the VIP Access app and click Submit. The Mobility Manager appears. Logging onto Mobility Suite or Admin Hub using push notification 1 Access Mobility Manager or the Admin Hub. 2 Type your IDP credentials and click Sign in. 3 On your mobile device, open the VIP Access app and tap Allow. Mobility Manager or the Admin Hub appears. Logging onto Mobility Suite or Admin Hub using a security code 1 Access Mobility Manager or the Admin Hub. 2 Type your IDP credentials and click Sign in. 3 On the Sign In Request screen, click Use a security code. 4 On the Sign in with your VIP Credential page, type the security code that appears on the VIP Access app and click Sign In. Mobility Manager or the Admin Hub appears. More information See “Logging onto Mobility Manager and Admin Hub when you don't have access to the VIP Access app” on page 142. Logging onto Mobility Manager and Admin Hub when you don't have access to the VIP Access app If your organization uses two-factor authentication, the second factor requires a security code that you access using Symantec VIP Access app on a mobile device. However, you may have an occasion in which the mobile device on which you installed the app and registered with VIP is unavailable. Symantec Mobility: Suite and VIP Access provide an out-of-band workflow that lets you access to Mobility Manager and the Admin Hub using a temporary security code. Logging onto Mobility Manager and the Admin Hub out-of-band 1 Access Mobility Manager or Admin Hub. 2 Type your IDP authentication credentials and click Sign In. 3 On the Sign In Request screen, click Use a security code. 142 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up two-factor authentication 4 On the Sign in with your VIP Credential page, click Don't have a security code?. 5 Click Continue to confirm your email address. This address is the email address linked to your IDP user name. 6 Check your email account for a message from VIP and open it. If this message does not appear in your inbox, check your junk mail folder. TIP: You may want to add this address to your approved recipients list so that future email messages appear in your inbox. 7 Copy the temporary VIP security code from the email message and paste it in the Security Code box on the Confirm your Identity page and click Submit. The email message indicates how long the temporary security code is valid. If you do not use the temporary security code before it expires, you must request a new one. More information See “Logging onto Mobility Manager or Admin Hub using two-factor authentication” on page 140. Renewing two-factor authentication when a certificate expires Two-factor authentication requires a current, valid certificate or the feature is disabled. Symantec Mobility handles the certificate renewal for SaaS customers. For on-premises tenants, before the current certificate expires you must request Symantec Mobility to set up two-factor authentication for you again using a new certificate. You can view and manage authentication certificates on the Settings > Certificates > Authentication certificates page. See “Managing authentication certificates in Symantec Mobility: Suite” on page 73. You are notified by email when your certificate is about to expire. But setting up two-factor authentication can take several days. So as a best practice, you should 143 Setting up user authentication and adding users to Symantec Mobility: Suite Setting up two-factor authentication enable the Certificate Expiration notification email setting to remind you in sufficient time to re-register. See “Configuring email notifications” on page 55. Renew two-factor authentication 1 On the Mobility Manager left pane, click Settings > Authentication and roles > Admin authentication. 2 On the right pane under Two-factor authentication, click Request setup again. Upload certificate 1 Click Browse and browse to and select the certificate. You must upload a valid certificate, and it must be valid for at least 30 days after the date you submit it. The file must be in .p12 file format. If your certificate is invalid, Symantec Mobility denies your request to set up two-factor authentication. You must re-request setup and upload a new, valid certificate. You can use a certificate issued by a certificate authority (CA) or a self-signed certificate issued from your server. See “Creating self-signed certificates” on page 101. 2 Optionally, type a pass phrase for the certificate and click Save. Your request is automatically sent to Symantec Mobility. In 3 - 5 days, an email notification that contains a verification key is sent to the primary administrator and to the administrator who requested the two-factor authentication setup. This email indicates if your setup request was approved or rejected. 144 Setting up user authentication and adding users to Symantec Mobility: Suite Establishing an iOS Work Hub PIN policy Enter verification key, validate, and enable two-factor authentication 1 When you receive the email notification from Symantec Mobility, on the Mobility Manager left pane, click Settings > Authentication and roles > Admin authentication. 2 Type the verification key and click Validate. If your verification key is rejected or if you get a success message but the certificate that you uploaded expired before you validate the verification key, repeat the process beginning with step 2 in Renew two-factor authentication above. If your verification key is successful, proceed with the next step. Note: If you have previously set up two-factor authentication and you receive notification from Symantec Mobility that the new certificate is invalid, you can revert back to a previous certificate that has not yet expired. That way your organization can continue to use two-factor authentication until you can successfully complete the re-setup process. 3 On the right pane under Two-factor authentication, click Off to enable the feature. When you click Off, On appears. This indicates the feature is enabled. More information See “Setting up two-factor authentication” on page 135. See “Managing authentication certificates in Symantec Mobility: Suite” on page 73. Establishing an iOS Work Hub PIN policy Symantec Mobility: Suite lets you create a policy that requires iOS device users to set up a PIN. This PIN lets users access the Work Hub, the WorkSpace, sealed, and wrapped apps making access easier and more convenient. And this same PIN works across all of the users enrolled devices for both online and offline use. Not only is the PIN easier to enter than IDP credentials, but it also serves as single sign-on. When users authenticate to wrapped or sealed apps and then open the Work Hub, they won't have to reauthenticate. Note that single sign-on based on authenticating to the Work Hub first does not apply to subsequent access to sealed and wrapped apps. 145 Setting up user authentication and adding users to Symantec Mobility: Suite Establishing an iOS Work Hub PIN policy Note: Authentication requirements in the app policy take precedence over the iOS Work Hub PIN policy. For example, if the PIN policy is disabled but the app policy requires authentication to access the app, IDP authentication is still required. You must also enable the user to access the app offline in the app policy for the offline PIN to function. The iOS PIN is supported for all identity providers. And it works whether mobile device management (MDM) is enabled or not. The Work Hub PIN policy is currently only supported for iOS. However, Android does support offline PINs. See “Establishing an Android offline PIN policy” on page 147. When new users enroll, after authenticating to access to the Work Hub using their IDP credentials, they are prompted to set up a user PIN. For users already enrolled, the next time they access the Work Hub, after they type their IDP credentials, they are prompted to set up a user PIN. If a user forgets their PIN, they can still authenticate using their IDP credentials. The Work Hub PIN is enabled by default with default settings. But you can modify these settings to customize these settings to make the requirements more or less lenient. For an iOS PIN policy to take effect, you must rewrap your apps and rebuild our Work Hub. 146 Setting up user authentication and adding users to Symantec Mobility: Suite Establishing an Android offline PIN policy Establish an iOS Work Hub PIN policy 1 On the Mobility Manager left pane, click Settings > Authentication and roles > iOS Work Hub PIN policy. 2 Modify any of the following settings: Work Hub PIN This option is enabled by default. When you disable this option, the remainder of the settings disappears. Users must authenticate using their IDP credentials when authentication is required. Minimum PIN length The default value is the minimum PIN length (4 digits). The PIN length range is 4 - 12 digits. Re-enter PIN every The default value is 8 hours. The range is 1 - 48 hours. PIN expires every The default is 90 days. The range is 7 - 365 days. Max attempts allowed The default is 3 attempts. The range is 3 - 10 attempts. PIN history depth How many PINs must expire before a PIN can be reused. The default is 3 PINs. The range is 0 - 10. Re-enter IDP credentials every The default is 2 days. You can specify intervals in hours (1 - 24) or days (1 - 30). Note: The Re-enter IDP credentials every interval must be greater than the Re-enter PIN interval. 3 Click Save. More information See “App policy configuration options” on page 349. See “Rebuilding the in-house iOS Work Hub” on page 53. See “Re-wrapping apps” on page 357. Establishing an Android offline PIN policy The Android offline PIN policy is only enforced when a user creates an offline PIN in the Work Hub. The offline Android PIN is used to access the User portal, the Work Hub, or any apps with policies that require offline authentication. 147 Setting up user authentication and adding users to Symantec Mobility: Suite Establishing an Android offline PIN policy Establish an Android offline PIN policy 1 On the Mobility Manager left pane, click Settings > Authentication and roles > Android Offline PIN policy. 2 Modify any of the following settings: 3 ■ Minimum PIN length The default setting is 4. ■ PIN history depth enabled. Disabled by default. ■ PIN history depth The default setting is 6. ■ Prohibit user name and email ■ Require uppercase PIN must have at least one uppercase letter. ■ Require lowercase PIN must have at least one lowercase letter. ■ Require numbers PIN must have at least one number. ■ Require non-alpha PIN must have at least one non-alphanumeric character. ■ First three unique The first three characters of the PIN must be different from each other (i.e., they cannot be the same). For example, the PIN cannot be: 11122. But the PIN can be 1A*22. Click Save. More information See “Establishing an iOS Work Hub PIN policy” on page 145. See “App policy configuration options” on page 349. 148 Chapter 6 Setting up an app proxy for Symantec Mobility: Suite This chapter includes the following topics: ■ About restricting app access to your intranet with an app proxy ■ Setting up Secure App Proxy ■ Secure App Proxy deployment model ■ Setting up Secure App Proxy in Mobility Manager ■ Installing Secure App Proxy ■ Upgrading Secure App Proxy ■ Using Symantec Secure Web to test Secure App Proxy installation ■ Uninstalling Secure App Proxy ■ Secure App Proxy command line tools ■ Secure App Proxy default file locations ■ Troubleshooting Secure App Proxy About restricting app access to your intranet with an app proxy Symantec Mobility: Suite integrates with Secure App Proxy to create a secure connection to intranet resources on a provisioned device from a Symantec Sealed app or an enterprise-wrapped app. When an app attempts to access your internal Setting up an app proxy for Symantec Mobility: Suite Setting up Secure App Proxy resources, the connection request is routed through the proxy. Mobile users access intranet resources as though they are connected to the company network. Some things to know about Secure App Proxy: ■ You must have a Symantec Mobility: Suite or the Symantec Mobility: Application Management module license to install and use Secure App Proxy. ■ The Mobility Manager from which you configure Secure App Proxy must be running Symantec Mobility: Suite 5.0 or later. ■ Mobile devices must be running the Work Hub on iOS 8/7/6 or Android 4.x. Next See “Setting up Secure App Proxy” on page 150. Setting up Secure App Proxy Follow this workflow to install Secure App Proxy and set it up in Symantec Mobility: Suite. Table 6-1 Secure App Proxy installation and setup workflow Phase Task Description 1 Before you deploy the app proxy in your environment, understand what the deployment model looks like and what you need to do to prepare your environment. Review the Secure App Proxy deployment model. See “Secure App Proxy deployment model” on page 151. 2 Set up Secure App Proxy in Mobility Manager. Define the proxy and upload or create required certificates. See “Setting up Secure App Proxy in Mobility Manager” on page 154. 3 Install Secure App Proxy on your server. Install the proxy on your server from the command line. See “Installing Secure App Proxy” on page 157. 4 Create app policies that direct traffic through Secure App Proxy. Your app policies must specify through which app proxy you want to direct app traffic. See “Creating app policies to control network access” on page 358. 150 Setting up an app proxy for Symantec Mobility: Suite Secure App Proxy deployment model Table 6-1 Secure App Proxy installation and setup workflow (continued) Phase Task Description 5 App policies must be assigned to specific apps. Assign your app policy to an app. See “Adding apps to Symantec Mobility: Suite” on page 331. 6 Use Symantec Secure Web to test Before you implement the app proxy in an app the app proxy. policy, test it first. See “Using Symantec Secure Web to test Secure App Proxy installation” on page 163. Click here for the interactive workflow. More information See “About restricting app access to your intranet with an app proxy” on page 149. Get started See “Secure App Proxy deployment model” on page 151. Secure App Proxy deployment model Before you install Secure App Proxy and integrate it with Symantec Mobility: Suite, make sure that you understand how to deploy the proxy in your environment. The deployment model that is depicted below is based on Symantec's recommendations and should be followed as a best practice. All of the instructions for Secure App Proxy in this documentation are based on the following deployment model. Figure 6-1 depicts the app traffic flow in the simplest terms: 151 Setting up an app proxy for Symantec Mobility: Suite Secure App Proxy deployment model Figure 6-1 Basic secure app proxy deployment model A: The app request is directed to your intranet URL. The request must pass through the first public-facing entry point into your network. You must open port 443 for this entry point. Specify the FQDN or IP address of this entry port in the Host name field on the Settings > Proxies > App > New/Edit Secure App Proxy page. B: Your network infrastructure forwards the request to the app proxy incoming NIC. (You must configure your network infrastructure to forward the request.) You configure the incoming NIC address when you install the app proxy. C: The proxy forwards the request through the outgoing NIC to the entry point to the intranet URL. You configure the outgoing NIC address when you install the app proxy. Add the intranet URL or domain to the White-Listed Locations table on the Policies and Rules > App Policies > New/Edit App Policy page. Configure it to listen on port 443. Figure 6-2 depicts a typical deployment scenario, though your network may not follow this model exactly: 152 Setting up an app proxy for Symantec Mobility: Suite Secure App Proxy deployment model Figure 6-2 Typical secure app proxy deployment model In the diagram, the firewall is the first public-facing entry point. You specify the FQDN or IP address of your firewall in the Host name field on the Settings > Proxies > App > New/Edit Secure App Proxy page when you set up the proxy. The request passes through the firewall and load balancer to the incoming NIC on the proxy. The proxy forwards the request to the intranet URL through the outgoing NIC. You specify the incoming and outgoing NIC addresses when you install the proxy. You specify the IP address or domain of the intranet site in the White-Listed Locations table on the Policies and Rules > App Policies > New/Edit App Policy page when you configure the app policy. Based on a typical deployment model, consider the following: ■ If you have a firewall and/or a load balancer, install Secure App Proxy behind them in a DMZ. ■ You can stand up multiple proxies behind a load balancer. The load balancer is expected to handle failover. When you use a load balancer, the recommended setting is to round-robin with persistence. ■ Symantec recommends no more than 3,000 concurrent connections per proxy. An app can open more than one connection at a time. For example, a web browser can have 20 connections open simultaneously. Monitor your telemetry 153 Setting up an app proxy for Symantec Mobility: Suite Setting up Secure App Proxy in Mobility Manager for active connections. If active connections begin to reach the maximum recommended load, set up another proxy to help balance the load. Warning: Do not install the Secure App Proxy and Secure Email Proxy on the same server. The configuration is unsupported, and the proxies will not work properly. Next See “Setting up Secure App Proxy in Mobility Manager” on page 154. More information Click here for the interactive workflow. See “About restricting app access to your intranet with an app proxy” on page 149. Setting up Secure App Proxy in Mobility Manager Before you install Secure App Proxy on your server, set it up in Mobility Manager. When you set up the proxy in Mobility Manager, you specify the proxy or load balancer address and port. You upload or create the required SSL certificates. Then you'll download a configuration file which you'll need to apply when install Secure App Proxy on your server. 154 Setting up an app proxy for Symantec Mobility: Suite Setting up Secure App Proxy in Mobility Manager Set up Secure App Proxy in Mobility Manager 1 In Mobility Manager, click Settings Proxies > App > New Secure App Proxy. 2 Specify the following information about the proxy. Apps use this information to communicate with app proxy. ■ Name 155 Setting up an app proxy for Symantec Mobility: Suite Setting up Secure App Proxy in Mobility Manager This can be any unique name you want. This name appears in the Secure App Proxy drop-down list on the New/Edit Policy page. 3 ■ Host name Specify the FQDN or the IP address of the first entry point into your network (in a typical deployment, this would be a firewall or load balancer). ■ Port Specify the port through which the host listens for connections from the app. Symantec recommends port 443 for SSL HTTP/S traffic. See “Secure App Proxy deployment model” on page 151. ■ Description Type a description that helps you differentiate this app proxy from other app proxies. You'll need certificates for the SSL termination point that devices are connecting to. Under SSL Certificate, do any of the following: To install a new certificate on the app proxy Select Install on Secure App Proxy and Create new. To upload an existing certificate to the app proxy 1 Select Install on Secure App Proxy and click Upload. 2 Click Choose File and locate the certificate. Note: The certificate must be in PKCS#12 format. 3 Optionally, specify a pass phrase. To install a new certificate on the load balancer Creating and installing new certificates on the load balancer is not supported. To upload an existing certificate to the load balancer 1 Select Install on Load Balancer and click Upload. 2 Click Choose File and locate the certificate. Note: The certificate must be in PKCS#12 format. 3 Optionally, specify a pass phrase. Note: Certificates to be installed on the app proxy are included in the configuration file. You install the configuration file when you install the proxy. However, certificates for the load balancer are not part of the configuration file. They are used by the device to validate the certificate with the connection to the load balancer. You must install the certificates on your load balancer. 156 Setting up an app proxy for Symantec Mobility: Suite Installing Secure App Proxy 4 Click Save. 5 Click Download Now to download the configuration file that you'll need when you install Secure App Proxy. 6 Type a password that you'll provide when you apply the configuration file during Secure App Proxy installation. 7 Save the configuration file to /tmp directory of the server on which you intend to install Secure App Proxy. The configuration file contains the information and certificates that are needed to establish a trusted communication between the app and Secure App Proxy. Next See “Installing Secure App Proxy” on page 157. More information Click here for the interactive workflow. See “About restricting app access to your intranet with an app proxy” on page 149. See “Secure App Proxy deployment model” on page 151. Installing Secure App Proxy After you set up Secure App Proxy in Mobility Manager, you're ready to install the proxy on your server. What you'll need ■ Server on which to install the app proxy The server on which you install the proxy must meet the following minimum system requirements: ■ 4 cores ■ 8-GB RAM ■ 20-GB disk space ■ 64-bit CentOS 6.5 or 64-bit RHEL 6.5 ■ Two NICs: one for incoming connections; the other for outgoing connections The installation script will recommend available interfaces. If you don't want to use the recommended interfaces, have the interfaces that you want to use available. ■ Access to internal DNS and routing gateways 157 Setting up an app proxy for Symantec Mobility: Suite Installing Secure App Proxy ■ Configuration file (which includes SSL certificates) Download the Secure App Proxy .iso file 1 In Mobility Manager, click Downloads > Download Secure App Proxy. Tip: This option appears towards the bottom of the Downloads page. 2 Save the .iso file to your /tmp directory on the server on which you plan to install the proxy. Install libicu ◆ On the server on which you install Secure App Proxy, open a terminal and run the following command: su yum install libicu 158 Setting up an app proxy for Symantec Mobility: Suite Installing Secure App Proxy 159 Install Secure App Proxy 1 As root, run the following commands: # mkdir -p/tmp/appproxy/mnt # mount -o loop /tmp/[app proxy .iso file]/tmp/appproxy/mnt /tmp/ # appproxy/mnt/setup.sh --install Setting up an app proxy for Symantec Mobility: Suite Installing Secure App Proxy 2 The following is an example of the installation script. This script assumes the administrator accepts all the default settings: [root@hdloaner-xxxxxx av]# ls -l total 36 -r--r-----. 1 builder builder 197 Jul 28 10:15 about -r-xr-x---. 1 builder builder 3434 Jul 17 09:08 configure.sh drwxr-x---. 2 builder builder 4096 Jul 28 10:15 install drwxr-x---. 2 builder builder 4096 Jul 28 10:15 lib -r--r-----. 1 builder builder 33 Jul 15 09:02 README drwxr-x---. 2 builder builder 4096 Jul 28 10:15 rpms -r-xr-x---. 1 builder builder 4005 Jul 21 09:21 setup.sh drwxr-x---. 2 builder builder 4096 Jul 28 10:15 uninstall drwxr-x---. 2 builder builder 4096 Jul 28 10:15 upgrade [root@hdloaner-xxxxxx av]# ./setup.sh install Installing... nginx: unrecognized service SYMANTEC SOFTWARE LICENSE AGREEMENT ... I have read and accepted the end user license agreement. Press Y to proceed > Y You have agreed to the end user license agreement. Continuing. ===== User Account ===== Please specify the user account to be used for running Symantec Secure App Proxy: (1) Create and use default user 'symc-proxy' (2) Enter custom user that you have created. (3) Quit without making changes. 1 WARNING: 'getent' could not detect group symc-proxy WARNING: 'getent' could not detect user symc-proxy Create user account and/or group? (1) Yes. (2) No, but continue install anyways. (3) No, quit without changes. 1 Creating group 'symc-proxy'... Creating user 'symc-proxy'... ===== Installation ===== ===== Installing Secure Proxy RPMs ===== /bin/rpm -I ./rpms/secure-app-proxy-5.0-29.x86_64.rpm 160 Setting up an app proxy for Symantec Mobility: Suite Installing Secure App Proxy 161 mkdir: cannot create directory `/usr/local/nginx/telemetry': File exists ===== Network configuration ===== Please select the address and port which will receive incoming connections from the device: 1) (eth0): 192.168.70.155 2) Enter IP manually #? 1 Please enter listen port. [443] > Please select the address which will send data to the target server: 1) (eth0): 192.168.70.155 2) Enter IP manually #? 1 ===== Syslog configuration ===== Do you want to enable syslog support (Y/N)? [N] > ===== Security configuration ===== Do you want to install the configuration package from AppCenter? Y/N >y Please enter configuration file location > /tmp/GATEWAY-NAME.json Please enter configuration file password > Installing AC authentication key: /usr/local/nginx/certs/ appvpn_auth_key.pem Installing AC authentication certificate: /usr/local/nginx/certs/ appvpn_auth_cert.pem Installing SSL private key: /usr/local/nginx/certs/appvpn_ssl_key.pem Installing SSL certificate: /usr/local/nginx/certs/appvpn_ssl_cert.pem Would you like to keep the old signing certificate and the old CA certificate (Y/N)? [N] > Installing assertion signing certificate: /usr/local/nginx/certs/ appvpn_signing_cert.pem Installing CA certificate: /usr/local/nginx/certs/appvpn_ca_cert.pem Security configuration file import has been successful. chmod 0550... chmod 0660... chmod 0770... chmod 0750... DONE chmod files. Changing 'owner:group' of folders to 'root:symc-proxy' Starting nginx-watchdog: ===== Secure Proxy started ===== ===== Installation complete ! ===== [ OK ] Setting up an app proxy for Symantec Mobility: Suite Upgrading Secure App Proxy 3 Verify that the service is running by typing the following command: # service nginx status Next See “Creating app policies to control network access” on page 358. More information Click here for the interactive workflow. See “About restricting app access to your intranet with an app proxy” on page 149. See “Secure App Proxy deployment model” on page 151. See “Secure App Proxy command line tools” on page 165. Upgrading Secure App Proxy You can upgrade Secure App Proxy on 64-bit CentOS/RHEL 6.4. If you want to upgrade your server to CentOS/RHEL 6.5, do so after you perform the proxy upgrade. Upgrade Secure App Proxy 1 Change directories to the directory that contains the setup.sh script. The default location of the setup.sh script is: /usr/local/nginx/scripts 2 Type the following command: # ./upgrade 3 Verify that the service is running by typing the following command: # service nginx status See “Troubleshooting Secure App Proxy” on page 170. More information See “About restricting app access to your intranet with an app proxy” on page 149. 162 Setting up an app proxy for Symantec Mobility: Suite Using Symantec Secure Web to test Secure App Proxy installation Using Symantec Secure Web to test Secure App Proxy installation After you install Secure App Proxy, test it to make sure that it works properly. Create a test policy 1 Click Policies and Rules > App Policies > New App Policy and specify a name and description for your test policy. 2 Under the General Settings section , make sure User authentication required is checked. This setting is checked by default. 3 Under the Network Access Control section, beside Secure App Proxy, check Redirect all traffic to, click the drop-down menu and select the Secure App Proxy that you want to test. 4 In the White-Listed Locations box, use the default setting for testing purposes. The default setting uses the TCP protocol and the asterisk (*) wildcard for the location and port to allow all URLs. 5 Save the policy. Download Symantec Secure Web app and configure it 1 Add the Symantec Secure Web app the same way you do any other Symantec Sealed app. See “Adding a Symantec Sealed app to Symantec Mobility: Suite” on page 342. 2 In the left pane, click Apps, select the Symantec Secure Web app and on the middle pane, and click the Edit icon at the top right. 3 Click the Policy drop-down list, and select the test policy that you created in the previous procedure. 4 In the Associated Users list, provision the app to include the user or users who are testing the Secure App Proxy. Tip: For testing purposes, you may want to consider creating a private group. See “Creating a private group” on page 63. 5 Click Save. 163 Setting up an app proxy for Symantec Mobility: Suite Uninstalling Secure App Proxy Have a provisioned user test Secure App Proxy 1 On the test user's mobile device running the most current version of the Work Hub, download the Symantec Secure Web app. 2 Attempt to open an intranet URL and then attempt to open an Internet URL. If the user is able to access the URLs for both intranet and Internet resources, the proxy works properly. More information Click here for the interactive workflow. See “About restricting app access to your intranet with an app proxy” on page 149. See “Creating app policies to control network access” on page 358. Uninstalling Secure App Proxy If you install Secure App Proxy with the default settings, the uninstall script performs a clean uninstallation of the /usr/local/nginx/scripts directory removing Secure App Proxy and its related files. If you modified the location of installation and log files, all app proxy files may not be removed during uninstallation. In that case, you'll need to locate and manually delete these files when you permanently uninstall the app proxy. A user and group account are created when you initially install Secure App Proxy. The default user and group account names are both symc-proxy, but you can customize these names. You may want to remove the user and group account names if you permanently uninstall the app proxy. However, make sure that you don't inadvertently remove possible shared accounts. 164 Setting up an app proxy for Symantec Mobility: Suite Secure App Proxy command line tools 165 Run the uninstall script 1 Change directories to the directory that contains the uninstall.sh script. The default location of the uninstall.sh script is: /usr/local/nginx/scripts 2 Run the following command: # ./uninstall.sh An example of an uninstall script is as follows: [root@hdloaner-xxxxxx av]# cd /usr/local/nginx [root@hdloaner-xxxxxx nginx]# ls -l total 40 drwxrwx---. 2 root symc-proxy 4096 Jul 28 10:15 drwxrwx---. 2 symc-proxy symc-proxy 4096 Jul 28 10:15 drwxrwx---. 2 root symc-proxy 4096 Aug 13 10:20 drwxr-x---. 2 root symc-proxy 4096 Aug 13 10:20 drwxrwx---. 2 root symc-proxy 4096 Aug 13 10:20 drwx------. 2 symc-proxy root 4096 Aug 13 10:20 -r--r-----. 1 root symc-proxy 33 Jul 15 09:02 drwxr-x---. 2 root symc-proxy 4096 Aug 13 10:20 dr-xr-x---. 3 root symc-proxy 4096 Aug 13 10:19 drwxrwx---. 2 root symc-proxy 4096 Jul 28 10:15 [root@hdloaner-xxxxxx nginx]# scripts/uninstall.sh Stopping nginx-watchdog: /bin/rpm -e secure-app-proxy-5.0-29.x86_64 certs client_body_temp conf html logs proxy_temp README sbin scripts telemetry [ OK [root@hdloaner-xxxxxx nginx]# ls -l total 0 See “Troubleshooting Secure App Proxy” on page 170. More information See “About restricting app access to your intranet with an app proxy” on page 149. See “Secure App Proxy default file locations” on page 169. Secure App Proxy command line tools You can modify Secure App Proxy after installation through the command line using the configure.sh script. The nginx service automatically restarts after the command finishes executing. This script must be run as superuser. The default location of the script is as follows: ] Setting up an app proxy for Symantec Mobility: Suite Secure App Proxy command line tools /usr/local/nginx/scripts The usage is as follows: # ./configure.sh [OPTIONS] {TOOL} Table 6-2 Configure.sh tools Tool Description appvpn [on/off] Enables or disables Secure App Proxy functionality. audit [on/off] Enables or disables the proxy audit feature. ca_certificate [path to certificate] Configures a new CA certificate location. change_account_to Changes the nginx user account. For example: # ./configure.sh change_account to symc-acct dns_cache [on/off] Enables or disables the DNS cache feature. When you enable this feature, the configuration script prompts you to specify additional parameters (such as maximum cache size, expiration time in seconds for successful DNS request entries, and expiration time for failed DNS request entries. dns_cache flush Flushes the DNS cache. Sends a signal to all workers to reset their DNS cache on the next request. DNS cache is reset on the next DNS request processed by the end user. listen Configures the listening parameters of the proxy. The configuration script prompts you for the listening parameters of the proxy: IP, port, SSL (on or off). 166 Setting up an app proxy for Symantec Mobility: Suite Secure App Proxy command line tools Table 6-2 Configure.sh tools (continued) Tool Description log Configures logging parameters (such as purge and rotation enablement, log file size limits, number of log archives to keep). This command does not have a configuration script to prompt you, so you must specify the settings in the command line. The usage is as follows: ./configure log -t [error_log|access_log|syslog] -e [on|off] -l [debug|info|notice|warn|error|crit|alert|emerg] -r [on|off] -p [on|off] -s [NUMBER] -f [NUMBER] The logging parameters are as follows: -t Specifies type of log for which you want to modify settings. Can be either "error_log", "access_log", or "syslog". -e Indicates whether a log is enabled or not. Can be "on" or "off". Cannot disable error_log or access_log. -l Specifies logging level for the particular log. Not applicable for access_log. -r Enables rotation for a log. Can be "on" or "off". Not applicable for syslog. -p Enables or disables purging for a log. Can be "on" or "off". Not applicable for syslog. -s Indicates the size upon which to rotate a log, in bytes. Not applicable for syslog. -n Number of archived logs to keep for the specific log. Not applicable for syslog. log -h Shows the log configuration help. network Configures the network parameters. The configuration script prompts you for the network interface and port that receives/transfer data. 167 Setting up an app proxy for Symantec Mobility: Suite Secure App Proxy command line tools Table 6-2 Configure.sh tools (continued) Tool Description security Starts the security package installation and configuration. The configuration script prompts you about whether security is configured for the server. If so, it prompts you for the location of the security configuration file that you downloaded on the App Proxy > Secure App Proxy page when you configured the proxy in Mobility Suite. It also asks you for the password that you created when you downloaded the configuration file from Mobility Manager. sign_certificate [path Configures a new signing certificate location. to certificate] You must specify the path to the sign certificate. syslog [on/off] Enables or disables logging to syslog. This feature sends log information to the local syslog daemon configuration. It is up to the administrator to configure the syslog daemon for remote syslog. task_queue Configures the task queue feature for the proxy. The configuration script prompts you for additional configuration parameters (such number of processing threads, task expiration in minutes, and maximum task queue size). telemetry [on/off] When enabled, this feature sends data to a local .json file for third-party monitoring. The administrator must feed the information into their own monitoring system. The data is not historical data. It is only a snapshot of the data at the time it is saved to the .json file. Data is continually replaced when it is requested by the monitoring system. whitelist [on/off] Enables or disables the whitelist feature. When you enable this feature, the configuration script prompts you for additional parameters (such as the IP/DNS name, cache size, expiration time in seconds, and the proxy-wide whitelist file location, if it's needed). More information See “About restricting app access to your intranet with an app proxy” on page 149. See “Secure App Proxy default file locations” on page 169. See “Setting up Secure App Proxy in Mobility Manager” on page 154. 168 Setting up an app proxy for Symantec Mobility: Suite Secure App Proxy default file locations See “Uninstalling Secure App Proxy” on page 164. Secure App Proxy default file locations Table 6-3 lists the default location for Secure App Proxy files. Table 6-3 Secure App Proxy default file locations File Location Default installation directory /usr/local/nginx Command line scripts /usr/local/nginx/scripts Includes the following scripts: ■ configure.sh ■ uninstall.sh ■ upgrade.sh Binary executables and libraries /usr/local/nginx/sbin Configuration files /usr/local/nginx/conf /usr/local/nginx/html Use configure.sh to update these files. Security certificates /usr/local/nginx/certs Log files /usr/local/nginx/logs error.log: main log file, all severity levels. OS service script /etc/init.d/nginx More information See “About restricting app access to your intranet with an app proxy” on page 149. See “Installing Secure App Proxy” on page 157. See “Uninstalling Secure App Proxy” on page 164. 169 Setting up an app proxy for Symantec Mobility: Suite Troubleshooting Secure App Proxy Troubleshooting Secure App Proxy Table 6-4 Troubleshooting suggestions Issues Recommendation Upgrade fails. Return Secure App Proxy to a clean state by uninstalling the proxy and then reinstalling it. See “Uninstalling Secure App Proxy” on page 164. See “Installing Secure App Proxy” on page 157. You cannot run the uninstallation script from Mount the proxy .iso file and use the setup the uninstall.sh scripts folder. .sh script to perform the uninstallation. Just make sure that the .iso file that you download is the same version as the proxy installed. 170 Chapter Setting up an email proxy for Symantec Mobility: Suite This chapter includes the following topics: ■ Secure Email Proxy workflow ■ Introduction to Secure Email Proxy ■ Installing Secure Email Proxy ■ Creating Secure Email Proxy clusters ■ Adding a Secure Email proxy to your Secure Email cluster ■ Enabling Push email notifications for your iOS Work Mail app ■ Testing Secure Email Proxy ■ Configuring the Work Mail app for use with Secure Email Proxy ■ Blocking email access for non-compliant devices ■ Monitoring Secure Email Proxy health ■ Upgrading, Uninstalling or Unregistering Secure Email Proxy ■ Secure Email Proxy command line tools ■ Secure Email Proxy default file locations ■ Troubleshooting Secure Email Proxy 7 Setting up an email proxy for Symantec Mobility: Suite Secure Email Proxy workflow Secure Email Proxy workflow The Secure Email Proxy workflow lists the suggested order of steps to install and configure all aspects of your Secure Email Proxy. The steps are organized in best practice sequence. The table Table 7-1 The complete Secure Email Proxy workflow Step Task 1 Understand the basics of Secure Email proxy deployment. This topic includes: ■ Supported email apps. ■ Supported versions of Microsoft Exchange. ■ Glossary of common terms. ■ Use-case example. ■ System requirements. See “Introduction to Secure Email Proxy” on page 175. 2 Install the Secure Email proxy iso. This topic includes: ■ Downloading the secure email proxy. ■ Running the install scripts. See “Installing Secure Email Proxy” on page 183. 3 Create a Secure Email cluster. See “Creating Secure Email Proxy clusters” on page 187. 4 Add an available Secure Email proxy to a Secure Email cluster. This topic includes: ■ Add one of more proxies to a cluster. ■ Edit an existing cluster. ■ Delete an existing cluster. See “Adding a Secure Email proxy to your Secure Email cluster ” on page 191. 172 Setting up an email proxy for Symantec Mobility: Suite Secure Email Proxy workflow Table 7-1 The complete Secure Email Proxy workflow (continued) Step Task 5 Enable push email notification for your iOS Work Mail app. This supports background email notifications to your iOS Work Mail app. This topic includes: ■ Port requirements for Push email. ■ ■ setup.sh --configure pushemail command to enable the PushService role. Configure push email settings. ■ Creating an impersonation account. ■ Secure Email proxy server roles. ■ Scale example. See “Enabling Push email notifications for your iOS Work Mail app” on page 195. 6 Configure your Work Mail app. This topic includes: ■ Creating a device policy. ■ Configure your Work Mail app using. Work Mail configurations from within a device policy. Configure your Native Email app using Native Email configurations from within a device policy. Define what email apps area allowed access via Secure Email proxy using Access via Email Proxy from within a device policy. ■ ■ See “ Configuring the Work Mail app for use with Secure Email Proxy” on page 205. 7 Test your Work Mail app. This topic includes: ■ Configuring for passive mode. ■ ■ Configuring your Work Mail app using a device policy OR (recommended) configuring your Work Mail app using App Config. Test email access. ■ Review logs. See “Testing Secure Email Proxy” on page 202. 8 Locate Secure Email Proxy policy default log files. This topic includes: ■ All binary, script and log file locations. See “Secure Email Proxy default file locations” on page 229. 173 Setting up an email proxy for Symantec Mobility: Suite Secure Email Proxy workflow Table 7-1 The complete Secure Email Proxy workflow (continued) Step Task 9 Block email access for non-compliant devices. This topic includes: ■ Configuring a compliance rule. See “Blocking email access for non-compliant devices” on page 217. 10 Monitor Secure Email proxy health. This topic includes: ■ ■ Checking the status of your registered Secure Email Proxy from the Mobility Manager console. Monitoring Secure Email Proxy usage with telemetry. See “Monitoring Secure Email Proxy health” on page 218. 11 Understand how to use the Secure Email command line tools. This topic includes: ■ Using the command line tools to install, uninstall, upgrade and configure your Secure Email Proxy. See “Secure Email Proxy command line tools” on page 227. 12 Know how to troubleshoot Secure Email Proxy. This topic includes: ■ ■ Definition of all Secure Email Proxy logs and when you should review a specific log. Problems with organizational email access. See “Troubleshooting Secure Email Proxy” on page 230. 13 Learn how to upgrade, uninstall or un-register your Secure Email Proxy. This topic includes: ■ Upgrading your Secure Email Proxy. ■ Uninstalling your Secure Email Proxy. ■ Un-registering your Secure Email Proxy. See “Upgrading, Uninstalling or Unregistering Secure Email Proxy” on page 222. 174 Setting up an email proxy for Symantec Mobility: Suite Introduction to Secure Email Proxy Introduction to Secure Email Proxy Symantec Mobility: Suite integrates with the Secure Email Proxy to manage access to your organization's Exchange ActiveSync mail server. It provides an access control point for email traffic to registered devices. When users attempt to access corporate email from their devices, the connection requests are routed through the email proxy. The email proxy verifies that the connections come from approved users on registered devices. The graphic below details this concept in its simplest form: Figure 7-1 Basic Secure Email Proxy deployment 175 Setting up an email proxy for Symantec Mobility: Suite Introduction to Secure Email Proxy A:The device sends the request to the first public-facing entry point into your network. Open inbound port 443 for this entry point. Specify this FQDN or IP address in the Exchange ActiveSync Host field in the device policy and the ActiveSync host in Device Policy field in the cluster configuration. B: Your network infrastructure forwards the request to the email proxy inbound NIC. (You must configure your network infrastructure to forward the request.) You configure the inbound NIC address when you install the email proxy. C: The proxy forwards the request through the outbound NIC to the entry point for your mail server. You configure the outbound NIC address when you install the email proxy. You specify the entry point FQDN or IP address in the Server Address field when you configure the cluster. You configure the entry point to listen on port 443. At the device, the following email applications are supported for use with Secure Email proxy. Note: Please note the requirement for device management for your specific email app. Table 7-2 Supported email apps Email app Device management requirement Supported mobile device OS versions Symantec Work Mail app Optional ■ Android 4.x ■ iOS 8/7 iOS native email app Required Windows Phone native email Required app iOS 8/7 Windows Phone 8.1 At the server running Microsoft Exchange, the following Microsoft Exchange Server versions are supported: 176 Setting up an email proxy for Symantec Mobility: Suite Introduction to Secure Email Proxy Table 7-3 Supported Mail Servers for use with Secure Email Proxy Supported Microsoft Exchange version Microsoft Exchange 2007 Microsoft Exchange 2010 Microsoft Exchange 2013 Microsoft Office 365 (O365) Outlook Mail There are several illustration that are provided in this guide. All of the components used in Secure Email proxy (including the PushService role) are listed in the glossary table below. It is suggested to review these terms before continuing with this guide. Table 7-4 Glossary of common terms Terminology Definition Mobility Suite Formerly referred to as App Center. Mobility Suite is an integrated, modular solution on a singular platform with the flexibility to license the Suite or individual modules: Symantec Mobility: Device Management (MDM), Symantec Mobility: Application Management (MAM), and Symantec Mobility: Threat Protection (Norton) Secure Email Proxy Secure Email Proxy manages access to your organization's Exchange ActiveSync mail server. It provides an access control point for email traffic to registered devices. When users attempt to access corporate email from their devices, the connection requests are routed through the email proxy. The email proxy verifies the connections come from approved users on registered devices. iOS Work Mail App The iOS Work Mail app supports Work Mail exchange on your iOS device. It is referenced frequently in ths guide when the implementation of Push email notifications is discussed. 177 Setting up an email proxy for Symantec Mobility: Suite Introduction to Secure Email Proxy Table 7-4 Glossary of common terms (continued) Terminology Definition PushService Role When the PushService role is enabled, you receive email push notifications to your iOS Work Mail application when it is running in the background. Enabling the PushService role is done by running a post installation command (./setup.sh --configure pushemail and configuring the push email settings section in the cluster configuration page. Local Redis Cache When you install Secure Email proxy, a local cache store is installed. The local cache uses Redis (open source data and cache store). Elements stored in the local cache are exclusive to the proxy instance. Distributed Redis Cache When you install Secure Email proxy, a distributed cache store is installed. The distributed cache uses Redis (open source data and cache store). Elements stored in the distributed cache are shared among other email proxy instances residing in the same cluster. The distributed cache instances associated with each email proxy nominate a master. The remaining distributed cache instances (slaves) send their data and key elements to the master. In turn, the slave distributed cache instances will receive data and key information from the master. ActiveSync Server ActiveSync is a service that allows a mobile device to be synchronized with either a desktop PC or a server running a compatible software product including Microsoft Exchange Server. ActiveSync typically runs on Exchange Servers. As ActiveSync can be run separate from an exchange server, you see the term ActiveSync server throughout this chapter. EWS EWS (Exchange Web Services) provides the functionality to enable client applications to communicate with the Exchange server. 178 Setting up an email proxy for Symantec Mobility: Suite Introduction to Secure Email Proxy Table 7-4 Glossary of common terms (continued) Terminology Definition CAS server The CAS (Client Access Server) is a Microsoft Exchange server role that handles all client connections to Microsoft Exchange server. The CAS supports all client connections to Exchange Server from Microsoft Outlook and Outlook Web App (OWA), as well as ActiveSync applications such as Symantec Work Mail. In a high volume environment, it is common to have CAS servers arranged in arrays with a load balancer at the front-end of the CAS array. Callback Server The callback server represents the IP address or FQDN of the server that the exchange server "calls back" in response to a request from the email proxy for email for a specific device. The callback server address is the email proxy server address or the address of a load balancer at the front end of an email proxy cluster. Load Balancer A load balancer distributes incoming requests across multiple computing resources. In high volume organizations, load balancers manage an even distribution of work between servers in an array or cluster. APNS APNS (Apple Push Notification Service) is an Apple based service that forwards notifications of 3rd party applications to iOS devices. SPOC SPOC (Single Point of Contact) is a Symantec cloud based service. Secure Email proxy uses SPOC as intermediary to APNS to facilitate push email notification to devices running iOS Symantec Work Mail. Use-case example Before you install Secure Email Proxy and integrate it with Symantec Mobility: Suite, make sure that you understand how to deploy the proxy in your environment. The deployment model that is depicted below is based on Symantec's recommendations 179 Setting up an email proxy for Symantec Mobility: Suite Introduction to Secure Email Proxy and should be followed as a best practice. All of the instructions for Secure Email Proxy in this documentation are based on the following deployment model. Figure 7-2 depicts a typical deployment scenario, though your network may not follow this model exactly. Figure 7-2 Typical Secure Email Proxy deployment In Figure 7-2, the firewall is your first public-facing entry point. So you would specify the FQDN or IP address of your firewall in the Exchange ActiveSync Host field in the device policy and the ActiveSync host in Device Policy field in the cluster configuration. You would specify the incoming and outgoing NIC addresses when you install the email proxy. The entry point into your mail server environment is a load balancer. So you would specify the FQDN or IP address of this load balancer in the Server Address field when you configure the cluster. Based on a typical deployment model, also consider the following: ■ If you have a firewall and/or a load balancer, install Secure Email Proxy behind them in a DMZ. ■ You can stand up multiple proxies behind a load balancer. The load balancer is expected to handle failover. When you use a load balancer, the recommended setting is to round-robin with persistence. 180 Setting up an email proxy for Symantec Mobility: Suite Introduction to Secure Email Proxy ■ Symantec recommends no more than one proxy per Exchange Client Access server (CAS). ■ You secure the transmission from the device to the proxy by uploading a certificate when you configure your cluster. You must provide the PCKS#12 certificate. See “Creating Secure Email Proxy clusters” on page 187. Warning: Do not install the Secure App Proxy and Secure Email Proxy on the same server. The configuration is unsupported, and the proxies will not work properly. System Requirements for Secure Email Proxy The table below details the system requirements for a Secure Email proxy installation: Note: For system requirements regarding the PushService role (to allow email push notifications to your iOS Work Hub app) See “Enabling Push email notifications for your iOS Work Mail app” on page 195. Table 7-5 System Requirements for server on which to install Secure Email proxy 4 cores 8 GB RAM 20 GB disk space 64-bit CentOS 6.5 or 64-bit RHEL 6.5 See “Install libicu” on page 183. Java JRE 1.8 update 5 or later Two NICs are recommended but not required: one for incoming connections; the other for outgoing connections. The installation script will recommend available interfaces. If you don't want to use the recommended interfaces, have the interfaces that you want to use available. For proxy installation, you'll need the following: 181 Setting up an email proxy for Symantec Mobility: Suite Introduction to Secure Email Proxy Table 7-5 (continued) Proxy name The proxy name is a unique identifier to register the proxy with Mobility Manager. The name appears in the Mobility Manager and assists administrators with managing the proxy. For proxy registration, you'll need to know the following: Your Mobility Suite qualified domain name. For example: AppCenter.example.com A user that has admin rights to Mobility Manager Licensing A valid Mobility Suite license must be applied for on-premise installation. (cannot be a trial license) As it relates to email proxy, the license is not used in the common method of enabling functionality. The license is used by mobility suite to establish trust with other services within the email proxy architecture to support the push functionality. If your mobility suite is SaaS based, a trial license can be used. Supported Mail Servers for use with Secure Email Proxy Microsoft Exchange 2007 Microsoft Exchange 2010 Microsoft Exchange 2013 Microsoft Office 365 (O365) Outlook Mail Requirements for your iOS Work Mail application: 182 Setting up an email proxy for Symantec Mobility: Suite Installing Secure Email Proxy Table 7-5 (continued) iOS Work Mail runs as a sealed app on iOS devices running iOS7 or iOS8. Wrap iOS Work Mail using a policy with authentication enabled. For iOS Work Mail to be push enabled, iOS Work Mail is configured using app config. If iOS Work Mail is configured using the Work Mail settings from a device policy, push is not enabled. For more information using app config to configure Work Mail, See “ Configuring the Work Mail app for use with Secure Email Proxy” on page 205. Installing Secure Email Proxy What you'll need Download the email proxy .iso file 1 In Mobility Manager, click Downloads > Download Secure Email Proxy. Tip: This option appears at the bottom of the Downloads page. 2 Save the .iso file to the /tmp directory on the server on which you intend to install Secure Email Proxy. Install libicu ◆ On the server on which you install Secure Email Proxy, open a terminal and run the following command: sudo yum install libicu 183 Setting up an email proxy for Symantec Mobility: Suite Installing Secure Email Proxy Install and register your email proxy 1 Assuming the email proxy iso has been copied to the /root directory, run the following commands as root: # mkdir -p /mnt/iso # mount -o loop /root/[email proxy .iso file] /mnt/iso/ # /mnt/iso/setup.sh --install 184 Setting up an email proxy for Symantec Mobility: Suite Installing Secure Email Proxy 2 The following is an example of the install script. This script assumes that the administrator accepts all the default settings. Important: You must register the proxy for the proxy and Mobility Manager to communicate, and it must be registered before it can be added to a cluster. As illustrated below, email proxy registration can be done as part of the email proxy installation. See “Secure Email Proxy command line tools” on page 227. 185 Setting up an email proxy for Symantec Mobility: Suite Installing Secure Email Proxy Troubleshooting: If any installation or registration issues occur, refer to the logs. See “Secure Email Proxy default file locations” on page 229. 186 Setting up an email proxy for Symantec Mobility: Suite Creating Secure Email Proxy clusters At the completion of the email proxy setup script, you see a message instructing you to configure the Push Service role (circled in red in the above graphic). The Push Service role supports background push email notifications to your iOS Work Mail app. See “Enabling Push email notifications for your iOS Work Mail app” on page 195. for information about how to enable and configure the Push Service role. Creating Secure Email Proxy clusters Creating a Proxy cluster After you successfully register your email proxy, you can create clusters to organize and assign common configurations to your email proxies. In Mobility Manager, clusters are for shared configurations only. Email proxy clusters are not a cluster in the traditional sense of load balancer or failover. As a best practice, Symantec recommends that you create a separate cluster for each CAS server that has a unique DNS entry. Each Secure Email Proxy must be assigned to a cluster. (A proxy can only be assigned to one cluster and a single cluster can have one or more proxies.) To create a cluster, access Settings > Proxies > Email and click Create New Cluster. The cluster configuration page appears. 187 Setting up an email proxy for Symantec Mobility: Suite Creating Secure Email Proxy clusters The Cluster configuration page 188 Setting up an email proxy for Symantec Mobility: Suite Creating Secure Email Proxy clusters The above graphic illustrates the cluster configuration page with example values. Note: For information regarding the Push email for iOS Work Mail clients, See “Enabling Push email notifications for your iOS Work Mail app” on page 195.. Push email settings are not enabled by default. Specify the General Settings: Name Pick a name that helps you differentiate this cluster from other clusters. Description Create that a description provides an explanation for why the proxies in this particular cluster are grouped together. Tip: If you follow Symantec's recommendation of creating a separate cluster for each Client Access Server (CAS) that has a unique DNS entry, your description might include the name of the CAS server. Mode ■ ■ Active mode Active mode filters enrolled devices based on device compliance. Use active mode when running Secure Email Proxy in your production environment. Passive mode Passive mode allows all traffic through the proxy to your EAS. The verdict of which connections would have been permitted if the cluster had been in active mode is recorded in the log. Use passive mode when running Secure Email Proxy in a test environment. See “Secure Email Proxy default file locations” on page 229. 189 Setting up an email proxy for Symantec Mobility: Suite Creating Secure Email Proxy clusters Log Level Log levels specify the level of detail about the proxies in this cluster to be sent to your logs. The logging levels are as follows: ■ ■ ■ ■ Error Emergency situation where the system is in an unusable state; severe situation where action is needed promptly; important problems that need to be addressed; or an error has occurred (something was unsuccessful). Warning Contains all of the information for the Error logging level plus information in which something out of the ordinary happened, but there is not a cause for concern. This log level is the default log level. Information Contains all of the Warning and Error logging level information plus informational-type messages that might be nice to know. Debug Contains all of the Error, Warning, and Information logging information plus information that can be useful to pinpoint where a problem occurs. Tip: Select a logging level that provides the information you need to monitor the proxy, but doesn't overload your logs. For example, you can set the log level to Debug when you need to diagnose an issue. Then set it back to Warning when the issue is resolved. External Proxy Address The external proxy address is the IP address or FQDN that is assigned to your email proxy which is public facing. If you have enabled a load balancer in front of your email proxy, the IP address or FQDN of the load balancer must be specified as the external proxy address. If you are using SSL, the external FQDN proxy address must include the FQDN of the SSL certificate used. Specify the Proxy Connection to ActiveSync settings: ActiveSync Server Address - Specify the fully qualified domain name (FQDN) or IP address of the server running ActiveSync. In most instances, this will be the same address as your installation of Microsoft Exchange Server or the Microsoft O365 cloud server. Note: ActiveSync and Exchange mail functions can be installed on different servers. 190 Setting up an email proxy for Symantec Mobility: Suite Adding a Secure Email proxy to your Secure Email cluster Port - Specify the port used for data transport between email proxy to the ActiveSync server. SSL checkbox - If you check SSL, you secure data transmission between your email proxy and your ActiveSync server. Symantec recommends for secure connections from your email proxy to the ActiveSync server that you check SSL. Terminate SSL at the proxy There are 2 options available for this function: ■ ■ Enable [New Certificate] - when this option is selected, you are prompted to upload a valid SSL certificate. (see below) This will secure data transmission between the device and your email proxy. The SSL certificate you upload must include the private key. (PKCS#12 format) For more information, see the section on SSL certificate chains at the following Nginx website; http://nginx.org/en/docs/http/configuring_https_servers.html#chains Disable - when this option is selected, the proxy does not terminate SSL. SSL may be terminated at some other point. (i.e. on a load balancer in front of the proxy) The new cluster appears in the Clusters section of the Proxies page. In the example below, Cluster1 has been created: Adding a Secure Email proxy to your Secure Email cluster After you successfully register your email proxy, (normally, as part of the email proxy installation) your email proxy appears as a node when you click the Available 191 Setting up an email proxy for Symantec Mobility: Suite Adding a Secure Email proxy to your Secure Email cluster Proxies button. For available email proxies to be configurable and thus functional, you drag the email proxy node into the Associated proxies column. Note: You must register your proxies before you can add them to a cluster. You can register your email proxy during installation or later through the command line. See “Secure Email Proxy command line tools” on page 227. 192 Setting up an email proxy for Symantec Mobility: Suite Adding a Secure Email proxy to your Secure Email cluster Add one or more proxies to a cluster ◆ Under Available Proxies, locate and drag one or more proxies to a cluster. In the example below, you add epx1 to the Proxy Cluster1 cluster. For adding multiple proxies, you select Add proxies from the Actions drop-down menu: Tip: To reassign a proxy to a different cluster, remove the proxy from the cluster first and then add it to the desired cluster. You can't drag a proxy to another cluster. See “Remove (unlink) a proxy from a cluster” on page 194. 193 Setting up an email proxy for Symantec Mobility: Suite Adding a Secure Email proxy to your Secure Email cluster Remove (unlink) a proxy from a cluster ◆ In the Clusters table, you may click the x beside the name the proxy that you want to remove or select Remove Proxies from the Actions drop-down menu. Confirm that you want to unlink the proxy from the cluster. Unlinked proxies appear in the Available Proxies list. When a proxy is no longer part of a cluster, it no longer processes data and stops accepting connections. Proxies that are removed from a cluster continue to check in with Mobility Manager on the regular basis for updates in case it's added back to a cluster. Tip: You must unlink every proxy from the cluster before you can delete the cluster. Delete an existing cluster ◆ When all proxies are removed from the cluster, in the Clusters table, select the Actions drop-down and click Delete cluster. 194 Setting up an email proxy for Symantec Mobility: Suite Enabling Push email notifications for your iOS Work Mail app Enabling Push email notifications for your iOS Work Mail app Specify the Push Email Settings The Push Email feature provides background email notification for your Symantec's iOS Work Mail application. With push email, you receive a badge notification for incoming email when your Symantec Work Mail application is in the background. This background email notification support for the iOS Symantec Work Mail application is a result of an architectural innovation which involves Mobility Suite, Email Proxy, Symantec's SPOC (Single Point Of Contact) technology, nginx opensource, ActiveSync and Exchange Web Services (EWS) , Apple Push Notification Services (APNS) and your mobile device. Enabling push notifications is done in the following order: 1 Review port requirements. 2 Enable the PushService role on your Secure Email proxy. 3 Configure the Push Email settings. Review port requirements Before you configure your Secure Email proxy to enable for email push notifications for your iOS Work Mail app, ensure that the following port requirements are met: Table 7-6 Push element Port requirement nginx listening port [Inbound] - Port 80 Exchange ActiveSync [Outbound] - Port 443 Exchange Web Services (EWS) [Outbound] - Port 443 Redis [Inbound] - Port 16380 Redis Sentinel [Outbound] - 16381 195 Setting up an email proxy for Symantec Mobility: Suite Enabling Push email notifications for your iOS Work Mail app Table 7-6 (continued) Push element Port requirement Symantec Single Point Of Contact (SPOC) [Outbound] - Port 443 Note: Access to Symantec SPOC from your Mobility Suite instance is a critical connection point in the email proxy architecture: https://spoc-pool-gtm.norton.com is the SPOC host URL. Single Sign On (SSO) [Outbound] - Port 443 Note: Access to SSO from your Mobility Suite instance is another critical connection point in the email proxy architecture. https://login.norton.com is the SSO host URL. Enable the Push Service role on your Secure Email proxy ■ At the completion of the email proxy setup script, you see a message instructing you to configure the push email role: ■ The PushService role is enabled on your email proxy by running the command: /usr/local/nginx/bin/setup.sh --configure pushemail and answering the following prompts: Enable Push Email: Options - y/n Available interfaces for incoming connections from the server running Exchange Web Services (EWS): Options: IP address of the proxy server or manually enter an IP address. Enter incoming port number: options: default port of 8080 or manually enter a port number. ■ You are prompted next to provide interface and port definition the distributed Redis cache. Redis is a memory key value data store that is installed as part of your Symantec email proxy installation and is enabled as a role when you enable the PushService role. The Redis store is used by email proxy to store entity id's and other important key values retrieved for use by email proxy. The distributed Redis cache is designed to be shared by multiple proxy servers. When you have multiple proxies within a cluster, a master proxy is nominated. All key values, subscription detail and proxy filtering criteria for each proxy are written to the distributed Redis cache of the master. These values are then replicated to the 196 Setting up an email proxy for Symantec Mobility: Suite Enabling Push email notifications for your iOS Work Mail app distributed Redis cache instances running on the slave proxies. You must specify Available interfaces for distributed Redis cache incoming connections from proxy server instances: Options: IP address of proxy server or manually enter an IP address Incoming port number for distributed cache: Options: default port number of 16380 or manually enter a port number. Incoming port number for distributed cache Sentinel: Options: default port number of 16381 or manually enter a port number. Below is an example of the entire PushService enablement process. (In the example below, default values are used): Configure Push Email settings After you successfully enable the PushService role, you configure Push Email settings. The graphic below is the push email configuration page you are required to complete to support push email to your Symantec Work Mail application. To access this page, go to Setting > Proxies > Email. Identify the cluster your proxy is associated with. From this row, click the Actions drop-down and select Edit cluster. Scroll to the Push email settings section and choose the Configure radio button: 197 Setting up an email proxy for Symantec Mobility: Suite Enabling Push email notifications for your iOS Work Mail app Configuration requirements for Push Email Settings that correlate to the graphic above are detailed in the table below: Push email for iOS Work Mail clients Available options; Configure, Do Not Configure. When the Configure radio button is selected, the push email configuration page will appear. You are required to provide values for each field to properly enable push email for Work Mail. When the Do Not Configure radio button is selected, the push email configuration page is suppressed. Push email for your Symantec Work Mail application is disabled. 198 Setting up an email proxy for Symantec Mobility: Suite Enabling Push email notifications for your iOS Work Mail app Exchange Web Services The fields in this section are applicable to the server running the Exchange Web Service (EWS). Address Specifies the IP address or FQDN of the server running Exchange Web Services (EWS) that your email proxy connects to. Port Specifies the TCP/IP port that is used to send data between your email proxy and the server running EWS. Version Specifies the version of Microsoft Exchange on the server where EWS is running . The default option is Autodetect. Impersonation Account When your email proxy server communicates with EWS, it does so using an Exchange Impersonation Account. Exchange Impersonation allows your proxy server to impersonate a specific account or multiple accounts. This allows your email proxy server to perform certain functions by using the permissions that are inherent to the impersonated account. Using an account from your proxy server does not provide the proper permissions to support function calls to EWS. To create an exchange impersonation account that impersonates all Users from an organization, run the New-ManagementRoleAssignment cmdlet to add the permission to impersonate to the specified user. You run this cmdlet by accessing the Microsoft Exchange Shell and running the following command: New-ManagementRoleAssignment -Name:impersonationAssignmentName -Role:ApplicationImpersonation -User:<serviceAccount> Please note that the impersonation account must be a user account from your active directory domain. In the example below, an exchange impersonation account called symc_ep1 has been created Domain Specifies domain of the user account used as the impersonation account. Username Specifies username of the impersonation account (symc_ep1 in the example graphic above). Password Password of the impersonation account used. 199 Setting up an email proxy for Symantec Mobility: Suite Enabling Push email notifications for your iOS Work Mail app ReApply The reapply option allows you to reapply the impersonation account defined in the cluster configuration page. This is needed if the impersonation account is correctly specified in the email proxy settings page but does not have sufficient privileges in your MS Exchange server environment. Once the account credentials have been correctly defined in exchange, reapplying the account in the cluster configuration page should result in proper usage of the impersonation account. Callback Server The callback server is the internal facing IP address of your email proxy server. The callback server can also be a load balancer in front of your internal facing proxy server. This is the server that your CAS server will call back to. Address Specifies the IP address or FQDN of your callback server. Port Specifies the port that EWS uses to communicate back to your callback server. Once you have completed all the required (and any optional) settings, click Save. Proxy Server Roles Once you complete the Push Service enablement, you see Push Service appear as a Role in your proxy details page. To access your proxy details page, access Settings > Proxies > Email and click one of the proxies listed in the available clusters table. In the example graphic below. epx1 is listed as the lone proxy server. Click this item to produce the proxy details page for that proxy server: ■ Email Proxy Role - when you install the email proxy server application, it is installed as several roles. Email Proxy represents the entire architecture that supports the proxy of email in your environment. Associated roles are installed when different functionality, within email proxy, are enabled. ■ PushService Role- the PushService role is enabled when you configure an email proxy installation to support push email. When the PushService role is 200 Setting up an email proxy for Symantec Mobility: Suite Enabling Push email notifications for your iOS Work Mail app enabled, you receive push notifications to your Symantec Work Mail application. For more information regarding the Push Service role, See “Creating Secure Email Proxy clusters” on page 187. and refer to step #4 in the create and configure a cluster procedure. ■ DistributedCache Role- The distributed cache role uses Redis as its memory key value data store. The Redis distributed cache role is installed as part of your Symantec email proxy installation and is enabled as a role when you enable the PushService role. The distributed Redis cache is designed to be shared by multiple proxy servers. When you have multiple proxies within a cluster, a master proxy is nominated. All key values, subscription detail and proxy filtering criteria for each proxy are written to the distributed Redis cache of the master. These values are then replicated to the distributed Redis cache instances running on the slave proxies. Scale example The information below details and illustrates several connection focus points for an organization with 15,000 devices using iOS Work Mail with PushService enabled. These connection focus points underscore where to look if you experience functional problems with your email proxy installation with the PushService role enabled. Please see the Email Proxy functional flow and Connection focus points legends for further breakdown of the graphic. The graphic illustrates an email proxy installation based on the following criteria: ■ Each proxy server can service up to 5,000 devices ■ There are 3 spaces illustrated –Internet - Device user, Apple, SPOC) DMZ Proxy servers Intranet - Mobility Suite, CAS servers and Exchange Server which also runs ActiveSync. ■ Two firewalls are installed and logically placed. ■ Mobility Suite is installed on-premises. ■ There are 3 proxy servers to accommodate an organization with 15.000 devices. A load balancer is located in front of the proxy servers. Also illustrated within each email proxy instance is the local and distributed Redis cache. The slave and master distributed Redis cache instances are noted. ■ A load balancer is located in front of the CAS server pool. ■ The push service role is enabled. 201 Setting up an email proxy for Symantec Mobility: Suite Testing Secure Email Proxy Testing Secure Email Proxy Before you create Mobility Manager device policies to use the Secure Email Proxy, you should test it in passive mode first. In passive mode, the proxy allows access to your organization's email. The activity is logged in passive mode, but no device compliance filtering occurs. See “Secure Email Proxy default file locations” on page 229. 202 Setting up an email proxy for Symantec Mobility: Suite Testing Secure Email Proxy Configure the cluster to passive mode 1 Click Settings > Email Proxy. 2 Select the cluster that contains the proxy you want to test, and click Edit. 3 Change the Mode to Passive, make sure the Logging Level is set to Information, and click Save. Passive mode allows all traffic through the proxy to your EAS. The verdict of which connections would have been permitted if the cluster had been in active mode is recorded in the log. The Information logging level contains all of the Warning and Error logging level information plus informational-type messages that might be helpful to know. Create a device policy 1 Create a device policy. See “ Configuring the Work Mail app for use with Secure Email Proxy” on page 205. 2 Make sure that the device policy has the highest precedence. See “Prioritizing device policies” on page 309. Attempt email access ◆ From a mobile device, attempt to access your organization's email. The device that you use to test the policy should ... ■ Belong to a person in the target group to whom you've assigned the device policy ■ Meet the device policy compliance rules, if any ■ Contain the email app that you permit in your device policy ■ Have MDM enabled if required per the device policy ■ Contain the native Work Hub if it's an iOS or Android device. If it's a Windows Phone device, the device should be registered with Mobility Suite. 203 Setting up an email proxy for Symantec Mobility: Suite Testing Secure Email Proxy Check the proxy logs 1 On the proxy server, access the logs in the following location: /usr/local/nginx/logs 2 View the logs to determine if email access would have been permitted. Log file entries in passive mode are prepended with the following: [Passive Mode] Decision in Active Mode will be: Below is an example of what the log files might look like in passive mode: 2014/04/03 14:40:06 [info] 22043#0x00007f872a535700: [EmailProxy] [Passive Mode] Decision in Active Mode will be: Request is blocked: [EAS:Applxxxxxxxxxx] key does not exist in Redis. User: domain\user1; DeviceId: Applxxxxxxxxxx PolicyId: xxxxxxxxx; UserAgent: Apple-iPhone3C1/1102.55400001 domain\user1 2014/04/03 14:40:09 [info] 22043#0x00007f872a535700: [EmailProxy] [Passive Mode] Decision in Active Mode will be: Request is blocked: [EAS:Applxxxxxxxxxx] is BLOCKED. User: domain\user1; DeviceId: Applxxxxxxxxxx PolicyId: xxxxxxxxx; UserAgent: Apple-iPhone3C1/1102.55400001 domain\user1 Allowed requests: 2014/04/03 15:35:43 [info] 43678#0x00007f01fdbd2700: [EmailProxy] [Passive Mode] Decision in Active Mode will be: Request is allowed. User: domain\user1; DeviceId: Applxxxxxxxxx; PolicyId: xxxxxxxx; UserAgent: Apple-iPhone3C1/1102.55400001 domain\user1 Return your cluster settings to production settings 1 In Mobility Manager, click Settings > Email Proxy. 2 Select the cluster that contains the proxy you tested, and click Edit. 3 Change the Mode back to Active, return the Logging Level to Warning, and click Save. Next See “ Configuring the Work Mail app for use with Secure Email Proxy” on page 205. More information Click here for the interactive workflow. See “Introduction to Secure Email Proxy” on page 175. 204 Setting up an email proxy for Symantec Mobility: Suite Configuring the Work Mail app for use with Secure Email Proxy Configuring the Work Mail app for use with Secure Email Proxy To configure your Work Mail app, you define Work Mail Configurations or App Config settings. Warning: In order to support background email push notifications to your iOS Work Mail app, you must configure your iOS Work Mail app using App Config. To configure you native email app, you define Native Email Configurations. You allow your native email or Work Mail apps access via Secure Email Proxy by configuring Access via Email Proxy. Aside from App Config, you configure these options within a Device Policy. Note: There are many configurable elements within a device policy. This section details the device policy elements relevant to configuring your native and Work Mail apps. This section also details device policy elements for configuring your native and Work Mail apps access via Secure Email Proxy. For information regarding all device policy elements, See “Creating device policies” on page 304. 205 Setting up an email proxy for Symantec Mobility: Suite Configuring the Work Mail app for use with Secure Email Proxy General Settings Configure General Settings 1 From your Mobility Manager console, access Device Policy > General Settings. Under the Device Management category, indicate whether device management is required. The iOS and Windows Phone native email apps require device management. The Symantec Work Mail app (Android and iOS) supports device management, but doesn't require it. The example below shows MDM enabled for iOS, Android and Windows devices. 2 Click the Compliance Rule drop-down list and select a rule. Compliance rules are optional. Note: You create Compliance Rules by accessing the Compliance Rules tab from your Mobility Manager console and clicking New. There are several compliance criteria listed. You select any one of the compliance criteria to enable enforcement of that criteria. If the criteria is not met, (default compliancy check is 72 hours) one of two Enforcement options are available. The enforcement option Block Access to Email via Email Proxy can be enabled when a compliance criteria is not met. Once the compliance rule has been created, the compliance rule appears in the Compliance Rule drop-down field within the devoice policy. For more information, See “Blocking email access for non-compliant devices” on page 217. 206 Setting up an email proxy for Symantec Mobility: Suite Configuring the Work Mail app for use with Secure Email Proxy 3 Modify the Update Frequency and Inventory Collection configurations as needed. Email Settings Work Mail configurations, Native Email configurations and Access via Email Proxy are defined in a Device Policy. You create a new device policy or edit an existing device policy. From your Mobility Manager console, access Device Policy > New to create a new device policy. To edit an existing device policy, select a device policy from the middle pane and click the Edit button located at the top right. of the right pane. Scroll to Email Settings. You see the following options: Work Mail Configurations If you are editing an existing device policy, you see the Add option available for Work Mail configuration profiles. Click the Add drop-down to add an existing Work Mail configuration profile. Once you add an existing Work Mail configuration profile, you can click the Edit link to edit the Work Mail configuration profile you added. Note: Profiles available from the add drop-down are existing (previously created) Work Mail configuration settings, within a device policy. To create a new Work Mail configuration setting, click New. The following screen appears: 207 Setting up an email proxy for Symantec Mobility: Suite Configuring the Work Mail app for use with Secure Email Proxy The table below defines the fields shown in the graphic above. Note: The settings shown in the graphic configure your Work Mail app to receive mail from your exchange server. There are additional settings in this policy. For a full listing and definition of all Work Mail settings, See “Work Mail policy settings” on page 446. 208 Setting up an email proxy for Symantec Mobility: Suite Configuring the Work Mail app for use with Secure Email Proxy To create a new configuration 1 Type a Name and Description for this configuration. 2 In the Exchange ActiveSync Host field, type the incoming public host address. The address must be an FQDN and must be accessible from mobile devices. For example: somehost.example.com This host name is the same host name that you specified in the ActiveSync host in Device Policy field when you created a cluster. 3 Specify the Domain. This field is optional. 4 Specify the User. Leave this field blank to prompt the user for the account user name. You can also use a token in the email field to set the field to accept the following input: ■ {userid} Specify the user's user ID to authenticate to Work Mail. A user ID differs from {user} in that it can contain additional delineators, such as a domain. For instance, user/domain. ■ {user} ■ Specify the user's user name to authenticate to Work Mail. {email} Specify the user's email address to authenticate to Work Mail. 5 Specify an account Email Address. You can specify an email address or use a token with a domain. For example: {email} or {user}@domain.com. 6 The Self-signed Certificates checkbox allows the device to get the server certificate from the server. This certificate is used to skip server certificate checks. 7 You can import an Authentication certificate to use for ActiveSync authentication. 8 Configure the remainder of the options as needed. 9 Click Save. Native Email Configurations Native Email configurations are defined in a Device Policy. 209 Setting up an email proxy for Symantec Mobility: Suite Configuring the Work Mail app for use with Secure Email Proxy You create a new device policy or edit an existing device policy. From your Mobility Manager console, access Device Policy > New to create a new device policy. To edit an existing device policy, select a device policy from the middle pane and click the Edit button located at the top right. of the right pane. Scroll to Email Settings and select Native Email Configurations. Select New to create a new native email configuration profile. Select Add to add an existing native email configuration profile. Click New to create a new native email configuration profile. The following screen appears: The table below defines the fields shown in the graphic above. 210 Setting up an email proxy for Symantec Mobility: Suite Configuring the Work Mail app for use with Secure Email Proxy Note: The settings shown in the graphic configure your native email app to receive mail from your exchange server. There are additional settings in this profile. For a full listing and definition of all native email settings, See “Native Email policy settings” on page 440. To create a new configuration 1 Click New. 2 Type a name and description for this configuration. 3 Type the Exchange Server Name that you want to appear as the email location on the device. 4 In the Exchange ActiveSync Host field, type the incoming public host address. The address must be an FQDN and must be accessible from mobile devices. For example: somehost.example.com This host name is the same host name that you specified in the ActiveSync host in Device Policy field when you created a cluster. 5 Specify the Domain. This field is optional. 6 Specify the User. Leave this field blank to prompt the user for the account user name. You can also use a token in the email field to set the field to accept the following input: ■ {userid} Specify the user's user ID to authenticate to Work Mail. A user ID differs from {user} in that it can contain additional delineators, such as a domain. For instance, user/domain. ■ {user} ■ Specify the user's user name to authenticate to Work Mail. {email} Specify the user's email address to authenticate to Work Mail. 7 Specify an account Email Address. You can specify an email address or use a token with a domain. For example: {email} or {user}@domain.com. 8 Configure the remainder of the options as needed. 9 Click Save. 211 Setting up an email proxy for Symantec Mobility: Suite Configuring the Work Mail app for use with Secure Email Proxy Access via Email Proxy Access via Email Proxy profiles define which native email and Work Mail apps have access to email via the Secure Email Proxy. Access via email proxy profiles are defined in a Device Policy. You create a new device policy or edit an existing device policy. From your Mobility Manager console, access Device Policy > New to create a new device policy. To edit an existing device policy, select a device policy from the middle pane and click the Edit button located at the top right of the right pane. Scroll to Email Settings and select Access via Email Proxy. Select New to create an access via email proxy profile. Select Add to add an existing Access via email proxy profile. Click New to create an access via email proxy profile. The following screen appears: 212 Setting up an email proxy for Symantec Mobility: Suite Configuring the Work Mail app for use with Secure Email Proxy The table below defines how to create an Access via Email Proxy profile: 213 Setting up an email proxy for Symantec Mobility: Suite Configuring the Work Mail app for use with Secure Email Proxy To create a new configuration 1 Type a Name and Description for this configuration. 2 Select which email apps you wish to have access to email via the Secure Email Proxy. 3 Click Save. For more information on the Access via Email Proxy profile, See “Access through Email Proxy policy settings” on page 430. Configuring Work Mail using App Config To allow organizational email access using Symantec Work Mail with Microsoft Exchange or O365 mail servers , you create an app configuration instead of a device policy to configure your iOS Work Mail app. Warning: In order to support background email push notifications to your iOS Work Mail app, you must configure your iOS Work Mail app using App Config. You can create this app configuration regardless of whether you route email access through Secure Email Proxy or not. You can create an app configuration for any form of the iOS Work Mail app (native Work Mail app, app store version, Symantec Sealed). Click the following link to learn more about the Symantec Mobility: Suite app configurations feature: https://www.symantec.com/docs/HOWTO94463 Note: App configurations do not require device management. However, when device management is not enabled, you can only apply app configurations to apps that are wrapped and have an app policy that requires user authentication. Symantec recommends that you use the Symantec Sealed version of the Symantec Work Mail app. When you configure the key/value pairs, the keys must match the parameters exactly (i.e., same name and same case). Similarly, the values must match the data type that is required. App configurations support the use of the following tokens as values: {email}, {userid}, {user}, {firstname}, {lastname}, {td_device_id}. You must have add or edit app permissions to define or modify app configurations. Download the Symantec Work Mail .plist file ■ Go to the following URL and save the .plist file attachment in a place that you can access when you create your app configuration in Mobility Manager: https://www.symantec.com/docs/TECH226407 Add a Work Mail app and create an app configuration (The following example illustrates configuration of a Work Mail app with Microsoft O365). 214 Setting up an email proxy for Symantec Mobility: Suite Configuring the Work Mail app for use with Secure Email Proxy 1 Add the Symantec Work Mail app to your app list. 2 In the list of apps on the center pane, select the Symantec Work Mail app you added. On the right pane, click the Config icon (circled in the graphic below). 3 In the Configuration Manager window on the top right , click the New icon. 4 Type a title for this configuration. 5 In the right pane, click Import, browse to and select the .plist file for Work Mail that you downloaded. If the import is successful, the predefined key value pairs appear. If it fails, an error message appears. Resolve the error and try importing the file again. Below is an example of a plist imported with values changed to support a connection to an O365 mail server thru Secure Email Proxy: 215 Setting up an email proxy for Symantec Mobility: Suite Configuring the Work Mail app for use with Secure Email Proxy 6 Modify the values for the first four keys only. Please refer to the example in the graphic above and field definitions the table below. Warning: Do not modify the values for the keys in the red box in preceding screen shot. The configuration parameters are as follows: Key Type Value userid String As shown in the graphic above, enter your userid as your email address. email String Enter your email address. domain String Enter your company domain name. server String Enter the IP address or server name of your Secure Email Proxy. If you have a load balancer residing in front of your Email Proxy, enter that IP address or server name. Warning: Do not modify the remaining values. They must remain as they are when imported. 7 deviceid String SuppressApplicationPIN Number SPOCURI String ApplicationID String ChannelID String Once you define the first 4 values in your app config, click the Save icon. Next, click close. 216 Setting up an email proxy for Symantec Mobility: Suite Blocking email access for non-compliant devices 8 From the Apps screen, highlight your iOS Work Mail app. In the Product Version section, click the Edit icon. As shown in the graphic below, click the Entitlements tab: 9 Define Group or User entitlement for the app. (This defines who can download the iOS Work Mail app to their device) 10 Click the settings icon under Config (circled in the graphic above). Click the drop-down to associate the app config (created in steps 5-7 above) with your iOS Work Mail app. Click Save. Your Work iOS Mail app receives this app config dynamically. Blocking email access for non-compliant devices You can create device policies in Symantec Mobility: Suite that block user access to your organization's email if their device is non-compliant. 217 Setting up an email proxy for Symantec Mobility: Suite Monitoring Secure Email Proxy health Configure the compliance rule 1 Create or edit a compliance rule and specify the rule requirements. See “Creating and managing compliance rules” on page 325. 2 Under Enforcements, check Block access to email and click Save. Apply the compliance rule to a device policy 1 Create or modify a device policy. See “ Configuring the Work Mail app for use with Secure Email Proxy” on page 205. 2 Under General Settings, click the Compliance Rule drop-down menu and select the rule that you created. 3 Click Save. Monitoring Secure Email Proxy health Registered Secure Email Proxies check in with Mobility Manager on a regular basis and report their status. You can monitor your proxy status from Mobility Manager. Proxy health is color-coded as follows: Gray The proxy is registered, but it is not assigned to a cluster. Green Healthy Yellow Warning The proxy hasn't checked in for more than 10 minutes. Red Error The proxy hasn't checked in for more than 30 minutes. This could also mean that the proxy has experienced a failure applying configuration updates or applying policies. Mobility Suite might have also detected the proxy processes are not running. If the email proxy can't communicate with Mobility Manager, a user's ability to access email is based on the last known device policy. Important: Access is allowed during this time even if the device becomes non-compliant. But users who are blocked email access continue to be blocked. After the proxy restarts, users are allowed/blocked access based on the most current device policy. In the Clusters section, click on your proxy to view status and health messages: 218 Setting up an email proxy for Symantec Mobility: Suite Monitoring Secure Email Proxy health Monitor the health of your proxies 1 Click Settings > Email Proxy. 2 In the Available Clusters table or the Available Proxies list, click on the name of the proxy you want to see more information about. Details about that proxy along with all of the other proxies in the cluster appear. This information includes the date and time of the last check-in, the status of the proxy, and any available information about the proxy. 3 For additional information, check the proxy logs. By default, the proxy logs are in the following location: /usr/local/nginx/logs Monitoring Secure Email Proxy usage with telemetry You can use telemetry to monitor Secure Email Proxy usage. For example, you can monitor the number of active connections to your proxy to help you assess when you should deploy another proxy to balance the load. Telemetry also provides data on the number of connection requests that are blocked, allowed, or able to pass directly through to your Exchange ActiveSync Server (EAS). This data is information that you can use for troubleshooting. Telemetry is automatically enabled when you install or upgrade to Secure Email Proxy 5.0. Data is collected approximately every minute. The most recent 10 minutes worth of data is stored in a .json file (with each minute organized into a timebucket) on your proxy server. Every minute, a new timebucket is added to the .json file while the oldest timebucket (created 11 minutes ago) is purged. Telemetry measures the activities of the nginx application and the controller application. The nginx application communicates proxy requests from the device to the Exchange infrastructure. Whereas the controller application communicates with Mobility Manager, providing a link between the proxy and Mobility Manager. Typically, administrators focus on nginx values that they can use to graph connection usage. The following is an example of what a single timebucket in a formatted .json file would look like: 219 Setting up an email proxy for Symantec Mobility: Suite Monitoring Secure Email Proxy health 220 { "timebuckets": [ { "controller" : { "checkin_requests" : 4, "checkin_requests_total" : 69, }, "nginx": { "active_connections": 3, "active_connections_delta:": 0, "ep_requests": 0, "ep_requests_allowed": 0, "ep_requests_allowed_total" : 34, "ep_requests_blocked": 0, "ep_requests_blocked_total" : 0, "ep_requests_error": 0, "ep_requests_error_total" : 0, "ep_requests_ignored": 0, "ep_requests_ignored_total" : 0, "ep_requests_served": 0, "ep_requests_served_total" : 0, "ep_requests_total" : 34, "http_requests": 2, "http_requests_total" : 88, }, "timebucket_id": 23393728 "timebucket_previous_save_time": "Tues, 24 Jun 2014 15:28:00.676 UTC", "timebucket_save_time": "Tue, 24 Jun 2014 15:29:05.677 UTC", "worker_start_time": "Tues, 24 Jun 2014 15:11:49.797 UTC", } ] } Telemetry values are as follows: checkin_requests Number of times the controller checked in with Mobility Suite. checkin_requests_total Number of times the controller checked in with Mobility Suite since the worker_start_time. Setting up an email proxy for Symantec Mobility: Suite Monitoring Secure Email Proxy health active_connections The number of active connections at the moment the data is saved. This number is approximate since connections can become severed. active_connections_delta The number of connections established less the connections terminated. The active_connections_delta value is an internally-used value. We recommend that you refer to active_connections instead. ep_requests The number of requests made to the proxy. ep_requests_allowed The number of requests in which the action was to allow the connection. ep_requests_allowed_total The number of requests measured from the worker_start_time in which the action was to allow the connection. ep_requests_blocked The number of requests in which the action was to block the connection. ep_requests_blocked_total The number of requests measured from the worker_start_time in which the action was to block the connection. ep_requests_error The number of requests in which the proxy detected an error in the request. ep_requests_error_total The number of requests measured from the worker_start_time in which the proxy detected an error in the request. ep_requests_ignored The number of requests in which the proxy allowed the connection to pass through to EAS. ep_requests_ignored_total The number of requests measured from the worker_start_time in which the proxy allowed the connection to pass through to EAS. ep_requests_served The number of requests in which the proxy took an action to handle the request by directly serving up a local resource. ep_requests_served_total The number of requests measured from the worker_start_time in which the proxy took an action to handle the request by directly serving up a local resource. 221 Setting up an email proxy for Symantec Mobility: Suite Upgrading, Uninstalling or Unregistering Secure Email Proxy ep_requests_total The sum total of all requests measured from the worker_start_time. http_requests The number of HTTP requests seen by the proxy. HTTP requests can come from email clients, outside scanners, or other clients requesting malformed requests. http_requests_total Number of HTTP requests seen by the proxy core measured from the worker_start_time. HTTP requests can come from email clients, outside scanners, or other clients requesting malformed requests. timebucket_id The timebucket_id for the nginx and controller applications. This value is a unique value calculated roughly as EPOCH seconds / telemetry_save_every_secs. timebucket_previous_save_time The time the last application timebucket was saved. This is the starting time for data through the timebucket_save_time. timebucket_save_time The timebucket save time for the application measured from the timebucket_previous_save_time (approximately a 1-minute span). worker_start_time The last time the proxy service started/restarted. View telemetry data 1 On the email proxy server, change directories to where the .json file is stored: /usr/local/nginx/telemetry 2 Type the following command: # cat status.json Upgrading, Uninstalling or Unregistering Secure Email Proxy Secure Email Proxy supports upgrades from version 4.4 or later. When you upgrade your email proxy from version 4.4 to version 5.x, the upgrade process does not preserve previous certificates. If you manually installed certificates, you must back them up first, install them through Mobility Manager, and then perform the upgrade. If you did not manually install certificates or installed certificates through Mobility Manager 5.x, you need only perform the upgrade. 222 Setting up an email proxy for Symantec Mobility: Suite Upgrading, Uninstalling or Unregistering Secure Email Proxy Important: Symantec Mobility: Suite supports upgrading Secure Email Proxy on 64-bit CentOS/RHEL 6.4. If you want to upgrade your server to CentOS/RHEL 6.5, do so after you perform the proxy upgrade. Backup email proxy certificates Perform this task if you manually installed certificates on your email proxy server. ◆ Back up any email proxy certificates you manually installed in a previous release. Install your certificates Perform this task if you need to reinstall certificates on your email proxy server or if you want to register new certificates. 1 In Mobility Manager, click Settings > Email Proxy, and edit the cluster that contains the email proxy you upgraded. 2 Under SSL Certificate beside Upload New, click Browse and locate the SSL certificate. Optionally, add a pass phrase. Then click Upload. Note: Certificates must be PKCS#12. For more information, see the section on SSL certificate chains at the following Nginx website. http://nginx.org/en/docs/http/configuring_https_servers.html#chains Upgrade Secure Email Proxy 1 Change directories to the directory that contains the setup.sh script. The default location of the setup.sh script is: /usr/local/nginx/bin 2 Type the following command: # ./setup.sh --upgrade 3 Verify that the service is running by typing the following command: # service nginx status See “Troubleshooting Secure Email Proxy” on page 230. Uninstalling Secure Email Proxy Before you uninstall Secure Email Proxy, you must unregister the proxy from Mobility Manager first. See the section called “Unregistering Secure Email Proxy” on page 227. 223 Setting up an email proxy for Symantec Mobility: Suite Upgrading, Uninstalling or Unregistering Secure Email Proxy If you install the email proxy with the default settings, the uninstall script performs a clean uninstallation of the /usr/local/nginx/bin directory removing Secure Email Proxy and its related files. If you modified the location of installation and log files, all email proxy files may not be removed during uninstallation. In that case, you'll need to locate and manually delete these files when you permanently uninstall the email proxy. A user and group account are created when you initially install Secure Email Proxy. The default user and group account names are both symc-proxy, but you can customize these names. You may want to remove the user and group account names if you permanently uninstall the email proxy. However, make sure that you don't inadvertently remove possible shared accounts. 224 Setting up an email proxy for Symantec Mobility: Suite Upgrading, Uninstalling or Unregistering Secure Email Proxy Run the uninstall script 1 Change directories to the directory that contains the uninstall.sh script. The default location of the uninstall.sh script is: /usr/local/nginx/bin 225 Setting up an email proxy for Symantec Mobility: Suite Upgrading, Uninstalling or Unregistering Secure Email Proxy 2 226 Type the following command: # ./setup.sh --uninstall An example of an uninstall script is as follows: [root@hdloaner-xxxxxx nginx]# cd /usr/local/nginx [root@hdloaner-xxxxxx nginx]# ls -l total 64 drwxr-xr-x. 2 root symc-proxy 4096 Aug 13 10:52 bin drwxrwx---. 2 root symc-proxy 4096 Jul 28 10:15 certs drwxrwx---. 2 symc-proxy symc-proxy 4096 Jul 28 10:15 client_body_temp drwxrwx---. 2 root symc-proxy 4096 Aug 13 10:53 conf drwxr-xr-x. 5 root symc-proxy 4096 Aug 13 10:52 controller drwxrwx---. 2 root symc-proxy 4096 Aug 13 10:52 filters drwxr-xr-x. 2 root symc-proxy 4096 Aug 13 10:52 html drwxr-xr-x. 7 root symc-proxy 4096 Aug 13 10:52 lib drwxrwx---. 2 root symc-proxy 4096 Aug 13 10:53 logs drwx------. 2 symc-proxy root 4096 Aug 13 10:53 proxy_temp -r--r-----. 1 root symc-proxy 35 Jul 15 09:02 README drwxrwx---. 2 root symc-proxy 4096 Aug 13 11:08 Redisdb drwxr-xr-x. 3 root symc-proxy 4096 Aug 13 10:52 res drwxr-xr-x. 2 root symc-proxy 4096 Aug 13 10:52 sbin drwxrwx---. 2 root symc-proxy 4096 Aug 13 10:54 telemetry drwxrwx---. 2 root symc-proxy 4096 Aug 13 10:53 var [root@hdloaner-xxxxxx nginx]# bin/setup.sh --uninstall Preserve any logs (y/n)? [y]: ======== Pre-uninstall ======== Checking for existing services Stopping nginx service Stopping nginx-watchdog: Waiting for nginx-watchdog:. [ [ OK OK ] ] ======== Uninstall RPM ======== Successfully uninstalled 'Email-Proxy-20140728.DEV-101547. UNSUPPORTED.x86_64' ======== Post-uninstall ======== NOTE: If install created a user or group, uninstall did not remove them. Uninstallation is complete [root@hdloaner-xxxxxx nginx]# ls -l Setting up an email proxy for Symantec Mobility: Suite Secure Email Proxy command line tools total 4 drwxrwx---. 2 root symc-proxy 4096 Aug 13 11:14 logs See “Troubleshooting Secure Email Proxy” on page 230. Unregistering Secure Email Proxy When you unregister Secure Email Proxy from Mobility Manager, the following events occur: ■ The proxy no longer communicates with Mobility Manager ■ It stops accepting connections ■ Policy, configuration, and user data is deleted ■ The proxy no longer appears on the Settings > Email Proxy page in Mobility Manager You must remove the proxy from the cluster before you can unregister it. And you must unregister the email proxy before you can uninstall it. See the section called “Uninstalling Secure Email Proxy” on page 223. Remove the proxy from the cluster 1 Click Settings > Email Proxy. 2 In the Available Clusters list, locate the proxy that you want to unregister and click the x beside the name. 3 Confirm that you want to unlink the proxy from the cluster. Unregister the proxy 1 In the Available Proxies list, locate the proxy that you want to unregister and click the x beside the name. 2 Confirm that you want to unregister the proxy. Secure Email Proxy command line tools You can modify Secure Email Proxy through the command line using setup.sh. The proxy automatically restarts when you change its configuration. The default location of setup.sh is as follows: /usr/local/nginx/bin The usage is as follows: ./setup.sh [OPTIONS...] 227 Setting up an email proxy for Symantec Mobility: Suite Secure Email Proxy command line tools Setup.sh options and tools Table 7-7 Options Description --install Installs Secure Email Proxy and its related packages. See “Installing Secure Email Proxy” on page 183. --uninstall Uninstalls Secure Email Proxy. Note: Before uninstalling Secure Email Proxy, ensure that proxy is not part of a cluster, and you have removed the proxy from Mobility Manager. See the section called “Unregistering Secure Email Proxy” on page 227. See the section called “Uninstalling Secure Email Proxy” on page 223. --upgrade Upgrades Secure Email Proxy. If the email proxy is registered with Mobility Manager and part of a cluster, the upgrade process preserves the settings. See “Upgrading, Uninstalling or Unregistering Secure Email Proxy” on page 222. --configure wizard Configuration of various Secure Email Proxy parameters, as follows: Runs the configuration wizard. The configuration wizard guides you through configuring the network parameters as well as registering the proxy with Mobility Manager. network Configures the network parameters for incoming and outgoing connections to Secure Email Proxy. register Registers Secure Email Proxy with Mobility Manager. regcheck Checks whether the proxy is registered with Mobility Manager. dbgetpasswd Retrieves and displays the password for the local proxy database. dbsetpasswd Generates a new random password for the local proxy database. 228 Setting up an email proxy for Symantec Mobility: Suite Secure Email Proxy default file locations Setup.sh options and tools (continued) Table 7-7 Options Description pushemail Configures your email proxy to support push email notifications to your iOS Work Hub application. See “Enabling Push email notifications for your iOS Work Mail app” on page 195. --help Displays the usage and available parameters for setup.sh. --version Displays the version of the proxy software. Secure Email Proxy default file locations Table 7-8 lists the default location for Secure Email Proxy files. Table 7-8 Secure Email Proxy default file locations File Location Default installation directory /usr/local/nginx Command-line scripts /usr/local/nginx/bin Contains the setup.sh script. Installer logs and state information /var/lib/SYMC.inventory Binary executables and libraries /usr/local/nginx/sbin /usr/local/nginx/lib /usr/local/nginx/controller Configuration files /usr/local/nginx/conf /usr/local/nginx/filters /usr/local/nginx/html Use setup.sh to update these files. Internal data files /usr/local/nginx/Redisdb Telemetry files /usr/local/nginx/telemetry State information, lock files, /usr/local/nginx/var named pipes, etc. Security certificates /usr/local/nginx/certs 229 Setting up an email proxy for Symantec Mobility: Suite Troubleshooting Secure Email Proxy Table 7-8 Secure Email Proxy default file locations (continued) File Location Log files /usr/local/nginx/logs The log files contained in this folder are as follows: ■ ■ ■ ■ ■ ■ OS service script error.log Main log file, all severity levels. Includes messages that describe which users/devices are blocked. controller.log : Includes messages that describe communication with Mobility Suite. registration.log Includes messages that describe registration with Mobility Suite. Redis.log Includes messages generated by internal Redis database processes. distributed.redis.log Includes messages that detail write activity to the local distributed cache. distributed.sentinel.log Includes messages that detail write activity between master and slave distributed cache systems. /etc/init.d/nginx Troubleshooting Secure Email Proxy Troubleshooting Secure Email Proxy issues requires knowledge of the available logs. Detailed logs are available for Secure Email Proxy and Symantec Mobility: Suite: ■ Table 7-9 lists relevant Mobility Suite logs to review, as they pertain to troubleshooting Secure Email Proxy. A description of what output is contained in each log is provided. ■ Table 7-10 lists all Secure Email Proxy logs and a description of the output for each log. ■ Table 7-11 lists all Secure Email Proxy error messages with a corresponding condition for each error. The condition provides a focused area of root cause analysis. Using the Mobility Suite and Secure Email Proxy logs in combination with the condition detail accelerates problem resolution. Once you are familiar with the available Mobility Suite and Secure Email Proxy logs and their output, 230 Setting up an email proxy for Symantec Mobility: Suite Troubleshooting Secure Email Proxy you can isolate which logs to review for root cause isolation based on the error condition occurring. Table 7-9 Mobility Suite Log definitions Log Purpose Relevant Mobility Suite logs for troubleshooting Secure Email proxy - located at /var/log/nukona appstore.log Useful for general device and server activity. Condition examples include; device on-boarding to Mobility Suite tenant, device connectivity top app store, device application downloads, Mobility Suite license adds, Mobility Manager console access, any Mobility Suite configuration page errors. celery.log Celery is a Mobility Suite task management function. Review this log for any error with Mobility Suite tasks. Table 7-10 Secure Email Proxy log definitions Log Purpose All Secure Email proxy logs - located at /usr/local/nginx/logs error.log Captures activity of the nginx service as well as telemetry. controller.log Captures activity of Secure Email Proxy controller based modules. Secure Email Proxy controller based modules include EWS Client, EWS subscription, Telemetry and Inventory. redis.log Captures connection and operation activity of the local Redis cache instance. distributed.redis.log Captures connection and operation activity of the distributed Redis cache instance. The activity is specific to the local Secure Email Proxy writing to the distributed cache instance. 231 Setting up an email proxy for Symantec Mobility: Suite Troubleshooting Secure Email Proxy Table 7-10 Secure Email Proxy log definitions (continued) Log Purpose distributed.sentinel.log Captures connection and operation activity of the distributed Redis cache instance where data is distributed between master and slave distributed cache instances. registration.log Captures the secure email proxy registration to the specified Mobility Suite tenant. Table 7-11 Secure Email Proxy error messages Actual Error or Warning Message Condition The proxy processes are not running. The number of processes running is 0. Verify that nginx is running or restart nginx. (service nginx restart) The proxy is running fewer processes than have been configured in nginx.conf. The number of processes running is less than the number of processes configured to run. The proxy is running more processes than have been configured in nginx.conf. The number of processes running is more than the number of processes configured to run. Unable to detect the number of running processes. There was an error determining the expected number of processes. There was an exception determining the number of processes running. An exception was caught while trying to An unknown exception occurred while trying determine status. Please review controller.log to get status for nginx processes. for more detail. The watchdog process is not running. The pid file for watchdog does not exist, or the PID could not be find in the proc FS. The log control process is not running. The pid file for log control does not exist, or the PID could not be find in the proc FS. Error getting local distributed cache status. Please review distributed.redis.log and controller.log. Cannot get the handlers to attempt to ping to the local distributed cache instance. Error connecting to local redis instance. Please review redis.log and controller.log. No response to a ping to the local redis instance. 232 Setting up an email proxy for Symantec Mobility: Suite Troubleshooting Secure Email Proxy Table 7-11 Secure Email Proxy error messages (continued) Actual Error or Warning Message Condition Error connecting to local distributed cache. Please review distributed.redis.log and controller.log. Tried to ping the local distributed cache instance but got no response. Error getting list of distributed cache slaves. An exception occurred when asking the local Please review distributed.sentinel.log and sentinel for the list of distributed cache slaves. controller.log. Error connecting to %d remote distributed Can't ping to any of the remote distributed cache slaves. Please review controller.log to cache slaves. see which IP addresses are not responding. Error connecting to %d remote distributed Able to ping at least one, but not all, cache slaves. Please review controller.log to distributed cache slaves. see which IP addresses are not responding. Error getting local sentinel status. Please review distributed.sentinel.log and controller.log. Can't read file configuration needed to ping the proxy's local sentinel. Error connecting to local sentinel. Please review distributed.sentinel.log and controller.log. Tried to ping the local sentinel but received no response. Error connecting to master redis instance. Please review distributed.sentinel.log and controller.log. Tried to ping the master, but received no response. Error connecting to %d remote sentinels. Can't ping any of the remote sentinel Please review distributed.sentinel.log and instances. controller.log to see which IP addresses are not responding. Error connecting to %d remote sentinels. Can ping at least one remote sentinel Please review distributed.sentinel.log and instance, but not all. controller.log to see which IP addresses are not responding. Local sentinel's master is mismatched with remote sentinel. Please review distributed.sentinel.log and controller.log. A remote sentinel disagrees with the local proxy on the IP address or port for the master instance. Error posting inventory data. Please review appstore.log and controller.log. Error submitting data to Mobility manager. Example: MM fails to process Inventory request. 233 Setting up an email proxy for Symantec Mobility: Suite Troubleshooting Secure Email Proxy Table 7-11 Secure Email Proxy error messages (continued) Actual Error or Warning Message Condition Unexpected error posting inventory data. Unexpected error type. Please review appstore.log and controller.log. "Could not determine Microsoft Exchange Autodetect failed to determine MS Exchange server version. Ensure that Microsoft version. Exchange Server is configured correctly, and that your Exchange Web Services impersonation account settings are correct." Failed to start push filter listener or push service data scanner. Unable to start push filter listener or push service data scanner thread. "Current authentication credentials for the Exchange Web Services impersonation account are incorrect." Current EWS authentication credentials are incorrect. "Could not authenticate with Exchange Web Could not authenticate with exchange web Services. Please ensure that your Exchange services. Please check that exchange web Web Services credentials are correct." services credentials are correct. "Exchange Web Services impersonation account does not have impersonation privileges." EWS user does not have impersonation privileges. Incorrect Microsoft Exchange Server version. EWS is not compatible with exchange Ensure that you have set correct exchange version. Please make sure you have set version in Mobility Manager, or use correct exchange version or use autodetect. autodetect. "Max Subscriptions has been exceeded for EWS Max Subscriptions has been exceeded your Exchange Web Services impersonation for your account. account." "Exception creating PushClientModule context pool. Please review error.log." Unexpected error. "Exception publishing Push Client module callback endpoint. Please review error.log and controller.log". Unable to create an HTTP server for listening EWS callbacks. Example: port number < 1024 while running Controller as non-privileged user "The cluster has not received an Exchange Web Service callback within the last %d minute(s)" There are devices in distributed cache that should be subscribed for notifications. However, we do not see EWS callbacks coming to any proxy in the cluster in last N (30 minutes by default). 234 Setting up an email proxy for Symantec Mobility: Suite Troubleshooting Secure Email Proxy Table 7-11 Secure Email Proxy error messages (continued) Actual Error or Warning Message Condition Push Client module did not receive EWS callbacks in last %d minute(s) There are devices in distributed cache that should be subscribed for notifications. We see callbacks coming to some proxies in the cluster. However, we do not see EWS callbacks coming to _this_ proxy in last N (30 minutes by default) "Unrecognized activity returned from Push Client module activity assessment routine." Unexpected return from Activity assessment routine. Notification module unable to initialize Redis Notification module unable to initialize Redis infrastructure. infrastructure. "Could not create SSO client." Could not create SSO client: " + e.getMessage(). SPOC notifications will be delayed to limit SSO request rate. SPOC notifications will be delayed to limit SSO request rate. Persistent failure to send notifications to SPOC. Persistent failure to send notifications to SPOC. "There was an error while trying to update device information on the Proxy. Please review controller.log." Updating redis was not successful or threw an exception. "An unknown error occurred while trying to apply configuration. Please review controller.log." An exception occurred in config module. Troubleshooting blocked organization email access Table 7-12 provides some suggestions for how to troubleshoot blocked organization email access. Table 7-12 Troubleshooting tips Suggestion More information Check the Secure Email Proxy log. Verify that the user connects to the proxy and is blocked by the proxy. See “Secure Email Proxy default file locations” on page 229. 235 Setting up an email proxy for Symantec Mobility: Suite Troubleshooting Secure Email Proxy Table 7-12 Troubleshooting tips (continued) Suggestion More information In Mobility Manager, click Reasons cited on the Details page are as follows: Devices [Device] > ■ Missing device policy Details to see a No device policy has been applied to the device. description as to why the ■ Failed compliance check email is blocked. The device is not in compliance with the device policy compliance rule or the policy is missing Access via Email Proxy configuration. ■ Missing user The user is not a provisioned user in the device policy. ■ Missing email access control settings Access via Email Proxy configuration has not been configured for the device policy. ■ No EAS ID MDM is not installed or not functioning correctly on the device. ■ Blocked by device policy The Access via Email Proxy configuration does not allow access for the email app the user is using. Click Settings > Email Proxy and verify that the proxy is checking in with Mobility Manager. If the email proxy can't communicate with Mobility Manager, the user's ability to access email is based on the last known device policy. Email access is allowed during this time even if the device becomes non-compliant. But users who are blocked email access continue to be blocked. After the proxy restarts, users are allowed/blocked access based on the most current device policy. See “Monitoring Secure Email Proxy health” on page 218. Update the user's device information using the Fetch Policy command. Updating the user's device ensures that the user has the most recent device policy. Verify that the user has the correct device policy. Click Device Policy > [Policy] to verify if the user is a provisioned user for that policy. See “Commands that can be sent to mobile devices” on page 450. 236 Chapter 8 Setting up Symantec Secure Email This chapter includes the following topics: ■ Setting up Symantec Work Mail in Symantec Mobility: Suite ■ Creating a device policy for Symantec Work Mail ■ Viewing reports about devices running Symantec Work Mail ■ Creating Symantec Work Mail app configurations Setting up Symantec Work Mail in Symantec Mobility: Suite Symantec Work Mail is a free Exchange ActiveSync (EAS) mobile email client for iOS and Android that integrates with Symantec Mobility: Suite. Work Mail lets your organization control who can access email and on which devices. It also gives you a way to block email access and remove data from the devices without wiping the entire device. Mobility Suite supports using mobile device management (MDM) with Work Mail, but doesn't require it. You can use Work Mail with Symantec Secure Email Proxy, but the Secure Email Proxy isn't required. If you want to use the Email Proxy, set up the proxy first. Setting up Symantec Secure Email Creating a device policy for Symantec Work Mail Setting us Symantec Work Mail in Mobility Suite 1 (Optional) Setup Secure Email Proxy. See “Introduction to Secure Email Proxy” on page 175. 2 Add the Work Mail Sealed app to your list of apps. See “Adding a Symantec Sealed app to Symantec Mobility: Suite” on page 342. 3 Based on the device operating system on which Work Mail will run, do either of the following: ■ iOS Configure the Work Mail app configuration. See “Creating Symantec Work Mail app configurations” on page 241. ■ Android Create a device policy for Work Mail. See “Creating a device policy for Symantec Work Mail” on page 238. More information See “Licensing Symantec Mobility: Suite” on page 32. If you want to restrict EAS access, you can configure F5 network controls to filter everything except the traffic that comes from Work Mail. For more information, go to the following URL: http://www.symantec.com/docs/TECH204320 Creating a device policy for Symantec Work Mail Symantec Mobility: Suite supports using Symantec Work Mail on Android devices. But you must configure a device policy that lets users access your organizational email. Note: If users access organizational email using Work Mail on iOS devices, create a Work Mail app configuration in the app policy instead of configuring a device policy. See “Creating Symantec Work Mail app configurations” on page 241. This topic assumes that you use Work Mail without Symantec Secure Email Proxy. Click the following link to learn more if you use Secure Email Proxy with Work Mail. See “ Configuring the Work Mail app for use with Secure Email Proxy” on page 205. 238 Setting up Symantec Secure Email Creating a device policy for Symantec Work Mail Create a device policy for Symantec Work Mail 1 Click Policies and rules > Device Policy > New Policy and specify a name and description for your policy. 2 Under Targeted Devices, specify the groups and device ownership (personal or corporate) for whom this policy applies. 3 Under General Settings in the Device Management category, enable device management if needed. The Work Mail app supports device management, but doesn't require it. 4 Optionally, click the Compliance Rule drop-down list and select a rule. See “Blocking email access for non-compliant devices” on page 217. 5 Modify the Update Frequency and Inventory Collection configurations as needed. 6 Configure Threat Protection Settings as desired. See “Threat Protection settings for device policies” on page 322. 7 Under Email Settings beside Work Mail Configurations, do one of the following: To use an existing profile Click Add and select an existing profile. See “Work Mail policy settings” on page 446. 239 Setting up Symantec Secure Email Creating a device policy for Symantec Work Mail To create a new profile 1 Click New. 2 Type a name and description for this profile. 3 In the Exchange ActiveSync Host field, type the host name or IP address of your EAS server. For example: services-mdm.acme.com 4 Optionally, specify the Domain. For example: acme 5 Specify the User. Leave this field blank to prompt the user for the account user name. You can also use a token in the email field to set the field to accept the following input: ■ {userid} Specify the user's user ID to authenticate to Work Mail. A user ID differs from {user} in that it can contain additional delineators, such as a domain. For instance, user/domain. ■ {user} ■ Specify the user's user name to authenticate to Work Mail. {email} Specify the user's email address to authenticate to Work Mail. 6 Specify an account Email Address. You can specify an email address or use a token with a domain. For example: {email} or {user}@domain.com. 7 Optionally, configure the remainder of the options as needed. See “Work Mail policy settings” on page 446. 8 8 Click Save. Configure any of the other device policy options you require. See “Creating device policies” on page 304. 9 Click Save. More information See “Introduction to Secure Email Proxy” on page 175. 240 Setting up Symantec Secure Email Viewing reports about devices running Symantec Work Mail Viewing reports about devices running Symantec Work Mail Symantec Mobility: Suite lets you view the status of provisioned devices that are running Symantec Work Mail. Green rows indicate the devices that are compliant with your Work Mail settings policy; red rows indicate the non-compliant devices. The Work Mail Status report shows the following details: ■ Whether Work Mail is installed ■ The last update to the Work Mail status for the device ■ Whether the device is Work Mail compliant ■ The type of device (iOS or Android) ■ The email address, user name, and the first and last name of the person who is associated with the device To view reports about devices running Work Mail 1 In the Mobility Manager on the left pane, click Reports. 2 On the Reports page, click the Reports drop-down menu and select Work Mail Status. 3 Select the group or groups to which this report applies. 4 Do either of the following: Click Create Report. The details appear at the bottom of the Reports page. Click Download CSV. Downloads the report into a comma-separated values file. More information See “Setting up Symantec Work Mail in Symantec Mobility: Suite” on page 237. Creating Symantec Work Mail app configurations To allow organizational email access using Symantec Work Mail on iOS devices, you must create an app configuration instead of a device policy. You create this app configuration regardless of whether you route email access through Secure Email Proxy or not. You can create an app configuration for any form of the Work Mail app (native app, app store version, Symantec Sealed). Click the following link to learn more about the Symantec Mobility: Suite app configurations feature. 241 Setting up Symantec Secure Email Creating Symantec Work Mail app configurations See “About defining and managing app configurations in Symantec Mobility: Suite” on page 366. Note: App configurations do not require device management. However, when device management is not enabled, you can only apply app configurations to apps that are wrapped and have an app policy that requires user authentication. Symantec recommends that you use the Symantec Sealed version of the Symantec Work Mail app. When you configure the key/value pairs, the keys must match the parameters exactly (i.e., same name and same case). Similarly, the values must match the data type that is required. App configurations support the use of the following tokens as values: {email}, {userid}, {user}, {firstname}, {lastname}, {td_device_id}. You must have add or edit app permissions to define or modify app configurations. See “Assigning roles” on page 64. Download the Symantec Work Mail .plist file ◆ Go to the following URL and save the .plist file attachment in a place that you can access when you create your app configuration in Mobility Manager: http://www.symantec.com/docs/TECH226407 Add a Work Mail app and create an app configuration 1 Add the Symantec Work Mail app to your app list. See “Adding apps to Symantec Mobility: Suite” on page 331. 2 In the list of apps on the center pane, select the Symantec Work Mail app you added. On the right pane, click the Configurations icon. 3 At the top of the Configuration manager, click New. 4 On the left, type a title for this configuration. 5 In the right pane, click the Import icon (up arrow), browse to and select the .plist file for Work Mail that you downloaded. If the import is successful, the predefined key value pairs appear. If it fails, an error message appears. Resolve the error and try importing the file again. 242 Setting up Symantec Secure Email Creating Symantec Work Mail app configurations 6 Modify the values for the first four keys only. Warning: Do not modify the values for the keys in the red box in preceding screen shot. The configuration parameters are as follows: 7 Key Type Value userid String Default value is the {user} token. But you can modify this value to use any of the supported tokens as appropriate. email String Default value is the {email} token. But you can modify this value to use any of the supported tokens as appropriate. domain String Type your company domain name. server String Type your company server name. deviceid String SuppressApplicationPIN Number Warning: Do not modify these values. They must remain as they are when imported. SPOCURI String ApplicationID String ChannelID String Add any additional key/value pairs as needed. Go to the following Knowledge base article for a document that provides the key/value pairs for Work Mail. http://www.symantec.com/docs/TECH226407 8 Click Close. 9 Make any other modifications to the app as desired, such as applying a policy to the app and assigning it to a user group. See “Creating and managing app policies” on page 346. 243 Chapter 9 Setting up the Apple Volume Purchase Program (VPP) This chapter includes the following topics: ■ About using the Apple Volume Purchase Program - Managed Distribution (VPP) with Symantec Mobility: Suite ■ Setting up Apple Volume Purchase Program - Managed Distribution (VPP) ■ Enabling app license management ■ Configuring VPP settings in Symantec Mobility: Suite ■ Monitoring VPP license usage ■ Reclaiming VPP licenses About using the Apple Volume Purchase Program Managed Distribution (VPP) with Symantec Mobility: Suite Apple uses redemption codes and VPP licenses for volume purchased apps. Since you can't convert redemption codes into VPP licenses, Symantec Mobility: Suite supports both. Mobility Suite applies the available redemption codes to an app first. If no redemption codes exist or are available, it then applies available VPP licenses to the app. Setting up the Apple Volume Purchase Program (VPP) Setting up Apple Volume Purchase Program - Managed Distribution (VPP) Note: Mobility Suite does not support VPP for iBooks. VPP lets you ... ■ Distribute VPP licenses to users for iOS store pointer apps ■ Manage and control VPP apps You can manage VPP apps by monitoring the number of remaining licenses and by reclaiming licenses. VPP can be used even if MDM is disabled. However, Mobility Suite must install the app using MDM to manage the app. Mobility Suite's MDM can manage the VPP app only if it's installed in one of the following ways: ■ MDM pushes the VPP app to the end user's device as a required app and the end user installs it. ■ The end user accesses the VPP app from the Work Hub or End-User Portal. After you enroll in Apple's VPP, you can download a service token file from your Apple account. Mobility Suite uses the service token file to establish connection with Apple's VPP program and download VPP information for purchased apps. VPP is only available in certain regions. Make sure that your organization qualifies. http://www.apple.com/business/vpp/ Get started See “Setting up Apple Volume Purchase Program - Managed Distribution (VPP)” on page 245. More information See “Adding a VPP app to Symantec Mobility: Suite” on page 343. Setting up Apple Volume Purchase Program Managed Distribution (VPP) Follow this workflow to set up VPP licensing in Symantec Mobility: Suite. 245 Setting up the Apple Volume Purchase Program (VPP) Setting up Apple Volume Purchase Program - Managed Distribution (VPP) VPP license setup Table 9-1 Phase Task Description 1 Enroll your organization in Apple's VPP is only available in certain regions. Make VPP sure that your organization qualifies. http://www.apple.com/business/vpp/ 2 Download the service token file from Apple After you enroll in Apple's VPP, you can download a service token file from your Apple account. Mobility Suite uses the service token file to establish connection with Apple's VPP program and download VPP information for purchased apps. http://www.symantec.com/docs/TECH212245 3 Configure VPP in Mobility Suite You must enable VPP in Mobility Suite and specify VPP license configuration options. License configurations include such options as automatically adding VPP apps when they become available and sending email notifications when the VPP licenses usage reaches the threshold that you specify. See “Configuring VPP settings in Symantec Mobility: Suite” on page 248. 4 optional Add VPP apps to Mobility Suite Perform this task if you did not configure Mobility Suite to automatically add VPP apps when they become available in the previous phase. See “Adding a VPP app to Symantec Mobility: Suite” on page 343. 5 Enable app license management VPP apps must first be added to Mobility Suite, then you edit the app to enable app license management. See “Enabling app license management” on page 247. The following additional tasks are optional and can be done when and as needed. 246 Setting up the Apple Volume Purchase Program (VPP) Enabling app license management Table 9-2 Additional, optional VPP setup tasks Task Description Enable license notification Configure this option to receive notifications when app license usage or app downloads reaches the threshold that you specify when you configure your VPP license configuration options. See “Setting up notifications” on page 54. Customize the VPP enrollment email invitation You can send end-users invitation emails to join VPP. This enrollment is a one-time process. You can use the default message or customize your own. See “Customizing user invitation emails” on page 284. Monitor VPP license usage You can monitor how many VPP licenses are used and how many are still available. See “Monitoring VPP license usage” on page 250. Reclaim VPP licenses Reclaim VPP licenses from users who no longer use or need the VPP app or have left your organization. See “Reclaiming VPP licenses” on page 251. More information See “About using the Apple Volume Purchase Program - Managed Distribution (VPP) with Symantec Mobility: Suite” on page 244. Enabling app license management After Apple Volume Purchase Program - Managed Distribution (VPP) apps are added to your Symantec Mobility: Suite, enable app license management for the apps that use VPP. Also enable app license management for any apps that users can download even if the number of downloads or app licenses has exceeded its limit. Tip: You can only enable app license management on existing apps — not when an app is initially added. See “Adding a VPP app to Symantec Mobility: Suite” on page 343. 247 Setting up the Apple Volume Purchase Program (VPP) Configuring VPP settings in Symantec Mobility: Suite Enable app license management 1 Click Apps, select the app for which you want to enable app license management, and in the upper right pane, click the Edit icon. 2 Beside Inventory, check Enable license management. 3 Optionally, beside Import Apple Redemption Codes, click Browse to locate and select the redemption code file. 4 Click Save. More information See “About using the Apple Volume Purchase Program - Managed Distribution (VPP) with Symantec Mobility: Suite” on page 244. See “Setting up Apple Volume Purchase Program - Managed Distribution (VPP)” on page 245. See “Configuring VPP settings in Symantec Mobility: Suite” on page 248. Configuring VPP settings in Symantec Mobility: Suite After you enroll your organization in the Apple Volume Purchase Program - Managed Distribution (VPP) and download your service token, set up VPP in Symantec Mobility: Suite. You register a new or replacement service token the same way. License Configuration settings apply to the most recent token registered. Enable VPP 1 Click Settings > App License Management. 2 Click Upload Token and browse to and select the token file you downloaded from Apple. 3 Check Enable Volume Purchase Program - Managed Distribution. The Enable Volume Purchase Program - Managed Distribution option is inactive until you upload a service token file. 248 Setting up the Apple Volume Purchase Program (VPP) Configuring VPP settings in Symantec Mobility: Suite Apply license configurations 1 Under License Configuration, check Automatically reclaim licenses when apps are uninstalled to reclaim associated VPP licenses when users uninstall the app from all of their respective devices. See “Reclaiming VPP licenses” on page 251. 2 Check Notify Publishers when license usage reaches [n] % of total to have email notifications sent when license usage reaches the threshold that you specify. Important: If you enable this option, you must also enable license notification. See “Setting up notifications” on page 54. 3 Check Allow users to personally purchase apps to permit end users to personally purchase and install apps directly from the App Store when no more licenses or downloads are available. If no more licenses are available for the app through Mobility Suite, users are permitted to personally purchase their own license. Even if additional licenses for that app are purchased or reclaimed, those licenses are not applied to that user's app. The new or reclaimed licenses are reserved for future use. Important: For more information about the implications of letting users purchase apps, see the following knowledge base article. http://www.symantec.com/docs/TECH212175 4 Check Automatically add licensed VPP Apps to automatically add VPP apps to your Mobility Manager as they become available, and then scroll up the page and beside VPP Sync, click Sync Now. You must click Sync Now after you enable this option for VPP licenses to automatically be loaded into your Mobility Manager. If you upload a new service token, click Sync Now to have those related VPP apps automatically added to your Mobility Manager. Mobility Suite sends an email notification to the administrator when a VPP app is automatically added. But you'll still need to assign the app to a user group, assign an app policy, and publish the app to make it available. 5 At the top of the right pane, click Save. Next See “Adding a VPP app to Symantec Mobility: Suite” on page 343. 249 Setting up the Apple Volume Purchase Program (VPP) Monitoring VPP license usage More information See “About using the Apple Volume Purchase Program - Managed Distribution (VPP) with Symantec Mobility: Suite” on page 244. See “Setting up Apple Volume Purchase Program - Managed Distribution (VPP)” on page 245. See the Symantec Sealed Program Developer's Guide. Monitoring VPP license usage You can monitor the total number of Apple Volume Purchase Program - Managed Distribution (VPP) licenses that are available and the number of licenses remaining from the Mobility Manager. Colored indicators visually show you the state of your licenses or downloads: Red No more licenses or downloads are available. Yellow The threshold for licenses or downloads specified on the Settings > App License Management page has been reached (by default, 80%). Green Ample licenses or downloads remain (i.e., licenses or downloads have not reached the specified threshold). VPP information automatically synchronizes every hour (this schedule is not configurable). If you purchase new licenses and don't want to wait for the synchronization process, perform a manual synchronization. Manually synchronize VPP information 1 In Mobility Manager, click Settings > App License Management. 2 Click Sync Now. Monitor VPP license usage from the Apps page 1 On the Mobility Manager left pane, click Apps. 2 In the Apps list, select the app whose license usage you want to check. App usage and availability appears on the right pane beside License. The Manage App Licenses button that appears beside license usage for store pointer apps directs you to the Manage App Licenses report. Tip: This button doesn't appear for non-store pointer apps since they don't employ app licensing. 250 Setting up the Apple Volume Purchase Program (VPP) Reclaiming VPP licenses View the Manage App License report 1 On the left pane, click Reports. 2 In the Report drop-down menu, select Manage App Licenses. 3 Specify any other report filter criteria, and click Create Report. More information See “About using the Apple Volume Purchase Program - Managed Distribution (VPP) with Symantec Mobility: Suite” on page 244. See “Enabling app license management” on page 247. See “Running reports in Symantec Mobility: Suite” on page 398. Reclaiming VPP licenses Symantec Mobility: Suite lets you reclaim Apple Volume Purchase Program Managed Distribution (VPP) licenses automatically or as needed. You must have the Reclaim App licenses role to manually reclaim VPP licenses. You can reclaim licenses regardless of whether the app is managed by MDM. You can reclaim VPP licenses through the Mobility Manager on any of the following pages: Mobility Manager page Description Settings > App License Management You can configure Mobility Suite to automatically reclaim the VPP license when the user removes the app from all of the user's devices. See “Configuring VPP settings in Symantec Mobility: Suite” on page 248. Apps > [App] You can reclaim VPP licenses from the Apps > [App] page in any of the following ways: ■ ■ If an app has had any VPP licenses associated with it, the Manage App Licenses option appears. Click this option to be directed to the Manage App Licenses report. You can select a specific license from within the report and reclaim it. When you delete a store pointer app that has VPP licenses associated with it, the administrator has the option to reclaim all of the existing licenses. Note: You cannot reclaim redemption codes. See “Adding apps to Symantec Mobility: Suite” on page 331. 251 Setting up the Apple Volume Purchase Program (VPP) Reclaiming VPP licenses Mobility Manager page Description Reports > Manage App Licenses report You can generate a Manage App Licenses report, which lists the apps that use VPP licenses based on app or user. You can also select a specific license from within the report and reclaim it. Redemption codes do not appear in the Manage App License report, but they do appear in App Inventory History report. See “Running reports in Symantec Mobility: Suite” on page 398. If you want to reclaim licenses from the Manage App Licenses report, you will also need the View the reports area role. More information See “About using the Apple Volume Purchase Program - Managed Distribution (VPP) with Symantec Mobility: Suite” on page 244. See “Assigning roles” on page 64. 252 Chapter 10 Setting up Windows Phone 8.1 This chapter includes the following topics: ■ Support for Windows Phone 8.1 in Symantec Mobility: Suite ■ Windows Phone 8.1 setup procedures ■ Enrolling a Windows Phone device ■ After device enrollment Support for Windows Phone 8.1 in Symantec Mobility: Suite Symantec Mobility Suite provides mobile device management (MDM) support of Windows phones running Windows 8.1 Phone. Note: Symantec Mobility: Suite does not currently support application and content management for Windows Phone 8.1. Mobility Suite leverages the Windows mobile device management (MDM) client to facilitate a smooth device enrollment process. The Mobility Manager administrator and the Windows Phone user must complete specific steps to ensure successful device enrollment. This chapter details the required responsibilities of the administrator and the user. Setting up Windows Phone 8.1 Windows Phone 8.1 setup procedures Note: Mobility Suite supports Windows 8.1 Phone exclusively. Windows Phone 7.x and Windows Phone 8.0 are not supported. In addition, Windows Tablets (such as Surface and Surface Pro running 8.1) are not supported. Windows Phone 8.1 setup procedures Symantec Mobility: Suite provides mobile device management (MDM) support of Windows phones running Windows 8.1. To enable support for Windows 8.1, execute these procedures: ■ Configuring a device policy ■ Creating a required DNS entry and configuring email domain mapping ■ Configuring device ownership prompt and text of MDM license page ■ Specify branding of the device enrollment screen ■ Providing enrollment instructions to the user Configuring a device policy A device policy must be active with MDM enabled for Windows Phone devices. MDM is supported on Windows Phones and allows a user to successfully enroll a Windows 8.1 Phone with Symantec Mobility: Suite. Each device policy also includes a Targeted devices definition which defines the group that is associated with that device policy. To create a new device policy or access an existing device policy, click Policies and Rules and click the New/Edit icon located at the top right. 254 Setting up Windows Phone 8.1 Windows Phone 8.1 setup procedures Note: The user must be a member of a group that is defined in the target definition of the device policy. Enrollment of the user's Windows 8.1 Phone to Mobility Suite is then allowed. (The user enrollment process is detailed in the section See “Enrolling a Windows Phone device” on page 266.) Within a device policy, there is multiple Profiles. Profiles exist for Work Mail, Password restrictions, Device restrictions, and VPN configuration to name a few such device profiles. Additionally, Inventory collection is different based on the device operating system. Below are the available inventory and device profile options: 255 Setting up Windows Phone 8.1 Windows Phone 8.1 setup procedures Each one of these device profiles and inventory collection settings may not be available on all mobile platforms. To help you plan device profile and policy implementation, please refer to Table 10-1. This details the full scope of device profiles available by mobile platform. This table defines what an administrator can configure, with respect to device management, based on the specific mobile platform of your users' devices: Table 10-1 Device Policy Settings Table Device Policy Profile iOS Inventory Android Samsung KNOX Windows Phone 256 Setting up Windows Phone 8.1 Windows Phone 8.1 setup procedures Table 10-1 Device Policy Settings Table (continued) Device Policy Profile iOS Collect Commercial App information Collect and display device location Collect and display personal identification information Email Work Mail configuration Native Email configuration Email Access control Access via Email Proxy Device Password Restrictions Wi-Fi Configuration Device Restrictions VPN Configuration SSO Configuration Resources Android Samsung KNOX Windows Phone 257 Setting up Windows Phone 8.1 Windows Phone 8.1 setup procedures Table 10-1 Device Policy Settings Table (continued) Device Policy Profile iOS Android Samsung KNOX Windows Phone Compliancy Rules Jailbroken or Rooted device Norton Mobile Security client installed MDM compliancy status Enforcement if compliancy rule not met Block access to email Block access to wrapped apps Windows Push Notification Service requirements (WNS) In order for Mobility Suite to send device policy updates to Windows 8.1 Phone devices, Windows Push Notification Service (WNS) must be configured with Mobility Suite. Mobility Suite communicates to Windows Push Notification Service (WNS) device policy changes to your Windows 8.1 Phone devices. WNS then communicates the device policy update to the Windows Notification Platform on your Windows Phone. The device policy is actuated. The Windows push credentials for the SaaS instances of Mobility Suite tenants have been registered. There is no action for the administrator to configure Windows Push Notification Services (WNS) with a SaaS based Mobility Suite tenant. If you are an administrator for an on-premises Mobility Suite tenant, you need to register for Windows push credentials for your Windows 8.1 Phone users to dynamically receive updates to device policies. If you do not register for Windows Push credentials, your Windows 8.1 Phone users will receive updates to device policies on a defined interval instead of dynamically. The interval values adhere to the following schedule and start at device enrollment: ■ Every 2 minutes with eight retries. ■ Then every 15 minutes with 8 retries. 258 Setting up Windows Phone 8.1 Windows Phone 8.1 setup procedures ■ Every 60 minutes thereafter The process below details the steps required to configure Windows Push Notification Services (WNS) with Mobility Suite for on-premises installations. Pre-requisites ■ Windows developer account - You must register with the Windows Phone Dev Center to obtain an account and gain access to the Windows Phone Dev Center. (When you register with Windows Phone Dev Center, you are also registered with the Windows Dev Center.) Access to the Windows Phone Dev Center is needed to create a 'dummy' Windows phone app which provide you with key elements needed for Windows Push Notification Services registration. To register for your Windows developer account, access https://dev.windows.com/ and sign in with your Microsoft account. ■ Visual Studio -To generate the Package Family Name (PFN), you must build a Windows phone 'dummy application. This is done using Visual Studio. It is recommended to have the most current version of Visual Studio. (Visual Studio Professional is acceptable). In to download Visual Studio, you need a Microsoft Developer Network (MSDN) subscription. To learn more information about the Microsoft Developer Network and obtaining a subscription, access https://msdn.microsoft.com/subscriptions/ ■ Windows 8.1 system -You must install Visual Studio on a system running Windows 8.1. This is needed to create new 'Windows Phone app' projects. Registering Windows Push Notification Services (WNS) with Mobility Suite There are 5 key elements you create. The specific instructions are listed in the steps below. A brief summary of 5 the elements is listed here: 259 Setting up Windows Phone 8.1 Windows Phone 8.1 setup procedures Step-by-step instructions 1 Log into the Windows Dev center page with your credentials. The focus should be on the 'Dashboard' tab. 2 Click 'Submit an app'. You see a series of icons displayed in the middle portion of the screen. This details the app creation process flow. 3 Click 'App name' and provide the name for your app in the 'App name' field. Click 'Reserve app name' and then click 'Save'. You now return to the app creation process flow page. 4 Click 'Services'. In the middle of this page, click the link for 'Live services site''. Several key elements for Windows Push Notification Services (WNS) registration are generated. Note the values of the following elements in a separate document: ■ Package Security ID (Package SID) ■ Client Secret ■ Identity Name (part of the 'Application identity' and is used in the creation of the Package Family Name (PFN). ■ Publisher (part of the 'Application identity' and is used in the creation of the Package Family Name (PFN). 260 Setting up Windows Phone 8.1 Windows Phone 8.1 setup procedures 5 Launch Visual Studio on your Windows 8.1 system. Click File > New >Project. Within the menu listing on the right, select Templates > Visual Basic > Store Apps > Windows Phone Apps. Select the 'Blank App (Windows Phone)' within the template listing located in the middle pane of the screen. Click 'OK'. 6 From the right pane, right-click 'Package.appxmanifest' and click 'View code'. Within the Package.appxmanifest xml, (shown in the middle pane) replace the 'Identity Name' and 'Publisher' values with the corresponding 'Identity Name' and 'Publisher' values you retrieved from the 'Services' item noted in step 4. 7 Within the right pane, (where you right-clicked Package.appxmanifest) right click the App name reference at the top level (i.e, App2) and select 'Build'. Once the build process has completed, right-click Package.appxmanifest and click 'View Designer'. You are prompted to close the first opened instance of Package.appxmanifest. Click 'Yes'. 8 You see the Package.appxmanifest xml in the left pane. Within this pane are listed several tabs that form the 'Manifest design'. Click the 'Packaging' tab. Within this window, drag the bottom slider to the left. You see the 'Package Family Name' field. Highlight and select the value in this field and copy it into the document that you created in step 4 to store our key WNS element values. Save this document. You have successfully generated the Package Family Name (PFN). Registering the Windows Push Notification Services (WNS) credentials with Mobility Suite. ■ Registering the Windows Push Notification Services (WNS) credentials with Mobility Suite is done by using a script located on the system running the Mobility Suite. ■ Access /usr/local/nukona/appstore_cu/ ■ The script syntax is as follows: ./manage.py scripts mdm_core win8-push-credentials add -c [client secret] [package_security_id] [pfn] Note: The 'Identity Name' and 'Publisher' elements are not used in the script. These two elements are needed to generate the Package Family Name. (PFN) Here is an example of a successful script completion. Please note the illustrative relationship to the three elements used in the syntax of the script: Note: The credential values shown in the example are purely fictitious. However, the format is correct. 261 Setting up Windows Phone 8.1 Windows Phone 8.1 setup procedures Creating a required DNS entry and configuring email domain mapping The following account and domain information is used to demonstrate device enrollment of a Windows 8.1 Phone to Mobility Suite when auto discovery is configured: Table 10-2 Example account and domain information Mobility Suite user account = bsmith User's email address = [email protected] Mobility Suite FQDN = SmithBob.appcenterhq.com In order for a user to enroll a Windows Phone to Mobility Suite, the user must first create a workplace account.. This change is made from within "Settings" on their Windows phone. Microsoft requires that the workplace account is in the form of an email address. The workplace account is saved and registered with Microsoft. The workplace account is required to allow hub applications to manage Windows Phone devices. A domain that is used in the creation of the workplace account which is mapped to Mobility Suite. This DNS entry requires that the administrator create a CNAME (alias record) in DNS to map the workplace account to Mobility Suite. The CNAME record is created using the following format: enterpriseenrollment.<TenantNameONLY> CNAME <email domain> Using our example account and domain values, the CNAME record within DNS appears as follows: Next, the administrator must map the email domain to Mobility Suite. The administrator accesses Settings > Device Management from the Mobility Manager Console. Within the Device Management page, the administrator accesses the "Windows Phone Settings" section and enters the domain value in the "Email Domain" field. 262 Setting up Windows Phone 8.1 Windows Phone 8.1 setup procedures The email domain represents the email domain which creates the user's workplace account. In our example, this email domain is smithco.com. Note: Only one email domain can be specified. Mobility Suite currently does not support using workplace accounts from multiple email domains. Specifying the email domain within the Mobility Suite device management page and creating the CNAME record within DNS enables auto-discovery during the workplace account registration. The benefit of auto-discovery is that the user need only enter their email address during the enrollment process. The user does not need to know the server name as the email domain is mapped to Mobility Suite. If the required CNAME DNS record is not created, the user must enter the server name. The server name is entered during the workplace registration process. The server name is the FQDN of the Mobility Suite. Configuring device ownership prompt and text of MDM license page During the enrollment of Windows Phone with Mobility Suite, the user is prompted to specify if the device is for personal or corporate use. In the same enrollment screen, the user is prompted to accept the end-user license agreement. The administrator can suppress the device ownership prompt and edit the text in the end-user license agreement. These changes are made in the same Device 263 Setting up Windows Phone 8.1 Windows Phone 8.1 setup procedures Management page where the email domain value is specified. Access Settings > Device Configuration > Device Management and scroll to the Enrollment Settings section: Specify branding of the device enrollment screen After the user successfully registers a workplace account with Microsoft, the user is presented with a Mobility Suite enrollment screen. The administrator can control the branding of this enrollment screen. In the example, the enrollment screen is branded as "Symantec Work Hub" The default value is "Mobility Manager": (to review the entire user enrollment process, access See “Enrolling a Windows Phone device” on page 266..) 264 Setting up Windows Phone 8.1 Windows Phone 8.1 setup procedures The administrator can define the branding of the enrollment screen. Access Settings > Branding from the Mobility Suite console and specify a value in the 'Short Title' field. Providing enrollment instructions to the user No Mobility Suite Work Hub is installed onto Windows Phones. No invitation link is sent to the user for device enrollment. Device enrollment of Windows Phone is purely user initiated. 265 Setting up Windows Phone 8.1 Enrolling a Windows Phone device Note: If you configure authentication as local IDP, you can send email invitations to your Windows device users. Windows phone users can create their own Mobility Suite user account and password. You can invite a single user or invite many by using a distribution list. For your Windows Phone users, email invitation for account enrollment is supported. Invitation for device enrollment is not supported. Account enrollment invitations can be configured and sent by accessing Users > Invite Users > Invite Users to Work Hub: The device enrollment steps that are listed in the next section (See “Enrolling a Windows Phone device” on page 266. ) are written as instructions for the user. The device enrollment steps are written with the assumption that the administrator has completed necessary configuration. This configuration includes device policy configuration and auto-discovery enablement (CNAME DNS entry + email domain mapping). As an administrator, you need to forward these device enrollment steps directly to the user in an email. Enrolling a Windows Phone device You can enroll your Windows Phone version 8.1 with Symantec Mobility: Suite. 266 Setting up Windows Phone 8.1 Enrolling a Windows Phone device Enroll a Windows Phone device with Mobility Suite 1 On your Windows Phone device on the Home page, swipe left to see an application list. Scroll down the list and tap Settings. 2 Under system applications, tap workplace. 267 Setting up Windows Phone 8.1 Enrolling a Windows Phone device 3 On the workplace page, tap add account. 268 Setting up Windows Phone 8.1 Enrolling a Windows Phone device 4 Type your email address and tap sign in. 269 Setting up Windows Phone 8.1 Enrolling a Windows Phone device 5 During the workplace registration process, you may see a message about the redirection of the email domain to Symantec Mobility: Suite. If this occurs, tap continue to complete the workplace account registration. 270 Setting up Windows Phone 8.1 Enrolling a Windows Phone device 6 Your email account is saved and registered with Microsoft as your workplace account. Once this registration process completes, the Work Hub enrollment screen appears. 271 Setting up Windows Phone 8.1 Enrolling a Windows Phone device 7 Type your user name and password, indicate whether the mobile device is personal, and accept the license agreement. Then tap Sign In. Contact your administrator if you are uncertain about the user name and password. Note: You may see a different branding title based on how your administrator configured the enrollment screen. 272 Setting up Windows Phone 8.1 Enrolling a Windows Phone device 8 Tap done when you see the screen that you have successfully enrolled your device. 273 Setting up Windows Phone 8.1 After device enrollment 9 The name of your workplace account appears on the Settings > workplace page. After device enrollment After the user has successfully enrolled their Windows 8.1 Phone, the administrator can take the following action: ■ View Device Details of the enrolled device by accessing Devices from the Mobility Manager console and select your Windows phone. Use the search filters to return results by any one of 20 different search criteria. ( Operating Systems > Windows is the filter used in the example): 274 Setting up Windows Phone 8.1 After device enrollment ■ Update relevant Windows device policies and associated device profiles. The primary device profiles that are associated with Windows Phone 8.1 are Native email configurations, Access via Email Proxy, Password Restrictions, WiFi configuration, Device restrictions, and Enrollment restriction. You change or update these profile settings by clicking Policies and Rules from the Mobility Manager console, highlighting the desired device policy and clicking the edit icon located at the top right: 275 Setting up Windows Phone 8.1 After device enrollment Available device profile options that can be used in a device policy for Windows Phone 8.1 devices: Device profile Description Native Email configurations You define native email settings (mail server, active sync server, username and domain) which are applied to the local instance of the Windows mail client. Access via Email Proxy Your Windows Phone 8.1 device user's access to email can be configured to go through an email proxy. Password Restrictions You can configure required password for your Windows Phone 8.1 device users. Auto-lock timeouts and password complexity can be configured. 276 Setting up Windows Phone 8.1 After device enrollment Device profile Description WiFi Configurations You can configure specific WiFi network contentions for your Windows Phone 8.1 device users. WPA, WPA2 and WEP password encryption is supported. Note: Within the WiFi device profile, you can enable Automatically join the target network . Due to Windows architecture, the device user can disable this option on their Windows Phone 8.1 despite the setting enabled in the WiFi device profile. Device Restrictions Device restrictions that can be applied to Windows Phone 8.1 devices include availability of the camera, Bluetooth, NFC, encryption of internal device storage and access to SD cards. Enrollment Restrictions You can specify the maximum number of Windows Phone 8.1 devices a particular user can register. You can also specify the version of Windows Phone that is allowed for registration. When the administrator changes or updates a device policy, user's see dynamic policy changes on their device. These device policy updates occur on the user's Windows Phone in less than 1 minute after the administrator has saved the device policy. This dynamic device update occurs as a result of Mobility Suite integration with Windows Push Notification Services. Issue device commands from the Mobility Suite console ■ You can issue certain device commands to any device that has MDM enabled. The available device commands that the administrator can issue are detailed in the table. The table arranges the device commands by mobile operating system: 277 Setting up Windows Phone 8.1 After device enrollment Available device commands by platform Table 10-3 Device Commands iOS Disassociate Each device is linked to one user. You can de-provision this device from its user, making it available for another user. Lock Lock the screen on the device. Lock w/phone number and message option Lock the screen on the device with an option to display a custom phone number and message on device lock screen. Wipe w/de-provision Wipe all data from the device with option to de-provision user from the device. Unmanage w/de-provision Removes the native email and Work Mail (Work Mail removal not applicable to Windows Phone) settings. Revoke all applications and content installed using MDM protocol. Remove MDM configurations and revoke work hub so that it cannot be used again. Also available is an option to de-provision the user from the device. Android Samsung KNOX Windows Phone 278 Setting up Windows Phone 8.1 After device enrollment Available device commands by platform (continued) Table 10-3 Device Commands iOS Android Samsung KNOX Windows Phone Remove All All applications that are installed using MDM protocol are uninstalled. All applications with App Policies applied (wrapped apps) are revoked. iOS revocation of application and content does not occur until the application or the Mobility Suite Work Hub next contacts the server. Reset Password - user sets new password on device Reset Password - administrator sets new password at console Update a) Forces the device to pull the latest device policy targeting it (formerly 'Fetch' command). b) The Mobility Suite pulls the latest device information from the device. Ping Sends a test message to the device work hub that returns a success acknowledgment or failure acknowledgment. Note: For iOS devices, the work hub must be in the foreground and logged in to respond to Ping requests. ■ To send commands from the Mobility Suite console to a particular device; 1 From the Mobility Manager console page, click 'Devices'. 2 Select a specific device. 3 Click the 'Commands' button at the top right portion on the right pane. 279 Section 2 Using Symantec Mobility: Suite ■ Chapter 11. Inviting users to enroll in Symantec Mobility: Suite ■ Chapter 12. Using Symantec Mobility: Device Management ■ Chapter 13. Using Symantec Mobility: Threat Protection ■ Chapter 14. Using Symantec Mobility: Application Management ■ Chapter 15. Using Symantec Mobility: Workforce Apps ■ Chapter 16. Managing media content in Symantec Mobility: Suite ■ Chapter 17. Symantec Mobility: Suite reporting Chapter 11 Inviting users to enroll in Symantec Mobility: Suite This chapter includes the following topics: ■ Types of Symantec Mobility: Suite user invitation emails ■ Sending and re-sending invitation emails ■ Tracking user invitations ■ Customizing user invitation emails Types of Symantec Mobility: Suite user invitation emails Symantec Mobility: Suite provides the following types of invitation emails that you can send to your users: Symantec Mobility: Suite (Mobility Manager) Invite Email to end users to enroll them with Mobility Suite. The email contains a link which directs them to a URL where they set up an account with Symantec Mobility: Suite and download the Work Hub. An administrator initially sends this email invitation to add the user through the local IDP. See “Adding users with the local identity provider (IDP)” on page 110. Inviting users to enroll in Symantec Mobility: Suite Sending and re-sending invitation emails NMS Invite Email to end users to install Norton Mobile Security on their Android device. The email contains a link which directs them to a URL where they download, install, and launch the NMS client. See “Tracking device compliance in Symantec Mobility: Suite” on page 329. Apple VPP Invite Email to end users to enroll them into the Apple Volume Purchase Program (VPP) program. The email contains a link which directs them to Apple iTunes. The end user must sign in using their personal Apple ID and agree to the terms and conditions. Upon successful enrollment, the end user receives a message indicating that your organization can now assign apps to them. This email is automatically sent to end users the first time they download a VPP app from Mobility Suite. An administrator does not need to manually send it. See “About using the Apple Volume Purchase Program Managed Distribution (VPP) with Symantec Mobility: Suite” on page 244. More information See “Sending and re-sending invitation emails” on page 282. See “Customizing user invitation emails” on page 284. Sending and re-sending invitation emails Symantec Mobility: Suite provides pre-formatted email invitations to invite Mobility Suite users to enroll in Mobility Suite, the Apple VPP Program (if used), and Norton Mobile Security (if used). You can modify the default message, and send or resend invitation emails to users as needed. If you enable Norton Mobile Security or the Apple VPP Program after the original Mobility Suite installation, you send similar enrollment invitations. You also use this same workflow to resend invitations if the initial invitation emails were not received, were inadvertently deleted, or if a user wants to enroll a new device. See “Customizing user invitation emails” on page 284. You can also track the status of the user invites you send. See “Tracking user invitations” on page 283. 282 Inviting users to enroll in Symantec Mobility: Suite Tracking user invitations Send or re-send user invitation emails 1 In Mobility Manager on the left pane, click Users > Invite users. 2 In the right pane, select the type of invite you want to send. See “Types of Symantec Mobility: Suite user invitation emails” on page 281. Note: If you customize the VPP user invitation, the customized message appears in the user invitation email that you send or resend. However, if you customized the Work Hub user invitation email and the user has already enrolled, a different message appears in the user invitation email that you resend, which cannot be customized. Note: The VPP user invitation does not appear if you do not have an Apple sToken uploaded. See “About using the Apple Volume Purchase Program - Managed Distribution (VPP) with Symantec Mobility: Suite” on page 244. 3 In the invite editor, follow the on-screen instructions to enter users by email or by group. Note: To use the Group Invite option, you'll need to have groups set up first. See “Creating groups” on page 61. You have the option to edit and format the message according to your needs. You also have the option to save the message as a template, which is used the next time you send invitation emails. 4 When you're ready to send the invites, click Send Invite. More information See “Adding users with the local identity provider (IDP)” on page 110. See “Downloading and installing Norton Mobile Security (NMS) manually” on page 319. Tracking user invitations After you send a user invitation of any type, you can use Mobility Manager to track when invitations were sent and which ones failed. 283 Inviting users to enroll in Symantec Mobility: Suite Customizing user invitation emails Track user invitations 1 In Mobility Manager on the left pane, click Users > Track invites. 2 Click the Type drop-down list to select the type of invite you want to track. 3 Customize your query by doing any of the following: ■ To narrow your search by tracking-status, click Status and chooseAll, Sent, or Failed. ■ To search a range of calendar dates, click the From and to fields and select the start and end dates of the range. ■ Optionally, set the number of items to display per page. More information See “Sending and re-sending invitation emails” on page 282. See “Customizing user invitation emails” on page 284. See “Types of Symantec Mobility: Suite user invitation emails” on page 281. Customizing user invitation emails In most cases, you invite users to enroll with Symantec Mobility: Suite through email. Mobility Suite provides default email templates that include links to download your Work Hub and enrollment links. You may want to customize the email invites to better suit your needs. Customize user invitation emails 1 In Mobility Manager, click Users > Invite templates. 2 Under User invitation email templates, for the invitation you want to customize, click the pencil-shaped Edit icon (located at the far right end of the invite title bar). 3 Use the invite editor to customize the invitation message. Note: To replace or add images, place the cursor where the image is to appear and then click the Image icon (next to the Toggle HTML switch). Enter the URL for the image and then click OK. 4 Click Save. More information See “Types of Symantec Mobility: Suite user invitation emails” on page 281. 284 Inviting users to enroll in Symantec Mobility: Suite Customizing user invitation emails See “Sending and re-sending invitation emails” on page 282. See “Customizing and sending user invitation emails in other languages” on page 71. 285 Chapter 12 Using Symantec Mobility: Device Management This chapter includes the following topics: ■ Restricting device enrollment ■ Managing the mobile devices enrolled with Symantec Mobility: Suite ■ Setting default mobile device management (MDM) values for new device policies ■ Viewing device details and settings ■ Mobile Device Management (MDM) reporting in Symantec Mobility: Suite ■ Enabling and restricting device inventory collection, and viewing device inventory ■ Controlling the collection of personally identifiable information (PII) in Symantec Mobility: Suite ■ Locking, wiping, resetting passwords, and issuing other commands to managed devices ■ Locating a lost or stolen device ■ Viewing a device's command history ■ Creating device policies ■ Sharing settings between different device policies ■ Prioritizing device policies ■ Assigning and unassigning device policies ■ Applying MDM to groups in Symantec Mobility: Suite Using Symantec Mobility: Device Management Restricting device enrollment ■ About Samsung KNOX support Restricting device enrollment Symantec Mobility: Suite lets you monitor when users enroll devices based on the following criteria: ■ Number of devices per user ■ Device operating system When you configure these setting, users can still enroll devices that violate this policy. But you can monitor violations by running a Registration restriction report. And if you enable the Enrollment Restrictions notification on the Settings > Mobility Manager configuration > Notification Emails page, Mobility Manager sends you email notifications to let you know when a user enrolls a restricted device. A low-priority message of the violation is sent to the Administrator inbox in Mobility Manager. See “Monitoring your Symantec Mobility: Suite license status” on page 36. Note: No notifications are sent if a user upgrades to restricted device operating system. Tip: If you use APIs, you can impose limited registration restrictions on devices. For more information, see the Symantec Mobility: Suite API Integration Guide. Restrict device enrollment 1 Create a device policy and assign it to the group for whom you want to apply enrollment restrictions. Note: The policy cannot be assigned to an individual person. See “Creating device policies” on page 304. 2 In the device policy under Device settings, beside Enrollment restriction, click New to create a new Enrollment restriction profile or click Add to select an existing one. See “Enrollment restriction policy settings” on page 436. 3 Make any other changes to your device policy, and then click Save. More information See “Configuring email notifications” on page 55. 287 Using Symantec Mobility: Device Management Managing the mobile devices enrolled with Symantec Mobility: Suite See “Symantec Mobility: Suite reports” on page 399. See “Configuring email notifications” on page 55. See “Sharing settings between different device policies” on page 306. Managing the mobile devices enrolled with Symantec Mobility: Suite Symantec Mobility: Suite lets you monitor and manage devices enrolled with Mobility Suite from the Mobility Manager. The device list displays enrolled devices and for each, the name of the device, its operating system, and the device user. You can filter the list by one or more criteria you select from the Filter by selector. Device details are displayed in the right pane. You can also issue commands and change ownership for selected devices. Send commands to a single device 1 In the Mobility Manager on the left pane, click Devices. 2 On the Device list, check the box beside the device you want to send the command to. 3 At the top of the right pane, click the Command icon (orange circle with three horizontal bars). 4 In the Device commands window, click the command you want to send to the selected device. Note: Available commands are only those supported by the operating system of the selected device . See “Commands that can be sent to mobile devices” on page 450. Send commands to multiple devices 1 In the Mobility Manager on the left pane, click Devices. 2 On the Device list, check the box for each of devices you want to send commands to. To select all devices, check the box located immediately above the device-list scroll bar. 3 On the right pane, click the command you want to send to the devices. See “Commands that can be sent to mobile devices” on page 450. 288 Using Symantec Mobility: Device Management Managing the mobile devices enrolled with Symantec Mobility: Suite Change device ownership 1 In the Mobility Manager on the left pane, click Devices. 2 From the Device list, select the device for which you want to change ownership. 3 At the top of the right pane, click the Ownership icon (orange circle with curved arrow). 4 Select the desired ownership option and then click Save. View commands sent to any managed device 1 In the Mobility Manager on the left pane, click Devices. 2 On the right pane, click Recent Commands. You can filter device commands by status, command, and who issued the command. View a list of all corporately-owned devices 1 In the Mobility Manager on the left pane, click Devices. 2 On the right pane, click Corporate Devices. From this page, you can add and delete devices and download the list in .csv format. Click the + icon to add devices; click the Download icon to download the list. View details about specific mobile devices 1 In the Mobility Manager on the left pane, click Devices. 2 From the list of devices, select the device that you want to manage or get more details about. Note: You can also filter the list of devices or search for a specific device. 3 In the right pane, select the type of information you want to see about the selected device. The following table describes the information for each type. 289 Using Symantec Mobility: Device Management Setting default mobile device management (MDM) values for new device policies Details Provides the following device information: ■ ■ ■ Settings Device Compliance app, MDM, and email Device Details OS, model, MAC address, serial number, Mobility Manager ID, ownership, jailbroken/rooted, and Work Mail device ID. Work Hub information Date enrolled, date last connected, notifications enabled, notifications verified, Offline PIN set Indicates device policies and profiles apply to the selected device. See “Creating device policies” on page 304. Inventory Shows which apps, certificates, and content are installed on the selected device. See “Enabling and restricting device inventory collection, and viewing device inventory” on page 297. Location Displays a map depicting the last known location of the selected device. See “Locating a lost or stolen device” on page 303. Command History Provides a list of the commands that have been sent to the selected device. See “Viewing a device's command history” on page 303. More information See “Setting default mobile device management (MDM) values for new device policies” on page 290. See “Locking, wiping, resetting passwords, and issuing other commands to managed devices” on page 300. Setting default mobile device management (MDM) values for new device policies To configure default MDM settings for a new device policy in Symantec Mobility: Suite, on the left pane of the Mobility Manager select Settings > Device Configuration. Under Device management , check Enable MDM for the specific device OS. Mobility Manager MDM supports iOS, Android and Windows devices. 290 Using Symantec Mobility: Device Management Setting default mobile device management (MDM) values for new device policies Each setting on the Device Management page is described in the UI. The default settings are chosen to be generally applicable to most users, but should be adjusted to meet your specific needs if they are too lenient or restrictive. Notes ■ When MDM is enabled on this page , any new device policy you create inherits the settings defined on this page. ■ Settings on this page only define the default template values that are used when you create a new device policy. Settings on this page do not globally enable or disable MDM. ■ iOS MDM requires that you upload an iOS MDM certificate to Mobility Suite. See “Managing the iOS app and MDM certificates used by Symantec Mobility: Suite” on page 75. ■ Once MDM is activated in Mobility Suite, mobile users cannot use Mobility Suite until their device complies with the device policy that is assigned to them. 291 Using Symantec Mobility: Device Management Setting default mobile device management (MDM) values for new device policies ■ If there is no browser activity for several minutes, the Mobility Suite server will time-out and any changes will be lost. Be sure to save your settings if you need to suspend this device management workflow for any reason. iOS tiered access rights iOS device management access rights are tiered as follows: ■ App Management- Allows you to manage app and profile installation and removal. ■ App and Device Management- The default setting; includes the App Management rights and adds the ability to remotely control the device. ■ App and Device Management with Wipe- Adds the ability to wipe the device. Note: If you increase the level of iOS access rights, Safari must be an enabled application. Please access iOS Settings > Device Restrictions to confirm Safari application enablement status before changing iOS access rights. Specific MDM access rights by tier App Management ■ Allow inspection of installed configuration profiles ■ Allow installation and removal of configurations ■ Allow query of Device Information (serial number, IMEI, etc.) ■ Allow inspection of installed provisioning profiles ■ Allow installation and removal of provisioning profiles ■ Allow inspection of installed applications ■ Allow manipulation of settings ■ Allow app management (install app, remove app, etc.) App and Device Management ■ All of the App Management settings ■ Allow device lock and passcode removal ■ Allow query of Network Information (WiFiMAC, PhoneNumber, VoiceRoamingEnabled, DataRoamingEnabled, PersonalHotspotEnabled) ■ Allow restriction-related queries ■ Allow security-related queries 292 Using Symantec Mobility: Device Management Setting default mobile device management (MDM) values for new device policies App and Device Management with Wipe ■ All of the App and Device Management settings ■ Allow device erase Installing iOS apps with MDM You can let Mobility Suite manage iOS apps remotely from Mobility Manager. For instance, when an iOS app is installed with MDM, the app can be removed remotely without user consent. Both iOS app types, Native, or Web Clip are supported. Allowing devices that can't use MDM access to Mobility Suite Devices using Android 2.2 or older are not capable of remote management but may need to be allowed to use Mobility Suite. To allow these and other devices that cannot run MDM, select the option to allow devices that do not have remote management capabilities. Adjust polling and alerting intervals You can adjust polling times (when devices check in) and alerting times (when device check-ins are past due). These settings can affect security and device battery life. Devices that check-in more often use more battery power. If set too long however, policy updates, commands sent to the device, and location data may be delayed beyond a useful or safe limit. The default polling time is 72 hours (three days). For iOS devices, alert emails can be sent to administrators and the device user when a policy check of the device fails. Device management features Device management features vary depending on which Work Hub-type is used: iOS Native, iOS Web Clip, or Android. See “Mobile Device Management (MDM) settings by Work Hub type” on page 454. Disabling MDM You can uncheck the MDM option on the Device Management page at any time, and MDM will no longer be required on the mobile devices. However, MDM is not automatically uninstalled from user devices. See “Managing the mobile devices enrolled with Symantec Mobility: Suite” on page 288. Cisco ISE integration Mobility Suite supports integration with Cisco® Identity Services Engine (ISE) version 1.2. ISE integration requires the native Work Hub and MDM. To establish 293 Using Symantec Mobility: Device Management Viewing device details and settings the integration with Mobility Suite, you enable the Cisco ISE APIs. Once enabled, MDM-managed devices can report into the Cisco ISE system. See “Enabling Cisco ISE integration” on page 133. Viewing device details and settings You can view device details and settings for any device that is managed by Symantec Mobility: Suite device management. The list displays all of the settings that apply to the device, regardless of which policy specifies the setting. The list is created after first resolving any policy priority conflicts. Each setting indicates the policy that specifies it. You can open policies for editing directly from this view to make changes as necessary. The list also includes compliance statuses for the listed devices. Note: Your iOS device must have a unique 'Device Name'. If your iOS device has the same device name as a currently enrolled iOS device, the following error message is displayed: Permission Denied: The device belongs to another user and only that user may login. To verify the device name of your iOS device, on the device, tap Settings > General > <Name on your iOS device>. View device details and settings 1 Click Devices. 2 On the center pane, select the desired device. 3 On the right pane, select any of the following options: 294 Using Symantec Mobility: Device Management Viewing device details and settings Details The Details page provides the following information ■ Device Compliance When a device is not in compliance, details about why appear beside the label. ■ Required App Compliance ■ MDM Device Policy Compliance Access via Email Proxy If access is blocked, details about why appear. For example, it could be the device does not have a device policy assign to it or the app attempting access is not a permitted app in your Access via Email Proxy shared settings. See “Troubleshooting Secure Email Proxy” on page 230. Device Info Provides OS, model, MAC address (if available), Mobility Suite ID, ownership (corporate or personal), whether the device is jailbroken or rooted, and if the device uses Work Mail, the email client device ID. If the device is a corporate device, the device info also includes whether voice roaming, data roaming, and personal hotspot features are enabled. Work Hub Info Provides details about the Work Hub interaction with the Mobility Suite server. Includes when the device was enrolled, last connection timestamp, whether notifications are enabled and verified, which notification service is used, and if set, the offline PIN. ■ ■ ■ ■ Settings Norton Mobile Security Provides details about the device security state (compliance), last communication date and time, last scan time, and anti-virus definition and status. If a threat is present, click the link to see more information about the threat (app name, package, threat name, detection date). The Settings page provides information about the policy(s) and profiles (device settings) targeted to the device. Device settings are controlled by device policies. See “Creating device policies” on page 304. Inventory The device inventory includes installed apps, installed certificates, and installed content. See “Enabling and restricting device inventory collection, and viewing device inventory” on page 297. 295 Using Symantec Mobility: Device Management Mobile Device Management (MDM) reporting in Symantec Mobility: Suite Location Provides the last known location of the device. Note: Requires that location tracking is enabled See “Locating a lost or stolen device” on page 303. Command history Provides a list of the commands sent to the device. Mobile Device Management (MDM) reporting in Symantec Mobility: Suite Symantec Mobility: Suite provides out-of-the-box reports that are designed to help you manage mobile devices in your environment. You access device reports in Mobility Manager on the Reports page. Table 12-1 MDM reports Report Description Blacklisted Devices A list of blacklisted devices. Shows the device name, Mobility Suite ID, the MAC address, the user associated with the device, and that user's email address. To remove a device from the blacklist, contact Support. Device Details Provides an overview of the device, device compliance, and information about the Work Hub installed on the device. This report also lets you display device details based on device ownership (corporate or personal) and by any or all of the policies applied to the device. You can also choose to display results for one or more, or all of the Groups simultaneously. Devices missing required apps The list shows missing apps, the device, platform, user, and email address. Devices by Platform & OS Versions A pie chart showing the devices by platform and OS versions. Jailbroken/Rooted Devices A list of jailbroken/rooted devices. Provides the user, device, device manufacturer, operating system, type of device (e.g., phone or tablet), Mobility Suite ID, UDID, MAC address, whether the device is corporately owned, and the email address. 296 Using Symantec Mobility: Device Management Enabling and restricting device inventory collection, and viewing device inventory Table 12-1 MDM reports (continued) Report Description MDM Compliance Status A list of all devices and their current MDM compliance status. Green rows are compliant; red rows are non-compliant. Other information can include the device name, the level of MDM in effect, the date the user first accepted the terms and conditions of MDM, the date the user was last known to be compliant, the device policy name, and the reason for any non-compliance. MDM Non-Compliant Devices A list of devices that are non-compliant. New Users Per Week A chart enumerating newly enrolled users, by week. Work Mail Status A list of all of the devices that you specify under Group Restrictions and whether Work Mail is installed, if it is compliant, and the Work Mail ID. Users by Group A list of users, the groups they belong to, their email address, and VPP status. A list of information about the device name, the date the user first accepted the terms and conditions of MDM, the user name, user's first name, last name, and email address, the date the user was last known to be compliant, the device policy name, and the reason for any non-compliance. Shows one row per user per group. More information See “Running reports in Symantec Mobility: Suite” on page 398. See “Symantec Mobility: Suite reports” on page 399. See “Managing the mobile devices enrolled with Symantec Mobility: Suite” on page 288. Enabling and restricting device inventory collection, and viewing device inventory Symantec Mobility: Suite device inventory includes the following: ■ Installed apps Displays the name, version, app source, and as appropriate, controls to allow, block, or revoke an app 297 Using Symantec Mobility: Device Management Enabling and restricting device inventory collection, and viewing device inventory See “Adding apps to Symantec Mobility: Suite” on page 331. ■ Installed content Displays the file name, time stamps, and source information for content items downloaded to the device See “Adding and managing content” on page 392. ■ Installed certificates Displays the certificates installed on the device, what the certificates are for, and the certificate expiration date ■ Personal identification information (PII): phone number, IMEI, and MAC address ■ Device location- The last reported location of the device Enable inventory collection 1 In the left pane, click Policy and rules and create a new policy or edit an existing policy. See “Creating device policies” on page 304. 2 On the policy template, in the Inventory Collection group, check Enable collection & display of commercial app information. 3 Optionally, check the following options: . ■ Restrict the collection of commercial app information to corporate devices This option restricts the collection of information about commercial apps to include only corporate devices. ■ Enable collection and display of user location Note: The device must be turned on and have a cellular or IP network to receive the device policy. The location information is sent according to the polling interval set in the policy (default is 60 minutes). See “Locating a lost or stolen device” on page 303. ■ Enable collection and display of personal identification information. You can choose any or all of the following: ■ Phone number ■ IMEI ■ MAC address (always collected from Android devices) 298 Using Symantec Mobility: Device Management Controlling the collection of personally identifiable information (PII) in Symantec Mobility: Suite Note: Depending on the legal jurisdictions that apply to your organization, you may not be allowed to collect some or all personal identification information (PII). See “Controlling the collection of personally identifiable information (PII) in Symantec Mobility: Suite” on page 299. 4 Click Save. View device inventory 1 Click Devices and select the device whose location you want to view. 2 In the right pane, click Inventory. Controlling the collection of personally identifiable information (PII) in Symantec Mobility: Suite Depending on the legal jurisdictions that apply to your organization, you may not be allowed to collect some or all personally identifiable information (PII). PII for mobile devices is: ■ Phone number ■ IMEI ■ MAC address Symantec Mobility: Suite can be set to not collect this information, either in total, or selectively. The settings to turn off PII collection are in the General Settings section of a Device Policy. Note: Applies to iOS devices only. See “Creating device policies” on page 304. Controlling the collection of personally identifiable information 1 Open a new policy (Policies and rules > New Device Policy) or edit an existing Device Policy (Policies and rules > selected policy > Edit). 2 In the Inventory Collection section, uncheck Enable collection & display of personal identification information. 3 If you only want to suppress the collection of a subset of PII, place checkmarks next to the information type you want to suppress. 299 Using Symantec Mobility: Device Management Locking, wiping, resetting passwords, and issuing other commands to managed devices 4 If this is a new policy, set the other Device Policy options as needed and then assign the policy. See “Assigning and unassigning device policies” on page 309. 5 Save the policy. Locking, wiping, resetting passwords, and issuing other commands to managed devices A lost or stolen device can pose a serious risk, particularly if the device has sensitive data, or runs apps that access your corporate network. Symantec Mobility: Suite lets you reduce these risks by issuing special commands directly to a lost or stolen device. For instance, you can command a managed device to become locked or to wipe its data. Issuing commands to managed mobile devices 1 On the Mobility Manager left pane, click Devices. 2 On the center pane, select the device to which you want to send a command. 3 At the top right of the right pane, click the Command icon (orange circle with three horizontal lines). 4 Execute the desired command. The following table lists the commands that you can send to managed devices. Table 12-2 Managed devices commands Command Description Lock Locks the screen on the device, requiring the currently set password to unlock. 300 Using Symantec Mobility: Device Management Locking, wiping, resetting passwords, and issuing other commands to managed devices Table 12-2 Managed devices commands (continued) Command Description Selectively wipe, unmanage, and disassociate device from user Delete, or "wipe," email, Work Mail settings, and apps installed through MDM; unmanage the device by removing all MDM configurations; revoke access to all content, wrapped apps, and the Work Hub so they cannot be used; disassociate the device from its current user. Notes 1 Once a device has been wiped, it must be re-enrolled with Symantec Mobility: Suite. 2 If the Work Hub is not installed through MDM, it is not uninstalled by a selective wipe. The app no longer functions, and the device user must manually uninstall the app. 3 On Android, the contents of the external SD card is not deleted when a wipe command is performed. 4 If the Work Hub is reinstalled on the device after using this command, you must reset the Work Hub to Allowed in the Device Inventory. See “Enabling and restricting device inventory collection, and viewing device inventory” on page 297. Wipe Removes all apps and content from the device and resets the device to factory defaults. Notes 1 On Android, the contents of the external SD card is not deleted when a wipe command is performed. 2 Once a device has been wiped, it must be re-enrolled with Symantec Mobility: Suite. Disassociate from For devices that can be reused by a different user, disassociating the user device removes the database association between the device and the current user. The Work Hub is left on the device, for easy enrollment by a new user. Revoke all apps Any apps delivered through Mobility Suite receive a poison-pill that destroys the apps and any associated data. Personal apps and data are left untouched. Reset password The current password is removed from the device and the user must enter the new password that you enter into the New password field. 301 Using Symantec Mobility: Device Management Locking, wiping, resetting passwords, and issuing other commands to managed devices Table 12-2 Managed devices commands (continued) Command Description Update device Forces the device to download the device policy that is targeted to it, and returns device information back to Symantec Mobility. Ping device Work Hub Triggers the device to respond to Mobility Suite with an acknowledgment message. Note: The Work Hub must be in the foreground and logged into Mobility Suite. Reset MDM Forces the device to register with MDM again. Important notes ■ Most of these commands require that you enter your administrator credentials before the command is executed. See the list Required command permissions. ■ Several factors can affect how long it takes for commands to reach devices, and you should not expect commands to be received immediately. iOS devices receive commands upon their next regularly scheduled check-in. Check-in times are controlled by the device policies that are assigned to the devices. See “Creating device policies” on page 304. Required command permissions A list of the permissions required for the device commands: ■ Dissociate from User - Any permission ■ Lock the Device - Requires at least the App and Device Management permission. ■ Wipe the Device - Requires the App and Device Management with Wipe permission ■ Selectively wipe, unmanage, and disassociate device from user - MDM access right must be enabled to perform MDM commands. ■ Revoke all apps - MDM access right must be enabled to perform MDM commands. ■ Reset Password - Requires the App and Device Management permission. ■ Update device - Any level of MDM is required. ■ Ping Device Work Hub - Any permission. 302 Using Symantec Mobility: Device Management Locating a lost or stolen device Locating a lost or stolen device Symantec Mobility: Suite lets you configure device policies that track the location of enrolled devices that run the native Work Hub. The device must be turned on and connected to a cellular or IP network to receive the device policy and to send its location information. By default, location collection occurs every 60 minutes. You can change the interval to be longer or shorter. The reported location is based on the most recent information sent from the device, which can vary depending on the update frequency. Enable inventory collection Before device location can be displayed, devices must receive a device policy that enables the collection of location information. You select this option in the device policy Inventory collection settings. See “Enabling and restricting device inventory collection, and viewing device inventory” on page 297. View device location 1 Click Devices and select the device whose location you want to view. 2 In the right pane, click Location . The last reported location for the selected device appears on a map. Viewing a device's command history A record of the commands sent to each device is stored in Symantec Mobility: Suite. View the command history for one or more devices ◆ Go to the Devices page, and do one of the following: ■ Check a single device: Select a single device and at the top of the device details, click Command history. ■ Check multiple devices: Select two or more devices (use the check-boxes to select multiple devices) and on the right, for each command, select View Status. Note: You can use the search filters to narrow the list. ■ Check all devices: With no devices selected, on the right, click Recent commands. 303 Using Symantec Mobility: Device Management Creating device policies The device ID, status, user, command, issuer, and last update are displayed for each device. Creating device policies Device policies control mobile device access to your network and data resources. Device policies also control the degree to which you can manage a device's behavior. The Work Hub that's installed on enrolled devices enforces the device policies. Tip: If you've created Device profiles, you can select the profile you want as you create your device policy. You can also create a new Device profile or add to an existing profile as you create your policy. See “Sharing settings between different device policies” on page 306. Notes: ■ The default values you see when you create a new device policy are defined within the Settings > Device Management page. To change these default values, See “Setting default mobile device management (MDM) values for new device policies” on page 290. ■ Device policy changes are applied to all devices that are associated with the policy, even when the policy change is not applicable to all the devices in the group. Create a device policy 1 In the left pane, click Policies and rules > Device policies and at the top of the right pane, click New Device Policy. 2 Enter a name and description for the policy. 3 In the Groups box, select the group to apply to your device policy. Use the Filters drop-down list to specify whether the policy applies to corporately-owned devices, personally-owned devices, or both. 4 Select and set the policy options. See the Policy settings information section of this topic for information about the policy settings. 5 Click Save. Policy settings information General settings The general settings enable MDM, and set compliance, update frequency and inventory collection options. 1 Device Management 304 Using Symantec Mobility: Device Management Creating device policies 2 ■ In the device management section of your device policy, you enable or disable MDM for your iOS, Android, or Windows Phone 8.1 devices. ■ The default values you see for MDM when you create a new device policy are defined in the Device Management section. See “Setting default mobile device management (MDM) values for new device policies” on page 290. Compliance Rule The compliance rule must already be configured to select it from the drop-down menu. Important: Devices using an email proxy require a device policy that specifies a compliance rule. See “Creating and managing compliance rules” on page 325. 3 Update Frequencies When you set the option Devices are checked for required app compliance every [n] hours to 0, upon the initial device enrollment of either an iOS or Android device, Mobility Suite pushes down required apps. Thereafter, however, as long as the value remains 0, required apps cannot be pushed down to enrolled devices. 4 Inventory Collection See “Enabling and restricting device inventory collection, and viewing device inventory” on page 297. 305 Using Symantec Mobility: Device Management Sharing settings between different device policies Threat protection, Email, and Device Settings 1 Threat protection settings (Android only) See “Threat Protection settings for device policies” on page 322. 2 Email Settings See “Work Mail policy settings” on page 446. See “Native Email policy settings” on page 440. See “Access through Email Proxy policy settings” on page 430. 3 Configure Device Settings See “Password policy settings” on page 442. See “WiFi policy settings” on page 444. See “Device Restriction policy settings” on page 432. See “VPN policy settings” on page 444. See “SSO policy settings” on page 443. See “Resources policy settings” on page 443. See “Enrollment restriction policy settings” on page 436. See “Kiosk Mode policy settings” on page 436. More information See “Tracking device compliance in Symantec Mobility: Suite” on page 329. See “Prioritizing device policies” on page 309. Sharing settings between different device policies In Symantec Mobility: Suite, policies are collections of the policy settings that are targeted to specific groups of users. To make creating and managing policies easier, you can save collections of policy settings as "Device profiles." You provide each profile a name. These names appear in drop-down menus within the policy editor. When you create a new policy or edit an existing policy, you can optionally add one or more of your saved Device profiles. Device profiles are organized by function. These settings are sometimes referred to as "shared settings" because devices with differing operating systems can share that same setting. Go to Policies and rules > Device profiles to see the list of Settings can be added to a policy profile or from within a new or existing device policy. Each setting group shows how many policies are using the group's settings. 306 Using Symantec Mobility: Device Management Sharing settings between different device policies Tip: Click the policy count to see a list of the policies that use the settings. When you create a setting from within a device policy, the setting also appears in the Device profile. Notes: ■ Settings are only active when they are associated with a device policy. See “Creating device policies” on page 304. ■ To view the Device Policy page, you must be a member of a group that has permission to view the device policy. See “Creating groups” on page 61. Applying settings to specific operating systems When you create a setting, you have an option to apply that setting to a specific device operating system. In the example below, the Password Restrictions setting is applied to all device platforms (iOS, Android with and without Samsung KNOX, and Windows Phone). Important note: Due to functional differences between operating systems, some settings may not apply to all operating systems .See “Mobile Device Management (MDM) settings by Work Hub type” on page 454. for a list of applicable settings by operating system. Adding a Device profile 1 On the left pane, click Policies and rules > Device Policies > Device profiles. 2 In the right pane, select the category of settings you want to use for a new device profile. Note: Most of the categories require that you enable MDM. See “Setting default mobile device management (MDM) values for new device policies” on page 290. 3 Click the plus mark to add a new profile for the selected category. 307 Using Symantec Mobility: Device Management Sharing settings between different device policies 4 Type a name and description for the profile, and then choose the settings you want to use. See “Access through Email Proxy policy settings” on page 430. See “Native Email policy settings” on page 440. See “Password policy settings” on page 442. See “Resources policy settings” on page 443. See “Device Restriction policy settings” on page 432. See “Work Mail policy settings” on page 446. See “SSO policy settings” on page 443. See “VPN policy settings” on page 444. See “WiFi policy settings” on page 444. See “Enrollment restriction policy settings” on page 436. See “Kiosk Mode policy settings” on page 436. See “Certificate Template policy settings” on page 432. See “Certificate Authority policy settings” on page 431. 5 Click Save. The collection of settings is now available for use in device policies. Applying device profiles to device policies You can add device profiles to new and existing device policies. Apply a Device profile to a device policy 1 In Mobility Manager on the left pane, click Policies and rules > Device Policies > Policy list. 2 Do one of the following: To edit an existing policy Select an existing policy from the list and in the right pane, click the Edit icon (pencil). To create a new policy Do all of the following: ■ Click New Policy. ■ In the New Policy window, type a name and useful description. Select the group or groups to which the policy applies. ■ 308 Using Symantec Mobility: Device Management Prioritizing device policies 3 For each group of settings, use the drop-down menus to select a setting. Note: Only the settings you have previously configured appear in the drop-down menus. 4 Click Save. Changes made to existing policies propagate to the mobile devices in the targeted groups. Prioritizing device policies Symantec Mobility: Suite device policies are targeted to specific groups of users, and each group is restricted to one policy. However, a user can be assigned to more than one group and so, can fall under the control of more than one device policy. To ensure the proper application of policies and policy restrictions, Mobility Suite lets you set the priority by which policies are applied. You can promote a more restrictive policy to a higher priority to ensure that in case of a conflict, the more restrictive policy takes control. Prioritize device policies 1 Click Policies and rules, select a policy, and at the top of the right pane, click Policy Priority. 2 Click the Up and Down buttons to raise or lower the priority of the selected policy. 3 Click Save. More information See “Creating device policies” on page 304. Assigning and unassigning device policies You assign device policies from within the policy. You can add groups to the policy when you create a new policy or add them to existing policies by editing the policy. The default groups and any that you create appear in the policy template. Place a checkmark beside the groups to which the policy applies and then save the changes. Similarly, you remove groups from device polices by deselecting them. 309 Using Symantec Mobility: Device Management Applying MDM to groups in Symantec Mobility: Suite Assign and unassign device policies 1 In Mobility Manager, click Policies and rules. 2 Select the policy that you want to assign, and in the right pane, click Edit. 3 Under Targeted Devices click the Groups field and select the group that you want to add. 4 To remove a group, select the group click x . 5 Click Save. More information See “Creating device policies” on page 304. See “Creating groups” on page 61. See “Applying MDM to groups in Symantec Mobility: Suite” on page 310. See “Managing the mobile devices enrolled with Symantec Mobility: Suite” on page 288. Applying MDM to groups in Symantec Mobility: Suite Symantec Mobility: Suite lets you tailor MDM to meet the needs of your organizational groups. For instance, some groups may require no MDM while others may require strict MDM. You specify MDM activity in Device Policies. When you create or edit a device policy, you select the groups to which the policy applies. Note: Only one device policy is allowed per group. Considerations for group MDM A device policy with MDM enabled lets you control how often the device is polled, whether to collect and display the location of the device, and whether to collect and display information about commercial apps. Some groups may require more frequent polling. Some groups may need to have location data available while other do not. Your particular security needs dictate which options are used and the values that are applied to the policy settings. A device policy can also control access to Exchange Active Sync through Symantec Work Mail. You set the access options for Work Mail in the device policy. You can also enable or disable MDM profiles for iOS devices based on a device policy. On Android devices, you can enable or disable the device administrator. 310 Using Symantec Mobility: Device Management Applying MDM to groups in Symantec Mobility: Suite Assigning an MDM-enabled device policy to an organizational group Before you begin, this procedure assumes that you have already created groups or have mapped your organizational groups from an external identity provider (IDP). See “Creating groups” on page 61. See “Setting up user authentication and adding users to Symantec Mobility: Suite” on page 104. You use the normal device policy editing and targeting procedures to apply a policy to an organizational group. See “Creating device policies” on page 304. See “Assigning and unassigning device policies” on page 309. When you create or open a policy for editing, your groups are listed as a roster at the top of the policy editor. Select the groups that the policy is targeted to and then save the policy. The group assignments are made immediately and targeted devices receive the updated policy at their next update interval. Symantec Mobility: Suite manages apps using app policies. These policies control who can access an app, who must install it, what category it is associated with, and similar information. See “Creating and managing app policies” on page 346. Corporate versus personal mobile device management in Symantec Mobility: Suite Symantec Mobility: Suite lets you take independent control of polices that are targeted to corporately owned mobile devices, and policies that are targeted to personal devices operating in your environment. For instance, you may want your corporate devices to use MDM but not personal devices. To satisfy this scenario, you create an MDM-enabled device policy and assign it to your corporate devices. If you want to issue a non-MDM policy to the personal devices, create a non-MDM device policy and target it to only personal devices. Assigning device policies by corporate or personal device ownership In the Device Policy editor, under Targeted Devices, use the Filters drop-down menu to select the ownership assignment for the policy. See “Assigning and unassigning device policies” on page 309. 311 Using Symantec Mobility: Device Management About Samsung KNOX support About Samsung KNOX support Symantec Mobility: Suite integrates with Samsung KNOX. The KNOX service is part of Samsung's "Samsung Approved For Enterprise" (SAFE). Mobility Suite leverages KNOX APIs to provide expanded capabilities. Those capabilities include the following: ■ Mobile Device Management (MDM) ■ ■ ■ Mobility Suite supports configuring and restricting the following settings for Samsung KNOX devices: ■ Device restrictions See “Device Restriction policy settings” on page 432. ■ Email proxy See “Access through Email Proxy policy settings” on page 430. ■ Native email settings See “Native Email policy settings” on page 440. ■ Password settings See “Password policy settings” on page 442. ■ Registration restrictions See “Enrollment restriction policy settings” on page 436. ■ Work Mail settings See “Work Mail policy settings” on page 446. You can initiate certain device commands from the Mobility Manager to Samsung KNOX devices. See “Commands that can be sent to mobile devices” on page 450. Mobile Application Management (MAM) Apps that are marked as "Required" install silently on Samsung KNOX devices. If a required app is updated, the update also installs silently. How do I removed required apps from Samsung KNOX-enrolled devices? To provide these capabilities, when users enroll their Samsung KNOX device with Mobility Suite, the following clients are installed: 312 Using Symantec Mobility: Device Management About Samsung KNOX support The Work Hub supports the MAM functionality. The Work Hub is the app that users access to download corporate apps from your app store. This client supports the MDM functionality. Users do not perform any tasks from this app. However, it is required to be on their device to offer MDM functionality. A message appears when users open the app to warn about removing it. See Removing the Corporate Access for Samsung client from an Android device. Important: Your device policy must have the option Enable MDM for Android devices selected. Otherwise, the enrollment process does not install Corp Access for Samsung and MDM is not supported on the device. However, the Work Hub is installed and mobile application management is supported. 313 Using Symantec Mobility: Device Management About Samsung KNOX support More information See “Building the Android Work Hub” on page 53. See “Creating device policies” on page 304. 314 Chapter 13 Using Symantec Mobility: Threat Protection This chapter includes the following topics: ■ Securing mobile devices with Symantec Mobility: Suite ■ Mobile security implementation workflow ■ Inviting users to enroll in Norton Mobile Security ■ Downloading and installing Norton Mobile Security (NMS) manually ■ Symantec Mobility: Suite Mobile Security: User experience ■ Remediating false-positive malware alerts ■ Threat Protection settings for device policies ■ Using Symantec Mobility: Suite device compliance rules ■ Creating and managing compliance rules ■ Associating a compliance rule with a device policy ■ Mobile security commands ■ Checking the status of sent Mobile Security commands ■ Tracking device compliance in Symantec Mobility: Suite ■ Threat protection reporting in Symantec Mobility Using Symantec Mobility: Threat Protection Securing mobile devices with Symantec Mobility: Suite Securing mobile devices with Symantec Mobility: Suite Symantec Mobility: Suite provides features to enhance mobile security for Android devices. Mobility Suite device compliance rules can evaluate the status of Norton Mobile Security (NMS) on enrolled Android devices. You can also send commands to enrolled devices; one at a time or in multiples. Device users that do not already have NMS installed on them can download and install the NMS app. Upon registration with Mobility Suite, and depending on device policy settings, Android devices with malware on them can be blocked from using certain network resources. Users that already have NMS installed are prompted to enroll with Mobility Suite. See “Mobile security implementation workflow” on page 316. Click here to watch a video and learn more about Norton Mobile Security. Mobile security implementation workflow Table 13-1 lists and describes the steps required to implement the Symantec Mobility mobile security features. Table 13-1 Norton Mobile Security implementation workflow Task Description 1 Verify that Symantec Mobility: Suite is licensed for Mobile Security. See “Licensing Symantec Mobility: Suite” on page 32. 2 Invite users to download and install Norton Mobile Security. See “Inviting users to enroll in Norton Mobile Security” on page 317. Note: You can use an App Policy to make the Norton Mobile Security app a required app. See “Making an app so that it is required and managing required apps” on page 362. 3 Users download and install the Norton Mobile Security app on their devices. See “Symantec Mobility: Suite Mobile Security: User experience” on page 320. 316 Using Symantec Mobility: Threat Protection Inviting users to enroll in Norton Mobile Security Table 13-1 Norton Mobile Security implementation workflow (continued) Task Description 4 Create a device policy with Threat Protection settings. See “Threat Protection settings for device policies” on page 322. 5 Create a compliance rule for Android devices that includes the Norton Mobile Security threat-protection features. See “Creating and managing compliance rules” on page 325. 6 Associate the compliance rule with a device policy. See “Associating a compliance rule with a device policy” on page 327. Click here to watch a video and learn more about Norton Mobile Security. Inviting users to enroll in Norton Mobile Security To use the mobile security features of Mobility Suite, you invite users to install and enroll the Norton Mobile Security (NMS) app with Mobility Suite. The following diagram depicts the enrollment workflow for both, admin and user: 317 Using Symantec Mobility: Threat Protection Inviting users to enroll in Norton Mobile Security Note: If Norton Mobile Security is already on the device, the user is simply invited to enroll with Mobility Suite There are three ways to invite users to enroll in Norton Mobile Security: ■ A: Send users a Norton Mobile Security e-mail enrollment invitation. A template is provided with a basic greeting, instructions, and URL to the app. You can edit the greeting as desired using the built-in editor. You can add user email addresses singly, add groups of users or use a comma-separated list (on a single line) to add several email addresses at one time. Warning: Each invitation contains a unique ID and can only be used once. Emails cannot be forwarded or otherwise duplicated for reuse, for instance, by sending to a departmental mailing list. If a device user inadvertently loses or deletes their invite, they must request that another is sent to them. The NMS app token associated with each enrollment invitation expires at 90 days. After that time, a new email must be sent. 318 Using Symantec Mobility: Threat Protection Downloading and installing Norton Mobile Security (NMS) manually See “Sending and re-sending invitation emails” on page 282. See “Customizing user invitation emails” on page 284. ■ B: Tell the device user to use the Work Hub on their device to download the Norton Mobile Security app. (Norton Mobile Security is located under Apps.) User download and installation instructions for NMS are included in the Symantec Mobility: Suite User Guide. ■ C: Provision the Norton Mobile Security app on an internal server and send users a link to the app. Note: To use this option, you must set Mobility Suite to provision the app for "side-loading." Additionally, users must set their Android devices to allow apps from unknown sources. See “Downloading and installing Norton Mobile Security (NMS) manually” on page 319. Entitling users for Norton Mobile Security If your installation of Mobility Suite includes the mobile security features (Trial and Enterprise versions), the Norton Mobile Security app is made available in your Work Hub list. You must apply an app entitlement to the Norton Mobile Security app for the groups that use it. Additionally, the Norton Mobile Security app is not customizable nor can it be deleted from the App Details page in the Mobility Manager. See “About defining and managing app configurations in Symantec Mobility: Suite” on page 366. Click here to watch a video and learn more about Norton Mobile Security. Related information See “Tracking user invitations” on page 283. See “Types of Symantec Mobility: Suite user invitation emails” on page 281. Downloading and installing Norton Mobile Security (NMS) manually If Google Play is unavailable, or if you need to provision the NMS app from a local resource, you can set the option in Mobility Suite to allow the Norton Mobile Security app to be side-loaded onto the device. Side-loading circumvents Google Play and 319 Using Symantec Mobility: Threat Protection Symantec Mobility: Suite Mobile Security: User experience also requires your device users set the option on their devices to allow app installations from unknown sources. Setting Mobility Suite to allow side-loading apps 1 In the left menu, select Settings > Side loading applications. 2 In the right pane, check Enable side loading for Norton Mobile Security (Android only). 3 Click Save. For more details, and instructions for your users to set the option to allow app installs from unknown sources, see the knowledge base article, Frequently asked questions about side-loading Norton Mobile Security on Android at www.symantec.com/docs/TECH218353. Symantec Mobility: Suite Mobile Security: User experience Symantec Mobility: Suite mobile security is managed on Android devices through the Norton Mobile Security (NMS) app for Android. Some NMS features are provided independently of Mobility Suite, such as malware protection. However, devices with NMS and enrolled with Mobility Suite are capable of being policed with the Mobility Suite mobile security functions. User-required actions Device policies determine the actions (if any) a user must take to remediate a non-compliance status. For example, malware threats cannot be removed by the Mobility Suite admin, and must be removed by the device user. If for example, a policy forbids email retrieval from an infected device, then the malware threat must be removed from the device before email access is restored. Norton Mobile Security installation and enrollment To begin using the mobile security features of Mobility Suite, the device user either installs Norton Mobile Security and enrolls with Mobility Suite, or if already present on the Android device, proceeds with enrollment. The two scenarios go as follows: 1 The user does one of the following, depending on which method you ask them to use: ■ From an enrollment email invitation: If Norton Mobile Security is not on the device, an Install button is displayed. If Norton Mobile Security is already on the device, an Enroll button appears. In either case, the user taps the button to proceed. 320 Using Symantec Mobility: Threat Protection Remediating false-positive malware alerts ■ 2 From the Work Hub: Users tap Apps and then tap the Norton Mobile Security icon. If Norton Mobile Security is not on the device, an Install button is displayed. If Norton Mobile Security is already on the device, an Enroll button is displayed. The user taps the button and proceeds with the associated workflow, Install or Enroll. Users that download the app install it and accept the license agreement, launch the app, and are prompted to enroll. If Norton Mobile Security is already on the device, the user is prompted to accept the license agreement and then to enroll. Removing the threats identified by Norton Mobile Security Norton Mobile Security alerts device users when known threats are identified. Users tap the threat notification to open Norton Mobile Security and go to the Anti-Malware tab. A Trash icon appears next to infected apps. The user taps the icon and then OK to remove the app (and associated threat). Note: Threats cannot be removed from devices remotely by the Mobility Suite administrator. Click here to watch a video and learn more about Norton Mobile Security. Remediating false-positive malware alerts Symantec Mobility: Suite administrators may issue device policies that specifically prohibit device access to corporate resources when the device is non-compliant with the policy settings. In cases where the policy is using status information from a Norton Mobile Security client residing on the Android device, a known-good app may be flagged as being malware- a condition referred to as a false positive. To remediate the malware threat, delete the malware app from the device. The app must be deleted by the user; Symantec Mobility administrators cannot delete apps from Android devices remotely. However, this action may not desirable. For instance, the app may be important to the user or to the enterprise. In such cases, the Symantec Mobility administrator should submit a false-positive report to Symantec. This report is called a “Mobile Application Rating Dispute Submission”. Go to https://www.symantec.com/false_positive/ and complete the form, providing the following information: ■ When the detection occurred: Choose the selection: “During a scheduled scan or during a scan I requested” 321 Using Symantec Mobility: Threat Protection Threat Protection settings for device policies ■ Product being used: Choose the selection: “Norton Mobile Security (any version)” On the last page of the submission form, provide the required information: ■ Name of person to contact ■ Email address ■ Whether you are the creator or distributor of the app ■ The name and web site of the company making the app ■ The name and version of the app ■ App download URL ■ Description of the app ■ The reason for submitting the form Optionally, provide the MD5 or SHA256 hash of the app in question (instructions for obtaining the hash are provided on the form). If you are the creator or a distributor of the app, you also have the option to provide information about your app-code signatory (the issuer and subject). Symantec typically responds within 24-48 hours. Warning: If a device policy is set to block access to email servers or secured apps in Mobility Suite, a minimum 12 hour lockout takes effect when malware is detected on the device. This is the shortest interval between device scans by Norton Mobile Security. More information See “Creating and managing compliance rules” on page 325. See “Managing the mobile devices enrolled with Symantec Mobility: Suite” on page 288. Click here to watch a video and learn more about Norton Mobile Security. Threat Protection settings for device policies In the Suite and Threat Protection versions of Symantec Mobility, you can create a device policy for enforcing various threat protection-related conditions on Android devices. When you specify any of the Threat Protection Settings to be something other than User Defined, the device policy settings are enabled and enforced by the device policy. 322 Using Symantec Mobility: Threat Protection Threat Protection settings for device policies Note: These settings apply to Android devices that have the Norton Mobile Security app installed. The settings will successfully apply on Android 3.9 and higher. The policy settings are ignored by devices running Android versions prior to 3.9. See “Securing mobile devices with Symantec Mobility: Suite” on page 316. Threat protection device policy settings ■ Anti-Malware Scan Frequency- The default setting is User Defined, which lets the user define how often their device is scanned. Anti-malware scanning can take time and consume battery power, so many admins allow the device user to set how often their device is scanned. If you chose to administrate this feature, you can set the scan frequency to Daily, Weekly, or Monthly. ■ Scan SD card- If checked, when the Anti-Malware Scan is performed, the SD card is also scanned for malware. ■ Web protection- The default setting is User Defined. When set to Enabled, the web protection features of Norton Mobile Security are enabled on the device. See the Norton Mobile Security client help for information about this feature. Creating device policies that use Threat Protection Settings Use the following procedure to specify threat protection settings in device policies: Set threat protection settings 1 Go to Policies and rules> Device policies > New Device Policy Note: You can also edit an existing device policy to add the threat protection settings. Select the device policy from the Device policies list and click the Edit icon (pencil). 2 Enter a name and optionally, a description for this policy. 3 Scroll down to Threat protection settings. 4 Select the desired threat-protection settings. 5 If no other device policy settings are required for this policy, click Save. Otherwise, select any other settings you need and then click Save. See “Creating device policies” on page 304. You can also create a Compliance Rule to require that certain threat-protection settings are in place. See “Associating a compliance rule with a device policy” on page 327. 323 Using Symantec Mobility: Threat Protection Using Symantec Mobility: Suite device compliance rules Using Symantec Mobility: Suite device compliance rules Device compliance rules control access to email and secured ("wrapped") apps for iOS and Android devices, based on criteria that you set. You associate compliance rules with device policies, which are in-turn, assigned to groups or individual devices. Mobility Suite uses the status information provided by the Norton Mobile Security app to determine whether an Android device is free of malware or in a state of remediation. Table 13-2 describes the workflow to implement device compliance rules in Symantec Mobility: Suite. Table 13-2 Step 1 Compliance workflow Task Description Create one or more compliance Compliance rules let you define the requirements rules. for mobile devices. You specify the actions Mobility Suite takes for out-of-compliance devices. See “Creating and managing compliance rules” on page 325. 2 Associate compliance rules with You invoke a compliance rule by associating it device policies. with a device policy See “Associating a compliance rule with a device policy” on page 327. 3 Monitor device compliance. You monitor device compliance through reports or viewing device details in Mobility Manager: Note: Users must delete threats from their devices, Mobility Suite administrators can't remove threats from users' devices. It may take up to 15 minutes for deleted threats to appear on the Compliance report. See “Tracking device compliance in Symantec Mobility: Suite” on page 329. More information See “Securing mobile devices with Symantec Mobility: Suite” on page 316. 324 Using Symantec Mobility: Threat Protection Creating and managing compliance rules Creating and managing compliance rules Compliance rules let you control which devices can connect to Symantec Mobility: Suite, which can access email, and which can use secured ("wrapped") apps. Create a compliance rule 1 Click Policies and rules > Compliance rules. 2 In the upper right corner, click New Rule. 3 Type a Name and a Description for the rule. 4 Under Requirements, select the compliance requirements: Not a jailbroken/rooted device The device is not rooted/jailbroken. NMS client installed (Android devices only) The device has an active Norton Mobile Security client installed. Antivirus definitions up-to-date (Android devices with NMS client only) The device's antivirus definitions are up-to-date. No malware/threat detected (Android devices with NMS client only) The device contains no malware or threat, or the threat is identified and remediated. Note: Users must delete threats from their devices, Mobility Suite administrators can't remove threats from users' devices. It may take up to 15 minutes for deleted threats to appear on the Compliance report. See “Running reports in Symantec Mobility: Suite” on page 398. MDM compliant The device complies with its assigned MDM policy. See “Creating device policies” on page 304. 325 Using Symantec Mobility: Threat Protection Creating and managing compliance rules 5 Under Enforcements, specify how you want Mobility Suite to enforce a rule for non-compliant devices: Block access to email Blocks access to the email proxy and the user cannot access through email proxy new email from the non-compliant device. (iOS and Android) See “Blocking email access for non-compliant devices” on page 217. Block access to Blocks user access to Mobility Suite wrapped apps on the wrapped applications non-compliant device. (iOS and Android) 6 Click Save. Managing compliance rules Mobility Manager displays a list of existing compliance rules. Click on a rule to see a summary of its settings. You can also clone, delete, or edit compliance rules. Manage compliance rules 1 Click Policies and rules > Compliance rules. 2 Select a rule from the Compliance rules list. 3 Do any of the following: To copy a rule: ■ Click the Clone icon (double pages). ■ Change the name of the rule and make the required modifications. Tip: Compliance rule names must be unique. Click Save. ■ To delete a rule: ■ Click theDelete icon (trash can). ■ Click Yes to confirm that you do want to delete the compliance rule. To edit a rule: ■ Click the Edit icon (pencil). ■ Make the required modifications. ■ Click Save. Next See “Associating a compliance rule with a device policy” on page 327. 326 Using Symantec Mobility: Threat Protection Associating a compliance rule with a device policy More information See “Using Symantec Mobility: Suite device compliance rules” on page 324. See “Tracking device compliance in Symantec Mobility: Suite” on page 329. Associating a compliance rule with a device policy Compliance rules establish the compliance criteria you apply to the devices you manage in Symantec Mobility: Suite. After you define your compliance rules, you associate them with device policies. Associate a compliance rule with a device policy 1 Click Policies and rules > Device policies. 2 Select a device policy and then click the Edit icon. 3 Under General settings, click the Compliance rule drop-down menu and select the rule that you want to apply to this policy. Note: You can select only one compliance rule per device policy. 4 Make any other changes to your device policy as needed. See “Creating device policies” on page 304. 5 Click Save. Next See “Tracking device compliance in Symantec Mobility: Suite” on page 329. More information See “Using Symantec Mobility: Suite device compliance rules” on page 324. Mobile security commands To help you manage mobile security, Symantec Mobility: Suite provides the following security-related commands that you can send to managed devices. 327 Using Symantec Mobility: Threat Protection Checking the status of sent Mobile Security commands Table 13-3 Mobile security commands Command Location in Admin Console Description Run A/V scan on devices Devices > (one or more devices) > Commands Select one or more devices from the device list and click Commands > Run A/V Scan. Scans devices for existing viruses, worms, spyware, and Trojans. Run LiveUpdate Devices > (one or more devices) > Commands Select one or more devices from the device list and click Commands > Run LiveUpdate. The LiveUpdate service downloads A/V definitions for the A/V scanner. Send Norton Mobile Security Invite Users > (User) > User Actions Select a user to send or resend an invitation to enroll with Norton Mobile Security. See “Inviting users to enroll in Norton Mobile Security” on page 317. Several other commands are available for other device management tasks: See “Commands that can be sent to mobile devices” on page 450. More information See “Viewing a device's command history” on page 303. Checking the status of sent Mobile Security commands You can easily check the status of the commands you send to devices: Check the status of sent commands Go to the Devices page, and do one of the following: ■ Check a single device: Select a single device and at the top of the device details, click Command history. ■ Check multiple devices: Select two or more devices (use the check-boxes to select multiple devices) and on the right, for each command, select View Status. 328 Using Symantec Mobility: Threat Protection Tracking device compliance in Symantec Mobility: Suite Note: You can use the search filters to narrow the list. ■ Check all devices: With no devices selected, on the right, click Recent commands. The device ID, status, user, command, issuer, and last update are displayed for each device. Tracking device compliance in Symantec Mobility: Suite You can track device compliance in Mobility Manager. Compliance metrics appear in the following Mobility Manager locations: ■ Dashboard page: Snapshot of device compliance metrics See “About Symantec Mobility Manager” on page 18. ■ Devices page: Compliance status of a selected device See “Viewing device details and settings” on page 294. ■ Devices page: The compliance rule that is associated with a selected device policy See “Creating device policies” on page 304. ■ Reports: Device compliance reports See “Running reports in Symantec Mobility: Suite” on page 398. More information See “Using Symantec Mobility: Suite device compliance rules” on page 324. Threat protection reporting in Symantec Mobility Symantec Mobility provides out-of-the-box reporting for threat protection-related activities: ■ NMS Protection Report Provides the following information: ■ Device name ■ User name ■ Last communication with the Mobility server ■ Last scan time (A/V scan) 329 Using Symantec Mobility: Threat Protection Threat protection reporting in Symantec Mobility ■ ■ Phone number ■ Device state ■ AV definition (date last updated and version) ■ AV Status Threat log report Provides the following information: ■ Device name ■ User name ■ Threat name ■ Threat type ■ Install Time ■ App ■ Detection Time ■ Resolution Time See “Running reports in Symantec Mobility: Suite” on page 398. 330 Chapter 14 Using Symantec Mobility: Application Management This chapter includes the following topics: ■ Adding apps to Symantec Mobility: Suite ■ Using App Polices to manage apps in Symantec Mobility ■ Commonly used Symantec Mobility app policies ■ About defining and managing app configurations in Symantec Mobility: Suite ■ Creating custom app and content metadata fields ■ Customizing wrapped app badging ■ Publishing apps ■ Using Symantec Sealed apps Adding apps to Symantec Mobility: Suite You add apps to your Mobility Suite app library and then make them available to your device users. The process of adding an app differs, based on the type of app, and in some cases, the role of the person who adds the app. Similarly, app publishing is affected by role, publishing phase, and the type of app. For instance, native, web, and secure web apps can be published to the Development, Beta, and Production phases of the app life cycle. However, store pointer apps can only be published to the Production phase. See “Publishing apps” on page 376. Using Symantec Mobility: Application Management Adding apps to Symantec Mobility: Suite In many cases, you associate an app with an app policy. App policies control how an app "behaves" with respect to the criteria you set up in the policy. See “Creating and managing app policies” on page 346. App size considerations No explicit maximum size limits for apps apply. However, when creating your apps, keep in mind that if an app is too large, it may timeout due to the web server's configuration. For more information about app size considerations, refer to the following knowledge base article: http://www.symantec.com/docs/HOWTO82309 Adding apps manually Depending on the type of app, the workflow to add it to Mobility Suite are slightly different. The references at the end of this topic take you to specific instructions for each app type. See “Adding a native app to Symantec Mobility: Suite” on page 335. See “Adding a web app to Symantec Mobility: Suite” on page 336. See “Adding a secure web app to Symantec Mobility: Suite” on page 338. See “Adding a store pointer app to Symantec Mobility: Suite” on page 340. See “Adding a Symantec Sealed app to Symantec Mobility: Suite” on page 342. See “Adding a VPP app to Symantec Mobility: Suite” on page 343. Adding apps automatically Some apps can be added automatically to your Mobility Suite: ■ If you are enrolled in the Apple Volume Purchase Program - Managed Distribution (VPP) service, and enable the option to Automatically add licensed VPP Apps these apps are automatically added. See “Setting up Apple Volume Purchase Program - Managed Distribution (VPP)” on page 245. ■ If you participate in the Symantec Sealed Program and configure your WorkSpace Settings to Automatically include Symantec Sealed apps in Workspace as they're made available in public app stores. See “The WorkSpace and using Symantec Sealed apps with Mobility Suite” on page 384. Mobility Suite sends an email notification to the administrator when a VPP or Sealed app is automatically added. 332 Using Symantec Mobility: Application Management Adding apps to Symantec Mobility: Suite After you add an app After apps are added (manually or automatically), complete the following tasks: ■ Assign ("entitle") the app to a user or group See “Entitling apps to users and groups” on page 344. ■ Create and apply an app policy to the app. See “Creating and managing app policies” on page 346. ■ Publish the app See “Publishing apps” on page 376. Important caveats Be aware of the following caveats regarding apps and app publishing: ■ Developers can only add apps to the Development phase of the app life cycle. ■ Publishers and Administrators can add apps to the Development, Beta, and Production phases. ■ Developers, Publishers, and Administrators can assign an app policy to the app when they add the app. ■ App policies can only be assigned to native and secure web apps. Additionally, app policies are not enforced on the apps that are added to the Development phase. ■ Developers, Publishers, and Administrators can specify the groups and users who can install the app. However, only Administrators and Publishers can specify the groups and users who must install the app. Next If you're setting up Secure App Proxy: See “Using Symantec Secure Web to test Secure App Proxy installation” on page 163. More information See “Making your workforce more productive using the Symantec Sealed apps provided with Symantec Mobility: Suite” on page 383. Symantec Mobility: Suite app types Table 14-1 lists the types of apps you can add to your Mobility Suite. 333 Using Symantec Mobility: Application Management Adding apps to Symantec Mobility: Suite App types Table 14-1 App type Description Native app An app that is downloaded on the end user's device and designed to run specifically on the device's operating system. Typically, your organization creates and secures this app for your organization's own use. See “Adding a native app to Symantec Mobility: Suite” on page 335. Web app An app that links to a website based on a specified URL. A shortcut is created for this app on the end user's device, which launches the app in the device's default browser (e.g., Safari, Chrome). See “Adding a web app to Symantec Mobility: Suite” on page 336. Secure web app A web app that is launched in a Symantec Mobility: Suite browser (or "sandbox") on the end user's device (not the device's default browser). See “Adding a secure web app to Symantec Mobility: Suite” on page 338. Store pointer by URL app An app that links to an app at an external app store (e.g., Apple App Store or Android Google Play). This type of app lets end users download the app directly from the external app store onto their device. See “Adding a store pointer app to Symantec Mobility: Suite” on page 340. Symantec Sealed app An app that incorporates Symantec Sealed technology. Symantec Sealed apps are provisioned on the same app venues as other apps. Symantec maintains and promotes a catalog of Symantec Sealed apps. Symantec stringently tests Sealed apps to ensure that the security controls provided by the Sealed technology work as intended with the app and within the Mobility Suite environment. The benefits of using Symantec Sealed apps are: ■ ■ ■ Isolated and protected operation in a secure Mobility Suite WorkSpace See “The WorkSpace and using Symantec Sealed apps with Mobility Suite” on page 384. Developer-recommended app policy settings Stringent testing by Symantec to verify the Symantec Sealed functionality and security features You can configure Mobility Suite to automatically add Sealed apps as they become available in the app stores or you can manually add them. See “Adding a Symantec Sealed app to Symantec Mobility: Suite” on page 342. 334 Using Symantec Mobility: Application Management Adding apps to Symantec Mobility: Suite App types (continued) Table 14-1 App type Description VPP apps An iOS store pointer app that requires an Apple Volume Purchase Program - Managed Distribution (VPP) license. To use VPP apps, you must first configure VPP in Mobility Suite. Then you can automatically have VPP apps added when they become available. Or you can add them the same way you do a store pointer by URL app. See “About using the Apple Volume Purchase Program - Managed Distribution (VPP) with Symantec Mobility: Suite” on page 244. See “Adding a VPP app to Symantec Mobility: Suite” on page 343. More information See “Adding apps to Symantec Mobility: Suite” on page 331. Adding a native app to Symantec Mobility: Suite A native app is programmed for specific device operating systems. iOS native apps have the file extension, .IPA and Android native apps have the file extension, .APK. Typically, a native app is created and secured by your organization for your organization's own use. Note: You must upload the app's code-signing certificate to Mobility Suite before you can add a native app. See “Uploading the Distribution (code-signing) certificate to Symantec Mobility: Suite” on page 82. Add a native app 1 Click Apps > App list and at the upper right, click Add App. 2 On the Add new app page, click Upload app. 3 Browse to and select the iOS or Android app. 4 On the Add new app page, you can edit the default title, and optionally add a subtitle and description for this app. 5 Under Policy, click the drop-down list and select the policy that you want to assign to this app. See “Creating and managing app policies” on page 346. 335 Using Symantec Mobility: Application Management Adding apps to Symantec Mobility: Suite 6 Under Publication, specify any one of the following publication types: Not Publishing Apps published to this version appear in the Mobility Manager, but are unavailable to users. Administrators and Publishers can set the version of this app to Development, Beta, or Production at a later time. Additionally, apps published to this version cannot be assigned to users at this time. Publish as Production Sets the app live and available to all users it's assigned to. The next time the Work Hub updates on the end users mobile device, the app is available for download. Publish as Beta Makes the app available to beta users. Beta users can be any users within the group you choose when publishing. Set as Development Makes the app available for developers (for example, to code the app). App policies are not enforced on apps that are published to this version. 7 Under Phone screen shots and/or Tablet screen shots, click Browse and add screen shots. 8 Click Save to save your app. More information See “Entitling apps to users and groups” on page 344. See “Adding apps to Symantec Mobility: Suite” on page 331. Adding a web app to Symantec Mobility: Suite Symantec Mobility: Suite lets you add web apps to your app store. A web app is simply a shortcut to a webpage. The web app appears on the user's device as an app icon. When the user taps the web app, the website is accessed through the default web browser (e.g., Safari or Chrome). If you publish the app (beta, development, or production), you can assign the app to users and groups. However, you cannot assign an app policy to a web app. Note: Web apps that have policies assigned to them are Secure Web apps. See “Adding a secure web app to Symantec Mobility: Suite” on page 338. 336 Using Symantec Mobility: Application Management Adding apps to Symantec Mobility: Suite Add a web app 1 Click Apps > App list and at the upper right, click Add App. 2 Click Add web app, secure web app, or store pointer by URL. 3 Type or copy/paste the URL for the webpage shortcut into the URL field and click Fetch. 4 Below the confirmation message, click Add Web App. 5 On the Add new app page, you can edit the default title and optionally type a subtitle for this app and edit the description. You can also select a different language for the text boxes; click the language selector (default is "EN") to select a language. 6 Beside Platform, select the appropriate platform (iOS or Android). 7 Under Publication, specify any one of the following publication types: Not publishing Indicates that this app is not available for anyone to use. Publish as Production Sets the app live and available to all users it's assigned to. The next time the Work Hub updates on the users mobile device, the app is available for download. Publish as Beta Makes the app available to beta users. Beta users can be any users within the group you choose when publishing. Set as Development Makes the app available for developers (for example, to code the app). App policies are not enforced on the apps that are published to this version. If you select any publication channel other than Not publishing, an Entitlements category appears. 8 Under Entitlements, select the Groups or Users who are entitled to download the app. For groups that are required to download the app, enable the Required option. For users that are required to download the app, add the users in the Select required users box. You can also create app configurations that you assign to users and groups. See “About defining and managing app configurations in Symantec Mobility: Suite” on page 366. 9 Click Phone screen shots and/or Tablet screen shots, click Browse and add screen shots. 10 Click Save to save your app. The app is immediately available to the specified groups and/or users. 337 Using Symantec Mobility: Application Management Adding apps to Symantec Mobility: Suite More information See “Adding apps to Symantec Mobility: Suite” on page 331. Adding a secure web app to Symantec Mobility: Suite Symantec Mobility: Suite lets you add a secure web app to your app store. A secure web app is a shortcut to a webpage, but it has additional security features that a regular web app does not. A web app is launched in a Mobility Suite browser (or "sandbox") on the end user's device (not the device's default browser). You must apply an app policy for a secure web app and you must secure it with a provisioning or keystore certificate. To add a secure web app, you'll need the following items: Prerequisites ■ App policy When you create a secure web app, you must apply an app policy to it. Make sure that you have already set up your app policy. See “Creating and managing app policies” on page 346. ■ iOS web clip ■ ■ iOS code-signing certificate Each iOS app that you add is cryptographically signed using an iOS code-signing certificate. See “Managing the iOS app and MDM certificates used by Symantec Mobility: Suite” on page 75. ■ Mobile Provisioning Profile You need to assign your Mobile Provisioning Profile to an iOS Secure web Apps when you add it. See “Managing the iOS app and MDM certificates used by Symantec Mobility: Suite” on page 75. Android web clip You can select an existing key or create your own from Mobility Manager. Add a secure web app 1 Click Apps > App list and at the upper right corner, click Add App. 2 Click Add web app, secure web app, or store pointer by URL. 3 On the Add new app page under URL, type the URL of the web app, and then click Fetch. 4 Check Make secure web app, and then click Add web app. 338 Using Symantec Mobility: Application Management Adding apps to Symantec Mobility: Suite 5 On the Add new app page, you can edit the default title and optionally type a subtitle for this app and edit the description. You can also select a different language for the text boxes; click the language selector (default is "EN") to select a language. 6 Beside Platform, select the appropriate platform (iOS or Android). 7 Optionally, if you want to replace the app's icon, click Replace Icon and browse to and select the graphic file you want to use for the app icon. 8 Type a description of this app to help your users understand the purpose of the app. 9 Under Policy, click the drop-down list and select the policy that you want to assign to this app. 10 Do one of the following tasks: iOS secure web app Under Provisioning, click Browse to locate your mobile provisioning file. Android secure web app Under Keystore, do one of the following: ■ ■ Click the drop-down menu to select a key from the keystore. Click Create new to create a new key. 11 Under Publication, specify any one of the following publication types: Publish as production Sets the app live and available to all users it's assigned to. The next time the Work Hub updates on the user's mobile device, the app is available for download. Publish as beta Makes the app available to beta users. Beta users can be any users within the group you choose when publishing. Publish as development Makes the app available for developers (for example, to code the app). App policies are not enforced on apps that are published to this version. 339 Using Symantec Mobility: Application Management Adding apps to Symantec Mobility: Suite 12 Under Entitlements, select the Groups or Users who are entitled to download the app. For groups that are required to download the app, check the Required option. For users that are required to download the app, add the users in the Select required users box. You can also create app configurations that you assign to users and groups. See “About defining and managing app configurations in Symantec Mobility: Suite” on page 366. 13 Under Phone Screen shots and/or Tablet Screen shots, click Browse and add screen shots. 14 Click Save to save your app. The app is immediately available to the specified groups and/or users. More information See “Adding apps to Symantec Mobility: Suite” on page 331. Adding a store pointer app to Symantec Mobility: Suite Symantec Mobility: Suite lets you add store pointer apps to your app store. A store pointer app is simply a shortcut to an app in an external app store (e.g., Apple App Store or Android Google Play). Users tap your store pointer app and are directed to the appropriate location in the external app store where they can download the app onto their device. Add a store pointer app 1 Click Apps > App list and at the upper right, click Add App. 2 Click Add web app, secure web app, or store pointer by URL. 3 On the Add app by URL page, do any of the following tasks: If you know the URL of the external store Type the URL in the URL field. app 340 Using Symantec Mobility: Application Management Adding apps to Symantec Mobility: Suite To locate a store pointer link for Apple App Store 1 Click iOS store pointer search. 2 Search for the app that you want to add. 3 Click on the app link and copy the entire Direct Link. For example, the Direct Link for Symantec Work Mail for iPhone is: https://itunes.apple.com/us/app/ symantec-secure-email-for-ios/ id635147409?mt=8&uo=4 4 To locate a store pointer link for Android 1 Google Play 4 Return to the Mobility Manager and paste the direct link into the URL field. Click Android Google Play Store search. 2 Search for the app that you want to add and select it. 3 Copy the app URL in your browser's navigation pane. 4 Return to the Mobility Manager and paste the direct link into the URL field. Click Fetch. A message appears below the Fetch option indicating that Mobility Suite is ready to create the app. This message means that the URL is valid. 5 Click Add Store Pointer. 6 On the Add new app page, you can edit the default title and optionally type a subtitle for this app and edit the description. You can also select a different language for the text boxes; click the language selector (default is "EN") to select a language. 7 Under Entitlements, select the Groups or Users who are entitled to download the app. For groups that are required to download the app, check the Required option. For users that are required to download the app, add the users in the Select required users box. You can also create app configurations that you assign to users and groups. See “About defining and managing app configurations in Symantec Mobility: Suite” on page 366. 341 Using Symantec Mobility: Application Management Adding apps to Symantec Mobility: Suite 8 Under Phone Screen shots and/or Tablet Screen shots, click Browse and add screen shots. 9 Click Save to save your app. The app is immediately available to the specified groups and/or users. More information See “Adding apps to Symantec Mobility: Suite” on page 331. Adding a Symantec Sealed app to Symantec Mobility: Suite Symantec Sealed™ technology is applied to native apps created by Symantec Sealed Partner Program app developers. Apps using the Sealed technology are called Symantec Sealed apps. The technology adds extra security features to apps, for instance, restricting how they share data or which apps they can interact with. By default, Symantec Mobility: Suite automatically adds your Sealed apps to Mobility Suite as soon as they become available in the public app stores. When sealed apps are automatically added, Mobility Suite sends the administrator an email notification. However, you can opt to manually add them instead. When Sealed apps are added to Mobility Suite, they are assigned the default policy that you specified for your WorkSpace. However, you can edit the app to change the default policy. See “Adding apps to Symantec Mobility: Suite” on page 331. Automatically add Sealed apps to Mobility Suite 1 Click Apps > App list and at the upper right corner, click WorkSpace settings. 2 Verify that Automatically include Symantec Sealed apps in WorkSpace as they're made available in public app stores is checked. 3 If you make any changes, click Save. See “The WorkSpace and using Symantec Sealed apps with Mobility Suite” on page 384. Manually add Sealed apps to Mobility Suite Note: The option, Automatically include Symantec Sealed apps in WorkSpace as they're made available in public app stores must be disabled to manually add Sealed apps to Mobility Suite. 342 Using Symantec Mobility: Application Management Adding apps to Symantec Mobility: Suite 1 Click Apps > App list and in the upper right corner, click Add app. 2 in the Add new app window, click Add Symantec Sealed app. 3 Check the app or apps to be added and then click Add Sealed apps. Note: To select all of the Sealed apps, check the box at the top of the list (next to "App name"). The apps are added to your list of apps. More information See “Symantec Mobility: Suite app types” on page 333. See “Making your workforce more productive using the Symantec Sealed apps provided with Symantec Mobility: Suite” on page 383. See the Symantec Sealed Program Developer's Guide. Adding a VPP app to Symantec Mobility: Suite You can add Apple Volume Purchase Program - Managed Distribution (VPP) apps to Symantec Mobility: Suite either manually or automatically when they become available. Mobility Manager sends an email notification to the administrator when a VPP app is automatically added. But you'll still need to assign the app to a group, assign an app policy, enable app license management, and publish the app to make it available. For your end users to use VPP apps, you must set up VPP in Mobility Manager. See “Configuring VPP settings in Symantec Mobility: Suite” on page 248. Manually add VPP apps to Mobility Manager ◆ You manually add a VPP app the same way you do any other store pointer app. See “Adding a store pointer app to Symantec Mobility: Suite” on page 340. Automatically add VPP apps to Mobility Manager 1 Click Settings > App license management. 2 Under License Configuration, check Automatically add licensed VPP Apps to automatically add VPP apps to your Mobility Manager as they become available. Next See “Enabling app license management” on page 247. 343 Using Symantec Mobility: Application Management Adding apps to Symantec Mobility: Suite More information See “About using the Apple Volume Purchase Program - Managed Distribution (VPP) with Symantec Mobility: Suite” on page 244. See “Setting up Apple Volume Purchase Program - Managed Distribution (VPP)” on page 245. Entitling apps to users and groups You can specify who can or must download an app by applying entitlement information to the app. Note: Only Production versions can be entitled. See “Publishing apps” on page 376. Specify app entitlements 1 Go to Apps and select the app you want to entitle. In the right panel, in the Production Version section, click the Edit icon (pencil) 2 Under Entitlements in the Groups box, start typing the name of a group. A list of your existing Mobility Suite groups appears from which you can choose. You can select as many groups as needed. 3 You can assign an app configuration for that group. Mobility Suite only supports app configurations for iOS 7 or later apps that support this feature. Click the following link to learn more about creating app configurations and applying them to groups and users. See “About defining and managing app configurations in Symantec Mobility: Suite” on page 366. 4 Check Required if this app is a required app for that group or user. See “Making an app so that it is required and managing required apps” on page 362. 5 Click the + icon to add as many additional groups as are needed and repeat steps 3 - 4 to apply configurations to the groups and to make the app required. 6 If you added multiple groups, move them in the order that you want their entitlements applied by clicking on the Groups box and dragging it up or down. App entitlements are applied to the first match that occurs in the Entitlements table. If you define multiple Groups, the entitlement is only applied to the first group in the table to which the user belongs. 344 Using Symantec Mobility: Application Management Using App Polices to manage apps in Symantec Mobility 7 Click in the Select required users field, and start typing the name of a user who is required to install the app. Mobility Suite will begin to list names that match what you type. Select the name that you want to add. You can add as many users as are needed. 8 Click in the Select users field, and start typing the name of a user who is permitted to install the app, but not required to. Mobility Suite will begin to list names that match what you type. Select the name that you want to add. You can add as many users as are needed. 9 Repeat steps 3 -4 to add app configurations and make the app required. Using App Polices to manage apps in Symantec Mobility Managing the mobile apps you provision from Symantec Mobility requires one or more App Policies that you create in the Symantec Mobility admin console. App policy basics App policies control how apps (or data used by an app) can be used within the Mobility-managed network environment. For example, you can create app policies that require users to authenticate to launch the app or create an app policy to encrypt data. You create as many app policies as you need to enforce the mobile app management requirements of your organization. You assign the app policies to their respective apps after you create the policy. When you assign an app policy to an app, Mobility Suite takes the app apart, injects the wrap code, and repacks and resigns the app — a process known as "app wrapping." Note: Refer to the most current release notes to see if you are required to re-wrap your apps after you perform an upgrade. Re-wrapping an app updates the app to include any new policy enforcement "wrap code" distributed with an upgrade. After you re-wrap an app, end users who use that app are notified that a newer version is available to download. To fully take advantage of wrapping changes, you must also rebuild the Work Hub. Symantec Mobility documentation, including release notes. See “Rebuilding the in-house iOS Work Hub” on page 53. See “Rebuilding your Android Work Hub” on page 54. 345 Using Symantec Mobility: Application Management Using App Polices to manage apps in Symantec Mobility About applying policies to Android apps Android apps should have policies applied during initial publishing of the app. Apps installed on Android devices that don't initially have a policy applied to them must be uninstalled and then reinstalled after the policy is applied. When an app is wrapped, users receive an Android notification of an Mobility Suite update. But installing the update for the app referenced in the notification won't be possible. The user must uninstall the app and then re-install the wrapped version of the app. When an updated policy is applied to an already wrapped app (iOS or Android), the app is dynamically re-wrapped. If the Android Work Hub is running (in the foreground or background), the device receives an Android notification of an Mobility Suite update. If the Work Hub isn't running, the device receives the notification upon the next connection to Mobility Suite. In either instance, the user can simply update the policy without having to uninstall and reinstall the wrapped app. You must have the Can add app policy permission assigned to your role to create app policies. See “Assigning roles” on page 64. More information See “Creating and managing app policies” on page 346. See “Re-wrapping apps” on page 357. Creating and managing app policies Use the following workflows to create and manage app policies: Create a new app policy 1 Click Policies and rules > App Policies and in the upper right corner, click New App Policy. Troubleshooting: You create a new policy and this warning appears: The following options will be deselected and disabled 'Open with WorkSpace browser only'. See “The WorkSpace and using Symantec Sealed apps with Mobility Suite” on page 384. 2 Specify a name and description for your app policy. The Name field is mandatory. The app policy name appears in the Policy drop-down list when you add or edit an app. Tip: Create a description that distinguishes this policy from other app policies and denotes the key objective of the policy. 346 Using Symantec Mobility: Application Management Using App Polices to manage apps in Symantec Mobility 3 Configure the General Settings and Network Access Control settings. See “App policy configuration options” on page 349. 4 Click Save. App management roles App management tasks are constrained by Roles. For instance, you can't change an app's policy unless you are assigned to a role that includes the criteria, Can change app policy. Review the topics about assigning roles before you attempt to manage apps. See “Assigning roles” on page 64. Managing app policies The following table describes the available app management tasks and how to perform them: Table 14-2 Task Description App policy management tasks Role Procedure Assign apps to An app can only be associated with Can 1 an app policy a single app policy, but an app change 2 policy can be assigned to multiple app policy apps. When you assign a policy to an app, users who have already downloaded the unwrapped app are notified that a new version of the app is available. In this case, iOS users can install the updated version over the unwrapped version. However, Android users must uninstall the unwrapped version before installing the updated wrapped version. View View app policies to see what View App settings are applied. This may also Policy be helpful in troubleshooting policies that aren't working as intended. ◆ Click Apps > {Policy Name} > Edit icon. On the Edit App page, under Policy, select the policy from the drop-down list, and click Save. Click Policies and rules > App policies > {Policy Name}. The details of the policy appear in the right pane. 347 Using Symantec Mobility: Application Management Using App Polices to manage apps in Symantec Mobility Table 14-2 App policy management tasks (continued) Task Description Clone Cloning an existing app policy Can 1 creates a new policy with the same change properties of the policy from which app policy 2 it was cloned. The only property you can change on the new policy is the 3 policy name. However, you can edit the cloned policy if there are additional properties that you want to change. Edit Edited policy changes are applied to the associated apps at the time the changes are saved. You don't need to republish the apps. Note: An app whose app policy has changed is updated dynamically on a device running that app if (1) the app is communicating with your Mobility Suite server, (2) the app is enabled for authentication, and (3) the authentication period on that running app has not timed out. There are some settings within an app policy, however, that are not updated dynamically (e.g., Block iTunes file sharing), which are specified on the Policies and rules > App policies page. If an app is not enabled for authentication, or the authentication period has timed out, users are notified that there is a new version of the app available and must download it for the policy changes to take effect. Role Procedure Can 1 change app policy 2 Click Policies and rules > App policies > {Policy Name} > Clone. On the Clone app policy page, under Name, type a name for this policy. Click Save. Click Policies and rules > App policies >{Policy Name} > Edit. On the Edit app policy page, make your changes as required, and click Save. See “Creating and managing app policies” on page 346. 348 Using Symantec Mobility: Application Management Using App Polices to manage apps in Symantec Mobility Table 14-2 App policy management tasks (continued) Task Description Role Procedure Delete You can delete an app policy as Can 1 long as it is not assigned to an app. delete app Remove the app policy from any app policy 2 to which it assigned. Users who have downloaded an app from which a policy is deleted are notified that a new version of the app is available. You do not need to 3 republish the app. Click Policies and rules > App policies > {Policy Name}. In the right pane under Apps using this policy, click any app listed. You are directed to the Apps page for that app. Click Edit, and on the Edit app page, select No policy from the Policy drop-down list, and then click Save. 4 Repeat this procedure for each app that the policy is assigned to. 5 Return to the App Policy page, and on the center pane, click on the app policy that you want to delete again. Click the Delete icon and confirm. Next See “Adding a native app to Symantec Mobility: Suite” on page 335. See “Adding a secure web app to Symantec Mobility: Suite” on page 338. More information See “App policy basics” on page 345. App policy configuration options Configure app policies in Symantec Mobility: Suite to control how apps or app data are used. The following table describes the app policy options: 349 Using Symantec Mobility: Application Management Using App Polices to manage apps in Symantec Mobility Table 14-3 General Settings Label Option Description Authentication User authentication required Requires the user to enter a user name and password to launch the app. Tip: The following Authentication options are Tip: Encryption of on-device storage works whether or not not available when this authentication is enabled. However, if authentication is not option is disabled. enabled, encrypted storage is only available during the period that the app is running. Re-authentication required after [n] minutes of idle Forces the user to re-authenticate if the device screen locks or runs in the background for the number of minutes that you specify. Offline authentication permitted Allows the user to authenticate access to apps using your Offline PIN Policy. See “Configuring the local identity provider (IDP)” on page 105. See “Establishing an iOS Work Hub PIN policy” on page 145. Destroy data and disable Revokes the app if the user has violated your Password Lockout app upon password lockout policy. See “Configuring the local identity provider (IDP)” on page 105. Enable InterApp SSO SSO lets the user seamlessly authenticate to other wrapped apps or the Work Hub after initial authentication to the Work Hub or a wrapped app. See “Creating app policies that permit single sign-on (SSO)” on page 360. Encrypt initial application bundle Encrypts the app's bundle information. The app bundle is a type of directory containing resources, graphics, and other collateral required by the app. Encrypting this information increases security by preventing exposure of the directory contents. Tip: This settings change takes effect only on app reinstall. 350 Using Symantec Mobility: Application Management Using App Polices to manage apps in Symantec Mobility Table 14-3 General Settings (continued) Label Option Description On-Device Storage Allowed Allows the app to write and store app-related files and data to the device. The app reads the file and tries to store the annotated file locally. Android secure web apps don't support file downloads. Tip: Most apps need to write to the device to work properly. Encryption required Encrypts the app-related files and data that are written and stored to the device (e.g., files used for printing and uploading). Tip: This option is not available when the Allowed If you want to require encryption but not require user option is disabled. authentication, you must enable the Clear data on app close option. Clear data on app close Clears app-related data when the app is closed. If the app is not properly closed (e.g., the device is shut down while the app is running), the data is cleared the next time the app starts. Tip: This option is not available when the Allowed option is disabled. Tip: This option is useful, for example, for an unauthenticated secure web app that caches files. Permit SD card storage (for Android only) Allows the app to store files to any SD card on Android devices. 351 Using Symantec Mobility: Application Management Using App Polices to manage apps in Symantec Mobility Table 14-3 General Settings (continued) Label Option Description Usage Restrictions Inter-app document sharing Prevents apps from previewing, opening, copying, or printing files from other apps. Inter-app document sharing can also be restricted to apps running in the WorkSpace. ■ Allow app to share data only with other apps in their WorkSpace. Allow app to share data with all other apps on the device. ■ Prevent app from sharing data with any other app. ■ See “The WorkSpace and using Symantec Sealed apps with Mobility Suite” on page 384. Clipboard/Pasteboard sharing Prevents users from pasting text that they copy from an app or app-related file. Clipboard/Pasteboard sharing can also be restricted to apps running in the WorkSpace. ■ ■ ■ Browser choice for links in WorkSpace apps Allow app to share the clipboard/pasteboard only with other apps in their WorkSpace. Allow app to share the clipboard/pasteboard with all other apps on the device. Prevent app from sharing the clipboard/pasteboard with any other app. Restricts the opening of links from apps running in the WorkSpace to require a secure browser that is also running in the WorkSpace. If there is no secure browser in the WorkSpace, the user sees an error message to that effect. Only Symantec Sealed browser apps can apply this restriction. ■ ■ Open with WorkSpace browser only. An error message appears if there are no browsers are in WorkSpace. Open with WorkSpace or system default browser. Important: This option is less secure. See “The WorkSpace and using Symantec Sealed apps with Mobility Suite” on page 384. Destroy data and disable app on jailbroken (iOS) or rooted (Android) devices Destroys app-related data and disables the Work Hub if the user attempts to install it on jailbroken iOS devices and rooted Android devices. The following usage restrictions apply only to iOS 352 Using Symantec Mobility: Application Management Using App Polices to manage apps in Symantec Mobility Table 14-3 Label General Settings (continued) Option Description Block AirDrop and multi-peer file sharing Prevents users from using AirDrop or from using multi-peer file sharing apps to share documents. Block AirPrint File printing Prevents users from printing files using AirPrint. Block Social Media file sharing Prevents users from posting a file to a social media site, such as Twitter or Facebook. Block adding files to Safari reading list Prevents users from adding files to their Safari browser reading list. Block iTunes file sharing Prevents an app from sharing any files with iTunes. Tip: Without this option, application files in <Application_Home>Documents directory may be backed up and shared to iTunes. Block iCloud file sharing In iOS 5 and later, an application can tag files for cloud storage that are synced to the user's iCloud account. This option prevents document syncing, uploading, and downloading with iCloud. The following usage restrictions are effective for Android only If the client is removed or MDM is disabled Poll Server If a user removes the Work Hub from an Android device or if (MDM) is disabled, executes one of the following: ■ Allow data and app access ■ Block app from running ■ Destroy data and disable app Automatically connect to the Polls the Mobility Suite server based on the specified number of server to check for updates hours to check for a new version of the app. Tip: Apps typically only communicate with the server when users launch them or put them in the background or foreground. By enabling this feature, the app communicates with the server whether the user is using the app or not. Check for updates every [n] Checks the server for updates at the interval that you specify. hours Fail-Safe Revocation Timer Revokes the app if it has not communicated with the Mobility Suite server within the specified number of hours. Automatically destroy data Destroys data and disables the app if the device is unable to and disable app if no server connect with the Mobility Suite server within the number of hours contact within [n] hours that you specify. 353 Using Symantec Mobility: Application Management Using App Polices to manage apps in Symantec Mobility Table 14-3 Label General Settings (continued) Option Description Force upgrade on new Allow a grace period of [n] versions hours Forces the user to upgrade and re-login if the amount of time you specify passes after a new version of the app is released. The grace period starts from the time the app is published. When a new version of an app is published, users with a previous version of the app are notified that a new version is available. When forced upgrade is enabled, they are given the grace period window to perform the upgrade. During the grace period they may continue to use the previous version of the app. After the grace period expires, they are no longer able to use the app. Instead, when they open the app they are directed to the Work Hub to perform the upgrade. After the app is updated on the device, they may continue to use it. Forced upgrade only applies to production versions of apps. Beta versions of apps cannot force upgrades. Table 14-4 Label Option Network Access Control Description Notification Messages Show notification messages Sends a notification message to end users when apps are blocked. Tip: A notification message may not appear in every instance an app is block. If multiple instances of blocked apps occur, the notification messages maybe bundled together. However, each blocked event appears in the device's log. Secure App Proxy Redirect all traffic to Directs app traffic through the app proxy that you specify. See “About restricting app access to your intranet with an app proxy” on page 149. 354 Using Symantec Mobility: Application Management Using App Polices to manage apps in Symantec Mobility Table 14-4 Label Option Network Access Control (continued) Description White-listed Locations Protocols Specifies the protocol. See “Creating app policies to control network access” on page 358. Specifies the host name or address. Location Supports IPv4 addresses or host names. You can use single wildcard prefixes. Examples of supported host names and addresses are as follows: ■ ■ ■ ■ ■ www.example.com Connections to www.example.com *.example.com Connections to the hosts in the example.com domain * Connections to all hosts *.yahoo.com Requests to the hosts that start with yahoo.com 192.168.0.0/17 All IPv4 addresses in range from 192.168.0.0 to 192.168.127.255 Warning: If you create a white-list, to prevent app download failure, you must add the URL, *.s3.amazon.com to the white-list. Port Specifies the port. An empty value or an asterisk (*) wildcard means all ports are accepted. This field accepts multiple ports separated by commas or in a range. For example: 80, 1000-1999, 443 Security 355 Using Symantec Mobility: Application Management Using App Polices to manage apps in Symantec Mobility Table 14-4 Label Option Network Access Control (continued) Description ■ Require SSL When you select this option, only traffic that is sent over a secured connection is permitted. The supported versions are as follows: ■ SSL 3.0 ■ ■ Credential Injection ■ TLS 1.0 ■ TLS 1.1 ■ TLS 1.2 Accept untrusted certificates Not supported for iOS secure web apps By default, this option is not enabled and the certificate check is enforced. Traffic is only permitted if the server that the application is connecting to has a trusted certificate according to the device's trusted root store. When you enable this option, the remote server certificate is accepted even if it cannot be validated using device's trusted root store. SSL Cipher Restriction Specify the SSL cipher strength required for the connection to be permitted. Tip: Require SSL must be enabled for this option to appear. If you select Any Encryption, then a connection is permitted based on any level of cipher encryption. However, locations that use cipher suites without encryption are blocked. If you select Strong, then only connections that meet the OWAPS TLS criteria are permitted. Important: When you set the cipher strength to Strong, if the URL points to a web server that accepts both weak and strong ciphers, the server will likely negotiate for a weaker cipher in which case Mobility Suite will block the connection. However, if the web server only accepts strong ciphers, Mobility Suite will allow the connection. More information 356 Using Symantec Mobility: Application Management Using App Polices to manage apps in Symantec Mobility Table 14-4 Label Network Access Control (continued) Option Description Allows credentials that are used for wrapped app login to be passed to the network connection to enable SSO functionality. Tip: You must have first enabled the User authentication required option in General Settings to enable this option. If you use SAML as the IDP, the session cookie is injected. If you use any other IDP, the user name and password credentials are injected. User name and password are only injected for sites protected by HTTP Basic or HTTP Digest authorization. See “Setting up user authentication and adding users to Symantec Mobility: Suite” on page 104. More information See “App policy basics” on page 345. See “Creating and managing app policies” on page 346. Re-wrapping apps There are times when you may need to re-wrap an app (for example, after you upgrade to a newer version of Symantec Mobility: Suite). Re-wrapping an app updates the app to include any new policy enforcement "wrap code" distributed with an upgrade. After you re-wrap an app, end users who use that app are notified that a newer version is available to download. To re-wrap an individual app 1 Click Apps > App list. 2 On Apps list, click the app that you want to re-wrap. 3 In the upper right corner, click the Re-wrap icon (circle with right-pointing curved arrow). 4 Repeat this procedure for each app that you want to re-wrap. To re-wrap multiple apps associated with an app policy 1 On the Mobility Manager left pane, click App Policy. 2 On the center pane, click the app policy associated with the apps you want to re-wrap. 3 In the upper right corner, click the Edit icon. 357 Using Symantec Mobility: Application Management Commonly used Symantec Mobility app policies 4 Click Save. 5 Repeat this procedure for each app policy associated with the apps that you want to re-wrap. Commonly used Symantec Mobility app policies Some of the most commonly used app policies are those controlling an app's network access, permitting single sign-on (SSO) and making an app "required." See “Creating app policies to control network access” on page 358. See “Creating app policies that permit single sign-on (SSO)” on page 360. See “Making an app so that it is required and managing required apps” on page 362. Creating app policies to control network access Symantec Mobility: Suite lets you restrict an app's access to only the internal resources that you specify in the app policy. By default, end users receive a notification message when URL connections that don't comply with your network access policy are blocked. You can restrict access to whitelisted domains even if you don't use Secure App Proxy. Create a new app policy ◆ Click Polices and rules > App policy and click New app policy. Specify a name and description for your new app policy. Configure General Settings as desired. Tip: The User authentication required option is enabled by default; it must be enabled to use Secure App Proxy. See “App policy configuration options” on page 349. Specify the app proxy you want to direct traffic through Note: Follow this procedure only if you want to use Secure App Proxy. ◆ Under Network Access Control beside Secure app proxy, check Redirect all traffic to. Click the drop-down menu and select the app proxy that you want to redirect app traffic through. See “Setting up Secure App Proxy” on page 150. Define your whitelist 1 In the Whitelisted locations table, do one of the following: 358 Using Symantec Mobility: Application Management Commonly used Symantec Mobility app policies Allow all URLs to connect to your network This is the default setting. No further action is required. Tip: Even if you allow all URLs to connect, you may still want to specify security and credential injection restrictions. Specify a specific URL that Specify the following information: users are permitted to connect ■ Protocol to within your network Note: UDP is not supported for Mobility Suite 4.4 if you use Secure App Proxy. ■ Location ■ Port ■ Security Security settings let you specify whether SSL encryption is required, if untrusted certificates are accepted, and the SSL cipher strength. Important: When you set the cipher strength to Strong, if the URL points to a web server that accepts both weak and strong ciphers, the server will likely negotiate for a weaker cipher in which case Mobility Suite will block the connection. However, if the web server only accepts strong ciphers, Mobility Suite will allow the connection. Credential Injection ■ See “App policy configuration options” on page 349. Important: If you use SAML as your IDP and want to use app proxy, you must add the SAML server address to your whitelist. Even if you permit all URLs to connect to your network (*.*), you must still manually add the SAML server address for SAML authentication and single sign-on to occur. 2 Click New Location to add and specify another network location. Tip: When you click New, the settings from the previous URL are duplicated in the new URL list. Note: Mobility Suite supports 50 domains per policy. 359 Using Symantec Mobility: Application Management Commonly used Symantec Mobility app policies 3 To change the order of the domain in the list, on the Whitelisted locations box, select the location that you want to move and drag and drop it in the desired order. Important: See “How Symantec Mobility: Suite evaluates network access whitelist entries” on page 360. 4 Click Save. Next See “Adding apps to Symantec Mobility: Suite” on page 331. More information Click here for the interactive workflow. See “About restricting app access to your intranet with an app proxy” on page 149. See “Creating and managing app policies” on page 346. How Symantec Mobility: Suite evaluates network access whitelist entries Work Hub matches entries starting from the top of the whitelist list. The policy evaluates the first entry to see if there is an exact match. If there is an exact match, the connection is permitted. If there is not an exact match, the policy evaluates to the next entry and so forth until there is an exact match (in which case, the connection is permitted) or there are no exact matches (in which case, the connection is blocked. For examples and more details about the evaluation of whitelist entries, see the Symantec knowledge base article, How Symantec Mobility evaluates network access whitelist entries. More information See “Creating and managing app policies” on page 346. See “App policy configuration options” on page 349. See “Creating app policies to control network access” on page 358. Creating app policies that permit single sign-on (SSO) Symantec Mobility: Suite lets you create app policies that can simplify the authentication process and provide easier usability for your end users. When you create an app policy that requires authentication and permits single sign-on (SSO), your end users can authenticate to an app once. Then they can access any of the other wrapped apps on their device that require authentication and permit SSO 360 Using Symantec Mobility: Application Management Commonly used Symantec Mobility app policies without reauthenticating. You can use the app policy SSO feature with any supported identity provider (IDP). The Work Hub works exactly the same as a wrapped app for purposes of SSO. Important: The SSO feature could become a security vulnerability if an unauthorized person gets control of an end user's device and is able to launch previously unopened wrapped apps using the SSO feature. As a best practice, you may want to encourage your end users to lock their devices when they are not in use. Create an app policy to permit single sign-on 1 Go to Policies and rules > App policies and click New App Policy. Specify a name and description for your new app policy. See “Creating and managing app policies” on page 346. 2 Under General Settings, check User authentication required. Enable SSO between apps is enabled by default. 3 Add or modify other app policy settings as needed. See “App policy configuration options” on page 349. 4 Click Save. More information See “How Symantec Mobility: Suite single sign-on app policies work” on page 361. See “Setting up user authentication and adding users to Symantec Mobility: Suite” on page 104. How Symantec Mobility: Suite single sign-on app policies work When you enable this feature, the end user experience is as follows: assume App A, B, and C are all wrapped with policy conditions that require authentication and allow for SSO. The end user opens App A and is required to authenticate. After the authentication credentials pass through the IDP, App A launches. Within a few minutes, the end user then opens App B. App B launches without requiring the end user to authenticate. Within a few minutes, the end user then launches App C. Again, the app launches without requiring the user to authenticate. The amount of time between when the user accesses the first app and authenticates and then opens a subsequent app without requiring authentication depends on the IDP's session timeout settings. If you use the local IDP or Active Directory/LDAP, the default Mobility Suite session timeout is 30 minutes. So if the user opens an app that requires authentication and allows for SSO within 30 minutes of opening the first app, no authentication is required. If you use SAML as the IDP, the session timeout settings are configured within the IDP. 361 Using Symantec Mobility: Application Management Commonly used Symantec Mobility app policies The SSO feature works by sharing the encrypted cookie login credentials from the last wrapped app that was opened through SSO to the next wrapped app that requests SSO. So when the user closes the last app that was opened through SSO, the user must reauthenticate to open a subsequent wrapped app. For example, assume Apps A, B, C, and D are all wrapped with policy conditions that require authentication and allow for SSO. The end user opens App A and must authenticate. Within a few minutes, the user opens App B. No authentication is required. Within a few minutes the user opens wrapped App C. No authentication is required. While App A and App B are still running, the user closes App C. Then the user opens App D. The user is required to reauthenticate. The SSO feature could become a security vulnerability if an unauthorized person gets control of an end user's device and is able to launch previously unopened wrapped apps using the SSO feature. As a best practice, you may want to encourage your end users to lock their devices when they are not in use. More information See “Creating app policies that permit single sign-on (SSO)” on page 360. Making an app so that it is required and managing required apps You can require that certain Symantec Mobility: Suite apps be installed on the mobile devices that access your organization’s network. For instance, you may require that a particular app is used to access a database or other online company resource. To enforce your company’s mobile device usage policy, you can monitor required app compliance. Some caveats apply: ■ For an iOS app to be required, MDM must be enabled, and the option to use required apps is set in Device Management. See “Setting default mobile device management (MDM) values for new device policies” on page 290. ■ For an Android app to be required, MDM must be enabled. See “Setting default mobile device management (MDM) values for new device policies” on page 290. ■ Only Production versions of apps can be set to be required. See “Publishing apps” on page 376. ■ App entitlements are applied to the first match that occurs in the Entitlements table. If you define Groups, the entitlement is only applied to the first group in the table to which the user belongs. Groups take precedence over Users. If the Groups entitlement is applied first, the Users entitlement is not applied. 362 Using Symantec Mobility: Application Management Commonly used Symantec Mobility app policies For example, assume you have a user, John Doe. And John Doe is a member of the Publishers group. You defined the entitlement that Everyone can install the app. Then you defined the entitlement that Publishers are required to install the app. Since John Doe is a member of the Everyone group by default, the first entitlement group Everyone is applied. So in this scenario, John Doe is permitted to install the app, but not required to. Note: The following screen shot depicts an Android app. App configuration is not available for Android apps. Table 14-5 describes the differences between the operating systems for the push and installation of required apps and how to uninstall required apps. 363 Using Symantec Mobility: Application Management Commonly used Symantec Mobility app policies Table 14-5 Required app push/installation and deletion Operating system App push and installation of required apps Deleting required apps iOS By default, once per day a server-side check is made for any new required apps. If found, a command is sent to the iOS devices telling them to return their inventories of required apps. Any devices that do not currently have the new required app are flagged to receive the app. The app is then pushed to the device. This process continues until all devices list their proper compliment of required apps. If the device owner prevents or interrupts the installation, Mobility Suite attempts to push the app again the next day and will continue to do so until the app is installed or the administrator resolves the conflict through other actions. Any app installed remotely on an iOS device by using the server-side MDM command, such as a required app, can also be removed remotely. To uninstall a required app, the administrator uses the device inventory page to send a command to revoke the app. Each time the Work Hub is opened on the mobile device, the app checks with your Mobility Suite server to see if there are any new apps that are required. If there are, then the user is notified to download and install the app. If the user does not open the Work Hub within a contiguous 72 hour period (default value) and if Google Cloud Messaging (GCM) is configured, a message is sent to the device that directs the user to download and install the new app. The administrator sends an email or other notification to the device user requesting that they uninstall the app. Android See “Rescinding (un-publishing) and updating (replacing) apps” on page 383. Below are procedures for how to make an existing app required. Click the link below to learn how to make an app required when you initially add the app to Mobility Suite. See “Adding apps to Symantec Mobility: Suite” on page 331. 364 Using Symantec Mobility: Application Management Commonly used Symantec Mobility app policies Make an app so that it is required Note: Only the production versions of apps can be made to be required. 1 Click Apps > App list and select the app from the App list. 2 On the right pane in the Production version section, click the Edit icon. 3 Under Entitlements, check Required beside the groups who must install the app. 4 If you added multiple groups, move them in the order that you want their entitlements applied by clicking on the Groups box and dragging it up or down. Note: App entitlements are applied to the first match that occurs in the Entitlements table. If you define multiple Groups, the entitlement is only applied to the first group in the table to which the user belongs. 5 In the Select required users field, start typing the name of a user who is required to install the app. Mobility Suite lists names that match what you type. Select the name that you want to add. You can add as many users as are needed. 6 Make any other modifications to the app settings as desired. 7 Click Save. Verify that required apps are installed on a device 1 Click Devices. 2 Choose the desired device from the Device list, and in the right pane, select Inventory. If present on the device, the app appears in the Installed apps inventory. View a list of devices that do not have required apps installed on them 1 Click Reports. 2 In the Report drop-down list, select Devices Missing Required Apps. Note: Leave the start and end date filters blank to return results for all dates. Similarly, leave the check boxes under Group restrictions unchecked to see results from all groups. 3 In the App drop-down list, do one of the following: 365 Using Symantec Mobility: Application Management About defining and managing app configurations in Symantec Mobility: Suite 4 ■ Select a specific app. ■ Click All Apps. Click Run Report. About defining and managing app configurations in Symantec Mobility: Suite An app configuration is a dictionary of app-specific key/value pairs for various app settings. Symantec Mobility: Suite lets you define custom app configurations for supported apps. You can assign these app configurations to specific groups or specific users when you set up the app in Symantec Mobility: Suite. When a user launches a custom-configured app and authenticates, Mobility Suite sends the app's configuration information to the app. The app applies the configuration accordingly. If you add, modify, or remove the configuration, the app is updated the next time it checks in with Mobility Suite (e.g., the app returns to the foreground or the user relaunches the app and reauthenticates). App configurations do not require device management. However, when device management is not enabled, you can only apply app configurations to apps that are wrapped and have an app policy that requires user authentication. Example You want to add an email app to Mobility Suite that lets employees access organizational email. You want your east coast employees to be able to access your east coast mail server and west coast employees to access your mail server on the west coast. To do this, you create a different app configuration for each geographic region. Then you assign the configurations to the appropriate groups of users when you add the email app to Mobility Suite. Note: You must have add or edit app permissions to define or modify app configurations. See “Assigning roles” on page 64. App configurations can only be applied to the iOS and Android apps that allow custom app configurations. Specific information about using app configurations with iOS and Android are as follows: 366 Using Symantec Mobility: Application Management About defining and managing app configurations in Symantec Mobility: Suite iOS iOS's MDM provides a mechanism to pass app configuration data to apps. Mobility Suite App Management configuration is compatible with iOS MDM, so the app developer doesn't need to make any special modifications to the app code. The iOS MDM app configuration data is delivered to the app as the dictionary value for the key com.apple.configuration.managed of the standardUserDefaults object. See the Apple documentation for NSUserDefaults. Android For Android apps, the app developer must create or modify their app code to look for the app configuration data. For more information about how to modify the app code for Android apps, see the following KB: Mobility Suite custom app configuration requirements for Android apps Next See “Defining key-value pairs for app configurations in Symantec Mobility: Suite” on page 367. More information See “Creating and managing app policies” on page 346. See “Accessing the App Configuration Manager in Symantec Mobility: Suite” on page 370. See “Adding apps to Symantec Mobility: Suite” on page 331. Defining key-value pairs for app configurations in Symantec Mobility: Suite Symantec Mobility: Suite provides a configuration editor (called the Configuration manager) that lets you add the key value pairs. You can manually enter key value pairs. But the simplest method is to obtain a property list file (.plist) from the app vendor or copy the app configuration from ann existing app, import it, and then modify it as needed. You may want to create multiple app configurations for the same app that you can assign to different groups. So Mobility Suite lets you clone an existing app configuration's key value pairs and modify it as needed. To define the key value pairs, you must obtain a list of configuration parameters from the app vendor. The keys must match the app vendors parameters exactly (i.e., same name), and they must be entered in lowercase text. Similarly, the values must match the data type that the app vendor requires. App configurations support the use of the following tokens as values: {email}, {userid}, {user}, {firstname}, {lastname}, {td_device_id}. 367 Using Symantec Mobility: Application Management About defining and managing app configurations in Symantec Mobility: Suite Export Import 368 Delete configuration Save configuration Add new key Export key value pairs from an app Perform this task if you want to copy key value pairs from one app to another. 1 In the Mobility Manager on the left pane, click Apps. In the center pane, select the app whose app configuration you want to copy. 2 On the right pane, click the Configurations icon. Using Symantec Mobility: Application Management About defining and managing app configurations in Symantec Mobility: Suite 3 In the Configuration manager, click the Export icon, save the .plist list file, and close the Configuration manager. 4 Proceed to Import key value pairs from a .plist. Import key value pairs from a .plist Perform this task if you want to import a .plist file that contains the key value pairs 1 At the top of the Configuration manager, click New. See “Accessing the App Configuration Manager in Symantec Mobility: Suite” on page 370. 2 Add a title for this configuration. 3 In the right pane, click the Import icon, browse to and select the .plist file that you want to import. The predefined key value pairs appear. If an error message appears, resolve the error and try importing the file again. 4 Modify the values for each key as needed. The following screen shot provides an example of an email app configuration. 5 Click the Save icon to save your changes. 6 Click Close to close the Configuration manager. See “Accessing the App Configuration Manager in Symantec Mobility: Suite” on page 370. Manually enter the key value pairs Perform this task to manually enter key value pairs 369 Using Symantec Mobility: Application Management About defining and managing app configurations in Symantec Mobility: Suite 1 In the Configuration manager, click New. 2 Add a title for this configuration. 3 Under Key, hover over the default dictionary name (Root) until the "+" mark appears, and then click it. 4 Type the keys and values. 5 Click Save to save your changes. 6 Click Close to close the Configuration manager. Clone key value pairs Perform this task when you want to copy key value pairs within the same app configuration 1 In the Configuration manager, select the app configuration that you want to clone on the left. New 2 Click Clone. The newly cloned app configuration appears. The title appears as copy of [app configuration]. 3 Modify the title for this app configuration, make any necessary modifications, and click the Save icon. Next See “Assigning an app configuration to a group or user” on page 372. More information See “About defining and managing app configurations in Symantec Mobility: Suite” on page 366. See “Creating and managing app policies” on page 346. Accessing the App Configuration Manager in Symantec Mobility: Suite The App Configuration Manager lets you assign key-value pairs to the apps you upload to Symantec Mobility: Suite. You can access the Configuration Manager in the following ways: ■ In the Entitlements section of the Add new app dialog, under the Config heading of each group or user, click the tools icon (small gear) . Tip: The tools icon only appears for apps that are wrapped with an app policy that has authentication control enabled. See “Adding apps to Symantec Mobility: Suite” on page 331. 370 Using Symantec Mobility: Application Management About defining and managing app configurations in Symantec Mobility: Suite ■ Select an app from the Apps list and in the upper right corner, click the Configurations icon (circle with left and right pointing arrowheads) to launch the Configuration Manager. 371 Using Symantec Mobility: Application Management About defining and managing app configurations in Symantec Mobility: Suite ■ When you edit a version of the app (i.e., Product, Development, or Beta), under Entitlements, each group or user displays a tools icon (small gear). Click the icon to launch the Configuration Manager. More information See “Defining key-value pairs for app configurations in Symantec Mobility: Suite” on page 367. Assigning an app configuration to a group or user After you create an app configuration in Mobility Manager, you can assign it to a group of users or a single user: 372 Using Symantec Mobility: Application Management Creating custom app and content metadata fields Assign an app configuration to a group or user 1 Whether you add a new app or edit an app version, under Entitlements beside the selected Groups or Users, in the Config column, click the drop-down menu and select the configuration that you want to apply to that group or user. See the following screen shot for an example. 2 Click Save. More information See “Creating and managing app policies” on page 346. See “Adding apps to Symantec Mobility: Suite” on page 331. Creating custom app and content metadata fields Symantec Mobility: Suite lets you create up to 20 metadata fields that can be applied to applications by the Developer, Publisher, or Administrator and to Content by the Publisher or Administrator. The metadata is available to provide information about the application to the Developers, Publishers, Administrators, and Managers of the app or content. The metadata can be assigned per version of the app or content and can be made viewable to end users via the End-user Portal. Create custom app and content metadata fields 1 In Mobility Manager, do one of the following: 373 Using Symantec Mobility: Application Management Creating custom app and content metadata fields 2 ■ Click Settings > Metadata > App notes. ■ Click Settings > Metadata > Content notes. For either choice, click Add New Field. You can add up to 20 fields. 3 Specify the following information: Field Name The field name is a text field that provides the label for the metadata that will be shown when adding/modifying a version, as well as to end users if made viewable. Type There are three types: Text, Choice, and URL. Text will allow text to be entered. Choice will allow choices to be specified and will result in a drop down list for the publisher of the application. URL will allow the publisher to specify a URL to be displayed. Help Text Text that will appear when the field is hovered over. Values must match the following regular expression, if specified For type Text, the administrator can type a regular expression used for matching. For example, you could force only numeric text fields, etc. List of choices (separated This field appears when the Type is Choice. by commas) You can add multiple choices. 374 Using Symantec Mobility: Application Management Customizing wrapped app badging Value is required Has a drop-down menu of the following: ■ Never ■ When a develop submits an app for publish ■ When a publisher publishes an app If Never is selected, then the metadata field is not mandatory; however, if either of the others is selected, the Developer or Publisher will not be able to save the application until after the metadata has been entered. If a mandatory metadata field is created after an app has already been published, it will require it if the version is edited. For the purposes of defining enforcement for metadata, the following definitions are used: ■ ■ Users can view values A Developer is a user who is in a group that has the "Edit Development Metadata" permission. A Publisher is a user who is in a group that has the "Edit Beta Metadata" or "Edit Production Metadata” permission. Will enable the user to view the metadata from the Self-Service End User portal. Developers can edit values For app metadata only. Values carry over to each If not selected, then a new version will cause the field data new version to reset. Field is deprecated, meaning it's no longer visible but data remains 4 This option can be selected if the metadata value is no longer used but should be the administrator would like the data to be retained. Click Save. Customizing wrapped app badging Symantec Mobility: Suite lets you customize the badging that appears on your wrapped apps. By default, the Symantec logo appears on apps to indicate that they are wrapped. But you can modify the badging. And you can preview what the badging will look like before you deploy it. After you save your changes, you must rewrap your apps for the new badging to appear. Note: App badging only applies to wrapped apps. It does not apply to Sealed apps. 375 Using Symantec Mobility: Application Management Publishing apps Customize wrapped app badging 1 In Mobility Manager on the left pane, click Apps > Wrapped app badging. 2 Enable the option to add your company logo as a badge for wrapped apps with policies. 3 Click Select App Badge. Browse to and select the graphic that you want to use. Use images in .png or .jpg format. We recommend using images at least 200 x 200 pixels. 4 Preview what the badging will appear like for iOS and Android apps. 5 Optionally, click Restore Default Settings to return to the default, Symantec icon. 6 Click Save. 7 Rewrap your apps. See "Wrapping an app to add security". More information See “Branding your in-house Work Hub” on page 44. See “Branding the Mobility Manager” on page 40. See “Creating and managing app policies” on page 346. Publishing apps Symantec Mobility: Suite provides flexible workflows for managing apps throughout their life cycle. After you add an app to your app library, you can publish it to one of the following life cycle phases (or "versions"): 376 Using Symantec Mobility: Application Management Publishing apps Publish your app to When you want to... this version... Development Make it available to developers (for example, to code the app) Note: App policies are not enforced on apps that are published to this version. Beta Make it available to beta users (for example, to test the app) Note: The Forced Upgrade policy is not enforced on apps that are published to this version. Production Make it available to end users (for example, to use the app in its completed version) See “Adding apps to Symantec Mobility: Suite” on page 331. Apps are managed during these phases by different users who have different permissions based on their assigned roles. The table below lists the five pre-configured Admin roles that Mobility Suite provides. You can customize these roles, or create new roles, to suit the needs of your organization. For example, you may have an admin who is responsible for more than one role, or who is allowed to perform only some of the tasks in a pre-configured role. See “Creating groups” on page 61. Role Permissions Administrator ■ Can perform all tasks Developer ■ Can add native and web apps ■ Can add, edit, and delete private groups ■ Can view apps ■ Can submit request to publish apps ■ Can delete unpublished apps ■ Can edit app metadata while the app is in the Development phase Can assign app entitlements while the app in the Development phase ■ 377 Using Symantec Mobility: Application Management Publishing apps Role Permissions Publisher ■ Can add, edit, and delete groups and private groups ■ Can add native, web, secure web, and external store apps ■ Can edit app assignments ■ ■ Can edit app and content entitlements and receive entitlement requests Can publish apps ■ Can add, delete, and view content ■ Can edit app and content metadata for published and unpublished apps ■ Can add, edit, and delete private groups for apps and content ■ ■ Can edit app entitlements while app is in the Beta and Production phases Can view apps and content ■ Can add and edit groups ■ ■ Can revoke apps and content on devices, or revoke devices completely Can view devices ■ Can lock, ping, wipe, and de-provision devices ■ Can reset passwords on devices ■ Can block and uninstall apps on devices ■ Can add, edit, and delete app, content, and MDM policies Manager Device Manager Policy Editor Understanding the App Life cycle Workflow The workflows that you follow to add and publish apps is going to be based on the structure and needs of your organization. However, there are basic tasks that are followed for adding and publishing apps based on (1) the type of app you want to install, (2) the roles and permissions of the users involved in pushing an app through the workflow, and (3) the commands available within each workflow phase. Table 14-6 describe the typical app life cycle workflows for each app type and the tasks associated with those app types based on the pre-configured roles provided by Symantec Mobility: Suite. 378 Using Symantec Mobility: Application Management Publishing apps Table 14-6 Native and Web App added by developer ■ ■ ■ ■ ■ Native and Web App added by Publisher Developer adds ■ app Developer ■ submits request for app to be published Admin assigns app to publisher ■ Publisher publishes app to Beta or Production, and assigns users who can install it If published to Beta, publisher sets app to Production, and assigns users who can install it Secure Web App Publisher adds ■ app Publisher ■ publishes app to Beta or Production, and assigns users who can install it If published to ■ Beta, publisher sets app to Production, and assigns users who can install it Table 14-7 ■ External Store Pointer Publisher adds ■ Publisher adds app app Publisher See Table 14-8 publishes app to on page 382. Beta, Production, or Development, and assigns users who can install it If published to Development, publisher sets app to Beta or Production, and assigns users who can install it If published to Beta, publisher sets app to Production, and assigns users who can install it Note: Different versions of an app can belong to more than one phase. For example, one version of an app can be in Development while another version is in Beta. Each version can be assigned to different groups so that the appropriate users can install it. However, you cannot have multiple versions of an app in one phase. For example, if you publish a new version of an app to Beta, the previous Beta version is automatically unpublished. Publishing vs. Setting You can only publish an app to a workflow phase (or version) once. If you are a publisher, you can do this at the time you add a native, web, and secure web app. If you assign an app to the Development phase at the time you add it, you can then publish it to the Beta or Production version later. However, you can set the version of an app at any time. 379 Using Symantec Mobility: Application Management Publishing apps Table 14-7 Workflow 1: Adding and publishing a native app Workflow phase Use Case Development Developer develops and app ■ and wants other developers to test it ■ Developer adds an app to the app library Developer specifies a group of users (for example, other developers) who are entitled to install the app Following its successful testing, developer wants to submit the app for beta testing ■ Developer submits a request to publish the app A yellow dot appears next to the app in the center pane of the Apps page indicating that the app is ready for publishing. Publisher needs to verify the ■ readiness of an app before making it available for beta ■ testing Admin edits the app and assigns it to a Publisher Publisher notices missing screenshot and rejects the app, which sends it back to the Developer for modifications, or: Beta Tasks 380 Using Symantec Mobility: Application Management Publishing apps Table 14-7 Workflow phase Workflow 1: Adding and publishing a native app (continued) Use Case Tasks Developer wants to re-submit ■ the modified app for beta testing ■ ■ ■ Production Developer adds metadata (for example, a screenshot) to the app and re-submits it for publishing Admin edits the app and assigns it to a Publisher Publisher verifies the app, specifies a group of users (for example, beta users) who are entitled to install it, assigns a policy to it, and then publishes it to the Beta version Beta users test the app ■ During this phase, the Publisher can rescind the app from the Beta version, and/or replace the app with a different version Following its successful beta ■ testing, publisher wants to make the app available to all end users Publisher edits the app in the following ways: ■ Provides/edits the subtitle, category, description, and metadata ■ Specifies a group of users who are entitled to install the app (for example, all users) Publisher sets the app to the Production version ■ 381 Using Symantec Mobility: Application Management Publishing apps Table 14-8 Workflow 2: Adding and publishing an external store app Workflow phase Use Case Tasks Production Publisher wants to publish a link to an app in the Apple App Store ■ ■ ■ ■ Publisher add an app by browsing and verifying the URL of the app Publisher modifies the title and description of the app Publisher selects the appropriate phone and tablet screenshots for the app Publisher specifies who can and must install the app Request an app for publishing 1 As a developer, in Mobility Manager on the left menu, click Apps. 2 On the center pane, click the app you want published. 3 Under Development version, click Submit for Publish. Assign an app for publishing 1 As an admin, in Mobility Manager on the left menu, click Apps. 2 From the center pane, click the app you want to assign to a publisher. 3 In the upper right corner, click Edit. 4 On the Edit App screen under Associated Users, do one of the following: 5 ■ Under Selected Groups, select the group that contains the publisher. ■ Under Specified Users, select the publisher. Click Save. Publish an app to Beta or Production 1 As a publisher, in Mobility Manager on the left menu, click Apps. 2 From the center pane, click the app you want to publish. 3 Under Development version, click Publish. 4 In the upper right corner, click Publish as Production or Publish as Beta, and then click Publish. 382 Using Symantec Mobility: Application Management Using Symantec Sealed apps Rescinding (un-publishing) and updating (replacing) apps You can rescind (or un-publish) a production or beta version of an app. When you do this, the app is no longer available for installation to the users to which it was previously assigned. You may want to do this, for example, if beta users discover a problem with an app and you want to re-assign it to a developer for modifications. You can then re-publish the modified version later. Rescind an app 1 In Mobility Manager on the left pane, click Apps. 2 Select the app you want to rescind. 3 Under the appropriate version that you want to unpublish, click Rescind. 4 Confirm that you want to rescind the app. Replace the version of an app 1 In Mobility Manager on the left pane, click Apps. 2 Select the app you want to replace. 3 On the version header, click the Replace icon (up arrow). If you are replacing a native app, you are prompted to browse and select a new file. If you are replacing a web app, you are prompted to select a new URL. More information See “Publishing apps” on page 376. See “Adding apps to Symantec Mobility: Suite” on page 331. See “Symantec Mobility: Suite app types” on page 333. Using Symantec Sealed apps Symantec Sealed apps incorporate Symantec's exclusive mobile app security technology to ease the task of securing mobile computing in your network environment. Making your workforce more productive using the Symantec Sealed apps provided with Symantec Mobility: Suite Productivity and security should go hand-in-hand, especially with an increasingly mobile workforce. Empower your workforce with productivity apps that are sealed with Symantec security but don't sacrifice the user experience. Visit the Symantec 383 Using Symantec Mobility: Application Management Using Symantec Sealed apps Secure Mobile Advisor site to get suggestions based on user roles for the types of apps that can make your employees more productive. Sealed apps come in two varieties: ■ Native apps Created by app developers, users download native apps from the public stores and install them onto their mobile devices. Sealed native apps come with app policies, but you can modify these policies. See “Creating and managing app policies” on page 346. ■ Web clip apps Web clip apps are shortcuts to Internet sites that are optimized for mobile devices. App policies cannot be applied to web clip apps. The list of Sealed partners and Sealed apps continues to grow. Visit the following website to learn more about the apps that are available and to read descriptions about how they can make your workforce more productive. http://www.symantec.com/mobility/sealed-marketplace/ More information See “The WorkSpace and using Symantec Sealed apps with Mobility Suite” on page 384. See “Adding a Symantec Sealed app to Symantec Mobility: Suite” on page 342. See “Symantec Mobility: Suite module licenses” on page 33. The WorkSpace and using Symantec Sealed apps with Mobility Suite Symantec Mobility: Suite 4.3 and later supports Symantec Sealed technology. Symantec Sealed is used by app developers to add security controls to apps that run on the devices managed by Mobility Suite. App developers integrate the Symantec Sealed technology into their apps as part of their development process (referred to as "sealing" the app). The Mobility Suite WorkSpace is a key part of the Symantec Sealed functionality. For more information about Symantec Sealed technology and its benefits, visit: http://www.securemobileadvisor.com/ The Mobility Suite WorkSpace Symantec Mobility: Suite provides a WorkSpace to realize the benefits of the Symantec Sealed technology. Sealed apps running in the WorkSpace can be configured to interoperate only with other apps in the WorkSpace. Depending on the app and assigned app policies, certain actions can be restricted to apps that only run in the WorkSpace. For example; you can restrict web browsing to a browser 384 Using Symantec Mobility: Application Management Using Symantec Sealed apps that only runs in a WorkSpace. Sealed Apps running in a WorkSpace can also be configured to restrict data sharing to only those apps in the WorkSpace. The combination of the Symantec Mobility: Suite WorkSpace and Symantec Sealed technology also brings workspace functionality to devices that do not natively provide secure workspaces. The WorkSpace policy Any apps that run in the WorkSpace that are not already managed by their own app policy, are managed by a default WorkSpace policy. The WorkSpace policy is a type of app policy and can be edited the same way you edit any other app policy. You can also create a new app policy specific to the WorkSpace, or assign an existing app policy if you have one already that meets your criteria. See “Creating and managing app policies” on page 346. You select the default WorkSpace policy on the Apps > App list > WorkSpace Settings UI: The Default Policy drop-down menu lists your app policies. Use this panel to also choose your options to have Mobility Suite automatically include Symantec Sealed apps, and to be notified as new apps with Symantec Sealed technology are made publically available. How the WorkSpace Policy interacts with App Policies The WorkSpace Policy is applied to a Symantec Sealed app when a specific app policy has not been applied. However, if an app policy is assigned to an app, the App Policy overrides the WorkSpace Policy. Additionally, in the case of Symantec Sealed apps, and depending on the options chosen by the app developer during the sealing process, recommended policy settings may be provided in the Symantec Sealed app. 385 Using Symantec Mobility: Application Management Using Symantec Sealed apps Using Sealed App recommended settings Apps incorporating Symantec Sealed technology may also provide recommended app policy settings. You select the option to use Sealed App recommended policy settings from in the app details UI (Apps > App list > Add App, or Apps > App list > [selected app] > Edit). The recommended policy settings are listed under the policy selector drop-down menu. While you do not have to use the recommended settings and can provide your own settings in a separate app policy, it is highly recommended to use the recommended setting. In some cases, an app will not work correctly without the recommended policy settings. See “Adding apps to Symantec Mobility: Suite” on page 331. App policy settings specific to controlling apps in the WorkSpace The app policy template provides settings that control app behavior in the WorkSpace: Symantec recommends selecting the following options: ■ Restrict data sharing to only those apps running in the WorkSpace. ■ Restrict clipboard/pasteboard sharing to only those apps running in the WorkSpace. 386 Using Symantec Mobility: Application Management Using Symantec Sealed apps ■ Force links from apps in the WorkSpace to only open in a browser that is also in the WorkSpace See “Creating and managing app policies” on page 346. 387 Chapter 15 Using Symantec Mobility: Workforce Apps This chapter includes the following topics: ■ About Symantec Mobility: Workforce Apps ■ Setting up Symantec Work File ■ Workforce Apps: First tasks ■ Managing Workforce apps About Symantec Mobility: Workforce Apps Symantec Mobility: Workforce Apps (“Workforce Apps”) provides enterprises with the essential functions to provision and manage a suite of secure workplace mobile apps. Three secure apps form the core of the Workforce Apps: ■ Work Mail- a secure EAS email client ■ Work Web- a secure web browser ■ Work File- a secure file sharing and collaboration app (requires a separate installation) You use the Symantec Mobility Manager (admin console) to send and track user invites, establish and maintain app policies, entitlements, and compile reports about app usage and user access. See “About Symantec Mobility Manager” on page 18. For Work File, you use the Work File administrator console to manage users and files. See the Symantec Work File Administrator Guide for information and instructions. Using Symantec Mobility: Workforce Apps About Symantec Mobility: Workforce Apps Workforce apps admin console The Workforce Apps Mobility Manager (admin console) displays a subset of the functions found in Symantec Mobility: Suite. You can upgrade your Workforce Apps installation to add MDM, MAM, and Threat Protection capabilities at any time. For upgrade information, contact your Symantec Sales representative. For an overview of Symantec Mobility, visit the Symantec Mobility website at http://www.symantec.com/mobility/ The functional differences between Workforce Apps and Mobility: Suite are summarized in the following table: Table 15-1 Included with Workforce Apps Excluded in Workforce Apps Admin console with functions for managing the three Workforce apps Mobile App Management (MAM) for: 1 Dashboard, App management, App Policies, User management 2 App Store supporting store-pointer app links Email and App Proxies, including push notifications 1 Uploading/provisioning of in-house apps 2 App wrapping of in-house apps 3 Uploading/Provisioning of any other Symantec Sealed apps Mobile Security Work Hub (mobile client), Work Mail (secure Mobile Device Management (MDM) functions EAS mail app), Work Web (secure browser), Work File (secure file sharing and collaboration) pre-loaded in the admin console Important Workforce Apps licensing note: Prior to installing the Workforce Apps license, your installation is in Trial License mode and all functions are available. During the trial period, you can use any of the functions in Symantec Mobility: Suite, including MAM, MDM, and media content provisioning. When you install your Workforce Apps License, functionality becomes restricted according to the preceding table. However, any device and app policies, app uploads and mobile security configurations you've made are retained. Once the Workforce Apps license is applied, you cannot change the behavior of policies and configurations you created while in Trial License mode. Getting started Symantec Mobility: Workforce Apps can be installed on-premises or provisioned as a service (SaaS). If you choose to install the suite on-premises, follow the instructions provided in the Symantec Mobility: Suite On-premises Installation Guide. 389 Using Symantec Mobility: Workforce Apps Setting up Symantec Work File If you choose the SaaS version of the suite, you can start administrating the product right away. See “Workforce Apps: First tasks” on page 390. See “Setting up Symantec Work File” on page 390. See “Managing Workforce apps” on page 391. Setting up Symantec Work File Symantec Work File requires a separate installation (on-premises) or registration (SaaS). Work File has its own admin console and uses app policies you create and entitle separately from those for Work Web and Work Email. However, you follow the same basic workflows to use Work File as you do for Work Web and Work Mail. Work File documentation covering installation and use are available at the following locations: ■ ■ ■ ■ ■ Workforce Apps: First tasks Your first tasks after installation of your on-premises, or registration of your SaaS instance of Workforce Apps are: 1 Install the Workforce Apps license See “Licensing Symantec Mobility: Suite” on page 32. 2 3 Set up groups and roles: ■ For Work Mail and Work Web: See “Creating groups” on page 61. See “Assigning roles” on page 64. ■ To set up groups and users in Work File see Manage Users in the Symantec Work File Administration Guide Set up an identity provider (IDP): ■ For Work Mail and Work Web: 390 Using Symantec Mobility: Workforce Apps Managing Workforce apps See “Setting up user authentication and adding users to Symantec Mobility: Suite” on page 104. ■ 4 For Work File, see Authorization and Authentication in the Symantec Work File Administration Guide Configure the WorkSpace policy in Workforce Apps: See “The WorkSpace and using Symantec Sealed apps with Mobility Suite” on page 384. 5 Set up app policies and app entitlements for Work Web, Work Mail, and Work File: ■ 6 See “Entitling apps to users and groups” on page 344. Set up user profiles in Work File See, User profiles in the Symantec Work File Administration Guide 7 Invite users: ■ For Work Mail and Work Web: See “Sending and re-sending invitation emails” on page 282. ■ For Work File, see Add New Users in the Symantec Work File Administration Guide Managing Workforce apps The three Workforce apps are pre-loaded into the Apps section of the admin console. In the left menu, click Apps > App list. The apps are listed in the center area. Entitling apps You set the group and user entitlement requirements for each app on the app details page. You can also force an app to be required by particular users or groups. See “Entitling apps to users and groups” on page 344. See “Making an app so that it is required and managing required apps” on page 362. Using App Policies App policies control app authentication requirements, usage restrictions, and network access. You create app policies in the Workforce Apps administration console under Policies and rules > App policies. See “Creating and managing app policies” on page 346. 391 Chapter 16 Managing media content in Symantec Mobility: Suite This chapter includes the following topics: ■ Adding and managing content ■ Creating and assigning content policies ■ Creating and removing content categories ■ Updating, editing, re-publishing, and deleting content files Adding and managing content Symantec Mobility: Suite accepts any type of file for upload and lets you push the file down to the mobile device. For content types that can be previewed, Mobility Suite renders a PDF version of the file and pushes both, the pre-rendered PDF and the original file to the mobile device. The Work Hub uses the PDF version for the in-app preview and retains the original for access within the app itself. You upload the content you want to distribute to your enrolled Mobility Suite users and then typically assign the content item to one or more Content Policies. Content policies control who can download the content item, if and when the content item expires, and similar security-oriented settings. Users are notified when new content is made available to them. See “Creating and assigning content policies” on page 394. Managing media content in Symantec Mobility: Suite Adding and managing content Add or edit content 1 Click Content. Any content uploaded previously is listed in the center pane. 2 3 Do one of the following: ■ To add content, in the upper right corner, click Add Content, and then browse to and select the file that you want to add. ■ To edit content, on the center pane under Content in the Search Content box, type the name of the file that you want to find. Click the Edit icon, and then add or edit the following information: Title Optionally, change the title of the content item. (By default, the original file name is used for new content.) You can add a short one-liner in the Subtitle field. Category Select a category from the drop-down list. Note: If no categories have been created, the list is blank. You create categories on the Settings > Standard / Enterprise Edition > Enhanced Store page. Note: See “Creating and removing content categories” on page 396. Policy Select a policy from the drop-down list. Note: You must create your content policies before you can associate content items with them. Note: See “Creating and assigning content policies” on page 394. Version (optional) Type a version number that is consistent with your organization's requirements, if any. Content Expiration If want the content to expire, check the box and enter an expiry date. Expires on (UTC) Specify the time of day you want the content to expire. Description Add a short description about the content so users know what to expect. 393 Managing media content in Symantec Mobility: Suite Creating and assigning content policies Thumbnail Optionally provide a thumbnail of the file. Click Browse to locate and select the thumbnail image. Screen shots Optionally provide a screen shot of the file. Click Browse to locate and select the screen shot image. Who can download Do any of the following tasks: ■ ■ If you want all users to be able to download this content, click All. If you want to allow only certain users and/or groups to be able to download this content, click Limited to the following selected groups and specified users and then select the groups and/or users that are allowed to access the content. Under Associated users, select the groups or individuals who can manage the content file and its settings. The permissions for each group are set in the Roles and permissions section of Mobility Suite. See “Creating groups” on page 61. 4 Click Save. Creating and assigning content policies In addition to managing apps and devices, Symantec Mobility: Suite also lets you manage and distribute media content to mobile users. Documents, images, audio, video and other files are uploaded to Mobility Suite's Content Center, where they are made available to enrolled users. For instance, many organizations produce media presentations and publications that are intended to be viewed by employees, perhaps at specific times. Mobility Suite lets you easily and quickly send content to the end users that have the native iOS version of the Work Hub, and track file download statistics. You control access to the content in the Content Center with a Content Policy. While you can download content from the Content Center without using content policies, data security in the enterprise often dictates a tighter rein on internally generated content. It's a good idea to create and implement a plan for controlling access to your content before you make the content available. 394 Managing media content in Symantec Mobility: Suite Creating and assigning content policies See “Updating, editing, re-publishing, and deleting content files” on page 397. Create a content policy 1 In Mobility Manager, click Policies and rules, and then Content policies. Existing content polices are listed in the center pane. 2 In the upper right corner, click New Content Policy. 3 Type a name for the policy, and then configure the content policy settings you want to use as follows: Encryption required Encrypts content and enables preview and disables sharing. For iOS 6 users, only the following content formats are supported when an encryption policy is applied: ■ PDF ■ Excel ■ Word ■ PowerPoint Allow offline access Allows users to access content offline. Allow content preview Allows users to view the content in the Work Hub. Note that this option is selected automatically if Encryption required is checked. Prevent sharing of content with other iOS apps Causes the document to be displayed only in a secure viewer that does not allow the document to be shared, exported, or printed. Note that this option is selected automatically if Encryption required is checked. Prevent content Prevents users with access to the web portal from downloads to a desktop downloading documents. through the User Portal 4 Automatically connect to the server to check for updates Allows the Work Hub to automatically check the server for updates at the specified interval. Fail-safe revocation timer Automatically destroys content if the Work Hub does not contact the Mobility Suite server in the configured number of hours. Automatically push download of new versions Forces the download of new content versions if the user does not download the new version in the configured number or hours. Click Save. 395 Managing media content in Symantec Mobility: Suite Creating and removing content categories Manage content policies ◆ Do any of the following tasks: To view a policy Select the policy from the center menu of the Content Policies page. The policy details are displayed in the right pane. To edit a policy Select the desired policy on the Content Policiespage and click Edit. To delete a policy Select the desired policy on the Content Policies page and click Delete Warning: You cannot undo this action. Also, you cannot delete a content policy that is shared with multiple content items unless all content items are first dissociated from the policy. You dissociate a policy from a content item in the item's listing on the Content page. Note: Policies applied to content are not active for content downloaded to Android devices. Creating and removing content categories You use categories to organize the content that you distribute through your Symantec Mobility: Suite Content Center. You can assign categories to the content in the Content Center at any time. The categories that you create appear in selection menus for various content management functions. Categories are one of the features of the Enhanced store experience in Mobility Suite. Create and remove content categories 1 Click Settings > Mobility Manager configuration > Enhanced store. 2 If not already selected, under Options, select Enable. 3 Under Content categories, click Add and then type a name for the new category in the space provided. 4 If you want to remove an existing category, click Remove. 5 Click Save. 396 Managing media content in Symantec Mobility: Suite Updating, editing, re-publishing, and deleting content files Updating, editing, re-publishing, and deleting content files When you change Symantec Mobility: Suite content file options, users with previous versions of the content on their devices are notified that a change occurred. Manage content files 1 In Mobility Manager, click Content. A list of existing content appears. 2 On the center pane, select the content file that you want to update. 3 Do any of the following by selecting the appropriate icon in the upper right corner: Edit Click the Edit icon to edit the properties of the current content file. Delete Click the Delete icon to delete the content file from Mobility Suite. This action also removes it from the device of any user who downloaded it Add version Click the More icon, and then Add version to publish a newer version of the content file to the Content Center. This version replaces the previous version. Republish Click the More icon, and then Republish to republish an older version of the content file to the Content Center. This action also replaces the previous version. It is a best practice to implement a versioning scheme and to use the Version label to track changes to your Content Center files. Unpublish Click the More icon, and then Unpublish to unpublish the current version of the content file from the Content Center. This action also removes it from the device of any user who downloaded it, but keeps it in the Mobility Suite. Download 4 Click the Download icon to initiate the download. If required by the option, click Save. 397 Chapter 17 Symantec Mobility: Suite reporting This chapter includes the following topics: ■ Running reports in Symantec Mobility: Suite ■ Symantec Mobility: Suite reports Running reports in Symantec Mobility: Suite View customized reports in Mobility Manager or download them as a .csv file. Run reports 1 In Mobility Manager, click Reports. 2 In the Report drop-down menu, select the report that you want to run. When you select certain reports, additional options to further refine the report may appear. See “Symantec Mobility: Suite reports” on page 399. 3 Specify a Start Date and End Date. 4 To restrict the report to specific user groups, under Group restrictions, check the groups for which you want the report to apply. Only certain reports let you restrict the report data by group. Symantec Mobility: Suite reporting Symantec Mobility: Suite reports 5 Click Run Report. You can view the results at the bottom of the right pane. 6 To download the report as a .csv file, click Download CSV. The file downloads to your default download directory or to a directory of your choice. More information Mobility Suite reporting is also accessible through the Mobility Suite API. For more information, see the Symantec Mobility: Suite API Integration Guide. See “Mobile Device Management (MDM) reporting in Symantec Mobility: Suite” on page 296. Symantec Mobility: Suite reports Table 17-1 Mobility Suite reports Report name Description All Apps The apps uploaded to Mobility Suite. Includes title, packbund (iOS) or 'bundle ID' (Android) platform and date of last publication. App Downloads by Category A pie chart of app downloads by category. Tip: You must have categories enabled in Mobility Suite. See “Customizing your app store” on page 60. App Downloads by Platforms & OS A pie chart of app downloads by OS. Versions App Downloads per Week A chart of app downloads per week. App Feedback Feedback from device users about a specific app. Click the App selector to select the app. The list shows the app, version, user name, rating, and review. 399 Symantec Mobility: Suite reporting Symantec Mobility: Suite reports Table 17-1 Mobility Suite reports (continued) Report name Description App Inventory History A list of apps with Inventory Management enabled. The report includes: ■ App title ■ Inventory code ■ Installation status ■ User using the code ■ Device installing the app ■ Date of the event ■ VPP license and redemption codes App License Status A list of apps, their license type (e.g., VPP license or redemption code), the number of licenses available, consumed, and reserved. App Logs A compilation of app logs (per application) sent from app users. Mobility Suite offers users the ability to send app logs to the administrator if they experience issues with the app. App Popularity by Install Count A chart of popular apps, based on install count. Associated Users per App A list of users administrating each app. Includes app name, app platform, group association, and user's full name. Blacklisted Devices A list of blacklisted devices. Shows the device name, Mobility Suite ID, the MAC address, the user associated with the device, and that user's email address. To remove a device from the blacklist, contact Support. Cisco ISE Status The status for devices that use Cisco ISE. Devices that MDM manages can be reported to the Cisco ISE system. Shows the device's IP address, command request, status, user name, initial connection to Mobility Suite, and last connection to Mobility Suite. 400 Symantec Mobility: Suite reporting Symantec Mobility: Suite reports Table 17-1 Mobility Suite reports (continued) Report name Description Command History History of the specified command and it's status. Use the selectors to choose the status and command. Shows the status, device, user, who issued the command, the command, when the command was last sent, and last updated. Device Details A list of all devices in the system. The list includes the following: Devices Missing Required Apps ■ User ■ Device ■ Manufacturer ■ OS version ■ Type (phone or tablet) ■ Phone number ■ Carrier name ■ IMEI ■ Mobility Suite ID ■ UDID (if available) ■ MAC address (if available) ■ Ownership (corporate or personal) ■ Targeted Policy ■ Applied Policy ■ Applied Threat Protection Policy ■ MDM Enabled- includes the level of MDM in effect (App Mgmt, App & Device Mgmt, App & Device Mgmt + Wipe) A list of the devices missing required apps. Choose the app with the App selector. You can also choose All Apps. The list shows missing apps, the device, platform, user, and email address. Devices by Platform & OS Versions A pie chart showing the devices by platform and OS versions. Groups With a Single User A list of groups with only a single user. The user's user name, full name, and email address are included. 401 Symantec Mobility: Suite reporting Symantec Mobility: Suite reports Table 17-1 Mobility Suite reports (continued) Report name Description Installed Content A list of the content that's installed on devices. Includes selectors for Content and Installed Version. Select All Content to see all of the content that's been installed. Provides the content name, the published version, installed version, device, user, and email address. Jailbroken/Rooted Devices A list of jailbroken/rooted devices. Provides the user, device, device manufacturer, operating system, type of device (e.g., phone or tablet), Mobility Suite ID, UDID, MAC address, whether the device is corporately owned, and the email address. MDM Compliance Status A list of all devices and their current MDM compliance status. Green rows are compliant; red rows are non-compliant. Other information can include the device name, the level of MDM in effect, the date the user first accepted the terms and conditions of MDM, the date the user was last known to be compliant, the device policy name, and the reason for any non-compliance. MDM Non-Compliant Devices A list of devices that are non-compliant. A list of information about the device name, the date the user first accepted the terms and conditions of MDM, the user name, user's first name, last name, and email address, the date the user was last known to be compliant, the device policy name, and the reason for any non-compliance. Manage App Licenses A list by managed apps that require licenses. List is by app and/or user (you can also select all apps and all users). It includes user, app, and the number of devices on which the user has installed the app. Check a specific user and click Reclaim Licenses to reclaim the licenses for that app from that user for all of their provisioned devices. Note: This report lists VPP licenses only. It does not show Apple redemption codes. See the App Inventory History for a list of apps with redemption codes. 402 Symantec Mobility: Suite reporting Symantec Mobility: Suite reports Table 17-1 Mobility Suite reports (continued) Report name Description Managed Apps A list of users, their provisioned device, managed app, app status, app configuration that was applied, and when the app was last updated. NMS Protection Report View Norton Mobile Security protection report to see which devices are at risk. New Users Per Week A chart enumerating newly enrolled users, by week. Operating System by User A list of users and their devices, by operating system. Includes user name, first name, last name, device name, and group association. Out of Date ADA Devices A list of devices running outdated versions of the Work Hub (i.e., the Work Hub doesn't match the current version of Mobility Suite that you are running). Registration Restriction - Devices Per User Violation Report A list of registered devices that violate the registration restriction policy for maximum number of registered devices that are allowed per user. See “Restricting device enrollment” on page 287. Registration Restriction - Platforms A list of registered devices that violate the registration Allowed Violation Report restriction policy for permitted device operating system platforms. See “Restricting device enrollment” on page 287. Work Mail Status A list of all of the devices that you specify under Group Restrictions and whether Work Mail is installed, if it is compliant, and the Work Mail ID. Sessions Per Week (Admin) A graph showing the number of Admin sessions occurring per week for the specified period. Sessions Per Week (Mobile Clients/Web Clip) A graph showing the number of times that mobile clients accessed your Mobility Suite instance using the mobile client or a web-clip session. Sessions Per Week (Portal) A graph showing the number of times users accessed the End-User Portal. Symantec Sealed Apps A list of the Symantec Sealed apps uploaded to your Mobility Suite that can be filtered by WorkSpace status: Joined, Not Joined, Revoked, and Suspended. 403 Symantec Mobility: Suite reporting Symantec Mobility: Suite reports Table 17-1 Mobility Suite reports (continued) Report name Description System Status Statistics Number of active users, apps, devices and app versions. Third Party Installed Apps A list of devices and the third-party apps that are installed on them. Third-party apps are apps that have not been distributed through the Mobility Suite, but rather through the App Store or Google Play. Note that this information is only available for devices using a device policy with Collect App Information enabled. Threat Log Report A list of malware infection threats in the system that pose privacy and security risks. User App Access A list of apps and users. Shows which apps users have installed. Shows the app title, the version of the app (called App Pointer) that is installed, the user name, the user's name, and the user's email. Users and Devices per App Version Similar to Users Per App report, but searchable by specific apps and app versions, and also shows the device name. Users by Group A list of users, the groups they belong to, their email address, and VPP status. Shows one row per user per group. More information See “Running reports in Symantec Mobility: Suite” on page 398. 404 Section 3 Maintaining and Troubleshooting Symantec Mobility: Suite ■ Chapter 18. Updating, resetting, and migrating Symantec Mobility: Suite components and device clients ■ Chapter 19. MDM Core configuration and troubleshooting ■ Chapter 20. Renewing and reissuing Symantec Mobility: Suite trust and authentication certificates Chapter 18 Updating, resetting, and migrating Symantec Mobility: Suite components and device clients This chapter includes the following topics: ■ Resetting the in-house iOS Work Hub ■ Removing Mobility Suite and MDM profiles from iOS devices ■ Database recommendations and setup for Symantec Mobility: Suite Resetting the in-house iOS Work Hub In certain cases, you may need to associate a new or different Distribution Profile with a new in-house iOS Work Hub. This activity is referred to as "resetting" the Work Hub. Here's a couple reasons why you would need to reset the in-house iOS Work Hub: ■ The trust certificate used with a Distribution Profile expires. See “Managing the iOS app and MDM certificates used by Symantec Mobility: Suite” on page 75. ■ Users are experiencing problems with their in-house iOS Work Hub. Resetting the in-house iOS Work Hub generates a "clean" Work Hub and forces Mobility Suite to reset database associations with the Work Hub. Updating, resetting, and migrating Symantec Mobility: Suite components and device clients Removing Mobility Suite and MDM profiles from iOS devices Reset the in-house iOS Work Hub 1 Click Settings > Device Clients | iOS Client and at the top right, click Reset. Tip: The Reset option only appears if you've built an iOS Work Hub. 2 Confirm that you want to reset your in-house iOS Work Hub. 3 Add the new Distribution profile on the Settings > Certificates | Apple/iOS Certificates page under Code-Signing Certificates. 4 Create and upload a new Apple Push Notification Certificate. 5 Create a new mobile provisioning profile. A new mobile provisioning profile is required when you build a new in-house iOS Work Hub. 6 Click Settings > Device Clients | iOS Client and launch the Mobility Suite builder or the In-browser Mobility Suite builder and build your new in-house iOS Work Hub. More information See “Building your in-house iOS Work Hub in Mobility Manager” on page 50. See “Building your in-house iOS Work Hub in your OS X environment” on page 48. See “Installing the iOS Provisioning Profile and iOS push certificate for Symantec Mobility: Suite” on page 79. See “Building your in-house iOS Work Hub” on page 47. Removing Mobility Suite and MDM profiles from iOS devices Some Work Hub upgrade and migration processes require removal of previously installed Work Hub profiles from iOS devices, such as the MDM profiles. Device-users remove profiles from their devices and may require instructions or assistance. Remove Mobility Suite profiles in iOS 1 On the device tap Settings > General. 2 Under General settings, tap Profile. 3 On the Mobility Suite profile, tap Remove. 4 On the warning message, tap Remove. 407 Updating, resetting, and migrating Symantec Mobility: Suite components and device clients Database recommendations and setup for Symantec Mobility: Suite 5 Enter the device passcode and tap Return. 6 Tap Done. More information See “Installing the iOS Provisioning Profile and iOS push certificate for Symantec Mobility: Suite” on page 79. Database recommendations and setup for Symantec Mobility: Suite Note: This section applies to Production installations only. Use the following information to configure the off-box databases for Symantec Mobility: Off-box database requirements ■ Oracle database (version 11g R2) — 20 GB minimum (30 GB recommended), using shared connections. ■ Configuration — Redundant, high availability (HA). ■ Database IOPS — 17-20 for 30000 mobile devices. ■ MySQL database (version 5.6) — 20 GB minimum (30 GB recommended) Note: Symantec recommends the creation of database scripts to maintain the size of the archive files and user login tables. Next, set up two databases, one for the primary DB and the other for the MDM Core functionality. The names you give these databases is your choice. Set up the Mobility Suite databases in Oracle 1 Open a terminal session to the Oracle instance you're using for your mobility suite installation and log in 2 Enter, CREATE DATABASE <name for the primary database> 3 Enter, CREATE DATABASE <name for the MDM Core database> 408 Updating, resetting, and migrating Symantec Mobility: Suite components and device clients Database recommendations and setup for Symantec Mobility: Suite Set up the Mobility Suitedatabases in MySQL 1 Open a terminal session to the MySQL instance you're using for your mobility suite installation and log in. 2 Enter, CREATE DATABASE <name for the primary database>; 3 Enter, CREATE DATABASE <name for the MDM Core database>; Recommendations and best-practices Review the following recommendations prior to setting up the databases: Database: How do I setup an Oracle DB for Mobility Manager 1 Always use the patched version of oracle as the Database Repository for Mobility Manager. Note: It is recommended to install Oracle 11.2.0.4. 2 3 Oracle Database Software comes in many editions; Express, Standard and Enterprise. It is best to install the Enterprise Edition as it provides additional features such as : ■ Online Index Rebuild ■ Oracle Database Diagnostic Pack –AWR and ADDM for Performance analysis ■ Parallel index scans ■ Parallel DML :-This is the ability to perform database changes (inserts, updates, deletes) in parallel ■ Oratop utility which is similar to top in Linux the only difference is it shows top CPU consuming oracle processes or sessions TheMobility Suite installation creates the tables and the related objects into the schema (user) which is provided on the configurator page. ■ Never use SYSTEM as the schema since it has the oracle server base tables. The schema which is used should have a dedicated role with limited privileges assigned to it. ■ Create a schema which would have its own default tablespace for storage. ■ Moreover the Tablespace should have sufficient no of datafiles each ideally of 2GB in size instead of keeping a single datafile with auto extend on. This reduces fragmentation on the disk. 409 Updating, resetting, and migrating Symantec Mobility: Suite components and device clients Database recommendations and setup for Symantec Mobility: Suite 4 The Mobility Suite installation creates the tables and the related indexes (TOTAL :- 811 application Indexes) in a single tablespace . Ideally, the indexes should have there own tablespace on a different disk. This plays an important role in performance. ■ Since currently we do not have any provision to provide a different tablespace for indexes during installation, it is advisable to move the indexes after installation to a different dedicated tablespace. 5 Timely statistics to gather jobs should be maintained for the database optimizer to select the best execution plan for queries. Moreover, the fixed object stats in database should be gathered whenever required. 6 The Redo logs (i.e., the transaction log of the database) should be multiplexed and should be on a different disk than the actual database for better performance. Post Mobility Suite installation parameter changes 1 Check the processes and the sessions parameter in the database .(Default is 150 which is not adequate). Processes should be at least set to 750 for Mobility Suite. 2 Set the SQLNET.EXPIRE_TIME=1 in the sqlnet.ora file. 3 Make Sure the Profile for the schema used has the attribute PASSWORD_LIFE_TIME to unlimited. Note: This is a temporary work around to prevent the oracle schema password from expiring. This prevents Mobility Suite from working. 4 The Listener, as recommended by Oracle, should not run on port 1521 port . This is the default port and is prone to database attacks. 5 The database should be configured for failover. Use data guard for database failover and Oracle RAC for node failover. 6 If possible, use the Oracle Automatic Storage Manager (ASM) for datafile management to reduce hotspots in files during read and write. Additional Oracle best practices ■ The database should be created on a different disk than the disk used for the actual Oracle software. Performance is made more consistent if you can spread the database across multiple disks, to prevent read/write "hotspots." ■ Assign at least 1GB of memory to the database (memory_target=1G) Use the command: alter system set memory_target=1G scope=spfile ; (a system restart is required). 410 Updating, resetting, and migrating Symantec Mobility: Suite components and device clients Database recommendations and setup for Symantec Mobility: Suite ■ Use a dedicated user as the default schema or user for the creation of application objects. Do not use SYSTEM or SYS schema. Using SYSTEM results in a SYSTEM tablespace which is never recommended. ■ Oracle recommends creating different tablespaces for indexes and table objects. Do not keep the tables and their corresponding indexes in the same tablespace. ■ For best performance, the Redo (i.e., "transaction") logs should be multiplexed and reside on a different disk than the database. ■ To improve the execution of search queries by the database optimizer, run statistics-gathering jobs on a timely basis. Use the SQL*Plus utility or SQL Developer tool to perform the following recommended tasks: Commonly used database administrator tasks Check Oracle database account password expiration ■ If the password associated with your Oracle database account expires, certain Mobility Manager functions will throw exceptions. One example of this is that the Work Hub cannot build. If the Oracle database has expired or is set to expire, the following action must be taken: ■ Update password within Oracle ■ Update Mobility Suite. Access /usr/local/nukona/etc/settings.cfg using your preferred editor (i.e, vi) and update the Oracle password value. ■ Rerun load_settings: python -m load_settings -d ■ Save the modified settings.cfg. You can now copy the updated settings.cfg to any front-end server as needed. Queries to check database size ■ To retrieve the total database size: select sum(bytes/1024/1024/1024) "GB" from dba_data_files; ■ To retrieve the space used by the objects in the database excluding the free space in the database: select sum(bytes/1024/1024/1024) "GB" from dba_segments ; Monitoring database sessions ■ To retrieve information about long running DML and select statements in the database: ■ set lines 180 ■ col event for a30 ■ col program for a40 411 Updating, resetting, and migrating Symantec Mobility: Suite components and device clients Database recommendations and setup for Symantec Mobility: Suite ■ set pages 1000 ■ select PROGRAM,SID,SERIAL#,status,event,to_char(LOGON_TIME, 'dd-mon-rrrr hh24:mi:ss') logontime from v$session where username is not null order by program desc; ■ ■ select * from v$sql_monitor : To check only the active sessions in the database ■ select sid,serial#,program,status,logon_time,blocking_session from gv$session where username is not null and status='ACTIVE' ; 412 Chapter 19 MDM Core configuration and troubleshooting This chapter includes the following topics: ■ Configuring and troubleshooting the MDM core Configuring and troubleshooting the MDM core Core Configuration files MDM Core has multiple configuration files. The main configuration file, /etc/mdmcore/core.config, contains settings that are applicable to the core as a whole. Individual services may have their own app.config or web.config files as well. Core.config file This file contains settings that affect all core services. It contains the database connection string, the database encryption key, and log settings for individual services. DBConnectionString This is the connection string used to connect to the database. It has three fields: Name This must always be ‘SqlConnectionString’ ProductName The .NET Framework data provider used to connect to a database or execute commands. See this link: http://msdn.microsoft.com/en-us/library/a6cd7c08.aspx MDM Core configuration and troubleshooting Configuring and troubleshooting the MDM core ConnectionString The connection string used to connect to a database. See this link: http://msdn.microsoft.com/en-us/library/system.data.sql client.sqlconnection.connectionstring.aspx PrivateKey This is the key that is used to encrypt sensitive fields in the database. Caution: Changing this field prevents the MDM Core services from accessing fields that have been encrypted with a previous key, including any devices that have been registered previously. Logging configuration MDM Core uses NLog as its log engine. NLog is highly configurable in its retention policy, message granularity, and log locations. The Core is set to log each service’s log messages to its own file. By default, these files are located in /usr/local/mdmcore/log. Log granularity is set to Debug and log files are set to rotate when their size reaches 10MB. For more information on how NLog can be configured, see this link: https://github.com/nlog/NLog/wiki/Configuration-file. App.config files App.config files are configuration files used for the Core’s system services. These files do not need to be modified. Web.config files Web.config files are similar to App.config files, but exist for web services. These files do not need to be modified. Core monitoring The MDM Core system services are monitored by monit. Services are checked every 30 seconds. If a service is not running, its init script is called. These scripts can be found in etc/init.d and start with "Mdm*". By default, monit tries 3 times to restart a service. If it fails to start it during these attempts, it times out and no further effort is made to start it. For more information on monit, see this link: http://mmonit.com/monit/documentation/monit.html. The MDM Core web services are hosted and monitored by Apache. Some of that behavior is configurable (see the following section), however it is possible to confirm a web service is available by using the curl command locally. For example: ■ CertInstall: curl http://localhost/certinstall/CertificateInstallerService.asmx/Alive 414 MDM Core configuration and troubleshooting Configuring and troubleshooting the MDM core ■ Challenge: curl http://localhost/challenge/ChallengeService.asmx/Alive ■ DemandCommand: curl http://localhost/iosws/DemandCommandService.asmx/Alive ■ OTA Enrollment: curl http://localhost/iosone/Enroll.aspx ■ OTA Configuration: curl http://localhost/iosone/Config.aspx ■ MDM: curl http://localhost/iosone/MDM.aspx Apache Config File Apache configuration specific to the MDM Core is located at /etc/httpd/conf.d/core/mdm_core.conf. The contents of this file control security, scalability, reliability, and behavior for its web services. Under normal circumstances there should be no need to edit this file, but if necessary it can be modified to suit your environment. Table 19-1 Apache config file settings Setting Default Description MonoMaxActiveRequests 1000 How many web requests will be served concurrently before requests are put in waiting. MonoMaxWaitingRequests 100 How many web requests can be placed in waiting before incoming requests are dropped. MonoAutoRestartMode Restart based on the number of web requests served. We do not recommend changing this setting. Requests MonoAutoRestartRequests 1100 How many web requests to serve before cleaning house and restarting mod_mono. This occurs quietly and does not affect ongoing operation. MonoSetEnv Enforce strict Microsoft interpretation of XML. Do not change this setting. MONO_STRICT_MS_ COMPLIANT=yes 415 MDM Core configuration and troubleshooting Configuring and troubleshooting the MDM core Table 19-1 Apache config file settings (continued) Setting Default Description MonoDebug true Provides additional information in stacktraces. We recommend keeping this on as it will make it easier for you to communicate any errors that occur. MonoServerPath /opt/mono/bin/mod-mono-server4 Location of mod_mono server. Unless you have moved this prerequisite on your system, do not change this setting. MonoAutoApplication Disabled Controls auto discovery and hosting of mono applications. We do not recommend changing this setting as it may result in a less secure system. More information on the above settings can be found here: http://www.mono-project.com/Mod_mono The following table describes the SSL configuration file (/etc/httpd/conf.d/ssl.conf). Table 19-2 SSL configuration file Setting Default Description SSLEngine ON Turns on Apache’s SSL Engine. We do not recommend changing this setting. SSLProtocol all –SSLv2 What SSL protocols are acceptable. We do not recommend changing this setting. 416 MDM Core configuration and troubleshooting Configuring and troubleshooting the MDM core Table 19-2 SSL configuration file (continued) Setting Default Description SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+ RSA:+HIGH:+MEDIUM:+LOW Cipher specifications permitted for use in SSL handshakes. We do not recommend changing this setting as it may have security implications. SSLCertificateFile /usr/local/mdmcore/certs/sign.crt Location of the SSL certificate (public key). PEM format. SSLCertificateKeyFile /usr/local/mdmcore/certs/sign.key Location of the SSL certificate’s matching private key. PEM format. SSLCertificateChainFile /usr/local/mdmcore/certs/gd_bundle.crt Chain containing certificates necessary for trust. PEM format. RewriteEngine ON Turns on the rewrite engine. We do not recommend changing this setting as it may have security implications. RewriteLog /var/log/httpd/rewrite.log Location to log rewrite activity. RewriteCond %{HTTPS} off %{REMOTE_HOST} Establishes a rewrite !localhost % {REMOTE_HOST} condition that excludes !127.0.0.1 HTTPS traffic and traffic from localhost. We do not recommend changing this setting as it may have security implications. RewriteRule (.*) https://%{HTTP_HOST} %{REQUEST_URI} Establishes a rewrite rule that moves all outside HTTP traffic over to HTTPS. We do not recommend changing this setting as it may have security implications. 417 MDM Core configuration and troubleshooting Configuring and troubleshooting the MDM core Table 19-2 SSL configuration file (continued) Setting Default Description SSLOptions +ExportCertData +StdEnvVars Instructs Apache to pass certificate information to mod_mono and create environmental variables for CGI/SSI that relate to handling SSL traffic. We do not recommend changing these settings as it may result in unexpected behavior and can compromise security. More information on the above settings can be found here: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html Core Database Settings The settings for the MDM Core’s web and system services are located in the AppConfigurations table, and listed below. Table 19-3 AppKey Core Database Settings Property Type Description CertificateInstallerService IsMono bool Set to true if running on Mono, false if running on .NET. OSIMDMHandler LogEvent bool Deprecated. Do not use. OSIMDMHandler LogStatus bool Deprecated. Do not use. OSIMDMHandler EmailNotify string Deprecated. Do not use. OSIMDMHandler SmtpServer string Deprecated. Do not use. OSIMDMHandler InventoryMSMQName string Location of message queue for inventory. OSIMDMHandler IsMono bool Set to true if running on Mono, false if running on .NET. OSIMDMHandler RejectDevices WithNoMDM bool Reject devices that do not provide an MDM Signature. Set to false. Signature 418 MDM Core configuration and troubleshooting Configuring and troubleshooting the MDM core Table 19-3 Core Database Settings (continued) AppKey Property Type Description OSIMDMHandler DisableCertificate bool CheckForCommands Do not validate a device’s client certificate when it contacts the server to retrieve commands. Set to false. OSIMDMHandler DisableCertificate CheckForCheckIn bool Do not validate a device’s client certificate when it contacts the server with check-in information. Set to True. OSIMDMHandler Certificate CheckExpiration int After a device’s client certificate has been validated, do not validate it again for the specified amount of seconds. OSIMDMHandler Certificate string RevocationCheckMode If “NoCheck”, certificate revocation list is not used. If “Offline”, only the local certificate revocation list is used. If “Online”, the certificate revocation list specified in the certificate is used. Also in the configuration service. OSIDemand Demand string CommandDemand CommandMSMQName CommandServiceService Location of message queue for iOS demand commands. APNSService APNSHost string Set this to “gateway.push.apple.com”. APNSService APNSConnection HoldMinutes double Defaults to 1. Number of minutes to hold apns connection open. This is to avoid spamming apns. APNSService APNSPort int Set this to 2195. APNSService APNSReconnect Interval int Connection to APNS (per tenant) will be torn down and re-built after the specified number of minutes. APNSService APNSFeedback Port int Set this to 2196. APNSService FeedbackPath string File location to place feedback. 419 MDM Core configuration and troubleshooting Configuring and troubleshooting the MDM core Table 19-3 Core Database Settings (continued) AppKey Property Type Description APNSService APNSFeedback Host string Set this to “feedback.push.apple.com”. APNSService APNSPath string The base location of the push notification message queue. By default, .\\Private$. APNSService FeedbackInterval int How often to collect Feedback from APNS in minutes. APNSService IsMono bool Set to true if running on Mono, false if running on .NET. APNSService MainLoopPause Seconds int Amount of time in seconds that the APNS Service will wait in between checking for requests. APNSService MaxMessages PerPoll int Amount of messages that the service will process every time it checks for requests. APNSService MaxThreadPool Threads int Maximum amount of threads the APNS service is allowed to generate. APNSService MDMPush CollapseSeconds double Amount of time in seconds that the service will wait to send APNS Push requests. Setting this to 0 will send right away. APNSService PushCertRefresh IntervalSeconds int Amount of time in seconds that the service will wait in between refreshing an in memory dictionary of push certificates. Defaults to 300 seconds (5 min). InventoryProcessingService InventoryMax ThreadCount int Maximum number of threads that can be running at the same time. InventoryProcessingService InventoryQueue Timeout int How many seconds to wait when pulling from the inventory queue before timing out. Only utilized if IsMono is set to true. 420 MDM Core configuration and troubleshooting Configuring and troubleshooting the MDM core Table 19-3 AppKey Core Database Settings (continued) Property Type Description InventoryProcessingService InventoryMSMQ Name string The location of the iOS inventory queue. By default, .\\Private$\\Inventory. InventoryProcessingService IsMono bool Set to true if running on Mono, false if running on .NET. InventoryProcessingService InventoryTimeout TimeSpan The amount of time an InventoryThread can run for before being terminated. Default is “00:01:30”. CommandService DemandMax ThreadCount string CommandService DemandThread Timeout TimeSpan The amount of time a DemandThread can run for before being terminated. Default is “00:01:30”. CommandService DemandCommand MSMQName string The location of the iOS demand queue. By default, .\\Private$\DemandCommand. CommandService APNSPath string The base location of the push notification message queue. By default, .\\Private$. This should match the APNSPath property in the APNSService. CommandService CheckForDuplicates bool If true, a message will only be placed on the push notification message queue if one is not already there. CommandService IsMono bool Set to true if running on Mono, false if running on .NET. CommandService DemandCommand QueueTimeout int How many seconds to wait when pulling from the demand queue before timing out. Only utilized if IsMono is set to true. Maximum number of threads that can be running at the same time. 421 MDM Core configuration and troubleshooting Configuring and troubleshooting the MDM core Table 19-3 Core Database Settings (continued) AppKey Property Type Description InventoryProcessingService DemandCommandService string URL to the DemandCommand web service in this environment. Must be reachable from wherever the InventoryProcessing service is located. Configuration and Command services Not currently in use. Verisign_mPKI_URL string Configuration, Inventory, JsonProcessing MDM Handler, and Service Enrollment services string ConfigurationService bool DisableCertificate Check Set to true to disable all certificate checks in the configuration service. Set to false. Other Important Tables: ■ DeviceIos – Contains information about all known (to MDM Core) iOS devices. UDID can be found here along with the password reset code, push token, magic, encryption certificate, and other information necessary to manage devices. ■ Certificates – Any certificates (including private keys) that were installed via the CertificateInstallerService can be found here. All relevant information for the certificate is located in this table. (Thumbprint, Subject, Type). You can look in this table to determine if the APNS certificate got installed correctly. ■ ChallengeTimeStamp – All challenges get stored here until they are used, or expire. Setting the logging level (mdmcore.log) The logging level is defined within /etc/mdmcore/Core.config. At the bottom of the file, there is a rules section where the minLevel can be set for the level of tracing that should be done for each of the services. By default this is set to "Debug", but it is helpful to have this set to "Trace" for debugging issues. There are about 10 lines to update (e.g., MDMHandler, CommandService, InventoryProcessingService, iOS rules, and so on). 422 Chapter 20 Renewing and reissuing Symantec Mobility: Suite trust and authentication certificates This chapter includes the following topics: ■ Replacing an expired SSL certificate in Symantec Mobility: Suite ■ Renewing the MDM certificate ■ Reissuing authentication certificates in Symantec Mobility: Suite ■ Viewing a device's certificates in Symantec Mobility: Suite Replacing an expired SSL certificate in Symantec Mobility: Suite If your SSL certificate is about to expire or is expired you can update it on the server(s) by replacing the old certificate bundle and certificate (gd_bundle.crt, sign.crt) with the new files. The files are in the usr/local/Nukona/certs/configurator directory. Once you have replaced the files, restart the service: service httpd graceful Renewing and reissuing Symantec Mobility: Suite trust and authentication certificates Replacing an expired SSL certificate in Symantec Mobility: Suite Updating SSL/MDM-Profile-Signing certificates To update SSL/MDM-Profile-Signing certificates 1 Identify the original certificate's SHA1 Fingerprint value (and save this for later) by running the following: # openssl x509 -in /usr/local/nukona/certs/configurator/sign.crt -fingerprint Example output: # openssl x509 -in /usr/local/nukona/certs/configurator/sign.crt -fingerprint SHA1 Fingerprint=DC:AD:2C:58:6F:BD:1C:E0:D8:6A:3D:BB:69:9F:D2:EA:C0:F8:E3:36 Note: This value can also be obtained by viewing the SSL certificate information from a web browser. 2 Replace the certificate files on the server with the new ones: /usr/local/nukona/certs/configurator/sign.crt /usr/local/nukona/certs/configurator/sign.key /usr/local/nukona/certs/configurator/gd_bundle.crt 3 Restart Mobility Suite services by running: # /usr/local/nukona/bin/nukona-services.sh 4 Change (cd) the working directory to: /usr/local/nukona/appstore_cu/ 424 Renewing and reissuing Symantec Mobility: Suite trust and authentication certificates Replacing an expired SSL certificate in Symantec Mobility: Suite 5 Delete the MDM profile signing key pair from Mobility Suite by running: # python manage.py scripts appstore keypair list Example output: # python manage.py scripts appstore keypair list id:1 Subject:'CCAPI-ac2' type:CCAPI id:2 Subject:'app-dist-app' type:ANDROID_SIGNING_KEY id:3 Subject:'Apple Production IOS Push Services: loc.asc.ac.iosclient (uid loc.asc.ac.iosclient)' type:PUSH id:4 Subject:'iPhone Distribution: Nukona, Inc (uid KS7268M59G)' type:CODESIGN id:6 Subject:'APSP:7b5da286-1853-4a4d-8114-84325064d0ee (uid com.apple.mgmt.External.7b5da286-1853-4a4d-8114-84325064d0ee)' type:MDM id:7 Subject:'ac2.asc.loc' type:PROFILE_SIGNING id:8 Subject:'com.quickmobile.snap.target.meetingplanner2013' type:ANDROID_SIGNING_KEY id:9 Subject:'nukona' type:ECOSYSTEM_MASTER id:10 Subject:'com.quickmobile.snap.target.meetingplanner2013' type:AKEKAPP id:11 Subject:'nukona' type:ECOSYSTEM_MASTER id:12 Subject:'nukona' type:ECOSYSTEM_MASTER id:13 Subject:'nukona' type:ECOSYSTEM_MASTER id:14 Subject:'nukona' type:ECOSYSTEM_MASTER Id:15 Subject:'nukona' type:ECOSYSTEM_MASTER id:16 Subject:'com.nukona.2013demo1' type:AKEKAPP 15 keys listed. 6 Locate the PROFILE_SIGNING key id, shown above as id:7). 7 Delete this key by running: # python manage.py scripts appstore keypair delete 7 425 Renewing and reissuing Symantec Mobility: Suite trust and authentication certificates Renewing the MDM certificate 8 Delete the MDM profile signing key pair from MDM Core by running: # python manage.py scripts mdm_core key list Example output: # python manage.py scripts mdm_core key list {u'SerialNumber': u'41A3A32B13CE04B5', u'Thumbprint': u'2E475451E2CA04A7D59681E7DA77522070B82BF0'} {u'SerialNumber': u'1497820D000000000010', u'Thumbprint': u'DCAD2C586FBD1CE0D86A3DBB699FD2EAC0F8E336'} 9 Delete the record for the old certificate's fingerprint/thumbprint (based on the output from step 1) by running: # python manage.py scripts mdm_core key del DCAD2C586FBD1CE0D86A3DBB699FD2EAC0F8E336 10 Force the change to take effect (these steps only need to be performed once to force the change): a. Kill, or log out of, the Work Hub on one of the iOS devices. b. Remove the MDM profile from the device. c. De-provision the device in Mobility Manager. d. Log back into the Work Hub and go through MDM profile installation. e. The MDM profile should successfully install. Mobility Suite should now be using the new SSL certificate for profile signing. Renewing the MDM certificate Follow this procedure to renew your iOS MDM certificate for Symantec Mobility: Suite. Renew the MDM certificate 1 Click Downloads > Download iOS MDM CSR. 2 Go to the Apple Push Certificates Portal website, locate the existing certificate, and click Renew. Tip: Don't click Create new certificate. 3 Upload the CSR retrieved in step 1. 4 In Mobility Manager, click Settings > Certificates > Apple/iOS Certificates > MDM certificate and upload the file you downloaded from Apple. 426 Renewing and reissuing Symantec Mobility: Suite trust and authentication certificates Reissuing authentication certificates in Symantec Mobility: Suite 5 Click Settings > Device configuration > Device management and check Enable MDM for iOS devices. 6 Click Save. More information See “Managing the iOS app and MDM certificates used by Symantec Mobility: Suite” on page 75. Reissuing authentication certificates in Symantec Mobility: Suite When a certificate expires or is about to expire, you must manually reissue the certificate. Reissue an authentication certificate 1 In Mobility Manager click Devices, and then in the Device list, select the desired device. 2 With the device selected, at the top of the right pane, click Inventory. 3 Under Installed Certificates, find the certificate to be reissued. 4 For the desired certificate, in the Actions column, click Reissue. More information See “Managing authentication certificates in Symantec Mobility: Suite” on page 73. See “Enabling and restricting device inventory collection, and viewing device inventory” on page 297. Viewing a device's certificates in Symantec Mobility: Suite For Symantec Mobility: Suite-managed mobile devices that have MDM installed and enabled, you can view a list of each device’s authentication certificates. The certificate information is part of the device inventory. See “Enabling and restricting device inventory collection, and viewing device inventory” on page 297. The Devices > (selected device) > Inventory > Installed Certificates table displays the common name of the certificates, the expiration date, the usage type, and the settings name. 427 Renewing and reissuing Symantec Mobility: Suite trust and authentication certificates Viewing a device's certificates in Symantec Mobility: Suite Note: The table includes certificates delivered through other mechanisms, such as the iPhone Configuration Utility. The certificates that are not delivered by MDM do not show the usage type or settings name in the table. 428 Section Reference ■ Chapter 21. Device Policy settings and descriptions ■ Chapter 22. MDM commands and features ■ Chapter 23. System and device requirements 4 Chapter 21 Device Policy settings and descriptions This chapter includes the following topics: ■ Access through Email Proxy policy settings ■ Certificate Authority policy settings ■ Certificate Template policy settings ■ Device Restriction policy settings ■ Enrollment restriction policy settings ■ Kiosk Mode policy settings ■ Native Email policy settings ■ Password policy settings ■ Resources policy settings ■ SSO policy settings ■ VPN policy settings ■ WiFi policy settings ■ Work Mail policy settings Access through Email Proxy policy settings You can select which of the Symantec Mobility: Suite-supported email apps are permitted to access your organizational email. Device Policy settings and descriptions Certificate Authority policy settings Allowed iOS Email Apps ■ Default iOS Email App ■ Symantec Work Mail App Allowed Android Email Apps ■ Symantec Work Mail App Allowed Windows Phone Email Apps ■ Windows Phone Default Email App Allowed Samsung KNOX email Apps ■ Default Samsung KNOX email app ■ Symantec Work Mail app More information See “Creating device policies” on page 304. See “Introduction to Secure Email Proxy” on page 175. See “ Configuring the Work Mail app for use with Secure Email Proxy” on page 205. See “About Samsung KNOX support” on page 312. Certificate Authority policy settings The following settings apply to the Policies and rules > Device profiles> Certificate Authority policy type: ■ Type- The type of Certificate Authority. Note that currently, there is only one value for this setting. ■ Base URL- the base URL for the Certificate Authority. Note that currently, this value is set for Symantec MPKI and cannot be changed. ■ New registration authority certificate- A Registration Authority (RA) certificate issued from the Certificate Authority is required. The certificate must be in .P12 or .PFX format ■ Passphrase- The optional but strongly recommended passphrase associated with the RA certificate. ■ New root certificate- You can optionally add a Root Certificate, if you have one. Note that the certificate file must be .CER, .CRT, .DER, or .PEM. See “Specifying a Certificate Authority (CA) for dynamic certificates” on page 85. 431 Device Policy settings and descriptions Certificate Template policy settings See “Using dynamic authentication certificates in Symantec Mobility: Suite” on page 83. Certificate Template policy settings The following settings apply to the Device Policy > Settings Catalog > Certificate Template: ■ Settings > Certificate Authority- Use this setting to select the Certificate Authority you use for your dynamic certificates. This setting requires that you first specify a Certificate Authority. See “Specifying a Certificate Authority (CA) for dynamic certificates” on page 85. ■ Policy> Certificate Profile OID- The Object Identifier used to identify the Certificate Profile you created for this service at the MPKI provider specified in the Certificate Authority setting. After you enter the OID, you must click Get Details to complete the workflow. See “Configuring a Certificate Template in Symantec Mobility: Suite” on page 87. See “Using dynamic authentication certificates in Symantec Mobility: Suite” on page 83. Device Restriction policy settings iOS Device Functionality ■ Allow App Installation ■ Allow Camera ■ Allow FaceTime ■ Allow Explicit Content ■ Allow Screenshots ■ Allow Global Background Fetch When Roaming ■ Allow Assistant; Allow Assistant When Locked ■ Allow Passbook While Locked ■ Allow In-App Purchases ■ Allow Adding Game Center Friends ■ Allow Multiplayer Gaming 432 Device Policy settings and descriptions Device Restriction policy settings ■ Force iTunes Password Entry ■ Allow Voice Dialing ■ Allow Open in From Managed to Unmanaged (iOS 7 and later) ■ Allow Open in Unmanaged to Managed (iOS 7 and later) ■ Allow Over-The-Air PKI Updates (iOS 7 and later) ■ Allow Touch ID to Unlock Device (iOS 7 and later) ■ AAllow activity continuation (aka Handoff) (iOS 8 and later) ■ Allow internet search results in Spotlight (iOS 8 and later) Applications ■ Allow You Tube ■ Allow iTunes ■ Allow Safari ■ Allow Safari Auto-fill ■ Force Safari Fraud Warning ■ Allow Javascript in Safari ■ Allow Popups in Safari ■ Allow Cookies in Safari- Never, From Visited Sites, Always Security / Privacy ■ Allow Diagnostic Submissions ■ Allow Untrusted TLS Prompt ■ Force Encrypted Backup ■ Allow Lock Screen Control Center (iOS 7 and later) ■ Force Limit Ad Tracking (iOS 7 and later) iCloud ■ Allow Cloud Backup ■ Allow Cloud Document Sync ■ Allow Photo Stream ■ Allow Shared Photo Stream ■ Allow Cloud Keychain Sync (iOS 7 and later) ■ Allow managed app data Sync (iOS 8 and later) 433 Device Policy settings and descriptions Device Restriction policy settings Supervised ■ Allow Game Center ■ Allow iBookstore ■ Allow iBookstore Erotica ■ Allow User Installed Configuration Profiles ■ Allow iMessage ■ Enforce Siri Profanity Filter ■ Allow Account Modification (iOS 7 and later) ■ Allow Cellular Data Modification (iOS 7 and later) ■ Allow Find My Friends Modification (iOS 7 and later) ■ Allow Host Pairing (iOS 7 and later) ■ Allow users to factory reset their devices (iOS 8 and later) ■ Allow users to enforce their own Restrictions (iOS 8 and later) Android ■ Allow camera use ■ Storage Encryption Samsung KNOX General ■ Storage Encryption ■ Background data ■ Google Backup ■ Clipboard ■ Send crash reports to Google ■ Reset settings ■ Mock locations ■ Over-the-air (OTA) OS updates ■ Power Button ■ Screen Capture ■ Change device settings 434 Device Policy settings and descriptions Device Restriction policy settings ■ Expand status bars ■ Side loading apps ■ Change wallpaper Connectivity ■ Bluetooth ■ Cellular Data ■ VPN ■ Data Roaming ■ WiFi ■ Push Roaming ■ Voice Roaming ■ Sync while roaming Hardware ■ Camera ■ Home Button ■ Microphone ■ Near field communications (NFC) ■ Write to SD card ■ USB debugging ■ USB storage Tethering ■ Tethering ■ Bluetooth tethering ■ USB tethering ■ WiFi tethering Windows Phone ■ Storage Encryption ■ External Storage Card ■ Camera ■ Bluetooth 435 Device Policy settings and descriptions Enrollment restriction policy settings ■ NFC Enrollment restriction policy settings Table 21-1 Symantec Mobility: Suite Enrollment restriction policy settings Option Description Devices per user Select any value from 1 to 5 devices per user. Or you can select Unlimited to let users enroll as many devices as they want. Platforms allowed Click the drop-down menu for each device operating system and select the OS device versions that are allowed to enroll. Check All newer versions to allow enrollment of an OS version more recent than the ones in the drop-down list. Important: Mobility Suite or the Work Hub may not yet support newly released updates to mobile operating systems. Allowing users to enroll these versions before Mobility Suite and the Work Hub can support them can result in undesired results. When you configure these setting, users can still enroll devices that violate this policy. But you can monitor violations by running a Registration restriction report. And if you enable the Enrollment Restrictions notification on the Settings > Mobility Manager configuration > Notification Emails page, Mobility Manager sends you email notifications to let you know when a user enrolls a restricted device. A low-priority message of the violation is sent to the Administrator inbox in Mobility Manager. More information See “Restricting device enrollment” on page 287. See “Sharing settings between different device policies” on page 306. Kiosk Mode policy settings Mobility Suite supports Kiosk mode for iOS. Kiosk mode allows only one application to run at a time on users mobile device. The purpose of Kiosk mode is to lock a device into a single application. The application takes over the screen of a device. This prevents device users from opening another application. You can use an application listed from the Mobility Manager managed application list OR you can use a third party application. You are required to know the app id for third party app. 436 Device Policy settings and descriptions Kiosk Mode policy settings Warning: Whether you are using an app from the Mobility Manager managed application list or a third party app, the app must reside on the device before a device policy is applied that contains the Kiosk mode profile. To configure a device for iOS Kiosk mode using Mobility Suite, follow the steps listed below: 1 Configure devices for Supervised mode - before you configure devices for Kiosk mode using Mobility Suite, the device must be in Supervised mode. To enable devices for supervised mode, you use the Apple Configurator application. ■ Access https://itunes.apple.com/us/app/apple-configurator/id434433123?mt=12 from your OSX machine and download the Apple Configurator. ■ Launch the Apple Configurator. ■ Connect the iOS device to your OSX machine. ■ Ensure that the Supervision slider is set to On and click Prepare. Note: During the Prepare process, the iOS device is wiped. This process takes 10-15 minutes. 2 Send an invite to your device users(s) to install the Work Hub to their iOS device. For more information regarding Work Hub invites, See “Sending and re-sending invitation emails” on page 282. Note: When your device users install the Work Hub, do not have a Kiosk profile defined within an active device policy. This is done in step 4. 437 Device Policy settings and descriptions Kiosk Mode policy settings 3 . After your device users have installed the Work Hub, they download and install the application that is to run in Kiosk mode on their devices. (Mobility Manager managed application or third party application). Note: The Mobility Manager managed application should be present in the Apps list within the Mobility Manager console. 438 Device Policy settings and descriptions Kiosk Mode policy settings 4 Once your device users have installed the Kiosk application, you create a new Kiosk profile within active device policy. Access Policies and Rules > Policy List . Select the active device policy and scroll down to the Device Settings section. Click the New link next to Kiosk Mode. The following screen appears: 439 Device Policy settings and descriptions Native Email policy settings You choose the application that is used by your device users in Kiosk mode. There are 2 ways to add the Kiosk mode application: 1. Add App - Click Add App to select the application from the Apps page in your Mobility Manager console. 2. App ID - Manually enter the application ID in the field shown. The App ID can be an app ID of an app listed in the Mobility Manager managed application list or an app id for a third party app. (an app that is not in the Mobility Manager managed application list) Note: As referenced in step3, the application, specified in the Kiosk mode profile, must already be installed on your users iOS devices. Once you add the Kiosk mode app, select the Hardware Options, Accessibility Options and User-enabled Accessability options you see in the graphic above. Click Save. Your device users, that are a member of the group assigned to the relevant device policy, receive the Kiosk mode profile. Your users devices are in Kiosk mode using the application you defined in the Kiosk mode profile. Note: If you wish to replace the Kiosk mode app, first remove the Kiosk profile from the active device policy. Ensure that your device users have received the updated MDM profile that does not include a Kiosk profile. Your device users, that are a member of the group assigned to the relevant device policy, receive the Kiosk mode profile. Your device users devices are in Kiosk mode using the application you defined in the Kiosk mode profile. Native Email policy settings The following tables describe the Native Email options that you can configure in Mobility Manager on the Device Policy > Settings Catalog > Native Email page. These are also the same settings as on the Device Policy > New/Edit Policy > Native Email Configurations page. Table 21-2 Name and description Option Description Name The name for this shared policy setting. This is the name that appears in the Device Policy drop-down list. 440 Device Policy settings and descriptions Native Email policy settings Table 21-2 Name and description (continued) Option Description Description Create a description to help you differentiate this Native Email shared policy setting from any other. Table 21-3 General Settings Option Description Exchange Server Name The name that appears as the email location on the device. Exchange ActiveSync Host Specify a fully qualified domain name of your Microsoft Exchange ActiveSync (EAS) server or Secure Email Proxy. This address must be accessible from mobile devices. For example: somehost.example.com. This field is mandatory. Domain Specify a fully qualified account domain name. User The account user name. Leave blank to prompt the user for the account user name. You can also use a token in the email field to set the field to accept the following input: ■ {userid}-Supply the user's user ID to authenticate to Symantec Work Mail. A user ID differs from {user} in that it can contain additional delineators, such as a domain. For instance, user/domain ■ {user}- Supply the user's user name to authenticate to Secure Email. {email}- Supply the user's email address to authenticate to Work Mail. ■ Email Address Account email address. You can specify an email address or use a token with a domain. For example: {email} or {user}@domain.com Past Days of Mail to Set the range of past emails to sync. Sync 441 Device Policy settings and descriptions Password policy settings Table 21-4 Samsung KNOX Specific Settings Option Settings Maximum Download Size Set the maximum size of the email that users can download. Connection Encryption Select the desired encryption level for devices running the Corporate Access for Samsung agent. See “About Samsung KNOX support” on page 312. Table 21-5 iOS Specific Settings Option Setting Message Export Prevents moving messages out of this email account. 3rd-party Applications When checked, prevents mail from being sent on a third-party app. Recent Address Syncing When checked, allows addresses in this account to be synced. Use SSL When checked, all communications is sent through the secure sockets layer. Certificate Type None or Authentication Certificate Note: Authentication certificates must be selected or imported when the Authentication Certificate option is used. See “Managing the iOS app and MDM certificates used by Symantec Mobility: Suite” on page 75. More information See “Sharing settings between different device policies” on page 306. See “Introduction to Secure Email Proxy” on page 175. Password policy settings ■ Auto-Lock- Elapsed time until the screen locks. ■ Password Quality ■ Allow simple passcodes- When checked, permits the use of otherwise discouraged character patterns, such as repetitions and ascending/descending sequences. 442 Device Policy settings and descriptions Resources policy settings ■ Require alphanumerics value- Password requires at least one letter. ■ Must be at least <n> characters- Minimum passcode length ■ Must be at least <n> symbols- Minimum complex characters ■ Password History- The number of new passwords required before an old one can be recycled. ■ Password Expiry- Elapsed time before the password must be changed. Set to 0 for no expiry. ■ Grace Period- How long until the device is locked with a passcode. ■ Failed Attempts- The number of false password entries allowed before Work Mail data is wiped from the device Resources policy settings ■ iOS AirPlay (iOS 7 and later)- Specify whitelist settings and password settings. ■ iOS AirPrint (iOS 7 and later)- Specify AirPrinters. ■ iOS APN- (iOS 7 and later)- Specify the access point, user name, password, server and port. SSO policy settings ■ Display Name- The name as it appears on the device. ■ Principal- The Kerberos principal name. You can use tokens in your strings (such as {userid}) or leave this field blank to have the device prompt the user. ■ Realm- The Kerberos realm name. ■ URL Prefixes- A list of the URL prefixes that must be matched for this user to authenticate through Kerberos. Each entry in the URL Prefixes field must contain a URL prefix. Only URLs that begin with one of the strings are allowed to access the Kerberos ticket. URL matching patterns must include the scheme—for example, http://www.example.com/. If a matching pattern does not end in forward slash (/), one is appended to it. The URL matching patterns must begin with either http:// or https://. A simple string match is performed, so the URL prefix http://www.example.com/ does not match http://www.example.com:80/. The pattern http:// and https:// matches all HTTP and HTTPS URLs, respectively. 443 Device Policy settings and descriptions VPN policy settings ■ Per-App SSO- You can check Apply to all apps or you specify just the apps that you want to apply iOS SSO. You must specify the Apple ID. You can also import a list of IDs from which you can choose. If you import a list of app identifiers that contains apps that you do not want to apply, check the boxes beside those apps and click Delete. See “Permitting enterprise single sign-on (SSO) for iOS devices” on page 132. VPN policy settings iOS VPN ■ Display Name ■ Connection Type ■ Server ■ Username ■ Machine Authentication- now includes the selection of Dynamically Generated Certificate. You must have a Managed PKI/CA set up in advance. ■ Group Name ■ Shared Secret ■ Hybrid Authentication ■ Password Prompt ■ Proxy WiFi policy settings WiFi policy settings are supported for iOS and Windows Phone. Connection Settings ■ Network Name Required if you are not using a 2.0 hotspot ■ Auto Join Automatically join the target network ■ Hidden Network The target network is a hidden network. Security Settings ■ Options include: 444 Device Policy settings and descriptions WiFi policy settings ■ None No additional suboptions appear. ■ WEP (iOS only) Password field appears ■ WPA/WPA2 Password field appears ■ Any Personal Password field appears ■ WEP Enterprise (iOS) Additional suboptions appear: ■ ■ Protocols ■ Authentication ■ Trust WPA/WPA2 Enterprise (iOS only) Additional suboptions appear: ■ ■ Protocols ■ Authentication ■ Trust Any Enterprise (iOS only) Additional suboptions appear: ■ Protocols ■ Authentication ■ Trust Network Settings (iOS only) ■ Network Type Proxy Settings ■ Proxy The following options appear for the Manual proxy configuration: ■ Server and Port ■ Authentication ■ Password 445 Device Policy settings and descriptions Work Mail policy settings The following options appear for the Automatic proxy configuration: ■ Proxy Server URL Work Mail policy settings The following tables describe the Symantec Work Mail options that you can configure in Mobility Manager on the Device Policy > Settings Catalog > Work Mail page. These are also the same settings as on the Device Policy > New/Edit Policy > Work Mail Configurations page. The settings that you configure for these options also apply to provisioned iOS and Android devices that run NitroDesk TouchDown™. Table 21-6 Name and description Option Description Name The name for this shared policy setting. This is the name that appears in the Work Mail Configurations drop-down list when you create a device policy. Description Table 21-7 Create a description to help you differentiate this Work Mail shared policy setting from any other. Account Option Description Exchange ActiveSync Host Specify a fully qualified domain name of your Microsoft Exchange ActiveSync (EAS) server or Secure Email Proxy. This address must be accessible from mobile devices. For example: somehost.example.com. This field is mandatory. Domain (Optional) Specify a fully qualified account domain name. 446 Device Policy settings and descriptions Work Mail policy settings Table 21-7 Account (continued) Option Description User Account user name. Leave blank to prompt the user for the account user name. You can also use a token in the email field to set the field to accept the following input: ■ {userid} Specify the user's user ID to authenticate to Work Mail. A user ID differs from {user} in that it can contain additional delineators, such as a domain. For instance, user/domain. ■ {user} ■ Specify the user's user name to authenticate to Work Mail. {email} Specify the user's email address to authenticate to Work Mail. Email Address Account email address. You can specify an email address or use a token with a domain. For example: {email} or {user}@domain.com Self-signed Certificates For self-signed servers, select this setting to obtain the server certificate from the server and bypass the server certificate check. Use only for self-signed servers. Authentication certificate Select or import a new certificate to use for EAS authentication. Click New to add a new certificate. Note: Android 2.x and 3.x do not recognize wildcard certificates. Security When Disable reconfiguration is selected, the originally defined account configuration can only be changed by an MDM-enabled Work Hub. This ensures that the configuration cannot be changed by other means such as device users, third parties, etc. 447 Device Policy settings and descriptions Work Mail policy settings Table 21-8 Option Password Description Password Quality When you check Require password, a password is required on the app. This does not affect any device password specified in the device policies. Checking this setting reveals the following additional settings: ■ ■ Allow simple passwords When checked, permits the use of otherwise discouraged character patterns, such as repetitions and ascending/descending sequences. Require alphanumeric value When checked, requires the password to contain at least one letter. Note: You can also specify the number of characters and symbols that must be used. ■ ■ ■ ■ ■ ■ PIN Recovery Must be at least <n> characters Must be at least the minimum number of characters that you specify. Must be at least <n> symbols Must be at least the minimum number of symbols that you specify. Auto-Lock Work Mail automatically locks after the time period that you specify. The default value is 5 minutes. Password History Set the number of new passwords that must be used before the user can recycle a previous password. Password Expiry Set the length of time between mandatory password changes. Set to 0 for no expiry. Failed Attempts Set the number of false password entries allowed before Work Mail data is wiped from the device. When checked, prevents the user from entering an Exchange account password to recover the PIN. This setting is applicable for Android devices only. Table 21-9 Email Option Description HTML Check to allow HTML email. Copy Contacts Check to disable the ability to copy contacts to the device phone book. 448 Device Policy settings and descriptions Work Mail policy settings Table 21-9 Email (continued) Option Description Clipboard Copy Check to prevent the user from using the Clipboard to copy email contents. Attachments Check to allow attachments. You can also set the maximum allowable attachment size, in kilobytes. Maximum Days to Sync Set the range of past emails to sync. Maximum Body Size Set the largest email body size that the user can choose, in kilobytes. Table 21-10 Calendar Option Description Calendar Sync Sets the range of past calendar events to sync. Note: If the current setting for this value is more restrictive (shorter) than the policy setting, the user setting takes precedence. Table 21-11 Android Device Options Option Description Storage Card Set whether cards are allowed, whether encryption is required, and whether the user can back up settings to the SD card. Security Features Set forced device encryption, forced manual sync when roaming, and the disabling of database backups and wiping of configuration settings. Widgets Selectively disable widgets and hide widget data when the device is locked. Notifications Set whether speech and task notifications are disabled. More information See “Setting up Symantec Work Mail in Symantec Mobility: Suite” on page 237. See “Sharing settings between different device policies” on page 306. Symantec Work Mail - Symantec Mobility: Suite enterprise support solutions contains abstracts about and links to all Symantec Mobility: Suite content relating to Symantec Work Mail, which includes How To topics, knowledge base articles, workflows, videos, etc. 449 Chapter 22 MDM commands and features This chapter includes the following topics: ■ Commands that can be sent to mobile devices ■ Mobile Device Management (MDM) settings by Work Hub type Commands that can be sent to mobile devices To help you manage mobile devices, Symantec Mobility: Suite provides several commands that perform various actions on the mobile device. You send these commands from the Mobility Manager. Issuing commands to managed mobile devices 1 On the Mobility Manager left pane, click Devices. 2 On the center pane, select the device or devices to receive a command. Note: Some commands cannot be sent to multiple devices at the same time. You may need to select a single device to issue a particular command. 3 At the top right of the right pane, click Commands. 4 Execute the desired command. See “Locating a lost or stolen device” on page 303. See “Managing the mobile devices enrolled with Symantec Mobility: Suite” on page 288. MDM commands and features Commands that can be sent to mobile devices Table 22-1 shows information about each of the available commands in Mobility Suite and the available device operating system that supports that command. Table 22-1 Available device commands by platform Platform Device Commands Disassociate Each device is linked to one user. You can disassociate this device from its user, making it available for another user. Lock Locks the screen on the device. Lock (with Phone Number and Message options) Locks the screen on the device with an option to display a custom phone number and message on device lock screen. Wipe Wipes all data from the device with option to de-provision user from the device. Note: For iOS devices, the MDM access rights must be set to App and device management with wipe. This is defined in the General Settings of the device policy. Also available is an option to disassociate (de-provision) the user from the device. The Work Hub is not removed with this option so that a new user can easily enroll with Mobility Suite. iOS Android Samsung KNOX Windows Phone 451 MDM commands and features Commands that can be sent to mobile devices Table 22-1 Available device commands by platform (continued) Platform Device Commands Selective Wipe Removes the native email and Work Mail (Work Mail removal not applicable to Windows Phone) settings. Revokes all applications and content installed using MDM protocol. Removes MDM configurations and revokes the Work Hub so that it cannot be used again. Also available is an option to disassociate (de-provision) the user from the device. The Work Hub is not removed with this option so that a new user can easily enroll with Mobility Suite. Revoke All All applications with app policies applied (wrapped apps) and content (if applicable) are revoked. iOS revocation does not occur until the application or the Work Hub next contacts the server. Work Hub is not revoked. Reset Password (user reset) Requires the user to reset the password to unlock the device. Reset Password (administrator reset) Requires the administrator to set a new password through the Mobility Manager before the user can unlock the device. iOS Android Samsung KNOX Windows Phone 452 MDM commands and features Commands that can be sent to mobile devices Table 22-1 Available device commands by platform (continued) Platform Device Commands iOS Android Samsung KNOX Windows Phone Update Device Forces the device to pull the latest device policy targeting it (formerly Fetch command) and the Mobility Manager pulls the latest device information from the device. Reset MDM Forces the device to re-enroll with MDM. Ping Sends a test message to the Work Hub that returns a success acknowledgment or failure acknowledgment. Note: For iOS devices, the Work Hub must be in the foreground and logged in to respond to Ping requests. Update Cellular Settings Updates the current cellular settings on the device. This setting is available only for iOS devices with device ownership set to corporate. Required command permissions Most of these commands require that you enter your administrator credentials before the command is executed: Required command permissions ■ Dissociate from User - Any permission ■ Lock the Device - Requires at least the App and Device Management permission. ■ Wipe the Device - Requires the App and Device Management with Wipe permission 453 MDM commands and features Mobile Device Management (MDM) settings by Work Hub type ■ Selective Wipe/Unmanage - MDM access right must be enabled to perform MDM commands. ■ Revoke all Apps and Content - MDM access right must be enabled to perform MDM commands. ■ Reset Password - Requires the App and Device Management permission. ■ Update Device Info - Any level of MDM is required, and based upon the access rights, determines what information is returned. ■ Reset MDM - Any permission. ■ Ping Device Agent - Any permission. ■ Update Cellular Settings - (for iOS devices only) Requires the App and Device Management with Wipe permission and the device must be a corporate device. Time required for commands to complete Several factors can affect how long it takes for commands to reach devices, and you should not expect commands to be received immediately. iOS devices receive commands upon their next regularly scheduled check-in. Check-in times are controlled by the device policies that are assigned to the devices. See “Creating device policies” on page 304. More information See “Mobile security commands” on page 327. See “Viewing a device's command history” on page 303. See “Mobile Device Management (MDM) settings by Work Hub type” on page 454. See “About Samsung KNOX support” on page 312. Mobile Device Management (MDM) settings by Work Hub type The available mobile device management (MDM) settings vary by the Work Hub type as follows: ■ iOS Work Hub- The iOS .ipa version of the device agent that provides access to all of the iOS-compatible MDM functions ■ Android Work Hub- The Android version of the device client that provides access to Android application management and connects with Android MDM clients ■ Corp Access - The Android MDM client for non-Samsung KNOX devices 454 MDM commands and features Mobile Device Management (MDM) settings by Work Hub type ■ Corp Access for Samsung - The Android MDM client for Samsung KNOX devices ■ Windows Phone- Windows Phone 8.1 devices can enroll with Mobility Suite. This enrollment is needed for the administrator to effect device management of Windows Phone 8.1 devices. Table 22-2 Device Policy Settings by device operating system Device Policy Setting Inventory Collect Commercial App information Collect and display device location Collect and display personal identification information Email Work Mail configuration Native Email configuration Email Access control Access via Email Proxy Device Password Restrictions Wi-Fi Configuration Device Restrictions 455 MDM commands and features Mobile Device Management (MDM) settings by Work Hub type Table 22-2 Device Policy Settings by device operating system (continued) Device Policy Setting VPN Configuration SSO Configuration Resources Registration Restrictions Compliancy Rules Jailbroken or Rooted device Norton Mobile Security client installed MDM compliancy status Enforcement if compliancy rule not met Block access to email Block access to wrapped apps More information See “Creating device policies” on page 304. See “Commands that can be sent to mobile devices” on page 450. 456 Chapter 23 System and device requirements This chapter includes the following topics: ■ Symantec Mobility: Suite system requirements ■ Determining which version of Symantec Mobility: Suite you're using ■ Gathering required information for a Symantec Mobility: Suite installation ■ Sending Symantec your feedback about Symantec Mobility: Suite Symantec Mobility: Suite system requirements Table 23-1 provides the system requirements for an on-premises installation of Symantec Mobility: Suite, the App and Email proxies, and the platform requirements for your iOS, Android, and Windows mobile devices. Table 23-1 On-premises installation system requirements Mobility Suite Requirement Processor 64-bit Memory 8 GB Virtual CPUs (Mobility Suite mandates usage of virtual machines to host on-premises installations) 2 minimum ( recommended for Trial versions) Storage 20 GB (30 GB recommended) Operating System Red Hat Enterprise Linux (RHEL) 6.5 or CentOS 6.5 4 minimum ( recommended for Production versions) System and device requirements Symantec Mobility: Suite system requirements Table 23-1 On-premises installation system requirements (continued) Mobility Suite Requirement External Databases MySQL 5.6 or Oracle 11.2 ■ ■ ■ ■ Database Size MySQL for CentOS Red Hat Enterprise Linux (RHEL) or CentOS is supported as an external database with Mobility Suite. MySQL for Windows is not supported for use as an external database with Mobility Suite. Oracle for Windows or Oracle for Linux is supported for use as an external database with Mobility Suite. Oracle for Solaris is not supported for use as an external database with Mobility Suite. 20 GB minimum ( recommended for Trial versions) 40 GB ( recommended for Production versions Browsers (for Mobility Manager access) Synchronization of computer clock Table 23-2 ■ Internet Explorer 9 or greater ■ Firefox 29 and higher ■ Safari 6.2 and higher ■ Chrome 32 and higher The Mobility Suite administrator is responsible for ensuring that the clock, of the system hosting the on-premises installation of the Mobility Suite tenant, is synchronized with a valid ntp server. An example of such a server is pool.ntp.org On-premises - required site connectivity Description Required site connectivity Supports Apple push notifications to devices running iOS http://feedback.push.apple.com:2195 applications. Supports Apple push notifications to devices running iOS http://gateway.push.apple.com:2196 applications. Supports Apple store pointer applications http://itunes.apple.com Supports Google Cloud Messaging (GCM) https://www.google.com Supports Android store pointer applications. https://play.google.com Support for Two-Factor-Authentication (2FA) https://login.vip.symantec.com Support for licensing (Symantec License Server) services-prod.symantec.com:443 458 System and device requirements Symantec Mobility: Suite system requirements Table 23-2 On-premises - required site connectivity (continued) Description Required site connectivity Supports push email notifications for the Work Mail application through Secure Email Proxy. spoc-pool-gtm.norton.com Supports Norton Mobile Security https://msws.appcenterhq.com Supports Symantec Sealed applications. https://signer.appcenterhq.com/msproxy Supports Symantec Sealed applications. https://signer.appcenterhq.com Table 23-3 RabbitMQ system requirements RabbitMQ Requirement Minimum rabbitmq-server version 3.4.3 Operating system CentOS 6.5 or Red Hat Enterprise Linux (RHEL) equivalent Processor 64-bit Memory 8 GB Storage 40 GB each server Servers At least 2 different servers in different data centers (RabbitMQ cluster) Ports 5672 Broker connection 55672 Management-agent connections between servers 15672 Management connection 4369 Erlang port 45000-45010 Cluster ports. You can extend this port range in rabbitmq.config if you have more than 3 mirroring servers Table 23-4 App Proxy system minimum requirements App Proxy Requirement Processor 64-bit Memory 8 GB 459 System and device requirements Determining which version of Symantec Mobility: Suite you're using Table 23-4 App Proxy system minimum requirements (continued) App Proxy Requirement CPU 4 cores or virtual CPUs minimum Storage 20 GB Operating System Red Hat Enterprise Linux (RHEL) 6.5 or CentOS 6.5 Table 23-5 Email Proxy system minimum requirements Email Proxy Requirement Processor 64-bit Memory 8 GB CPU 4 cores or virtual CPUs minimum Storage 20 GB Operating System Red Hat Enterprise Linux (RHEL) 6.5 or CentOS 6.5 Mail Server Microsoft Exchange Server 2007, 2010 or 2013 Microsoft O365 Server Java JRE 1.7.51 or later Table 23-6 Device platform system minimum requirements Mobile Platform Requirement iOS iOS 8x, 7.x Android 4.x Note: There is limited support for Android 5 Lollipop. Please access http://www.symantec.com/docs/DOC8144 for more details. Windows Windows Phone 8.1 Determining which version of Symantec Mobility: Suite you're using You may need to determine which version of Symantec Mobility: Suite you're using. For example, you may need to know your version number when contacting Symantec 460 System and device requirements Determining which version of Symantec Mobility: Suite you're using Support for assistance or when trying to locate the correct knowledge base article solution or Support forum discussion for your product version. Determine which version of Symantec Mobility: Suite you're using ◆ On any page of Mobility Manager at the bottom center, click the About Mobility Manager link. The following is an example of an About page: 461 System and device requirements Gathering required information for a Symantec Mobility: Suite installation More information See “About Symantec Mobility Manager” on page 18. Gathering required information for a Symantec Mobility: Suite installation Gather together the following information before you start an installation for Mobility Suite. Note: This applies to both trial and production licenses. Table 23-7 Item Required information for Mobility Suite installations Description Required Example /Optional Host Name Server host name. R ac1 FQDN Fully Qualified Domain Name. R myappcenter.company.com IP address Server IP address. R x.x.x.x 462 System and device requirements Gathering required information for a Symantec Mobility: Suite installation Table 23-7 Item Required information for Mobility Suite installations (continued) Description Required Example /Optional username The user name for the initial administrative account. R GCM Credentials User Email and Password for O Google/Android Developer account. See http://developer.android.com/guide/ google/gcm/index.html for details on GCM. PEM-format SSL The certificate common name R certificate (CN) must match the DNS name of the Mobility Suite. The SSL certificate must be issued by a CA which is known by the trust stores of your test devices. Using a self- signed certificate results in constant warnings from browsers and devices, detracting from the user experience. In addition, Android devices require the ability to verify the certificate. PEM-format private key A PEM-format private key R associated with the SSL certificate. The private key must not be passphrase-protected. PEM-format bundle A PEM-format bundle of intermediate certificates. IP address/DNS name of an email proxy host or SMTP server The IP address or DNS name of O an email proxy host or SMTP server, associated port number, username and password (if required). MySQL/Oracle database credentials IP Address, host name, listening R port, database name, user name, password. R admin 463 System and device requirements Sending Symantec your feedback about Symantec Mobility: Suite Table 23-7 Item Required information for Mobility Suite installations (continued) Description Required Example /Optional Encryption key passphrase A passphrase that is used to R upload the encryption key for the config file that is stored in the database. Sending Symantec your feedback about Symantec Mobility: Suite Symantec welcomes your suggestions about how we can improve Symantec Mobility: Suite. However, please refer to Symantec Support for any questions you have about how to use or troubleshoot issues with the product. www.symantec.com/business/support/index?page=landing&key=61596 464 System and device requirements Sending Symantec your feedback about Symantec Mobility: Suite Send Symantec your feedback about Symantec Mobility: Suite 1 On any page in Mobility Manager at the bottom center, click Suggestions for Improvement. 2 Type your suggestion in the space provided. 3 To send your suggestion to Symantec anonymously (i.e., Symantec does not know from which tenant or which customer the suggestion is sent), check Send anonymously. 4 Click Submit. If the submission is successful, a Suggestion Sent! message appears. More information See “About Symantec Mobility Manager” on page 18. 465
advertisement
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Related manuals
Download PDF
advertisement