598867

Apple iOS Deployment Manual

8
Zoom out
Zoom in
Previous page
1/88
Next page
iOS Deployment
Reference
100% resize factor
K Apple Inc.
© 2015 Apple Inc. All rights reserved.
Apple, the Apple logo, AirDrop, AirPlay, Apple TV, Bonjour,
FaceTime, FileVault, iBooks, iLife, iMessage, iPad, iPad Air,
iPhone, iPod, iPod touch, iTunes, iWork, Keychain, Keynote, Mac,
MacBook Air, MacBook Pro, Numbers, OS X, Pages, Passbook,
Safari, Siri, Spotlight, and Xcode are trademarks of Apple Inc.,
registered in the U.S. and other countries.
AirPrint, Apple Pay, Apple Watch, Hando, iPad mini, iTunes U,
and Touch ID are trademarks of Apple Inc.
AppleCare, App Store, iCloud, iCloud Keychain, and iTunes Store
are service marks of Apple Inc., registered in the U.S. and
other countries.
iBooks Store is a service mark of Apple Inc.
The Apple logo is a trademark of Apple Inc., registered in
the U.S. and other countries. Use of the “keyboard” Apple
logo (Option-Shift-K) for commercial purposes without the
prior written consent of Apple may constitute trademark
infringement and unfair competition in violation of federal and
state laws.
The Bluetooth® word mark and logos are registered
trademarks owned by Bluetooth SIG, Inc. and any use of such
marks by Apple Inc. is under license.
IOS is a trademark or registered trademark of Cisco in the U.S.
and other countries and is used under license.
Other company and product names mentioned herein may be
trademarks of their respective companies.
Mention of third-party products is for informational
purposes only and constitutes neither an endorsement nor
a recommendation. Apple assumes no responsibility with
regard to the performance or use of these products. All
understandings, agreements, or warranties, if any, take place
directly between the vendors and the prospective users.
Every eort has been made to ensure that the information in
this document is accurate. Apple is not responsible for printing
or clerical errors.
019-00124/2015-04
100% resize factor
Contents
6 Chapter 1: iOS Deployment Reference
6 Introduction
8 Chapter 2: Deployment models
8 Overview
8 Education deployment models
8 Overview
9 Institution-owned one-to-one
11 Student-owned
13 Shared use
15 Enterprise deployment models
15 Overview
15 Personalized device (BYOD)
17 Personalized device (corporate-owned)
19 Non-personalized device (shared)
21 Chapter 3: Wi-Fi
21 Overview
21 Wi-Fi throughput
22 Join Wi-Fi
22 Roaming
23 Plan for coverage and capacity
24 Design considerations
25 Wi-Fi standards in iOS devices
27 Chapter 4: Infrastructure and integration
27 Overview
27 Microsoft Exchange
29 Bonjour
30 AirPlay
31 Standards-based services
32 Digital certicates
33 Single Sign-On (SSO)
34 Virtual private networks (VPN)
34 Overview
35 Supported protocols and authentication methods
35 SSL VPN clients
36 VPN setup guidelines
38 Per App VPN
38 VPN On Demand
38 Overview
39 Stages
3
100% resize factor
39 Rules and actions
40 Backward compatibility
41 Always-on VPN
41 Overview
41 Deployment scenarios
42 Always-on VPN conguration prole
43 Always-on VPN payload
45 Chapter 5: Internet services
45 Overview
45 Apple ID
46 Find My iPhone and Activation Lock
47 Continuity
47 iCloud
48 iCloud Drive
48 iCloud Keychain
49 iMessage
49 FaceTime
49 Siri
49 Apple ID for Students
50 Apple Push Notication Service (APNs)
51 Chapter 6: Security
51 Overview
51 Device and data security
51 Overview
51 Passcode policies
52 Policy enforcement
52 Secure device conguration
52 Data protection
53 Encryption
53 Per-message S/MIME
53 External email addresses
53 Touch ID
54 Remote wipe
54 Local wipe
54 Network security
55 App security
57 Chapter 7: Conguration and management
57 Overview
57 Setup Assistant and activation
58 Conguration proles
58 Mobile device management (MDM)
58 Overview
60 Enrollment
60 Congure
60 Accounts
61 Queries
61 Management tasks
62 Managed apps
Contents 4
100% resize factor
63 Managed books
63 Managed domains
64 Prole Manager
64 Supervise devices
64 Device Enrollment Program
66 Apple Congurator
67 Chapter 8: App and book distribution
67 Overview
67 Volume Purchase Program (VPP)
67 Overview
68 Enroll in the Volume Purchase Program
68 Purchase apps and books in volume
68 Managed distribution
69 Custom B2B apps
69 In-house apps
70 In-house books
71 Deploy apps and books
71 Overview
71 Install apps and books using MDM
71 Install apps with Apple Congurator
72 Caching Server
74 Chapter 9: Planning for support
74 Overview
74 AppleCare Help Desk Support
74 AppleCare OS Support
75 AppleCare for Enterprise
75 AppleCare for iOS device users
75 iOS Direct Service Program
75 AppleCare Protection Plan for Mac or Apple Display
76 Chapter 10: Appendices
76 Restrictions
76 Overview
76 Device Enrollment Program settings
77 Device functionality
78 Supervised settings
80 Security and privacy settings
81 App usage
82 iCloud settings
82 Prole Manager user and user group restrictions
83 Install in-house apps wirelessly
Contents 5
100% resize factor
6
iOS Deployment Reference
Introduction
This reference guide is for IT administrators who want to support iOS devices on their networks.
It provides information about deploying and supporting iPad, iPhone, and iPod touch in a large-
scale enterprise or educational organization. It explains how they provide:
•
Integration with your existing infrastructure
•
Comprehensive security
•
Powerful tools for deployment
•
Methods to distribute apps and books to your employees or students
Note: Although this reference is focused solely on the deployment of iOS devices, some sections
also apply to Mac desktop and portable computers. In those instances, the term Apple devices
will be used to represent iPhone, iPad, iPod touch, and Mac desktop and portable computers.
Apple TV deployment is covered in the AirPlay section of this reference.
This guide is divided into the following sections:
Deployment models
There are several possible ways to deploy iOS devices in your organization. Regardless of the
deployment model you choose, it’s helpful to consider the steps you’ll need to take to ensure
that your deployment goes as smoothly as possible. While this guide encompasses all aspects
of an iOS device deployment, businesses and educational institutions may go about their
deployments dierently.
Wi-Fi setup and conguration
Apple devices can securely connect to corporate or guest Wi-Fi networks right out of the box,
making it quick and simple for users to join available wireless networks, whether they’re on
campus or on the road. This chapter discusses standard Wi-Fi protocols for data transmission
and encryption.
Infrastructure and integration
iOS devices have built-in support for a wide range of network infrastructures. In this section,
you’ll learn about iOS-supported technologies and best practices for integrating with Microsoft
Exchange, VPN, and other standard services.
Internet services
Apple has built a robust set of services to help users get the most out of their Apple devices.
These services include iMessage, FaceTime, Continuity, iCloud, iCloud Keychain, and how to set
up and manage Apple IDs used to access these services.
100% resize factor
1
Chapter 1 iOS Deployment Reference 7
Security considerations
iOS is designed to securely access corporate services and protect important data. iOS provides
strong encryption for data in transmission, proven authentication methods for access to
corporate services, and hardware encryption for all data stored on iOS devices. Read this section
for an overview about the security-related features of iOS.
Conguration and management
Apple devices support advanced tools and technologies to ensure that they are easily set up,
congured to meet your requirements, and managed with ease in a large-scale environment.
This section describes the dierent tools available for deployment, including an overview of
mobile device management (MDM) and the Device Enrollment Program.
App and book distribution
There are a number of ways to deploy apps and content throughout your organization. Programs
from Apple, including the Volume Purchase Program and the iOS Developer Enterprise Program,
let your organization buy, build, and deploy apps and books for your users. Use this section to
get an in-depth understanding of these programs and how to deploy apps and books purchased
or built for internal use.
Planning for support
Apple provides a variety of programs and support options for users of Apple devices. Before
deploying Apple devices, nd out what’s available for your organization and plan for any support
you’ll need.
The following appendices provide technical details and requirements:
MDM restrictions
Describes the restrictions you can use to congure iOS devices to meet your security, passcode,
and other requirements.
Install in-house apps wirelessly
Describes how to distribute your in-house apps using your own web-based portal.
Additional resources
•
www.apple.com/education/it
•
www.apple.com/ipad/business/it
•
www.apple.com/iphone/business/it
Note: You can nd a web version of this reference at https://help.apple.com/deployment/ios.
Note: If the iBooks Store is available in your country or region, you can download this reference
in ePub format. Simply search for iOS Deployment Reference.
100% resize factor
8
Deployment models
Overview
There are several ways to distribute and set up iOS devices, from pre-conguration to employee
or student self-service setup. Explore the possibilities before you get started. The tools and
process you use to deploy will also be determined by your particular deployment model.
•
In education, there are typically three deployment models for iOS devices: Institution-owned
one-to-one, Student-owned, and Shared use. Although most institutions have a preferred
model, you may encounter multiple models within your institution.
•
In enterprise, there are several possible ways to deploy iOS devices in your organization.
Whether you choose to deploy company-owned iOS devices, share iOS devices among
employees or institute a “bring your own device” (BYOD) policy, it’s helpful to consider the
steps you’ll need to take to ensure that your deployment goes as smoothly as possible.
After the deployment models are identied, your team can explore Apple’s deployment and
management capabilities in detail. These tools and programs are covered extensively within this
resource and should be reviewed with the key stakeholders within your organization.
Education deployment models
Overview
iPad brings an amazing set of tools to the classroom. Choosing the right strategies and tools can
help transform the educational experience for teachers, students, and other users.
Whether your institution deploys iOS devices to a single classroom or across all grade levels,
there are many options to easily deploy and manage iOS devices and content.
Deployment models
In educational institutions there are three common deployment models for iOS devices:
•
Institution-owned one-to-one
•
Student-owned
•
Shared use
While most institutions have a preferred model, you may encounter multiple models within
your institution.
The following are a few examples of how these models would be applied in a typical education
institution:
•
A middle school may plan and deploy an institution-owned one-to-one model for all
grade levels.
•
A large district may rst deploy an institution-owned one-to-one model at a single high
school, and then roll out identical models for the whole district.
100% resize factor
2
Chapter 2 Deployment models 9
•
A K-8 school may deploy both an institution-owned one-to-one model for fth through eighth
grades, and a shared use model for kindergarten through fourth grades.
•
In higher education it is common to see the student-owned model at the campus or
multi-campus levels.
Exploring these models in more detail will help you identify the best deployment model for your
unique environment.
Institution-owned one-to-one
An institution-owned one-to-one deployment model provides the greatest opportunity for iOS
devices to positively impact the learning process.
In a typical institution-owned one-to-one deployment, your institution purchases iOS devices for
all eligible students and instructors. This could be for a particular grade level, a department, or an
entire school district, college, or university.
In this model, each user is assigned an iOS device that’s congured and managed by your
institution. A mobile device management (MDM) solution will simplify and automate this
process. If the iOS devices are purchased directly from Apple or a participating Apple Authorized
Reseller or carrier, your institution can use the Device Enrollment Program (DEP) to automate
enrollment in MDM, so iOS devices can be handed to users directly.
Once iOS devices are distributed, users go through a streamlined Setup Assistant, are
automatically enrolled in MDM, and can further personalize their iOS device or download their
own content. Users may also receive an invitation to download specic educational content,
such as apps and books purchased through the Volume Purchase Program (VPP), or iTunes U
courses. If students are under the age of 13, your institution can initiate the creation of an Apple
ID on their behalf using the Apple ID for Students program, so apps and books can be delivered
to them. Your institution can deliver or update these resources over the air anytime during the
school year, and with Caching Server, most of these downloads can come from the institution’s
local network. If iOS devices are supervised, apps are installed automatically.
100% resize factor
Chapter 2 Deployment models 10
The following table illustrates the responsibilities of both the administrator and the user for an
institution-owned one-to-one deployment:
Prepare
Administrator:
•
Investigate, procure, and deploy an MDM solution.
•
Enroll in DEP, VPP, and the Apple ID for Students
program.
•
Unbox and (optionally) asset tag the iOS device.
•
Initiate creation of Apple IDs for students under 13
(if applicable).
Users:
•
Create Apple IDs, iTunes Store, and iCloud accounts.
Set up and congure
Administrator:
•
Assign iOS devices in DEP for supervision and
streamlined enrollment in MDM.
•
Use Apple Congurator instead of DEP and MDM to
congure and supervise the iOS devices.
•
Congure and install accounts, settings, and
restrictions wirelessly with MDM.
Users:
•
The user is provided a iOS device.
•
Enter institution credentials in Setup Assistant for
DEP (optional).
•
Personalize the iOS device with Setup Assistant and
enter a personal Apple ID.
•
iOS device settings and congurations are
automatically received from MDM.
Distribute devices and content
Administrator:
•
Purchase apps and books with VPP and assign
them to users with MDM.
•
Send VPP invitation to users.
•
Install Caching Server to speed up content delivery
over the local network.
Users:
•
Accept invitation to VPP.
•
Download and install apps and books assigned by
the institution.
•
If the iOS device is supervised, apps can be pushed
to the user’s device silently.
Ongoing management
Administrator:
•
Revoke and reassign apps to other users as needed
with MDM.
•
With MDM, an administrator can query managed
iOS devices to monitor compliance, or trigger alerts
if users add unapproved apps or content.
•
MDM can also lock iOS devices or remotely wipe
any managed accounts or data, or wipe an iOS
device entirely.
•
Deploy Apple TV to support AirPlay.
Users:
•
Back up the iOS device to iTunes or iCloud, to save
documents and other personal content.
•
If the iOS device is lost or stolen, the user can locate
it with Find My iPhone.
Additional Resources
•
VPP Overview
•
MDM Overview
•
Device Enrollment Program
•
Apple ID for Students
•
Apple ID
•
Caching Server
•
AirPlay
•
Apple Congurator
100% resize factor
Chapter 2 Deployment models 11
Student-owned
In higher education, students typically arrive on campus with their own iOS device. And while
not as prevalent, in some K-12 institutions, students bring their own iOS devices to school.
In this model, iOS devices are set up and congured by the student or a parent. In order to use
institutional services such as Wi-Fi, mail, and calendars, or to congure the iOS device for specic
classroom requirements, student-owned iOS devices are commonly enrolled in an MDM solution
provided by the institution. In education environments, technology such as MDM can play a role
in managing student-owned iOS devices. Access to an institution’s services acts as an incentive
for users to enroll their iOS devices in the organization’s MDM solution.
This ensures that all of the conguration settings, policies, restrictions, apps, books, and content
are deployed automatically and unobtrusively, yet remain under the control of the institution.
MDM enrollment is an “opt-in” process, so students can choose to remove management once
they complete a course, graduate, or leave the institution. Removing the management also
removes any content or services provided by the institution.
100% resize factor
Chapter 2 Deployment models 12
The following table illustrates the responsibilities of both the administrator and the user for a
student-owned deployment:
Prepare
Administrator:
•
Investigate, procure, and deploy an MDM solution.
•
Enroll in VPP.
Users:
•
Unbox and activate the iOS device.
•
Create Apple ID, iTunes Store, and iCloud accounts,
if applicable.
Set up and congure
Administrator:
•
No action necessary at this stage.
Users:
•
Enroll iOS devices using self service and congure
accounts, settings, and restrictions wirelessly via
MDM based on user/group policies dened by your
institution.
•
Personalize the iOS devices with Setup Assistant
and (optionally) enter a personal Apple ID.
•
Enroll in MDM.
Distribute apps and books
Administrator:
•
Purchase apps and books with VPP and assign
them to users with MDM.
•
Send VPP invitation to users.
•
Install Caching Server to speed up content delivery
over the local network.
Users:
•
Accept invitation to VPP.
•
Download and install apps and books assigned by
the institution.
•
Update iOS and apps on their iOS device.
Ongoing management
Administrator:
•
Revoke and reassign apps to other users as needed
with MDM.
•
With MDM, an administrator can query managed
iOS devices to monitor compliance, or trigger alerts
if users add unapproved apps or content.
•
MDM can also lock iOS devices or remotely wipe
any managed accounts or data, or wipe an iOS
device entirely.
Users:
•
Back up the device to iTunes or iCloud, to save
documents and other personal content.
•
If the iOS device is lost or stolen, the user can locate
it with Find My iPhone.
•
When the MDM relationship is removed, managed
accounts and data are removed, but the user’s
personal apps, books, data, and content are kept.
Note: VPP books are permanently assigned. They can’t
be revoked.
Additional Resources
•
VPP Overview
•
MDM Overview
•
Apple ID
•
Caching Server
100% resize factor
Chapter 2 Deployment models 13
Shared use
In a shared use model, iOS devices are purchased for use in a classroom or lab, and may
be shared among students throughout the day. These devices have limited personalization,
and therefore can’t take full advantage of a personalized learning environment for each student.
In addition to rotating devices with a shared use model, this approach could be used for a
one-to-one deployment in a highly controlled context, such as a lower grade level deployment.
In this case, devices have minimal personalization.
Shared use deployments are more tightly managed than personalized deployments, since the
setup, conguration, and management are performed by your institution’s sta. In a shared use
deployment, your institution takes responsibility for installing apps, books, and other content
necessary for learning.
100% resize factor
Chapter 2 Deployment models 14
The following table illustrates the responsibilities of both the administrator and the user for a
shared use deployment:
Prepare
Administrator:
•
Investigate, procure, and deploy an MDM solution.
•
Enroll in VPP.
•
Unbox and (optionally) asset tag the iOS device.
•
Create institutional Apple ID(s) for each instance of
Apple Congurator.
Users:
•
No action necessary at this stage.
Set up and congure
Administrator:
•
Use Apple Congurator to congure and supervise
devices.
•
Use Apple Congurator to enroll devices in MDM
(optional).
•
Use Apple Congurator or MDM to install accounts,
settings, and restrictions.
Users:
•
No action necessary at this stage.
Distribute apps
Administrator:
•
Purchase apps using VPP and deploy them using
redemption codes for installation and management
with Apple Congurator.
Users:
•
No action necessary at this stage.
Ongoing management
Administrator:
•
Update iOS on the device with Apple Congurator.
•
Update, congure, and install accounts, settings
and restrictions wirelessly with Apple Congurator
or MDM.
•
Periodically reset devices to standard conguration
with Apple Congurator.
•
Install and update apps on the iOS device with
Apple Congurator.
•
With MDM, you can query managed iOS devices to
monitor compliance, or trigger alerts if users add
unapproved apps or content.
•
MDM can also lock iOS devices or remotely wipe
any managed accounts or data, or wipe an iOS
device entirely.
•
Regular backup of the Mac running Apple
Congurator is necessary, because VPP purchases
are managed locally.
Users:
•
No action necessary at this stage.
Additional Resources
•
VPP Overview
•
MDM Overview
•
Apple ID
•
Apple Congurator
100% resize factor
Chapter 2 Deployment models 15
Enterprise deployment models
Overview
iOS devices can transform your business. They can signicantly boost productivity and give your
employees the freedom and exibility to work in new ways, whether in the oce or on the go.
Embracing this new way of working leads to benets across the entire organization. Users have
better access to information, so they feel empowered and are able to creatively solve problems.
By supporting iOS, IT departments are viewed as shaping the business strategy and solving real-
world problems, rather than xing technology and cost-cutting. Ultimately everyone benets,
with a reinvigorated workforce and new business opportunities everywhere.
Whether you’re a large or small organization, there are many easy ways to deploy and manage
iOS devices and content.
Start by identifying the best deployment models for your organization. Apple provides dierent
deployment and management tools, depending on the model you choose.
Deployment models
In enterprise, there are three common deployment models for iOS devices:
•
Personalized device (BYOD)
•
Personalized device (corporate-owned)
•
Non-personalized (shared device)
While most organizations have a preferred model, you may encounter multiple models within
your organization.
For example, a retail organization may deploy a personalized device (BYOD) strategy by allowing
employees to set up their personal iPads while keeping corporate resources separate from the
user’s personal data and apps. However, their retail stores may also deploy a non-personalized
device (shared device) strategy allowing iPod touch devices to be shared by several employees in
order to process transactions for customers.
Exploring these models in more detail will help you identify the best deployment model for your
unique environment.
Personalized device (BYOD)
With a bring-your-own-device deployment, users set up their personal iOS devices using their
own Apple ID. In order to access corporate resources, users can congure settings manually,
install a conguration prole, or more commonly, enroll the iOS device with your organization’s
MDM solution.
100% resize factor
Chapter 2 Deployment models 16
An advantage of using MDM to enroll personal iOS devices is that it keeps corporate resources
separate from the user’s personal data and apps. You can enforce settings, monitor corporate
compliance, and remove corporate data and apps, while leaving personal data and apps on each
user’s iOS device.
The following table illustrates the responsibilities of both the administrator and the user for a
personalized device (BYOD) deployment:
Prepare
Administrator:
•
Evaluate your existing infrastructure including Wi-Fi,
VPN, and mail and calendar servers.
•
Investigate, procure, and deploy an MDM solution.
•
Enroll in VPP.
Users:
•
Unbox and activate the iOS device.
•
Create Apple ID, iTunes Store, and iCloud accounts,
if applicable.
Set up and congure
Administrator:
•
Organizations can provide settings for individual
accounts to users, and policies can be pushed with
Exchange or installed using a conguration prole.
Users:
•
Enroll iOS devices using self service and congure
accounts, settings, and restrictions wirelessly using
MDM based on user/group policies dened by your
organization.
•
iOS device settings and congurations are
automatically received from MDM.
•
Alternatively, users can install conguration proles
manually or congure settings as provided by you.
Distribute apps and books
Administrator:
•
Purchase apps and books using VPP and assign
them to users with MDM.
•
Send VPP invitation to users.
•
Distribute in-house apps from the iOS Developer
Enterprise Program (iDEP) and in-house books
by hosting them on a web server or your MDM
solution.
•
Install Caching Server to speed up content delivery
over the local network.
Users:
•
Accept invitation to VPP.
•
Download and install apps and books assigned by
the organization.
Ongoing management
Administrator:
•
Revoke and reassign apps to other users as needed
with MDM.
•
With MDM, you can query managed iOS devices to
monitor compliance, or trigger alerts if users add
unapproved apps or content.
•
MDM can also lock iOS devices or remotely wipe
any managed accounts or data, or wipe an iOS
device entirely.
Users:
•
Back up the iOS device to iTunes or iCloud, to save
documents and other personal content.
•
If the device is lost or stolen, the user can locate it
with Find My iPhone.
•
When the MDM relationship is removed, managed
accounts and data are removed, but the user’s
personal apps, books, data, and content are kept.
100% resize factor
Chapter 2 Deployment models 17
Additional Resources
•
VPP Overview
•
MDM Overview
•
Apple ID
•
Caching Server
Personalized device (corporate-owned)
You can use the personalized device model to deploy iOS devices owned by your organization.
You can congure the iOS devices with basic settings before giving them to the user, or (as with
BYOD) provide instructions or conguration proles for users to apply themselves.
Alternatively, you can have users enroll their iOS devices with an MDM solution that provides
settings and apps over the air. Users can then personalize the iOS devices with their own apps
and data, which stay separate from your organization’s managed apps and data. If the iOS
devices are purchased directly from Apple or a participating Apple Authorized Reseller or carrier,
your organization can use the Device Enrollment Program (DEP) to automate enrollment in MDM,
so iOS devices can be handed to users directly or shipped to their homes and activated remotely.
100% resize factor
Chapter 2 Deployment models 18
The following table illustrates the responsibilities of both the administrator and the user for a
personalized device (corporate-owned) deployment:
Prepare
Administrator:
•
Evaluate your existing infrastructure including Wi-Fi,
VPN, and mail and calendar servers.
•
Investigate, procure, and deploy an MDM solution.
•
Enroll in the Device Enrollment Program (DEP) and
the Volume Purchase Program (VPP).
Users:
•
Create Apple ID, iTunes Store, and iCloud accounts,
if applicable.
Set up and congure
Administrator:
•
From the Device Enrollment Program website, link
your virtual servers to your MDM solution.
•
Streamline enrollment through Device Enrollment
Program by assigning iOS devices to your virtual
MDM servers by order number or by serial number.
•
Assign iOS devices in DEP for supervision and
streamlined enrollment in MDM.
•
Use Apple Congurator to congure and supervise
the iOS device (alternative to the above).
•
Congure and install accounts, settings, and
restrictions wirelessly with MDM or use USB with
Apple Congurator.
Users:
•
The user is provided an iOS device. If Apple
Congurator was used to setup the device, then no
further setup by the user is necessary.
•
Enter organization credentials in Setup Assistant for
DEP (optional).
•
Personalize the iOS device with Setup Assistant and
enter a personal Apple ID.
•
Enroll in MDM.
•
iOS device settings and congurations are
automatically received from MDM.
Distribute apps and books
Administrator:
•
Download your token from the VPP Store and link it
to your MDM solution.
•
Purchase apps and books using VPP and assign
them to users with MDM.
•
Send VPP invitation to users.
•
Distribute in-house apps from the iOS Developer
Enterprise Program (iDEP) and in-house books
by hosting them on a web server or your MDM
solution.
•
Install Caching Server to speed up content delivery
over the local network.
Users:
•
Accept invitation to VPP.
•
Download and install apps and books assigned by
the organization.
•
If the iOS device is supervised, apps can be pushed
to the user’s device silently.
Ongoing management
Administrator:
•
Revoke and reassign apps to other users as needed
with MDM.
•
With MDM, you can query managed iOS devices to
monitor compliance, or trigger alerts if users add
unapproved apps or content.
•
MDM can also lock iOS devices or remotely wipe
any managed accounts or data, or wipe an iOS
device entirely.
Users:
•
Back up the iOS device to iTunes or iCloud, to save
documents and other personal content.
•
If the device is lost or stolen, the user can locate it
with Find My iPhone.
100% resize factor
Chapter 2 Deployment models 19
Additional Resources
•
VPP Overview
•
MDM Overview
•
Device Enrollment Program
•
Apple ID
•
Caching Server
•
Apple Congurator
Non-personalized device (shared)
If iOS devices are shared by several people or used for a single purpose (such as in a restaurant
or hotel), they’re typically congured and managed by you rather than by an individual user.
With a non-personalized device deployment, users generally don’t store personal data or have
the ability to install apps.
Non-personalized devices are usually supervised with Apple Congurator and enrolled with an
MDM solution. This lets the content on the device be refreshed or restored, if it’s modied by
a user.
100% resize factor
Chapter 2 Deployment models 20
The following table illustrates the responsibilities of both the administrator and the user for a
non-personalized device (shared) deployment:
Prepare
Administrator:
•
Evaluate your existing infrastructure including Wi-Fi,
VPN, and mail and calendar servers.
•
Investigate, procure, and deploy an MDM solution.
•
Enroll in the Volume Purchase Program (VPP).
Users:
•
No action necessary at this stage.
Set up and congure
Administrator:
•
Unbox and (optionally) asset tag the iOS device.
•
Use Apple Congurator to congure and supervise
devices.
•
Use Apple Congurator to enroll devices in MDM
(optional).
•
Use Apple Congurator or MDM to install accounts,
settings, and restrictions.
Users:
•
No action necessary at this stage.
Distribute apps
Administrator:
•
Purchase apps using VPP and deploy them using
Apple Congurator.
•
Distribute in-house apps from the iOS Developer
Enterprise Program (iDEP) using Apple Congurator.
•
Distribute in-house books by hosting them on a
web server or your MDM solution.
Users:
•
No action necessary at this stage.
Ongoing management
Administrator:
•
Update iOS on the device with Apple Congurator.
•
Update, congure, and install accounts, settings
and restrictions wirelessly with Apple Congurator
or MDM.
•
Periodically reset devices to standard conguration
with Apple Congurator.
•
Install and update apps on the device with Apple
Congurator.
•
With MDM, you can query managed iOS devices to
monitor compliance, or trigger alerts if users add
unapproved apps or content.
•
MDM can also lock iOS devices or remotely wipe
any managed accounts or data, or wipe an iOS
device entirely.
Users:
•
No action necessary at this stage.
Additional Resources
•
VPP Overview
•
MDM Overview
•
Apple ID
•
Apple Congurator
100% resize factor
21
Wi-Fi
Overview
When preparing the Wi-Fi infrastructure for an Apple device deployment, there are several
factors to consider:
•
Wi-Fi throughput
•
Wi-Fi trigger threshold
•
Required coverage area
•
Number and density of devices using the Wi-Fi network
•
Types of Apple devices and their Wi-Fi capabilities
•
Types and amount of data being transferred
•
Security requirements for accessing the wireless network
•
Encryption requirements
Although this list isn’t exhaustive, it represents some of the most relevant Wi-Fi network
design factors.
Note: This section focuses on Wi-Fi network design in North America. The design may dier in
other countries.
Wi-Fi throughput
As you plan to deploy iOS devices within your organization, make sure your Wi-Fi network and
supporting infrastructure are robust and up to date. Consistent and dependable access to a
strong network is critical to setting up and conguring iOS devices. In addition, being able
to support multiple iOS devices with simultaneous connections from all of your employees,
students, or teachers is important to the success of your program.
Important: Your user and their iOS device must have access to your wireless network
and Internet services for setup and conguration. You may need to congure your web
proxy or rewall ports to allow all network trac from Apple’s devices to Apple’s network
(17.0.0.0/8), if Apple devices are unable to access Apple’s activation servers, iCloud, or
the iTunes Store. For a list of ports used by Apple devices, see the Apple Support article
TCP and UDP ports used by Apple software products.
100% resize factor
3
Chapter 3 Wi-Fi 22
Join Wi-Fi
Users can set Apple devices to join available Wi-Fi networks automatically. Wi-Fi networks
that require login credentials or other information can be quickly accessed without opening
a separate browser session, from Wi-Fi settings, or within apps such as Mail. And low-power,
persistent Wi-Fi connectivity lets apps use Wi-Fi networks to deliver push notications. You can
congure settings for wireless network, security, proxy, and authentication, using conguration
proles or mobile device management (MDM).
To see how iOS decides which wireless network to auto-join, see the Apple Support article
How iOS decides which wireless network to auto-join.
WPA2 Enterprise
Apple devices support industry-standard wireless network protocols, including WPA2 Enterprise,
ensuring corporate wireless networks can be accessed securely. WPA2 Enterprise uses 128-bit AES
encryption, which assures users that their data remains protected.
With support for 802.1X, iOS devices can be integrated into a broad range of RADIUS
authentication environments. 802.1X wireless authentication protocols supported by iOS include
EAP-TLS, EAP-TTLS, EAP-FAST, EAP-SIM, IKEv2, PEAPv0, PEAPv1, and LEAP.ara.
Roaming
For roaming on large enterprise Wi-Fi networks, iOS supports 802.11k and 802.11r.
The trigger threshold is the minimum signal level a client requires to maintain the
current connection.
iOS devices monitor and maintain the current BSSID’s connection until the RSSI crosses the
-70 dBm threshold. Once crossed, iOS initiates a scan to nd roam candidate BSSIDs for the
current ESSID.
This information is important to consider when designing wireless cells and their expected signal
overlap. For example, if 5 GHz cells are designed with a -67 dBm overlap:
•
iOS uses -70 dBm as the trigger and will therefore remain connected to the current BSSID
longer than you expect.
•
Review how the cell overlap was measured. The antennas on a portable computer are much
larger and more powerful than a smartphone or tablet, so iOS devices see dierent cell
boundaries than expected. It is always best to measure using the target device.
802.11k allows your iOS device to quickly identify nearby access points (AP) that are available for
roaming. When the signal strength of the current AP weakens and your device needs to roam to
a new AP, it will already know which AP is the best to connect with.
802.11r streamlines the authentication process using a feature called Fast Basic Service Set
Transition (FT) when your iOS device roams from one AP to another on the same network.
FT allows iOS devices to associate with APs more quickly. Depending on your Wi-Fi hardware
vendor, FT can work with both preshared key (PSK) and 802.1X authentication methods.
Note: Not every Wi-Fi network hardware vendor supports 802.11k and 802.11r. Check with
the manufacturer of your Wi-Fi hardware (controllers and APs) to nd out if support is
available. When you’ve veried support for both standards, you need to enable 802.11k and FT
functionality. Setup methods vary so consult the current conguration documentation for your
Wi-Fi hardware for details.
100% resize factor
Chapter 3 Wi-Fi 23
The table below shows which iOS devices can support 802.11k and 802.11r with iOS. Even if an
iOS device doesn’t support 802.11r, iOS 5.1 added support for “pairwise master key identier
caching” (PMKID caching), which can be used with some Cisco equipment to improve roaming
between APs. Additional SSIDs might be necessary to support both FT-capable iOS devices and
PMKID-caching iOS devices.
iOS device 802.11k/r support iOS 6 and later
supported methods
Pre-iOS 6 supported
methods
iPad Air 2, iPad mini 3,
iPhone 6, iPhone 6 Plus,
iPhone 5s. iPhone 5c,
iPad Air, iPad mini with
Retina Display, iPad (4th
generation), iPad mini,
iPhone 5, iPod touch (5th
generation)
Yes FT, PMKID caching Not applicable
iPad (3rd generation),
iPhone 4s
Yes FT, PMKID caching PMKID caching
iPad (2nd generation)
and earlier, iPhone 4 and
earlier, iPod touch (4th
generation) and earlier
No PMKID caching PMKID caching
•
Prior to iOS 5.1, no
method for optimized
AP roaming existed
in iOS.
•
“Sticky key caching”
(SKC) is a form of
PMKID caching. SKC
is not equivalent to,
nor compatible with,
opportunistic key
caching (OKC).
To view Apple’s wireless roaming reference, see the Apple Support article iOS 8: Wireless
roaming reference for enterprise customers. For more information about roaming with 802.11k
and 802.11r, see the Apple Support article iOS: Wi-Fi network roaming with 802.11k and 802.11r.
Plan for coverage and capacity
Although it’s important to provide Wi-Fi coverage where Apple devices are used, it’s also
essential to plan for the density of devices in a given area to ensure proper capacity.
Most modern, enterprise-class access points are capable of handling up to 50 Wi-Fi clients or
even more, although the user experience would likely be disappointing if that many devices
were actually using a single 802.11n access point. The experience for each user depends on the
available wireless bandwidth on the channel the device is using, and on the number of devices
sharing that bandwidth. As more devices use the same channel, the relative network speed for
those devices decreases. You should consider the expected usage pattern of the Apple devices as
part of your Wi-Fi network design.
100% resize factor
Chapter 3 Wi-Fi 24
Important: Avoid using hidden Service Set Identiers (SSIDs), because Wi-Fi devices must actively
seek out hidden SSIDs. This leads to delays when rejoining the SSID, potentially impacting data
ow and communications. There’s also no security benet in hiding the SSID. Users tend to
change location frequently along with their Apple devices, so hidden SSIDs often delay network
association time and hinder roaming performance. This practice may use more power than a
broadcast SSID and may aect device battery life.
2.4 GHz vs. 5 GHz
Wi-Fi networks operating at 2.4 GHz provide 11 channels in North America. However, due
to channel interference considerations, only channels 1, 6, and 11 should be used in a
network design.
5 GHz signals don’t penetrate walls and other barriers as well as 2.4 GHz signals, which results
in a smaller coverage area. Therefore, use 5 GHz networks when you design for a high density
of devices in an enclosed space, such as in classrooms or large meeting rooms. The number of
channels available in the 5 GHz band varies among vendors and from country to country, but at
least eight channels are always available.
5 GHz channels are non-overlapping, which is a signicant departure from the three non-
overlapping channels available in the 2.4 GHz band. When you design a Wi-Fi network for a
high density of Apple devices, the additional channels provided at 5 GHz become a strategic
planning consideration.
Important: Wireless coverage should be ubiquitous throughout the workspace. If legacy devices
are in use, both Wi-Fi bands—802.11b/g/n 2.4 GHz and 802.11a/n/ac 5 GHz—should be central to
the design plan.
Design considerations
There are three main considerations when you design your Wi-Fi networks.
Design for coverage
The physical layout of the building may have an impact on your Wi-Fi network design. For
example, in a small business environment, users may meet with other employees in conference
rooms or in oces. As a result, users move around the building throughout the day. In this
scenario, the majority of network access comes from low bandwidth activities such as checking
mail, calendars, and Internet browsing, so Wi-Fi coverage is the highest priority. A Wi-Fi design
could include a small number of access points on each oor to provide coverage for the oces.
Additional access points might be considered for areas where large numbers of employees
gather, such as a large conference room.
Design for capacity
Contrast the scenario above with a school that has 1000 students and 30 teachers in a two-story
building. Every student is issued an iPad, and every teacher is issued both a MacBook Air and an
iPad. Each classroom holds approximately 35 students, and classrooms are next to each other.
Throughout the day, students conduct research on the Internet, watch curriculum videos, and
copy les to and from a le server on the Local Area Network (LAN).
100% resize factor
Chapter 3 Wi-Fi 25
The Wi-Fi network design for high density is more complex, due to the higher density of
mobile devices. Because of the large number of devices in each classroom, one access point per
classroom might be required. Multiple access points should be considered for the common areas,
to provide adequate coverage and capacity. The number of access points for the common areas
may vary, depending on the density of Wi-Fi devices in those spaces.
Channel
64
Channel
44
Channel
52
Channel
48
Channel
64
Channel
36
Channel
157
Channel
161
Channel
36
Channel
40
Important: A pre-install site survey should always be performed to determine the exact number
of access points needed and where those access points should be mounted. A site survey also
determines the proper power settings for each radio. Once the installation of the Wi-Fi network
is complete, a post-install site survey should be performed to conrm the Wi-Fi environment.
For example, if designing a network to support a large number of people in a building it is best
to validate the design with people in the building. (Or, if classroom doors will be closed when the
network is in use, the door should be closed when validating the design as well.)
Sometimes it is desirable to create multiple SSIDs for dierent purposes. For example, a guest
network may be required. Care should be taken to avoid creating too many SSIDs, as the
additional SSIDs cause additional bandwidth usage.
Design for Applications
Apple products use multicast networking for services like AirPlay and AirPrint. Therefore,
multicast support should be part of the design plan. For information about how to prepare your
network for Bonjour, see Bonjour.
Wi-Fi standards in iOS devices
Wi-Fi specications for Apple iOS devices are detailed in the list that follows, which includes this
information:
•
802.11 compatibility: 802.11ac, 802.11n, 802.11a, 802.11b/g
•
Frequency band: 2.4 GHz or 5 GHz
•
Maximum Transmit Rate: This is the highest rate at which a client cant transmit data over Wi-Fi.
•
Spatial streams: Each radio can send independent data streams at the same time, each
containing dierent data, which can increase overall throughput. The number of these
independent data streams is dened as the number of spatial streams.
•
MCS index: The Modulation and Coding Scheme (MCS) index denes the maximum
transmission rate at which 802.11ac/n devices can communicate. 802.11ac uses Very High
Throughput (VHT) and 802.11n uses High Throughput (HT).
100% resize factor
Chapter 3 Wi-Fi 26
•
Channel width: The maximum channel width. Beginning with 802.11n, channels can be
combined to create a wider channel that allows for more data to be transmitted during a
single transmission. With 802.11n, two 20 MHz channels can be combined to create a 40 MHz
channel. With 802.11ac, four 20 MHz channels can be combined to create an 80 MHz channel.
•
Guard interval (GI): The guard interval is the space (time) between symbols transmitted from
one device to another. The 802.11n standard denes the option of a short guard interval of
400ns that provides faster overall throughput, but devices may use a long guard interval
of 800ns.
Model 802.11
compatibility
and frequency
band
Maximum
Transmit Rate
Spatial
streams
MCS index Channel
width
Guard
interval
iPad Air 2 802.11ac/n/a
@ 5 GHz
802.11 n/g/b
@ 2.4 GHz
866 Mbps 2 9 (VHT)
15 (HT)
80 MHz 400 ns
iPad mini 3 802.11n @ 2.4 GHz
and 5GHz
802.11a/b/g
300 Mbps 2 15 (HT) 40 MHz 400 ns
iPhone 6 Plus
iPhone 6
802.11ac/n/a
@ 5 GHz
802.11 n/g/b
@ 2.4 GHz
433 Mbps 1 9 (VHT)
7 (HT)
80 MHz 400 ns
iPhone 5s
iPhone 5c
iPhone 5
802.11n @ 2.4 GHz
and 5GHz
802.11a/b/g
150 Mbps 1 7 (HT) 40 MHz 400 ns
iPhone 4s
iPhone 4
802.11n @ 2.4GHz
802.11b/g
65 Mbps 1 7 (HT) 20 MHz 800 ns
iPad Air
iPad mini
with Retina
display
802.11n @ 2.4GHz
and 5GHz
802.11a/b/g
300 Mbps 2 15 (HT) 40 MHz 400 ns
iPad (4th
generation)
iPad mini
802.11n @ 2.4GHz
and 5GHz
802.11a/b/g
150 Mbps 1 7 (HT) 40 MHz 400 ns
iPad (1st,
2nd, and 3rd
generation)
802.11n @ 2.4GHz
and 5GHz
802.11a/b/g
65 Mbps 1 7 (HT) 20 MHz 800 ns
iPod
touch (5th
generation)
802.11n @ 2.4GHz
and 5GHz
802.11a/b/g
150 Mbps 1 7 (HT) 40 MHz 400 ns
iPod
touch (4th
generation)
802.11n @ 2.4GHz
802.11b/g
65 Mbps 1 7 (HT) 20 MHz 800 ns
100% resize factor
27
Infrastructure and integration
Overview
iOS supports a wide range of network infrastructures, including the following:
•
Local networking using Bonjour
•
Cable-free connections to Apple TV using AirPlay
•
Digital certicates to authenticate users and secure communications
•
Single Sign-On to streamline authentication to networked apps and services
•
Standards-based mail, directory, calendar, and other systems
•
Popular third-party systems like Microsoft Exchange
•
Virtual private networks (VPN), including Per App VPN and Always-on VPN
This support is built into iOS, so your IT department needs to congure only a few settings
to integrate iOS devices into your existing infrastructure. Read on to learn more about iOS-
supported technologies and guidelines for business and eduction.
Microsoft Exchange
iOS can communicate directly with your Microsoft Exchange Server using Microsoft Exchange
ActiveSync (EAS), enabling push email, out-of-oce replies, calendar, contacts, notes, and tasks.
Exchange ActiveSync also provides users with access to the Global Address List (GAL), and
provides administrators with passcode policy enforcement and remote wipe capabilities. iOS
supports both basic and certicate-based authentication for Exchange ActiveSync.
If your organization currently uses Exchange ActiveSync, you have the necessary services in place
to support iOS—no additional conguration is necessary.
Requirements
iOS 8 or later supports the following versions of Microsoft Exchange:
•
Oce 365 (using EAS 14.1)
•
Exchange Server 2013 (using EAS 14.1)
•
Exchange Server 2010 SP 2 (using EAS 14.1)
•
Exchange Server 2010 SP 1 (EAS 14.1)
•
Exchange Server 2010 (EAS 14.0)
•
Exchange Server 2007 SP 3 (EAS 12.1)
•
Exchange Server 2007 SP 2 (EAS 12.1)
•
Exchange Server 2007 SP 1 (EAS 12.1)
•
Exchange Server 2007 (using EAS 2.5)
100% resize factor
4
Chapter 4 Infrastructure and integration 28
Microsoft Exchange Autodiscovery
iOS and OS X support the Autodiscover service of Microsoft Exchange Server 2007 or later. When
you manually congure an Apple device, Autodiscover uses your email address and password to
determine the correct Exchange Server information.
For more information, see Autodiscover Service at the Microsoft website.
Microsoft Direct Push
Exchange Server automatically delivers email, tasks, contacts, and calendar events to iOS devices,
provided a cellular or Wi-Fi data connection is available.
Microsoft Exchange Global Address List (GAL)
Apple devices retrieve contact information from your organization’s Exchange Server corporate
directory. You can access the directory while searching in Contacts, and it’s automatically
accessed for completing email addresses as you enter them.
Note: iOS 6 or later supports GAL photos (requires Exchange Server 2010 SP 1 or later).
Set out-of-oce reply message
iOS 8 supports the use of automatic message replies when the user is unavailable. The user can
also select an end date for the replies.
Calendar
iOS 8 or later and OS X Mavericks or later support the following features of Microsoft Exchange:
•
Wirelessly create and accept calendar invitations
•
View an invitee’s calendar free/busy information
•
Create private calendar events
•
Congure custom repeating events
•
View the week numbers in Calendar
•
Receive calendar updates
•
Sync tasks with the Reminders app
View the Exchange identier
iOS 8 lets the user see the unique device identier that’s seen by the Exchange Server, called
the Exchange Device ID. This is useful when the Exchange Server the user connects to requires
devices to be whitelisted before access is allowed. They can supply this identier to you in
advance. The Exchange Device ID changes only if the device is restored back to factory settings.
It won’t change when upgrading from iOS 7 to iOS 8. To view the Exchange Device ID on an iOS
device, tap Settings > Mail, Contacts, Calendars > Add Account, then tap Exchange.
Identify iOS versions with Exchange
When an iOS device connects to an Exchange Server, the device reports its iOS version. The
version number is sent in the User Agent eld of the request header, and looks like Apple-
iPhone2C1/705.018. The number after the delimiter (/) is the iOS build number, which is unique
to each iOS release.
To view the build number on a device, go to Settings > General > About. You’ll see the version
number and build number, such as 4.1 (8B117A). The number in parentheses is the build number,
which identies the release the device is running.
100% resize factor
Chapter 4 Infrastructure and integration 29
When the build number is sent to the Exchange Server, it’s converted from the format NANNNA
(where N is numeric and A is an alphabetic character) to the Exchange format NNN.NNN. Numeric
values are kept, but letters are converted to their position value in the alphabet. For example, “F”
is converted to “06” because it’s the sixth letter in the alphabet. Numbers are padded with zeros
if necessary, to t the Exchange format. In this example, the build number 7E18 is converted to
“705.018.”
The rst number, 7, remains as “7.” The character E is the fth letter in the alphabet so it’s
converted to “05.” A period (.) is inserted in the converted version, as required by the format.
The next number,18, is padded with zero and converted to “018.”
If the build number ends with a letter, such as 5H11A, the number is converted as described
above, and the numeric value of the nal character is appended to the string, separated by
3 zeroes. So 5H11A becomes “508.01100001.”
Remote Wipe
You can remotely wipe the contents of an iOS device using features provided by Exchange.
Wiping removes all data and conguration information from the device, and the device is
securely erased and restored to its original factory settings. Wiping removes the encryption
key to the data (encrypted using 256-bit AES encryption), which immediately makes all of the
data unrecoverable.
With Microsoft Exchange Server 2007 or later, you can perform a remote wipe with the Exchange
Management Console, Outlook Web Access, or the Exchange ActiveSync Mobile Administration
Web Tool. With Microsoft Exchange Server 2003, you can initiate a remote wipe using the
Exchange ActiveSync Mobile Administration Web Tool.
Alternatively, users can wipe their own device by going to Settings > General > Reset and
choosing “Erase All Content and Settings.” Devices can also be congured to be automatically
wiped after a specied number of failed passcode attempts.
Bonjour
Bonjour is Apple’s standards-based, zero conguration network protocol that lets devices nd
services on a network. iOS devices use Bonjour to discover AirPrint-compatible printers, and both
iOS devices and Mac computers use Bonjour to discover AirPlay-compatible devices such as
Apple TV. Some apps also use Bonjour for peer-to-peer collaboration and sharing.
Bonjour works by using multicast trac to advertise the availability of services. Multicast trac is
usually not routed, so make sure Apple TV devices or AirPrint printers are on the same IP subnet
as the iOS devices that would use them. If your network is larger and utilizes many IP subnets,
you may want to consider using a Bonjour gateway such as those oered by various Wi-Fi
infrastructure manufactures.
For more information about Bonjour, see Apple’s Bonjour webpage and Apple's Developer
documentation on Bonjour.
100% resize factor
Chapter 4 Infrastructure and integration 30
AirPlay
iOS 8 and OS X Yosemite support the ability to stream content from an Apple device to Apple TV
even if the devices are on dierent networks or there’s no network available. The Apple device
uses Bluetooth® Low Energy (BTLE) to begin the discovery process of available Apple TV devices
and then establishes a connection directly to Apple TV using Wi-Fi. Bluetooth Low Energy
discovery is a distinct subset of peer-to-peer AirPlay.
In iOS 8 and OS X Yosemite, peer-to-peer AirPlay lets a user use AirPlay directly from a supported
iOS device or Mac to an Apple TV without rst connecting to an organization’s network. Peer-
to-peer AirPlay eliminates the need to join the right network or disclose Wi-Fi passwords, avoids
reachability issues in complex network environments, and provides a direct path from the AirPlay
sender to AirPlay receiver to optimize performance. Peer-to-peer AirPlay is enabled by default in
iOS 8 and OS X Yosemite, and doesn’t require any user conguration.
Peer-to-peer AirPlay requires:
•
Apple TV (3rd generation rev A Model A1469 or later) with Apple TV software 7.0 or later
•
iOS devices (late 2012 or later) with iOS 8 or later
•
Mac computers (2012 or later) with OS X Yosemite or later
To nd the model number of an Apple TV, see the Apple Support article Identifying Apple TV
models.
Peer-to-Peer discovery is initiated using Bluetooth Low Energy (BTLE) when a user selects AirPlay
on an iOS device running iOS 8 or Mac running OS X Yosemite. This causes the device and the
Apple TV to visit Wi-Fi channel 149,1 in the 5 GHz band and Wi-Fi channel 6 in the 2.4 GHz band,
where the discovery process continues. Once the user selects an Apple TV and AirPlay starts, the
Wi-Fi radios timeshare between channel 149,1 and whichever infrastructure channel each device
is currently using. If possible, the AirPlay sender roams to the same infrastructure channel the
Apple TV is using. If neither device is currently using an infrastructure network, the devices will
utilize Wi-Fi channel 149 only for AirPlay. Peer-to-peer AirPlay adheres to 802.11 standards, sharing
Wi-Fi bandwidth with other Wi-Fi devices.
When you deploy Apple TVs on a large enterprise Wi-Fi network, consider the following
guidelines:
•
Connect Apple TV to Ethernet whenever possible.
•
If possible, avoid using Wi-Fi Channels 149 and 153 for your infrastructure network.
•
Don’t place or mount the Apple TV behind objects that could disrupt the Bluetooth Low
Energy and Wi-Fi signals.
•
When mounting an Apple TV to a wall or other surface, always mount it with the foot side to
the surface.
•
If peer-to-peer AirPlay isn’t supported on either the AirPlay sender or receiver, then the
infrastructure connection is automatically used.
AirPlay discovery
iOS devices will continue to use the same discovery methods available today to nd AirPlay
receivers. AirPlay receivers can advertise themselves using Bonjour or Bluetooth. Discovery over
Bluetooth requires iOS 7.1 or later on the following:
•
iPad Air
•
Apple TV (3rd generation or later) running software 6.1 or later
•
iPhone 4s or later
100% resize factor
Chapter 4 Infrastructure and integration 31
•
iPad 3rd generation or later
•
iPad mini 1st generation or later
•
iPod touch 5th generation or later
Discovered AirPlay receivers appear in the AirPlay menu.
Bonjour services _airplay._tcp and _raop._tcp need to be advertised on Bonjour gateway
products. Contact your gateway vendor to make sure these services are advertised.
Connectivity
Infrastructure and peer-to-peer are the two supported modes of AirPlay connectivity. If both the
AirPlay sender and receiver support peer-to-peer AirPlay, that’s the preferred data path regardless
of infrastructure availability. Peer-to-peer AirPlay coexists with infrastructure connections, so the
AirPlay client or AirPlay sender can maintain Internet connectivity simultaneously with the peer-
to-peer connection. The 5 GHz band is better for connecting over peer-to-peer AirPlay, because it
provides a fast, direct connection between the AirPlay sender and AirPlay receiver.
Security
AirPlay uses AES encryption to ensure that content remains protected when mirroring or
streaming from an iOS device or Mac to an Apple TV.
AirPlay access to an Apple TV can be restricted by setting an Onscreen Code or Password.
Only users who enter the Onscreen Code (per AirPlay attempt) or Password on their iOS device
or Mac can send AirPlay content to an Apple TV.
Enabling Require Device Verication (Requires an iOS device with iOS 7.1 or later or a Mac with
OS X Mavericks v/10.9.2 or later.) requires the iOS device or Mac to authenticate on the initial
AirPlay connection. Require Device Verication is useful when Apple TV is deployed on an
open Wi-Fi network. To ensure iOS devices and Mac computers are securely paired, the user is
prompted to enter in a one-time Onscreen code. Subsequent connections don’t require a code,
unless Onscreen Code settings are enabled. Restoring an Apple TV or a previously-paired client
to factory settings resets the initial connection condition.
Peer-to-peer AirPlay is always secured with Require Device Authentication. This setting isn’t
congurable by the user, and it prevents any nearby unauthorized users from accessing an
Apple TV.
Note: For devices not on an infrastructure network, Bonjour advertisement of supported
AppleTV devices (A1469 or later) is triggered by Bluetooth.
Standards-based services
With support for the IMAP mail protocol, LDAP directory services, CalDAV calendaring, and
CardDAV contacts protocols, iOS and OS X can integrate with just about any standards-based
environment. And if your network environment is congured to require user authentication and
SSL, iOS and OS X provide a secure approach to accessing standards-based corporate email,
calendar, tasks, and contacts. With SSL, iOS and OS X support 128-bit encryption and X.509 root
certicates issued by the major certicate authorities.
100% resize factor
Chapter 4 Infrastructure and integration 32
In a typical deployment, Apple devices establish direct access to IMAP and SMTP mail servers
to send and receive mail over the air (or in the case of a Mac, over the air or Ethernet), set VIP
status in their message threads, and can also wirelessly sync notes with IMAP-based servers.
Apple devices can connect to your organization’s LDAPv3 corporate directories, giving users
access to corporate contacts in the Mail, Contacts, and Messages apps. CardDAV support lets
your users maintain a set of contacts synced with your CardDAV server using the vCard format.
Synchronization with your CalDAV server lets users do the following:
•
Create and accept calendar invitations
•
View an invitee’s calendar free/busy information
•
Create private calendar events
•
Congure custom repeating events
•
View the week numbers in Calendar
•
Receive calendar updates
•
Sync tasks with the Reminders app
All network services and servers can be within a DMZ subnetwork, behind a corporate rewall,
or both.
Digital certicates
Apple devices support digital certicates and identities, giving your organization streamlined
access to corporate services. These certicates can be used in a variety of ways. For example, the
Safari browser can check the validity of an X.509 digital certicate and set up a secure session
with up to 256-bit AES encryption. This involves verifying that the site’s identity is legitimate and
that communication with the website is protected to help prevent interception of personal or
condential data. Certicates can also be used to guarantee the identity of the author or “signer”
and can be used to encrypt mail, conguration proles, and network communications to further
protect condential or private information.
Use certicates with Apple devices
Out of the box, Apple devices include a number of preinstalled root certicates from various
Certication Authorities (CA) and iOS validates the trust for these root certicates. If iOS can’t
validate the trust chain of the signing CA, the service will encounter an error. For example, a
self-signed certicate can’t be veried by default in iOS. To view the current list of trusted root
certicates in iOS, see the Apple Support article iOS 8: List of available trusted root certicates.
iOS devices can update certicates wirelessly, if any of the preinstalled root certicates
become compromised. To disable this, there’s an MDM restriction that prevents over-the-air
certicate updates.
These digital certicates can be used to securely identify a client or server, and encrypt the
communication between them utilizing the public and private key pair. A certicate contains a
public key, information about the client (or server), and is signed (veried) by a CA.
A certicate and its associated private key are known as an identity. Certicates can be freely
distributed, but identities must be kept secured. The freely distributed certicate, and especially
its public key part, are used for encryption that can be decrypted only by the matching private
key. To secure the private key of an identity, it is stored in a PKCS12 le, encrypted with another
key that is protected by a passphrase. An identity can be used for authentication (such as 802.1x
EAP-TLS), signing, or encryption (such as S/MIME).
100% resize factor
Chapter 4 Infrastructure and integration 33
The list of supported certicate and identity formats on Apple devices are:
•
X.509 certicates with RSA keys
•
Certicate: .cer, .crt, .der
•
Identity: .pfx, .p12
Deploy certicates to establish trust with Certication Authorities (CA) that are not trusted by
default (such as an organizational-issuing certication authority).
Distribute and install certicates
Manually distributing certicates to iOS devices is simple. When a certicate is received,
users simply tap to review the contents, then tap to add the certicate to their device.
When an identity certicate is installed, users are prompted for the password that protects it.
If a certicate’s authenticity can’t be veried, it’s shown as untrusted and the user can decide
whether to add it to their device.
Install certicates using conguration proles
If conguration proles are being used to distribute settings for corporate services such as
S/MIME mail, VPN, or Wi-Fi, certicates can be added to the prole to streamline deployment.
This includes the ability to distribute certicates with MDM.
Install certicates via Mail or Safari
If a certicate is sent in a mail message, it appears as an attachment. Safari can also be used
to download certicates from a webpage. You can host a certicate on a secured website and
provide users with the URL where they can download the certicate onto their Apple device.
Certicate removal and revocation
To manually remove a certicate that’s been installed, choose Settings > General > Device
Management, select a prole, choose More Details, and choose the appropriate certicate to
remove. If a user removes a certicate that’s required for accessing an account or network, the
iOS device is no longer able to connect to those services.
An MDM server can view all certicates on a device and remove any certicates it has installed.
Additionally, the Online Certicate Status Protocol (OCSP) and CRL (Certicate Revocation List)
protocol are supported to check the status of certicates. When an OCSP- or CRL-enabled
certicate is used, both iOS and OS X periodically validate it to make sure that it hasn’t
been revoked.
Single Sign-On (SSO)
Single Sign-On (SSO) is a process in which a user can provide authentication information once,
receive a ticket, and use it to access resources for as long as the ticket is valid. This strategy
makes it possible to maintain secure access to resources without the system prompting the
user for credentials every time access is requested. It also increases the security of daily app use,
by ensuring that passwords are never transmitted over the network.
100% resize factor
Chapter 4 Infrastructure and integration 34
With iOS 7 or later, apps can take advantage of your existing in-house Single Sign-On
infrastructure via Kerberos. The Kerberos authentication system used by iOS 7 or later is
the most commonly deployed Single Sign-On technology in the world. If you have Active
Directory, eDirectory, or Open Directory, it’s likely to already have a Kerberos system in place
that iOS 7 or later can use. iOS devices need to be able to contact the Kerberos service over a
network connection to authenticate users. In iOS 8, certicates can be used to silently renew a
Kerberos ticket, letting users maintain connections to certain services that leverage Kerberos
for authentication.
Supported apps
iOS provides exible support for Kerberos Single Sign-On to any app that uses the
NSURLConnection or NSURLSession class to manage network connections and authentication.
Apple provides all developers with these high-level frameworks to make network connections
seamlessly integrated within their apps. Apple also provides Safari, as an example to help you get
started by using SSO-enabled websites natively.
Congure Single Sign-On
You congure Single Sign-On using conguration proles, which may be either manually
installed or managed with MDM. The Single Sign-On payload allows exible conguration.
Single Sign-On can be open to all apps, or restricted by app identier, service URL, or both.
Simple pattern matching is used for URLs which must begin with either http:// or https://.
The matching is on the entire URL, so be sure that they’re exactly the same. For example, a
URLPrexMatches value of https://www.example.com/ won’t match https://www.example.
com:443/. You may specify http:// or https:// to restrict the use of SSO to either secure or regular
HTTP services. For example, using a URLPrexMatches value of https:// allows the SSO account to
be used only with secure HTTPS services. If a URL matching pattern doesn’t end with a slash (/),
a slash is appended.
The AppIdentierMatches array must contain strings that match app bundle IDs. These strings
may be exact matches (com.mycompany.myapp, for example) or may specify a prex match on
the bundle ID by using the wildcard character (*). The wildcard character must appear after a
period (.), and only at the end of the string (for example, com.mycompany.*). When a wildcard is
given, any app whose bundle ID begins with the prex is granted access to the account.
Virtual private networks (VPN)
Overview
Secure access to private corporate networks is available in iOS and OS X using established
industry-standard virtual private network (VPN) protocols. Out of the box, iOS and OS X support
Cisco IPSec, L2TP over IPSec, and PPTP. iOS also supports IKEv2. If your organization supports one
of these protocols, no additional network conguration or third-party apps are required in order
to connect Apple devices to your VPN.
iOS and OS X support SSL VPN from popular VPN providers. Like other VPN protocols supported
in iOS and OS X, SSL VPN can be congured manually on the Apple device, or by conguration
proles or mobile device management.
100% resize factor
Chapter 4 Infrastructure and integration 35
iOS and OS X also support industry-standard technologies such as IPv6, proxy servers, and split-
tunneling, providing a rich VPN experience when connecting to corporate networks. And iOS
and OS X work with a variety of authentication methods including password, two-factor token,
digital certicates, and for OS X, Kerberos. To streamline the connection in environments where
certicate-based authentication is used, iOS and OS X feature VPN On Demand, which initiates a
VPN session when it’s needed in order to connect to specied domains.
With iOS 7 or later and OS X Yosemite or later, individual apps can be congured to use a VPN
connection independent from other apps. This ensures that corporate data always ows over a
VPN connection, and other data, such as an employee’s personal apps from the App Store, does
not. For details, see Per App VPN.
iOS also features Always-on VPN, when an iOS device must connect to a known, approved VPN
before connecting to any other network services. You can congure Always-on VPN for both
cellular and Wi-Fi congurations. For example, using Always-on VPN, an iOS device must connect
to a known and approved VPN before connecting to any other network services such as mail,
web, or messages. This feature depends on your VPN provider supporting this conguration,
and is available only for supervised devices. For information, see the Always-on VPN Overview.
Supported protocols and authentication methods
iOS and OS X support the following protocols and authentication methods:
•
L2TP over IPSec: User authentication by MS-CHAP v2 password, two-factor token, certicate,
machine authentication by shared secret or certicate.
•
SSL VPN: User authentication by password, two-factor token, certicates using a third-party
VPN client.
•
Cisco IPSec: User authentication by password, two-factor token, machine authentication by
shared secret and certicates.
•
IKEv2: Certicates (RSA-only), EAP-TLS, EAP-MSCHAPv2. (iOS-only)
•
PPTP: User authentication by MS-CHAP v2 password, certicate, and two-factor token.
OS X can also use Kerberos machine authentication by shared secret or certicate with L2TP over
IPSec and with PPTP.
SSL VPN clients
Several SSL VPN providers have created apps to help congure iOS devices for use with their
solutions. To congure a device for a specic solution, install the companion app from the
App Store and, optionally, provide a conguration prole with the necessary settings.
SSL VPN solutions include:
•
AirWatch SSL VPN: For information, see the AirWatch website.
•
Aruba Networks SSL VPN: iOS supports Aruba Networks Mobility Controller. For conguration,
install the Aruba Networks VIA app, available on the App Store.
For contact information, see the Aruba Networks website.
•
Check Point Mobile SSL VPN: iOS supports the Check Point Security Gateway with a full Layer-3
VPN tunnel. Install the Check Point Mobile app, available on the App Store.
•
Cisco AnyConnect SSL VPN: iOS supports Cisco Adaptive Security Appliance (ASA) running
suggested software release 8.2.5 or later. Install the Cisco AnyConnect app, available on the
App Store.
•
F5 SSL VPN: iOS supports F5 BIG-IP Edge Gateway, Access Policy Manager, and FirePass SSL VPN
solutions. Install the F5 BIG-IP Edge Client app, available on the App Store.
100% resize factor
Chapter 4 Infrastructure and integration 36
For more information, see the F5 technical brief
Secure iPhone Access to Corporate Web Applications.
•
Juniper Junos Pulse SSL VPN: iOS supports Juniper Networks SA Series SSL VPN Gateway
running version 6.4 or later with Juniper Networks IVE package 7.0 or later. Install the Junos
Pulse app, available on the App Store.
For more information, see Junos Pulse on the Juniper Networks website.
•
Mobile Iron SSL VPN: For information, see the Mobile Iron website.
•
NetMotion SSL VPN: For information, see the NetMotion website.
•
OpenVPN SSL VPN: iOS supports OpenVPN Access Server, Private Tunnel, and OpenVPN
Community. For conguration, install the OpenVPN Connect app, available on the App Store.
•
Palo Alto Networks GlobalProtect SSL VPN: iOS supports the GlobalProtect gateway from Palo
Alto Networks. Install the GlobalProtect for iOS app, available on the App Store.
•
SonicWALL SSL VPN: iOS supports SonicWALL Aventall E-Class Secure Remote Access
appliances running 10.5.4 or later, SonicWALL SRA appliances running 5.5 or later, and
SonicWALL Next-Generation Firewall appliances including the TZ, NSA, E-Class NSA running
SonicOS 5.8.1.0 or later. Install the SonicWALL Mobile Connect app, available on the App Store.
For more information, see the SonicWALL website.
VPN setup guidelines
Cisco IPSec setup guidelines
Use these guidelines to congure your Cisco VPN server for use with iOS devices. iOS supports
Cisco ASA 5500 Security Appliances and PIX Firewalls congured with 7.2.x software or later.
The latest software release (8.0.x or later) is recommended. iOS also supports Cisco IOS VPN
routers with IOS version 12.4(15)T or later. VPN 3000 Series Concentrators don’t support iOS
VPN capabilities.
Proxy setup
For all congurations, you can specify a VPN proxy:
•
To congure a single proxy for all connections, use the Manual setting and provide the
address, port, and authentication if necessary.
•
To provide the device with an auto-proxy conguration le using PAC or WPAD, use the Auto
setting. For PACS, specify the URL of the PACS or JavaScript le. For WPAD, iOS asks DHCP and
DNS for the appropriate settings.
The VPN proxy conguration gets used when the VPN is providing the following:
•
The default resolver and the default route: The VPN proxy is used for all web requests on
the system.
•
A split tunnel: Only connections to hosts that match the VPN’s DNS search domains will use
the VPN proxy.
Authentication methods
iOS supports the following authentication methods:
•
Pre-shared key IPSec authentication with user authentication via xauth.
•
Client and server certicates for IPSec authentication, with optional user authentication
via xauth.
•
Hybrid authentication, where the server provides a certicate and the client provides a pre-
shared key for IPSec authentication. User authentication is required via xauth.
•
User authentication is provided via xauth and includes the following authentication methods:
100% resize factor
Chapter 4 Infrastructure and integration 37
•
Username with password
•
RSA SecurID
•
CRYPTOCard
Authentication groups
The Cisco Unity protocol uses authentication groups to group users based on a common set
of parameters. You should create an authentication group for iOS users. For pre-shared key and
hybrid authentication, the group name must be congured on the device with the group’s
shared secret (pre-shared key) as the group password.
When using certicate authentication, there’s no shared secret. A user’s group is determined
from elds in the certicate. The Cisco server settings can be used to map elds in a certicate to
user groups.
RSA-Sig must be the highest priority on the ISAKMP priority list.
Certicates
When you set up and install certicates:
•
The server identity certicate must contain the server’s DNS name or IP address in the
SubjectAltName eld. The device uses this information to verify that the certicate belongs to
the server. For more exibility, you can specify the SubjectAltName using wildcard characters
for per-segment matching, such as vpn.*.mycompany.com. If no SubjectAltName is specied,
you can put the DNS name in the common name eld.
•
The certicate of the CA that signed the server’s certicate needs to be installed on the device.
If it isn’t a root certicate, install the rest of the trust chain so that the certicate is trusted.
If you use client certicates, make sure the trusted CA certicate that signed the client’s
certicate is installed on the VPN server. When using certicate-based authentication, make
sure the server is set up to identify the user’s group, based on elds in the client certicate.
Important: The certicates and certicate authorities must be valid (for example, not expired).
Sending of certicate chain by the server isn’t supported.
IPSec settings and descriptions
IPSec has various settings that you can use to dene how it will be implemented:
•
Mode: Tunnel mode.
•
IKE Exchange Modes: Aggressive Mode for pre-shared key and hybrid authentication or Main
Mode for certicate authentication.
•
Encryption Algorithms: 3DES, AES-128, or AES256.
•
Authentication Algorithms: HMAC-MD5 or HMAC-SHA1.
•
Die-Hellman Groups: Group 2 is required for pre-shared key and hybrid authentication.
Group 2 with 3DES and AES-128 for certicate authentication. Group 2 or 5 with AES-256.
•
PFS (Perfect Forward Secrecy): IKE phase 2, if PFS is used, the Die-Hellman group must be the
same as was used for IKE phase 1.
•
Mode Conguration: Must be enabled.
•
Dead Peer Detection: Recommended.
•
Standard NAT Traversal: Supported and can be enabled (IPSec over TCP isn’t supported).
•
Load Balancing: Supported and can be enabled.
•
Rekeying of Phase 1: Not currently supported. It’s recommend that rekeying times on the
server be set to one hour.
100% resize factor
Chapter 4 Infrastructure and integration 38
•
ASA Address Mask: Make sure all device address pool masks are either not set, or set to
255.255.255.255. For example:
asa(config-webvpn)# ip local pool vpn_users 10.0.0.1-10.0.0.254 mask
255.255.255.255
.
If you use the recommended address mask, some routes assumed by the VPN conguration
might be ignored. To avoid this, make sure your routing table contains all necessary routes and
make sure the subnet addresses are accessible before deployment.
•
Application Version: The client software version is sent to the server, letting the server accept
or reject connections based on the device’s software version.
•
Banner: The banner (if congured on the server) is displayed on the device and the user
must accept it or disconnect.
•
Split Tunnel: Supported.
•
Split DNS: Supported.
•
Default Domain: Supported.
Per App VPN
With iOS and OS X, VPN connections can be established on a per-app basis. This provides more
granular control over what data goes through VPN. With device-wide VPN, all data travels
through the private network regardless of its origin. This ability to segregate trac at the
app level allows the separation of personal data and organizational data. As more and more
personally owned devices are being used within organizations, Per App VPN provides secure
networking for internal-use apps, while preserving the privacy of personal device activity.
Per App VPN lets each app that’s managed by MDM communicate with the private network
using a secure tunnel, while excluding other non-managed apps on the Apple devices from
using the private network. Managed apps can be congured with dierent VPN connections to
further safeguard data. For example, a sales quote app could use an entirely dierent data center
than an accounts payable app, while the user’s personal web browsing trac uses the public
Internet. This ability to segregate trac at the app layer provides separation of personal data and
data belonging to the organization.
In order to use Per App VPN, an app must be managed by MDM and use standard networking
APIs. After enabling Per App VPN for any VPN connection, you need to associate that connection
with the apps that will use it to secure the network trac for those apps. This is done with the
App-to-Per App VPN mapping payload in a conguration prole. Per App VPN is congured
with an MDM conguration that species which apps and Safari domains are allowed to use
the settings.
For information about Per App VPN support, contact third-party SSL or VPN vendors.
VPN On Demand
Overview
VPN On Demand lets Apple devices automatically establish a connection without user action.
The VPN connection is started on an as-needed basis, based on rules dened in a conguration
prole. VPN On Demand requires requires certicate-based authentication.
100% resize factor
Chapter 4 Infrastructure and integration 39
VPN On Demand is congured using the OnDemandRules key in a VPN payload of a
conguration prole. Rules are applied in two stages:
•
Network Detection Stage: Denes VPN requirements that are applied when the device’s
primary network connection changes.
•
Connection Evaluation Stage: Denes VPN requirements for connection requests to domain
names on an as-needed basis.
For example, rules can be used to:
•
Recognize when an Apple device is connected to an internal network and VPN isn’t necessary
•
Recognize when an unknown Wi-Fi network is being used and require VPN for all network
activity
•
Require VPN when a DNS request for a specied domain name fails
Stages
VPN On Demand connects to your network in two stages.
Network detection stage
VPN On Demand rules are evaluated when the device’s primary network interface changes—
such as when an Apple device changes to a dierent Wi-Fi network, or switches to cellular on
iOS or Ethernet on OS X from Wi-Fi. If the primary interface is a virtual interface, such as a VPN
interface, VPN On Demand rules are ignored.
The matching rules in each set (dictionary) must all match in order for their associated action to
be taken If any one of the rules doesn’t match, evaluation falls through to the next dictionary in
the array, until the OnDemandRules array is exhausted.
The last dictionary should dene a “default” conguration—that is, it should have no matching
rules, only an action. This will catch all connections that haven’t matched the preceding rules.
Connection evaluation stage
VPN can be triggered as needed, based on connection requests to certain domains, rather than
unilaterally disconnecting or connecting VPN based on the network interface.
Rules and actions
Rules help dene the type of networks associated with VPN On Demand. Actions help dene
what happens when matching rules are found to be true.
On Demand matching rules
Specify one or more of the following matching rules for Cisco IPSec clients:
•
InterfaceTypeMatch: Optional. A string value of “cellular (for iOS) or Ethernet (for OS X)” or “Wi-
Fi.” If specied, this rule matches when the primary interface hardware is of the type specied.
•
SSIDMatch: Optional. An array of SSIDs to match against the current network. If the network
isn’t a Wi-Fi network or if its SSID does not appear in the list, the match fails. Omit this key and
its array to ignore SSID.
•
DNSDomainMatch: Optional. An array of search domains as strings. If the congured DNS
search domain of the current primary network is included in the array, this property matches.
Wildcard prex (*) is supported; e.g., *.example.com would match anything.example.com.
•
DNSServerAddressMatch: Optional. An array of DNS servers addresses as strings. If all of the
DNS server addresses currently congured for the primary interface are in the array, this
property will match. The wildcard character (*) is supported; for example, 1.2.3.* would match
any DNS servers with a 1.2.3. prex.
100% resize factor
Chapter 4 Infrastructure and integration 40
•
URLStringProbe: Optional. A server to probe for reachability. Redirection isn’t supported.
The URL should be to a trusted HTTPS server. The device sends a GET request to verify that
the server is reachable.
Action
This required key denes VPN behavior for when all of the specied matching rules evaluate as
true. Values for the Action key are:
•
Connect: Unconditionally initiate the VPN connection on the next network
connection attempt.
•
Disconnect: Tear down the VPN connection and do not trigger any new connections
on demand.
•
Ignore: Leave any existing VPN connection up, but do not trigger any new connections
on demand.
•
EvaluateConnection: Evaluate the ActionParameters for each connection attempt. When this is
used, the key ActionParameters, described below, is required to specify the evaluation rules.
•
Allow: For iOS devices with iOS 6 or earlier, see Backward compatibility.
ActionParameters
This is an array of dictionaries with the keys described below, evaluated in the order in which
they occur. Required when Action is EvaluateConnection.
•
Domains: Required. An array of strings that dene the domains for which this evaluation
applies. Wildcard prexes are supported, such as *.example.com.
•
DomainAction: Required. Denes VPN behavior for the domains. Values for the DomainAction
key are:
•
ConnectIfNeeded: Brings up VPN if DNS resolution for the domains fails, such as when the
DNS server indicates it can’t resolve the domain name, or if the DNS response is redirected,
or if the connection fails or times out.
•
NeverConnect: Don’t trigger VPN for the domains.
When DomainAction is ConnectIfNeeded, you can also specify the following keys in the
connection evaluation dictionary:
•
RequiredDNSServers: Optional. An array of IP addresses of DNS servers to be used for resolving
the domains. These servers don’t need to be part of the device’s current network conguration.
If these DNS servers aren’t reachable, VPN will be triggered. For consistent connections,
congure an internal DNS server or a trusted external DNS server.
•
RequiredURLStringProbe: Optional. An HTTP or HTTPS (preferred) URL to probe, using a GET
request. If DNS resolution for this server succeeds, the probe must also succeed. If the probe
fails, VPN is triggered.
Backward compatibility
Before iOS 7, domain triggering rules were congured from arrays of domains:
•
OnDemandMatchDomainAlways
•
OnDemandMatchDomainOnRetry
•
OnDemandMatchDomainNever
The OnRetry and Never cases are still supported in iOS 7 or later, although deprecated in favor of
the EvaluateConnection action.
100% resize factor
Chapter 4 Infrastructure and integration 41
To create a prole that works on both iOS 7 and earlier releases, use the new EvaluateConnection
keys in addition to the OnDemandMatchDomain arrays. Earlier versions of iOS that don’t
recognize EvaluateConnection use the old arrays; iOS 7 or later uses EvaluateConnection.
Old conguration proles that specify the Allow action should work on iOS 7 or later, with the
exception of OnDemandMatchDomainsAlways domains.
Always-on VPN
Overview
Always-on VPN gives your organization full control over device trac by tunneling all IP trac
back to the organization. The default tunneling protocol, IKEv2, secures trac transmission with
data encryption. Your organizations can now monitor and lter trac to and from its devices,
secure data within its network, and restrict device access to the Internet.
Always-on VPN activation requires device supervision. Once the Always-on VPN prole is installed
on a device, Always-on VPN automatically activates with no user interaction. Always-on VPN stays
activated (including across reboots) until the Always-on VPN prole is uninstalled.
With Always-on VPN activated on the device, the VPN tunnel bring-up and teardown is tied to
the interface IP state. When the interface gains IP network reachability, tunnel establishment is
attempted. When the interface IP state goes down, the tunnel is torn down. Always-on VPN also
supports per-interface tunnels. For iOS devices, there’ll be one tunnel for each active IP interface
(that is, one tunnel for the cellular interface, and one tunnel for the Wi-Fi interface). As long as
the VPN tunnel or tunnels are up, all IP trac is tunneled. All trac includes all IP-routed trac
and all IP-scoped trac (that is, trac from rst-party apps such as FaceTime and Messages).
If the tunnel or tunnels aren’t up, all IP trac is dropped.
All trac tunneled from a device will reach a VPN server. You can apply optional ltering and/or
monitoring treatments before forwarding the trac to its destination within your organization’s
network or the Internet. Similarly, trac to the device will be routed to your organization’s VPN
server, where ltering and/or monitoring treatments may be applied before being forwarded to
the device.
Deployment scenarios
iOS devices runs in single-user mode. There’s no distinction between device identity and user
identity. When an iOS device establishes a IKEv2 tunnel to the IKEv2 server, the server perceives
the iOS device as a single peer entity. Traditionally, there is one tunnel between a pair of iOS
devices and a VPN server. Since Always-on VPN introduces per-interface tunnels, there may be
multiple simultaneous tunnels established between a single iOS device and the IKEv2 server,
depending on the deployment model.
Always-on VPN conguration supports the following deployment models, fullling dierent
solution requirements.
Cellular-only devices
If your organization choses to deploy Always-on VPN on cellular-only iOS devices (Wi-Fi interface
permanently taken out or deactivated), one IKEv2 tunnel is established over the cellular IP
interface between each device and the IKEv2 server. This is the same as the traditional VPN
model. The iOS device acts as one IKEv2 client, with one identify (i.e. one client certicate or one
user and password) establishing one IKEv2 tunnel with the IKEv2 server.
100% resize factor
Chapter 4 Infrastructure and integration 42
Cellular and Wi-Fi devices
If your organization chooses to deploy Always-on VPN for iOS devices with both cellular and
Wi-Fi interfaces, two simultaneous IKEv2 tunnels will be established from the device. There are
two scenarios using cellular and Wi-Fi devices:
•
Cellular tunnel and Wi-Fi tunnel terminating on separate IKEv2 servers
Always-on VPN per-interface tunnel conguration keys allow your organization to congure
devices establishing a cellular tunnel to one IKEv2 server and Wi-Fi tunnel to a second IKEv2
server. One benet of this model is that a device can use the same client identify (that is, client
certicate or user/password) for both tunnels since the tunnels terminate on dierent servers.
With dierent servers, your organization also has greater exibility on per-interface-type trac
(cellular trac vs Wi-Fi trac) segregation and control. The drawback is that your organization
has to maintain two dierent IKEv2 servers with identical client authentication policies.
•
Cellular tunnel and Wi-Fi tunnel terminating on same IKEv2 servers
Always-on VPN per-interface tunnel conguration also lets your organization congure a
device to establish the cellular tunnel and the Wi-Fi tunnel to the same IKEv2 server.
Client identity usage:
•
One client identity per device: Your organization can congure the same client identity (that
is, one client certicate or one user/password pair) for both a cellular tunnel and Wi-Fi
tunnel, if the IKEv2 server supports multiple tunnels per client. The benet is that you can
avoid the extra client identity per device and the extra conguration/resource burden on
the server. The drawback is that as a device moves in and out of networks, new tunnels get
established and old tunnels become stale. Depending on the server implementation, the
server may not be able to clean up stale tunnels eciently and accurately. Your organization
must implement a strategy for stale tunnel cleanup on the server.
•
Two client identities per device: Your organization can congure two client identities (that is,
two client certicates or two user/password pairs), one for a cellular tunnel and one for a
Wi-Fi tunnel. The IKEv2 server sees two dierent clients establishing their own tunnel. The
benet of this model is that it works with most server implementations, since many servers
dierentiate tunnels by their client identities and only allow one tunnel per client. The
drawback of this model is doubled client identity management and doubled conguration
and resource management on the server.
Always-on VPN conguration prole
An Always-on VPN conguration prole can be composed either manually, using one of the
Apple conguration prole editors such as Prole Manager, Apple Congurator, or a third-party
MDM vendor. For more information, see Prole Manager Help or Apple Congurator Help.
User interaction keys
To keep users from deactivating the Always-on VPN feature, disallow removal of the Always-on
VPN prole by setting the top-level prole key “PayloadRemovalDisallowed” to true.
To keep users from altering Always-on VPN feature behavior by installing other conguration
proles, disallow UI prole installation by setting the allowUICongurationProleInstallation
key to false under the com.apple.applicationaccess payload. Your organization can implement
additional restrictions using other supported keys under the same payload.
100% resize factor
Chapter 4 Infrastructure and integration 43
Certicate payloads
•
Server CA Certicate: If the IKEv2 tunnel authentication method is to use certicates, the IKEv2
server sends its server certicate to the iOS device, which validates server identity. In order
for the iOS device to validate the server certicate, it needs the server’s Certicate Authority
(the issuer of the server certicate) certicate. The server CA certicate may have already been
installed onto the device previously. Otherwise, your organization can include the server CA
certicate by creating a certicate payload for the server CA certicate.
•
Client CA Certicate(s): If the IKEv2 tunnel authentication method is to use certicates or EAP-
TLS, the iOS device sends its client certicates to the IKEv2 server, which validates the client
identity. The client may have one or two client certicates, depending on the deployment
model selected. Your organization needs to include the client certicate(s) by creating
certicate payload(s) for the client certicate(s). At the same time, for the IKEv2 server to
validate the client identity, the IKEv2 server needs to have the client’s Certicate Authority
(the issuer of the client certicates) certicate installed.
•
Always-on VPN IKEv2 Certicate Support: Currently, Always-on VPN IKEv2 supports only
RSA certicates.
Always-on VPN payload
The following apply to the Always-on VPN payload.
•
The Always-on VPN payload can be installed only on supervised iOS devices
•
A conguration prole can contain only one Always-on VPN payload
•
Only one Always-on VPN conguration prole can be installed on an iOS device at a time
Connect Automatically in iOS
Always-on VPN provides an optional “UIToggleEnabled” key to let your organization enable a
“Connect Automatically” toggle in the VPN Settings. If this key isn’t specied in the prole or is
set to 0, Always-on VPN attempts to bring up one or two VPN tunnels. If this key is set to 1, the
toggle is presented in the VPN Settings pane and the user has the choice to turn on/o VPN
tunneling. If the user chooses to turn o VPN tunneling, no tunnel is established and the device
drops all IP trac. This is useful in the case when there’s no IP reachability and the user still wants
to make phone calls. The user can turn o VPN tunneling to avoid unnecessary attempts to bring
up a VPN tunnel.
Per-interface tunnel conguration array
At least one tunnel conguration is required (that is, applied to the cellular interface for cellular-
only devices, or applied to both cellular and Wi-Fi interfaces) in the TunnelCongurations array.
At most, two tunnel congurations can be included (one for cellular interfaces and one for Wi-Fi
interfaces).
Captive Trac Exceptions
Always-on VPN only supports Captive AutoLogon (automatic logging on to supported Captive
networks with pre-assigned credentials, such as credentials derived from SIM).
Always-on VPN also provides control over Captive handling by supporting the following:
•
AllowCaptiveWebSheet: A key to allow trac from built-in Captive WebSheet App to pass
outside the tunnel. WebSheet App is a browser that handles Captive logon if no third-party
Captive App is present. Your organization should consider the security risk of using this key,
because the WebSheet is a functional browser capable of rendering any content from the
responding Captive server. Allowing trac for WebSheet makes the device vulnerable to
misbehaving or malicious Captive servers.
100% resize factor
Chapter 4 Infrastructure and integration 44
•
AllowAllCaptiveNetworkPlugins: A key to allow trac from all entitled third-
party Captive Apps outside the tunnel. This key takes precedence over the
AllowedCaptiveNetworkPlugins dictionary.
•
AllowedCaptiveNetworkPlugins: A list of bundle IDs of entitled third-party Captive Apps.
Trac from this list of third-party Captive Apps is allowed outside the tunnel. If the
AllowAllCaptiveNetworkPlugins key is also congured, this list won’t take eect.
Service exceptions
Always-on VPN tunnels all IP trac by default. This includes all local trac and trac for cellular
carrier services. So the default Always-on VPN behavior doesn’t support any local IP service or IP
carrier service. Always-on VPN Service Exceptions support lets your organization alter the default
treatment of service trac to either pass outside the tunnel or drop. The currently supported
services are VoiceMail and AirPrint, and the allowed action is either Allow (to allow outside the
tunnel) or Drop (to drop regardless of the tunnel).
For more information about Always-on VPN IKEv2 protocol keys and attributes, see
Conguration Prole Key Reference at the iOS Developer Library website.
100% resize factor
… 8 …


Need help? Post your question in this forum.

Forumrules
1

Forum

apple-ios-deployment

  • Beautiful wrestlers who are fighting click on Bet-Tips.ru
    click and you will be extremely happy. Submitted on 23-1-2023 at 04:26

    Reply Report abuse

  • Bitcoin or Litecoin? Of course Litecoin!
    My Litecoin Address: LiFRfuM3jcJVXBLk19gVA8Lh1ukdP7Wngs
    Send me Litecoin. Please. God bless you! Thanks. Submitted on 2-12-2022 at 18:12

    Reply Report abuse


Report abuse

Libble takes abuse of its services very seriously. We're committed to dealing with such abuse according to the laws in your country of residence. When you submit a report, we'll investigate it and take the appropriate action. We'll get back to you only if we require additional details or have more information to share.

Product:

For example, Anti-Semitic content, racist content, or material that could result in a violent physical act.

For example, a credit card number, a personal identification number, or an unlisted home address. Note that email addresses and full names are not considered private information.

Forumrules

To achieve meaningful questions, we apply the following rules:

Register

Register getting emails for Apple iOS Deployment at:


You will receive an email to register for one or both of the options.


Get your user manual by e-mail

Enter your email address to receive the manual of Apple iOS Deployment in the language / languages: English as an attachment in your email.

The manual is 2,32 mb in size.

 

You will receive the manual in your email within minutes. If you have not received an email, then probably have entered the wrong email address or your mailbox is too full. In addition, it may be that your ISP may have a maximum size for emails to receive.

Others manual(s) of Apple iOS Deployment

Apple iOS Deployment User Manual - German - 99 pages

Apple iOS Deployment User Manual - Dutch - 100 pages


The manual is sent by email. Check your email

If you have not received an email with the manual within fifteen minutes, it may be that you have a entered a wrong email address or that your ISP has set a maximum size to receive email that is smaller than the size of the manual.

The email address you have provided is not correct.

Please check the email address and correct it.

Your question is posted on this page

Would you like to receive an email when new answers and questions are posted? Please enter your email address.



Info