Onboard Deployment Guide 3.9.6

ClearPass Onboard 3.9
DeploymentGuide

www.arubanetworks.com
1344 Crossman Avenue
Sunnyvale, California 94089
Phone: 408.227.4500
Fax 408.227.4550
ClearPass Onboard 3.9.6 | Deployment Guide 0511112-07 | January 2013
Copyright
© 2013 Aruba Networks, Inc. Aruba Networks trademarks include , Aruba Networks®, Aruba Wireless Networks®,
the registered Aruba the Mobile Edge Company logo, Aruba Mobility Management System®, Mobile Edge Architecture®, People Move.
Networks Must Follow®, RFProtect®, Green Island®. All rights reserved. All other trademarks are the property of their respective owners.
Open Source Code
Certain Aruba products include Open Source software code developed by third parties, including software code subject to the GNU
General Public License (GPL), GNU Lesser General Public License (LGPL), or other Open Source Licenses. Includes software from Litech
Systems Design. The IF-MAP client library copyright 2011 Infoblox, Inc. All rights reserved. This product includes software developed by
Lars Fenneberg et al. The Open Source code used can be found at this site:
http://www.arubanetworks.com/open_source
Legal Notice
The use of Aruba Networks, Inc. switching platforms and software, by all individuals or corporations, to terminate other vendors’ VPN
client devices constitutes complete acceptance of liability by that individual or corporation for this action and indemnifies, in full, Aruba
Networks, Inc. from any and all legal actions that might be taken against it with respect to infringement of copyright on behalf of those
vendors.
Warranty
This hardware product is protected by the standard Aruba warranty of one year parts/labor. For more information, refer to the
ARUBACARE SERVICE AND SUPPORT TERMS AND CONDITIONS.
Altering this device (such as painting it) voids the warranty.

ClearPass Onboard 3.9 | Deployment Guide | 3
Contents
Onboard.................................................................................................... 5
About ClearPass Onboard.....................................................................................5
Onboard Deployment Checklist......................................................................5
Onboard Feature List ......................................................................................7
Supported Platforms.......................................................................................8
Public Key Infrastructure for Onboard ............................................................8
Certificate Hierarchy.................................................................................9
Revoking Unique Device Credentials............................................................10
Revoking Credentials to Prevent Network Access.................................10
Re-Provisioning a Device .......................................................................10
Network Requirements for Onboard.............................................................11
Using the Same SSID for the Provisioning and Provisioned
Networks..........................................................................................11
Using a Different SSID for the Provisioning and Provisioned
Networks..........................................................................................11
Configuring the Online Certificate Status Protocol for the
Provisioned Network........................................................................11
Configuring a Certificate Revocation List (CRL) for the Provisioned
Network............................................................................................12
Network Architecture for Onboard................................................................12
Network Architecture for Onboard when Using ClearPass Guest .........14
The ClearPass Onboard Process..................................................................15
Devices Supporting Over-the-Air Provisioning.......................................15
Devices Supporting Onboard Provisioning ............................................17
Accessing Onboard.............................................................................................20
Configuring the User Interface for Device Provisioning ......................................20
Customizing the Device Provisioning Web Login Page................................21
Using the {nwa_mdps_config} Template Function .......................................22
Configuring ClearPass Servers for Device Provisioning......................................23
Configuring the Certificate Authority ..................................................................25
Setting Up the Certificate Authority ..............................................................26
Setting Up a Root Certificate Authority.........................................................27
Setting Up an Intermediate Certificate Authority ..........................................29
Obtaining a Certificate for the Certificate Authority......................................31
Using Microsoft Active Directory Certificate Services ..................................31
Installing a Certificate Authority’s Certificate................................................34
Renewing the Certificate Authority’s Certificate ...........................................35
Configuring Data Retention Policy for Certificates .......................................36
Uploading Certificates for the Certificate Authority.............................................36
Creating a Certificate...........................................................................................38
Specifying the Identity of the Certificate Subject..........................................39
Issuing the Certificate Request.....................................................................40
Managing Certificates..........................................................................................40
Searching for Certificates..............................................................................41
Working with Certificates ..............................................................................42
Working with Certificate Signing Requests...................................................44
Importing a Code-Signing Certificate ...........................................................47

4 | ClearPass Onboard 3.9 | Deployment Guide
Requesting a Certificate ......................................................................................48
Providing a Certificate Signing Request in Text Format...............................48
Providing a Certificate Signing Request File.................................................49
Specifying Certificate Properties ..................................................................49
Configuring Provisioning Settings .......................................................................50
Configuring Basic Provisioning Settings.......................................................50
Configuring Certificate Properties for Device Provisioning...........................51
Configuring Provisioning Settings for iOS and OS X ....................................53
Configuring Provisioning Settings for Mac OS X, Windows, and Android De-
vices........................................................................................................55
Configuring User Interface Options for Mac OS X, Windows, and Android De-
vices........................................................................................................56
Configuring Authorization Settings for Device Provisioning .........................57
Configuring Network Settings for Device Provisioning .......................................57
Configuring Basic Network Access Settings ................................................58
Configuring 802.1X Authentication Network Settings...................................59
Configuring Device Authentication Settings .................................................60
Configuring Mutual Authentication Settings .................................................61
Configuring Windows-Specific Network Settings.........................................62
Configuring Proxy Settings ...........................................................................63
Configuring Post-Installation Instructions.....................................................64
Configuring an iOS Device VPN Connection.......................................................64
Configuring an iOS Device Email Account ..........................................................66
Configuring an iOS Device Passcode Policy.......................................................68
Resetting Onboard Certificates and Configuration .............................................70
Advanced: Device Authentication During Provisioning .......................................71
Onboard Troubleshooting ...................................................................................72
iOS Device Provisioning Failures ..................................................................72

ClearPass Onboard 3.9 | Deployment Guide Onboard | 5
Chapter 3
Onboard
Onboarding is the process of preparing a device for use on an enterprise network by creating the
appropriate access credentials and setting up the network connection parameters. ClearPass Onboard
automates 802.1X configuration and provisioning for “bring your own device” (BYOD) and IT-managed
devices—Windows, Mac OS X, iOS and Android—across wired, wireless and VPNs.
ClearPass Onboard includes the following key features:
 Automatic configuration of network settings for wired and wireless endpoints.
 Provisioning of unique device credentials for BYOD and IT-managed devices.
 Support for Windows, Mac OS X, iOS and Android devices.
 Enables the revocation of unique credentials on a specific user’s device.
 Leverages ClearPass profiling to identify device type, manufacturer, and model.
About ClearPass Onboard
This section provides important information about ClearPass Onboard.
Onboard Deployment Checklist
Use the following checklist to complete your Onboard deployment.
Table 1 Onboard Deployment Checklist
Deployment Step Reference
Planning and Preparation
Review the Onboard feature list to identify the major areas of
interest for your deployment.
See “Onboard Feature List”
Review the list of platforms supported by Onboard, and identify the
platforms of interest for your deployment.
See “Supported Platforms”
Review the Onboard public key infrastructure, and identify any
certificate authorities that will be needed during the deployment.
See “Public Key Infrastructure for Onboard”
Review the network requirements and the network architecture
diagrams to determine how and where to deploy the Onboard
solution.
See “Network Requirements for Onboard”and
“Network Architecture for Onboard”
Configuration
Configure the hostname and networking properties of the Onboard
provisioning server.
 DNS is required for SSL.
 Ensure that hostname resolution will work for devices being
provisioned.
See “Network Setup”in the Administrator
Tasks chapter

6 | Onboard ClearPass Onboard 3.9 | Deployment Guide
Configure SSL certificate for the Onboard provisioning server.
A commercial SSL certificate is required to enable secure device
provisioning for iOS devices.
See “SSL Certificate”in the Administrator
Tasks chapter
Configure the Onboard certificate authority.
 Decide whether to use the Root CA or Intermediate CA mode of
operation.
Create the certificate for the certificate authority.
See “Configuring the Certificate Authority ”
Configure the data retention policy for the certificate authority. See “Configuring Data Retention Policy for
Certificates”
Configure ClearPass integration.
 Set Policy Manager connection and authentication details.
Set Profiler options, if required.
See “Configuring ClearPass Servers for
Device Provisioning”
Configure device provisioning settings.
 Select certificate options for device provisioning.
Select which device types should be supported.
See “Configuring Provisioning Settings”
Configure network settings for device provisioning.
 Set network properties.
 Upload 802.1X server certificates.
Set device-specific networking settings.
See “Configuring Network Settings for Device
Provisioning”
Configure networking equipment for non-provisioned devices.
 Set authentication for the provisioning SSID, if required.
Ensure the captive portal redirects non-provisioned devices to the
device provisioning page.
See “Network Requirements for Onboard”
Configure networking equipment to authenticate provisioned
devices.
 Ensure 802.1X authentication methods and trust settings are
configured correctly for all EAP types that are required.
Configure OCSP or CRL on the authentication server to check for
client certificate validity.
See “Network Requirements for Onboard”
Configure the user interface for device provisioning.
 Set display options for iOS devices.
 Set user interface options for other Onboard devices.
Setup the device provisioning Web login page.
See “Configuring the User Interface for Device
Provisioning”
Testing and Verification
Test device provisioning.
 Verify that each type of device can be provisioned successfully.
Verify that each type of device can join the provisioned network and
is authenticated successfully.
Test device revocation.
 Revoke a device’s certificate.
 Verify that the device is no longer able to authenticate.
Verify that re-provisioning the device fails.
Table 1 Onboard Deployment Checklist
Deployment Step Reference

Onboard Feature List
The following features are available in ClearPass Onboard.
Table 2 Onboard Features
Feature Uses
Automatic configuration of network settings
for wired and wireless endpoints.
 Configure wired networks using 802.1X
 Configure Wi-Fi networks using either 802.1X or pre-shared key
(PSK)
 Configure trusted server certificates for 802.1X
 Configure Windows-specific networking settings
 Configure HTTP proxy settings for client devices (Android, OS X
only)
Secure provisioning of unique device
credentials for BYOD and IT-managed
devices.
 Configure EAP-TLS and PEAP-MSCHAPv2 without user
interaction
 Revoke unique device credentials to prevent network access
Support for Windows, Mac OS X, iOS, and
Android devices.
 Leverage ClearPass Profiling to identify device type,
manufacturer, and model
 Control the user interface displayed during device provisioning
Certificate authority enables the creation and
revocation of unique credentials on a specific
user’s device.
 Root and intermediate CA modes of operation
 Supports SCEP enrollment of certificates
 Supports CRL generation to list revoked certificates
 Supports OCSP responder to query for certificate status
 Approve certificate signing request
 Reject certificate signing request
 Sign certificate from uploaded certificate signing request (CSR)
 Issue certificate
 Revoke certificate
 Display certificates
 Export certificate
 Renew root certificate
Provision additional settings specific to iOS
devices
 Exchange ActiveSync
 Passcode policy
 VPN settings

Supported Platforms
The platforms supported by ClearPass Onboard and the version requirements for each platform are
summarized in Table 3.
Note 1: Uses the “Over-the-air provisioning” method.
Note 2: Uses the “Onboard provisioning” method.
Note 3: Onboard may also be used to provision VPN settings, Exchange ActiveSync settings, and passcode policy on these
devices.
Public Key Infrastructure for Onboard
During the device provisioning process, one or more digital certificates are issued to the device. These are
used as the unique credentials for a device.
To issue the certificate, ClearPass Onboard must operate as a certificate authority. The following sections
explain how the certificate authority works, and which certificates are used in this process.
Table 3 Platforms Supported by ClearPass Onboard
Platform Example Devices Version Required for Onboard Support Notes
Apple iOS iPhone
iPad
iPod Touch
iOS 4
iOS 5
1, 3
Apple Mac OS X MacBook Pro
MacBook Air
Mac OS X 10.8 “Mountain Lion”
Mac OS X 10.7 “Lion”
1
Mac OS X 10.6 “Snow Leopard”
Mac OS X 10.5 “Leopard”
2
Android Samsung Galaxy S
Samsung Galaxy Tab
Motorola Droid
Android 2.2 (or higher) 2
Microsoft Windows Laptop
Netbook
Windows XP with Service Pack 3
Windows Vista with Service Pack 3
Windows 7
2

Certificate Hierarchy
In a public key infrastructure (PKI) system, certificates are related to each other in a tree-like structure. See
Figure 1.
Figure 1 Relationship of Certificates in the Onboard Public Key Infrastructure
The root certificate authority (CA) is typically an enterprise certificate authority, with one or more
intermediate CAs used to issue certificates within the enterprise.
Onboard may operate as a root CA directly, or as an intermediate CA. See “Configuring the Certificate
Authority ”.
The Onboard CA issues certificates for several purposes:
 The Profile Signing Certificate is used to digitally sign configuration profiles that are sent to iOS
devices.
 The identity information in the profile signing certificate is displayed during device provisioning.
 One or more Server Certificates may be issued for various reasons – typically, for an enterprise’s
authentication server.
 The identity information in the server certificate may be displayed during network authentication.
 One or more Device Certificates may be issued – typically, one or two per provisioned device.
 The identity information in the device certificate uniquely identifies the device and the user that
provisioned the device.
You do not need to manually create the profile signing certificate; it is created when it is needed. See
“Configuring Provisioning Settings for iOS and OS X”to control the contents of this certificate.
You may revoke the profile signing certificate; it will be recreated when it is needed for the next device
provisioning attempt.

Revoking Unique Device Credentials
Because each provisioned device uses unique credentials to access the network, it is possible to disable
network access for an individual device. This offers a greater degree of control than traditional user-based
authentication — disabling a user’s account would impact all devices using those credentials.
To disable network access for a device, revoke the TLS client certificate provisioned to the device. See
“Working with Certificates”.
Note: Revoking access for a device is only possible when using an enterprise network. Personal (PSK)
networks do not support this capability.
Revoking Credentials to Prevent Network Access
This is necessary to prevent the user from simply re-provisioning and obtaining a new certificate. To re-
provision the device, the revoked certificate must be deleted.
If the device is provisioned with an EAP-TLS client certificate, revoking the certificate will cause the
certificate authority to update the certificate’s state. When the certificate is next used for authentication, it
will be recognized as a revoked certificate and the device will be denied access.
Note: When using EAP-TLS authentication, you must configure your authentication server to use either
OCSP or CRL to check the revocation status of a client certificate. OCSP is recommended as it offers a real-
time status update for certificates.
If the device is provisioned with PEAP unique device credentials, revoking the certificate will automatically
delete the unique username and password associated with the device. When this username is next used for
authentication, it will not be recognized as valid and the device will be denied access.
Note: OCSP and CRL are not used when using PEAP unique device credentials. The Onboard server
automatically updates the status of the username when the device’s client certificate is revoked.
Re-Provisioning a Device
Because “bring your own” devices are not under the complete control of the network administrator, it is
possible for unexpected configuration changes to occur on a provisioned device.
For example, the user may delete the configuration profile containing the settings for the provisioned
network, instruct the device to forget the provisioned network settings, or reset the device to factory
defaults and destroy all the configuration on the device.
When these events occur, the user will not be able to access the provisioned network and will need to re-
provision their device.
The Onboard server detects a device that is being re-provisioned and prompts the user to take a suitable
action (such as connecting to the appropriate network). If this is not possible, the user may choose to
restart the provisioning process and re-provision the device.
Re-provisioning a device will reuse an existing TLS client certificate or unique device credentials, if these
credentials are still valid.
If the TLS client certificate has expired then the device will be issued a new certificate. This enables re-
provisioning to occur on a regular basis.
If the TLS client certificate has been revoked, then the device will not be permitted to re-provision. The
revoked certificate must be deleted before the device is able to be provisioned.
Revoking a device’s certificate will also prevent the device from being re-provisioned.

Network Requirements for Onboard
For complete functionality to be achieved, ClearPass Onboard has certain requirements that must be met by
the provisioning network and the provisioned network:
 The provisioning network must use a captive portal or other method to redirect a new device to the
 The provisioning server (Onboard server) must have an SSL certificate that is trusted by devices that will
be provisioned. In practice, this means a commercial SSL certificate is required.
 The provisioned network
 must support EAP-TLS and PEAP-MSCHAPv2 authentication methods.
 The provisioned network must support either OCSP or CRL checks to detect when a device has been
revoked and deny access to the network.
Using the Same SSID for the Provisioning and Provisioned Networks
To configure a single SSID to support both provisioned and non-provisioned devices, use the following
guidelines:
 Configure the network to use both PEAP and EAP-TLS authentication methods.
 When a user authenticates via PEAP with their domain credentials, place them into a provisioning role.
 The provisioning role should have limited network access and a captive portal that redirects users to the
 When a user authenticates via PEAP with unique device credentials, place them into a provisioned role.
 When a user authenticates via EAP-TLS using an Onboard client certificate, place them into a
provisioned role.
For provisioned devices, additional authorization steps can be taken after authentication has completed to
determine the appropriate provisioned role.
Using a Different SSID for the Provisioning and Provisioned Networks
To configure dual SSIDs to support provisioned devices on one network, and non-provisioned devices on a
separate network, use the following guidelines:
 Configure the provisioning SSID to use PEAP, or another suitable authentication method.
 When a user connects to the provisioning SSID, place them into a provisioning role.
 The provisioning role should have limited network access and a captive portal that redirects users to
the device provisioning page.
 When a user connects to the provisioned SSID, authenticate based on the type of credentials presented.
 For PEAP authentication with unique device credentials, place them into a provisioned role.
 For EAP-TLS authentication using an Onboard client certificate, place them into the provisioned role.
 In all other cases, deny access.
As for the single-SSID case, additional authorization steps may be taken after authentication has completed
to determine the appropriate provisioned role.
Configuring the Online Certificate Status Protocol for the Provisioned Network
Onboard supports the Online Certificate Status Protocol (OCSP) to provide a real-time check on the validity
of a certificate.
To configure OCSP for your network, you will need to provide the URL of an OCSP service to your network
equipment. This URL can be constructed by using the relative path mdps_ocsp.php/1.

For example, if the Onboard server’s hostname is onboard.example.com, the OCSP URL to use is: http://
onboard.example.com/mdps_ocsp.php/1.
Note: OCSP does not require the use of HTTPS and can be configured to use HTTP.
Configuring a Certificate Revocation List (CRL) for the Provisioned Network
Onboard supports generating a Certificate Revocation List (CRL) that lists the serial numbers of certificates
that have been revoked.
To configure a CRL, you will need to provide its URL to your network equipment. This URL can be
constructed by using the relative path mdps_crl.php?id=1.
For example, if the Onboard server’s hostname is onboard.example.com, the location of the CRL is: http://
onboard.example.com/mdps_crl.php?id=1.
Note: A certificate revocation list does not require the use of HTTPS and can be configured to use HTTP.
Network Architecture for Onboard
The high-level network architecture for the Onboard solution is shown in Figure 2.
Figure 2 ClearPass Onboard Network Architecture
The sequence of events shown in Figure 2 is:
1. Users bring their own device to the enterprise.
2. The ClearPass Onboard workflow is used to provision the user’s device securely and with a minimum of
user interaction.
3. Once provisioned, the device re-authenticates to the network using a set of unique device credentials.
These credentials uniquely identify the device and user and enable management of provisioned devices.
4. Administrators can configure all aspects of the provisioning workflow – including the devices that have
been provisioned, policies to apply to devices and the overall user experience for BYOD.

A more detailed view of the network architecture is shown in Figure 3 on page 13 below. This diagram
shows different types of client devices using the Onboard workflow to gain access to the network. Some of
the components that may be configured by the network administrator are also shown.
Figure 3 Detailed View of the ClearPass Onboard Network Architecture
The components shown in Figure 3 are:
1. Users bring different kinds of client device with them. Onboard supports “smart devices” that use the
iOS or Android operating systems, such as smartphones and personal tablets. Onboard also supports the
most common versions of Windows and Mac OS X operating systems found on desktop computers,
laptops and netbooks.
2. The Onboard workflow is used to provision the user’s device securely and with a minimum of user
interaction. The provisioning method used depends on the type of device.
a. Newer versions of Mac OS X (10.7 and later) and iOS devices use the “over-the-air” provisioning
method.
b. Other supported platforms use the “Onboard provisioning” method.
3. Once provisioned, client devices use a secure authentication method based on 802.1X and the
capabilities best supported by the device.
a. The unique device credentials issued during provisioning are in the form of an EAP-TLS client
certificate for iOS devices and OS X (10.7+) devices.
b. Other supported devices are also issued a client certificate, but will use the PEAP-MSCHAPv2
authentication method with a unique username and strong password.
4. Administrators can manage all Onboard devices using the certificate issued to that device.

Network Architecture for Onboard when Using ClearPass Guest
ClearPass Guest supports the provisioning, authentication, and management aspects of the complete
Onboard solution.
Figure 4 on page 14 shows the high-level network architecture for the Onboard solution when using
ClearPass Guest as the provisioning and authentication server.
Figure 4 ClearPass Onboard Network Architecture when Using ClearPass Guest
The user experience for device provisioning is the same in Figure 4 and Figure 2 on page 12, however there
are implementation differences between these approaches:
 When using the ClearPass Guest RADIUS server for provisioning and authentication, EAP-TLS and
PEAP authentication must be configured.
Navigate to RADIUS > Authentication > EAP & 802.1X to configure a server certificate and the
appropriate EAP types for the ClearPass Guest RADIUS server.
 ClearPass Policy Manager supports a rich policy definition framework. If you have complex policies to
enforce, multiple authentication or authorization sources that define user accounts, or you need features
beyond those available in the ClearPass Guest RADIUS server, you should deploy Policy Manager for
authentication.

The ClearPass Onboard Process
Devices Supporting Over-the-Air Provisioning
ClearPass Onboard supports secure device provisioning for iOS 4, iOS 5, and recent versions of Mac OS X
(10.7 “Lion” and later). These are collectively referred to as “iOS devices”.
The Onboard process for iOS devices is shown in Figure 5 on page 15.
Figure 5 ClearPass Onboard Process for iOS Devices
The Onboard process is divided into three stages:
1. Pre-provisioning. The enterprise’s root certificate is installed on the iOS device.
2. Provisioning. The user is authenticated at the device provisioning page and then provisions their device
with the Onboard server. The device is configured with appropriate network settings and a device-
specific certificate.
3. Authentication. Once configuration is complete, the user switches to the secure network and is
authenticated using an EAP-TLS client certificate.
A sequence diagram showing the interactions between each component of this workflow is shown in Figure
6 on page 16.

Figure 6 Sequence Diagram for the Onboard Workflow on iOS Platform
1. When a BYOD device first joins the provisioning network it does not have a set of unique device
credentials. This will trigger the captive portal for that device, which brings the user to the mobile device
provisioning page.
2. A link on the mobile device provisioning page prompts the user to install the enterprise’s root certificate.
Installing the enterprise’s root certificate enables the user to establish the authenticity of the
provisioning server during device provisioning.
3. The user then authenticates with their provisioning credentials – these are typically the user’s enterprise
credentials from Active Directory. If the user is authorized to provision a mobile device, the over-the-air
provisioning workflow is then triggered (see Figure 7 on page 17, below).
4. After provisioning has completed, the device switches to EAP-TLS authentication using the newly
provisioned client certificate. Mutual authentication is performed (the authentication server verifies the
client certificate, and the client verifies the authentication server’s certificate).
5. The device is now onboard and is able to securely access the provisioned network.
Over-the-air provisioning is used to securely provision a device and configure it with network settings.
Figure 7 on page 17 shows a sequence diagram that explains the steps involved in this workflow.

Figure 7 Over-the-Air Provisioning Workflow for iOS Platform
1. The only user interaction required is to accept the provisioning profile. This profile is signed by the
Onboard server, so that the user can be assured of its authenticity.
2. An iOS device will have two certificates after over-the-air provisioning is complete:
a. A Simple Certificate Enrollment Protocol (SCEP) certificate is issued to the device during the
provisioning process. This certificate identifies the device uniquely, and is used to encrypt the device
configuration profile so that only this device can read its unique settings.
b. A Transport Layer Security (TLS) client certificate is issued to the device. This certificate identifies
the device and the user that provisioned the device. It is used as the device’s network identity during
EAP-TLS authentication.
Devices Supporting Onboard Provisioning
ClearPass Onboard supports secure device provisioning for Microsoft Windows XP (service pack 3 and
later), Microsoft Windows Vista, Microsoft Windows 7, Apple Mac OS X 10.5 and 10.6, and Android devices
(smartphones and tablets). These are collectively referred to as “Onboard-capable devices”.
The Onboard process for these devices is shown in Figure 8.

Figure 8 ClearPass Onboard Process for Onboard-Capable Devices
The Onboard process is divided into three stages:
1. Pre-provisioning. This step is only required for Android devices; the Aruba Networks QuickConnect
app must be installed for secure provisioning of the device.
2. Provisioning. The device provisioning page detects the device type and downloads or starts the
QuickConnect app. The app authenticates the user and then provisions their device with the Onboard
server. The device is configured with appropriate network settings and credentials that are unique to the
device. See Figure 9 on page 19 for details.
3. Authentication. Once configuration is complete, the user switches to the secure network and is
authenticated using PEAP-MSCHAPv2 unique device credentials.

Figure 9 Sequence Diagram for the Onboard Workflow on Android Platform
1. When a BYOD device first joins the network it does not have a set of unique device credentials. This will
trigger the captive portal for that device, which brings the user to the mobile device provisioning page.
2. The Onboard portal is displayed. The user’s device type is detected, and a link is displayed depending on
the device type:
a. For Android devices, the link is to a file containing the Onboard configuration settings; downloading
this file will launch the QuickConnect app on the device.
b. For Windows and Mac, the link is to a executable file appropriate for that operating system that
includes both the QuickConnect app and the Onboard configuration settings.
3. The QuickConnect app uses the Onboard provisioning workflow to authenticate the user and provision
their device with the Onboard server. The device is configured with appropriate network settings and
credentials that are unique to the device.
4. After provisioning has completed, the app switches the device to PEAP authentication using the newly
provisioned unique device credentials. Mutual authentication is performed (the authentication server
verifies the client’s username and password, and the client verifies the authentication server’s
certificate).
5. The device is now onboard and is able to securely access the network.
The Onboard provisioning workflow is used to securely provision a device and configure it with network
settings. Figure 10 on page 20 shows a sequence diagram that explains the steps involved in this workflow.

Figure 10 Onboard Provisioning Workflow in the QuickConnect App
Accessing Onboard
To access ClearPass Onboard:
 From the Home page, click the ClearPass Onboard command link. Alternatively, use the Onboard link
at the top level of the left navigation to go directly to any of the features within Onboard.
Configuring the User Interface for Device Provisioning
The user interface for device provisioning can be customized in three different ways:
 Customizing the Web login page used for device provisioning.
All devices will reach the device provisioning Web login page as the first step of the provisioning
process. See “Customizing the Device Provisioning Web Login Page”to make changes to the content or
formatting of this page.
 Customizing the properties of the device provisioning profile for iOS and OS X devices.

After starting the provisioning process, users of iOS and OS X are prompted to accept a configuration
profile. See “Configuring Provisioning Settings for iOS and OS X”to make changes to the content of this
profile.
 Customizing the user interface of the QuickConnect app for Windows, Mac OS X and Android devices.
The provisioning process for Windows, Mac OS X and Android devices uses a separate app, which has a
customizable user interface. See “Configuring Provisioning Settings for Mac OS X, Windows, and
Android Devices” to make changes to the user interface.
Customizing the Device Provisioning Web Login Page
Onboard creates a default Web login page that is used to start the device provisioning process.
To edit this page, navigate to Customization > Web Logins, click to expand the Onboard Provisioning
row in the list, and then click Edit. The RADIUS Web Logins Editor form opens. Scroll to the Onboard
Device Provisioning rows of the form. (For details about the rest of this form, see “Creating a Web Login
Page” in the RADIUS Services chapter.
The Onboard-specific settings required for a device provisioning page are described below:
Mark the Enable device provisioning check box to activate the Onboard features for this Web login page.
Note: If this check box is not marked, device provisioning will be inoperative.
Select the appropriate Onboard configuration from the Configuration drop-down list.
To modify the instructions provided to users on the device provisioning page, edit the contents of the
Header HTML text area.
The default instructions are displayed to the user as:

This corresponds to the following text prepopulated in the Header HTML text area:

Please configure security and network settings on your device to allow secure 
access to the internal network. Please follow the instructions listed below: 
 
1.    {nwa_iconlink icon="images/icon-
certificate22.png" text="Install root certificate (click here)"}{nwa_mdps_config
name=root_cert}{/nwa_iconlink} 
2.    Login below using your {nwa_mdps_config
name=organization_name} credentials 
3.    Install the certificate when prompted 
4.    Go to your Wi-Fi settings and connect to
SSID: {nwa_mdps_config name=wifi_ssid}
 

Using the {nwa_mdps_config} Template Function
Certain properties can be extracted from the Onboard configuration and used in the device provisioning
page.
To obtain these properties, use the {nwa_mdps_config} Smarty template function. The “name” parameter
specifies which property should be returned, as described in Table 4 on page 22.
Table 4 Properties Available for Use with the (nwa_mdps_ocnfig) Smarty Template Function
Name Description
root_cert URL of the Onboard certificate authority’s root certificate.
Browsing to this URL will install the root certificate on the device, which is required as
part of the pre-provisioning step.
Example:
<a href="{nwa_mdps_config name=root_cert}">
Install Onboard root certificate
</a>
wifi_ssid Name of the wireless network. See “Configuring Basic Network Access Settings”.
Example:
Connect to the network named {nwa_mdps_config name=wifi_ssid}
organization_name The organization name. See “Configuring Basic Provisioning Settings”.
Example:
<h2>
Welcome to {nwa_mdps_config name=organization_name}
</h2>

Configuring ClearPass Servers for Device Provisioning
To configure ClearPass servers for device provisioning, navigate to Administrator > Network Setup >
ClearPass, or click the ClearPass command link. The Manage ClearPass Servers form opens.
The first part of the form is used to specify the connection details for the ClearPass Policy Manager.
Mark the Send device information to ClearPass Policy Manager check box when you will use Policy
Manager as the authentication server for devices provisioned with Onboard.
Specify the hostname or IP address of the Policy Manager publisher node in the Host text field.
You must provide a valid username and password for the Policy Manager. This account should have “Super
Administrator” privileges.
Note: Onboard requires only the ability to create guest user accounts, Onboard accounts, and endpoint
records. No other configuration changes are made using these credentials.

The second part of the form specifies options for ClearPass Profiler.
Mark the Send device information to ClearPass Profiler check box when you will use Profiler to
collect device information.
Select the events of interest in the Profiling Events checklist:
 When client requests a guest-facing page – Device information is sent to Profiler as soon as a guest-
facing page (such as a Web login page, guest self-registration page, or device provisioning captive portal
page) is requested.
 Note: Selecting this option may collect information about devices that are not actively using the
network, i.e. devices that are not logged in.
 When client registers a guest account – Device information is sent to Profiler when a guest self-
registration form is completed and a guest account is created or updated.
 When client submits a Web login form – Device information is sent to Profiler when a Web login form
is submitted, indicating a login attempt has been made.
 When client provisions a device – Device information is sent to Profiler when a valid device
provisioning request has been received.
The Profiling Interval text field may be used to limit the rate of repeated updates for the same client. This
option can be used to reduce the load on the Profiler server, especially if the “When client requests a guest-
facing page” profiling event is enabled.

A primary Profiler server must be configured. Specify the hostname or IP address of the Profiler server in
the Host text field. You must also provide a valid username and password for the Profiler.
A secondary Profiler server may also be configured. This server will be used if the primary Profiler server is
unreachable.
Click the Save Changes button to apply the new configuration settings.
Configuring the Certificate Authority
To configure certificate authority settings, Navigate to Onboard > Certificate Authority Settings, or
click the Certificate Authority Settings command link.
The Certificate Authority Settings form opens.
This page is used to configure the Onboard certificate authority and to perform maintenance tasks for the
CA.:
 Set up a root or intermediate certificate authority (See “Setting Up the Certificate Authority”)
 Determine the OCSP URL for the certificate authority
 View the trust chain for the certificate authority (See “To view the Certificate Authority’s trust chain, go
to Onboard > Certificate Authority Settings and click the View CA Certificate link at the top of the page.
The Certificate Authority Trust Chain page is displayed. This page shows a graphical representation of
the certificates that make up the trust chain.”)
 Renew the certificate authority’s certificate (See “Renewing the Certificate Authority’s Certificate”)
 Configure the data retention policy applied to certificates issued by the authority (See “Configuring Data
Retention Policy for Certificates”)

Setting Up the Certificate Authority
The Certificate Authority Settings form is used to set up the mode of operation for the certificate authority.
The Name and Description fields are used internally to identify this certificate authority for the network
administrator. These values are never displayed to the user during device provisioning.
Select the appropriate mode for the certificate authority:
 Root CA – The Onboard certificate authority issues its own root certificate. The certificate authority
issues client and server certificates using a local signing certificate, which is an intermediate CA that is
subordinate to the root certificate.
Use this option when you do not have an existing public-key infrastructure (PKI), or if you want to
completely separate the certificates issued for Onboard devices from your existing PKI.

Click the Continue button to proceed to the second step. See “Setting Up a Root Certificate Authority”.
 Intermediate CA – The Onboard certificate authority is issued a certificate by an external certificate
authority. The Onboard certificate authority issues client and server certificates using this certificate.
Use this option when you already have a public-key infrastructure (PKI), and would like to include the
certificate issued for Onboard devices in that infrastructure.
Click the Continue button to proceed to the second step. See “Setting Up an Intermediate Certificate
Authority”.
Setting Up a Root Certificate Authority
If you already have a certificate and private key for the certificate authority, see “Installing a Certificate
Authority’s Certificate”.
The Root Certificate Settings form is used to configure the distinguished name and properties for the
certificate authority’s root (self-signed) certificate.
Note: If you intend to change any of the root certificate’s distinguished name properties, and you have
previously created any client or server certificates or performed device provisioning using the existing root
certificate, these certificates will be invalidated and deleted as the root certificate’s distinguished name has
changed.
To avoid the complication of revoking and reissuing certificates, it is recommended that you configure the
certificate authority before any device provisioning or other configuration is done.

In the Identity section of the form:
 Enter values in the Country, State, Locality, Organization, and Organizational Unit text fields that
correspond to your organization. These values form part of the distinguished name for the root
certificate.
 Enter a descriptive name for the root certificate in the Common Name text field. This value will be used
to identify the root certificate as the issuer of other certificates, notably the signing certificate.
 Enter a descriptive name for the signing certificate in the Signing Common Name text field. This value
will be used to identify the signing certificate as the issuer of client and server certificates from this
certificate authority.
The other identity information in the signing certificate will be the same as for the root certificate.
 Enter a contact email address in the Email Address text field. This email address will be included in the
root and signing certificates, and provides a way for users of the certificate authority to contact your
organization.

In the Private Key section:
 Mark the Generate a new private key check box to create a new private key for the root certificate.
This is only necessary if you are recreating the entire certificate authority from the beginning.
Note: If you have previously created any client or server certificates or performed device provisioning
using the existing root certificate, these certificates will be invalidated when changing the root
certificate’s private key.
 The Key Type drop-down list specifies the type of private key that should be created for the certificate.
You can select one of these options:
 1024-bit RSA – not recommended for a root certificate
 2048-bit RSA – recommended for general use
 4096-bit RSA – higher security
In the Self-Signed Certificate section:
 Use the CA Expiration field to specify the lifetime of the root certificate in days. The default value of
3653 days is a 10-year lifetime.
 The Clock Skew Allowance field adds a small amount of time to the start and end of the root
certificate’s validity period. This permits a newly issued certificate to be recognized as valid in a network
where not all devices are perfectly synchronized.
 The Digest Algorithm drop-down list allows you to specify which hash algorithm should be used.
Note: MD5 is not recommended for use with root certificates.
Mark the Generate CA certificate and invalidate all other certificates check box to confirm the
changes.
Click the Create Root Certificate button to save the settings and generate a new root certificate.
Setting Up an Intermediate Certificate Authority
The Intermediate Certificate Settings form is used to configure the distinguished name and properties for
the certificate authority’s certificate, which will be issued by an external certificate authority.
Note: If you intend to change any of the intermediate certificate’s distinguished name properties, and you
have previously created any client or server certificates or performed device provisioning using the existing
intermediate certificate, these certificates will be invalidated as the intermediate certificate’s distinguished
name has changed.
In this case, you should use the Reset to Factory Defaults form (see “Resetting Onboard Certificates and
Configuration”) to delete all client certificates and re-provision all devices. You will also need to reissue any
server or subordinate CA certificates.
To avoid the complication of revoking and reissuing certificates, it is recommended that you configure the
certificate authority before any device provisioning or other configuration is done.

In the Identity section of the form:
 Enter values in the Country, State, Locality, Organization, and Organizational Unit text fields that
correspond to your organization. These values form part of the distinguished name for the certificate
authority.
 Enter a descriptive name for the certificate authority in the Common Name text field. This value will be
used to identify the intermediate certificate as the issuer of client and server certificates from this
certificate authority.
 Enter a contact email address in the Email Address text field. This email address will be included in the
certificate authority’s certificate, and provides a way for users of the certificate authority to contact your
organization.
In the Private Key section:
 Mark the Generate a new private key check box to create a new private key for the intermediate
certificate. This is only necessary if you are recreating the entire certificate authority from the beginning.
Note: If you have previously created any client or server certificates or performed device provisioning
using the existing intermediate CA certificate, these certificates will be invalidated when changing the
intermediate CA’s private key.

 The Key Type drop-down list specifies the type of private key that should be created for the certificate.
You can select one of these options:
 1024-bit RSA – not recommended for a certificate authority
 2048-bit RSA – recommended for general use
 4096-bit RSA – higher security
In the Intermediate Certificate section:
 The Digest Algorithm drop-down list allows you to specify which hash algorithm should be used.
Note: MD5 is not recommended for use with certificate authority certificates.
Mark the Generate CA certificate request and invalidate all other certificates check box to confirm
the changes.
Click the Create Certificate Request button to save the settings and generate a new certificate signing
request.
Obtaining a Certificate for the Certificate Authority
The Intermediate Certificate Request page displays the certificate signing request for the certificate
authority’s intermediate certificate. This page is also used to renew the certificate authority’s intermediate
certificate when it is close to expiring.
You can copy the certificate signing request in text format using your Web browser. Use this option when
you can paste the request directly into another application to obtain a certificate.
You can click the Download the current CSR link to download the certificate signing request as a file.
Use this option when you need to provide the certificate signing request as a file to obtain a certificate.
Once you have obtained the certificate, click the Install a signed certificate link to continue configuring
the intermediate certificate authority. See “Installing a Certificate Authority’s Certificate”.
You can also click the Change CA settings link to return to the main Certificate Authority Settings
form. Use this option to switch to a root CA, or to change the name or properties of the intermediate CA and
reissue the certificate signing request.
Using Microsoft Active Directory Certificate Services
Navigate to the Microsoft Active Directory Certificate Services Web page. This page is typically found
at https://yourdomain/certsrv/. The Welcome page is displayed.

Click the Request a Certificate link on this page. The Request a Certificate page is displayed.
Click the link to submit an advanced certificate request. The Submit a Certificate Request or Renewal
Request page is displayed.

Copy and paste the certificate signing request text into the Saved Request text field.
Because this certificate is for a certificate authority, select the “Subordinate Certificate Authority” in the
Certificate Template drop-down list.
Click the Submit button to issue the certificate. The Certificate Issued page is displayed.
Select the Base 64 encoded option and then click the Download certificate chain link.
A file containing the intermediate certificate and the issuing certificates in the trust chain will be
downloaded.
Refer to the instructions in “Installing a Certificate Authority’s Certificate” for information on uploading this
certificate file.

Installing a Certificate Authority’s Certificate
The CA Certificate Import page may be used to:
 Upload a certificate that has been issued by another certificate authority. This process is required when
configuring an intermediate certificate authority.
 A private key is not required, as the certificate authority has already generated one and used it to
create the certificate signing request.
 Upload a certificate and private key to be used as the certificate authority’s certificate. This process may
be used to configure a root certificate authority.
 A private key is required, as the certificate authority’s existing private key will be replaced.
Note: This form may be used multiple times, to import each of the certificates in the trust chain. Check the
message displayed above the form to determine which certificate or type of file must be uploaded next.
In the Step 1 section of the form, select one of the following options in the Format radio buttons:
 Copy and paste certificate as text. The form expands to include the Step 2 fields.
To upload a single certificate, copy and paste the certificate into the Certificate text field. The text
must include the “BEGIN CERTIFICATE” and “END CERTIFICATE” lines. Leave the passphrase fields
blank.
To upload a certificate and private key, copy and paste the certificate and private key into the
Certificate text field. The text must include the “BEGIN CERTIFICATE” and “END CERTIFICATE”
lines, as well as the “BEGIN RSA PRIVATE KEY” and “END RSA PRIVATE KEY” lines.

 Upload certificate file – Step 2 and Step 3 are displayed on the CA Certificate Import form.
Choose the file to upload in the Certificate field.
To upload a single certificate, choose a certificate file in PEM (base-64 encoded) or binary format (.crt
or PKCS#7). Leave the passphrase fields blank.
To upload a certificate’s private key as a separate file, choose the private key file in PEM (base-64
encoded) format. If the private key has a passphrase, enter it in the Private Key Passphrase and
Confirm Passphrase fields. The private key will be automatically matched to its corresponding
certificate when uploaded.
To upload a combined certificate and private key, choose a file in either PEM (base-64 encoded) or
PKCS#12 format. If the private key has a passphrase, enter it in the Private Key Passphrase and
Confirm Passphrase fields.
Click the Upload Certificate button to save your changes.
 If additional certificates are required, you will remain at the same page. Check the message displayed
above the form to determine which certificate or type of file must be uploaded next.
 When the trust chain is complete, it will be displayed. This completes the initialization of the certificate
authority.
Renewing the Certificate Authority’s Certificate
When a root certificate is close to expiration, it must be renewed.
Navigate to Onboard > Certificate Authority Settings and click the Renew Root Certificate link. The
Root Certificate Renewal form is displayed.

Select an option in the Renewal Type drop-down list:
 Basic Renewal – Uses the same private key for the root certificate, but reissues the root CA certificate
with an updated validity period. Use this option to maintain the validity of all certificates issued by the
CA.
 Replacement Renewal – Generates a new private key for the root certificate, and reissues the root CA
certificate with an updated validity period. Use this option if the root certificate has been compromised,
or if you want to invalidate all certificate that were previously issued by the CA.
Whether you renew or replace the root certificate, you should distribute a new copy of the root certificate
to all users of that certificate.
Click the Renew Root Certificate button to perform the renewal action.
Configuring Data Retention Policy for Certificates
The data retention policy for certificates and certificate requests can be configured by navigating to
Onboard > Certificate Authority Settings and clicking the Configure data retention link.
The Manage Data Retention form is displayed.
In the Onboard Device Certificates section of the form, specify a value in the Minimum Period and
Maximum Period fields that is appropriate for your organization’s retention policy.
Note: Use a blank value for Minimum Period to enable the Delete Certificate and Delete Request
actions in the Certificate Management list view. This is useful for testing and initial deployment.
The default data retention policy specifies the values:
 Minimum Period of 12 weeks
 Maximum Period of 52 weeks
Uploading Certificates for the Certificate Authority
The Certificate Authority Trust Chain page is used to view the certificate authority’s current trust chain, or
to upload a new certificate in the trust chain when configuring a certificate authority.
To view the Certificate Authority’s trust chain, go to Onboard > Certificate Authority Settings and click
the View CA Certificate link at the top of the page. The Certificate Authority Trust Chain page is
displayed. This page shows a graphical representation of the certificates that make up the trust chain.
The first certificate listed is the root certificate. Root certificates are always self-signed and are explicitly
trusted by clients.

Each additional certificate shown is an intermediate certificate. The last certificate in the list is the signing
certificate that is used to issue client and server certificates.
To view the properties of a certificate in the trust chain, click the Show certificate link . The Certificate
Information view opens.
To export a certificate:
1. Click the Download Bundle link. The Export Certificate form opens.
2. In the Format row, choose the certificate format. The form expands to includ e configuration options
for that format.
3. Complete the fields with the appropriate information, then click Export Certificate.

Creating a Certificate
From the Certificate Management page, click the Generate a new certificate signing request link
to access the Certificate Request form.
To create a new certificate or certificate signing request, first select the type of certificate you want to
create from the Certificate Type drop-down list:
 TLS Client Certificate – Use this option when the certificate is to be issued to a client, such as a user
or a user’s device.
 When this option is selected, the issued certificate’s extended key usage property will contain a value
of “Client Auth”, indicating that the certificate may be used to identify a client.
 TLS Server Certificate – Use this option when the certificate is to be issued to a network server, such
as a Web server or as the EAP-TLS authentication server.
of “Server Auth”, indicating that the certificate may be used to identify a server.
 Certificate Authority – Use this option when the certificate is for an subordinate certificate authority.
 When this option is selected, the issued certificate will contain an extension identifying it as an
intermediate certificate authority, and the extended key usage property will contain the three values
“Client Auth”, “Server Auth” and “OCSP Signing”.

Specifying the Identity of the Certificate Subject
In the first part of the form, provide the identity of the person or device for which the certificate is to be
issued (the “subject” of the certificate). Together, these fields are collectively known as a distinguished
name, or “DN”.
 Country
 State
 Locality
 Organization
 Organizational Unit
 Common Name – this is the primary name used to identify the certificate
 Email Address
The Key Type drop-down list specifies the type of private key that should be created for the certificate. You
can select one of these options:
 1024-bit RSA – lower security
 2048-bit RSA – recommended for general use
 4096-bit RSA – higher security
Note: Using a private key containing more bits will increase security, but will also increase the processing
time required to create the certificate and authenticate the device. The additional processing required will
also affect the battery life of a mobile device. It is recommended to use the smallest private key size that is
feasible for your organization.
If you have selected TLS Client as the certificate type, the Subject Alternative Name section is also shown.
The alternative name can be used to specify additional identification details for the certificate’s subject. If
one or more of these options are provided, the issued certificate will contain a subjectAltName extension
with the specified values.
Table 5 on page 40 explains the fields that may be included as part of the subject alternative name.

Issuing the Certificate Request
Mark the Issue this certificate immediately check box to automatically create the certificate.
Click the Create Certificate Request button to save your changes.
 If the “Issue this certificate immediately” check box is marked, the certificate will be issued immediately
and will be displayed in the Certificate Management list view.
 If the “Issue this certificate immediately” check box is
 not marked, the certificate request will be displayed in the Certificate Management list view. The
certificate can then be issued or rejected at a later time.
Managing Certificates
To view the list of certificates and work with them, go to Onboard > Certificate Management, or click
the Certificate Management command link.
This list view displays all of the certificates and certificate requests in the Onboard system. Table 6 on page
41 lists the types of certificate that are displayed in this list.
Table 5 Subject Alternative Name Fields Supported When Creating a TLS Client Certificate Signing
Request
Name Desctiption
Device Type Type of device, such as “iOS”, “Android”, etc.
Device UDID Unique device identifier (UDID) for this device. This is typically a 64-bit, 128-bit
or 160-bit number represented in hexadecimal (16, 32 or 40 characters,
respectively).
Device IMEI International Mobile Equipment Identity (IMEI) number allocated to this device.
Device ICCID Integrated Circuit Card Identifier (ICCID) number from the Subscriber Identity
Module (SIM) card present in the device.
Device Serial Serial number of the device.
MAC Address IEEE MAC address of this device.
Product Name Product string identifying the device and often including the hardware version
information.
Product Version Software version number for the device.
User Name Username of the user who provisioned the device.

Searching for Certificates
The Filter field can be used to quickly search for a matching certificate. Type a username into this field to
locate all certificates matching that username quickly.
The filter is applied to all columns displayed in the list view. To search by another field, such as MAC
address, device type, or device serial number, click the Columns tab, select the appropriate column(s),
and then click the Save and Reload button. The list view will refresh to update the results of the filter.
Click the Clear Filter link to restore the default view.
Use the paging control at the bottom of the list to jump forwards or backwards by one page, or to the first or
last page of the list. You can also click an individual page number to jump directly to that page.
Note: When the list contains many thousands of certificates, consider using the Filter field to speed up
finding a specific certificate.
Click the column headers to sort the list view by that column. Click the column header a second time to
reverse the direction of the sort.
Table 6 Types of Certificate Supported by Onboard Certificate Management
Certificate Type “Type” Column Notes
Root certificate ca Self-signed certificate for the certificate
authority
Intermediate certificate ca Issued by the root CA or another
intermediate CA
Profile signing certificate profile-signing Issued by the certificate authority
Certificate signing request tls-client or tls-server The type shown depends on the kind of
certificate requested
Rejected certificate signing request tls-client or tls-server Certificate request that was rejected due to
an administrator decision
Device certificate scep-client Issued to iOS and OS X (10.7+) devices only
Client certificate tls-client Identity certificate issued to a specific user’s
device
Server certificate tls-server Identity certificate issued to a server
Code-signing certificate ca Used for signing the Windows provisioning
application
Revoked certificate -- Certificate that has been administratively
revoked and is no longer valid
Expired certificate -- Certificate that is outside its validity period
and is no longer valid

Working with Certificates
Click on a certificate to select it. You can then select from one of these actions:
 View certificate – Displays the properties of the certificate. Click the Cancel button to close the
certificate properties.
 Export certificate – Displays the Export Certificate form.
Use the Format drop-down list to select the format in which the certificate should be exported. The
following formats are supported:
 PKCS#7 Certificates (.p7b) – Exports the certificate, and optionally the other certificates forming
the trust chain for the certificate, as a PKCS#7 container.
 Base-64 Encoded (.pem) – Exports the certificate as a base-64 encoded text file. This is also known
as “PEM format”.
 Binary Certificate (.crt) – Exports the certificate as a binary file. This is also known as “DER
format”.
 PKCS#12 Certificate & Key (.p12) – Exports the certificate and its associated private key, and
optionally any other certificates required to establish the trust chain for the certificate, as a PKCS#12
container. This option is only available if the private key for the certificate is available to the server.
If you selected the PKCS#12 format, you must enter a passphrase to protect the private key stored in the
file.
Note: To protect against brute-force password attacks and ensure the security of the private key, you
should use a strong passphrase – one consisting of several words, mixed upper- and lower-case letters,
and punctuation or other symbol characters.
Click the Export Certificate button to download the certificate file in the selected format.

 Revoke certificate – Displays the Revoke Certificate form.
Mark the Revoke this client certificate check box to confirm that the certificate should be revoked,
and then click the Revoke Certificate button.
Once the certificate has been revoked, future checks of the certificate’s validity using OCSP or CRL will
indicate that the certificate is no longer valid.
Note: Due to the way in which certificate revocation lists work, a certificate cannot be un-revoked. A
new certificate must be issued if a certificate is revoked in error.
Note: Revoking a device’s certificate will also prevent the device from being re-provisioned. This is
necessary to prevent the user from simply re-provisioning and obtaining a new certificate. To re-
provision the device, the revoked certificate must be deleted.

 Delete certificate – Removes the certificate from the list. This option is only available if the data
retention policy is configured to permit the certificate’s deletion. See “Configuring Data Retention Policy
for Certificates”.
The Delete Certificate form is displayed. Mark the Delete this client certificate check box to confirm
the certificate’s deletion, and then click the Delete Certificate button.
Working with Certificate Signing Requests
Certificate signing requests can be managed through the Certificate Management list view. This allows for
server certificates, subordinate certificate authorities, and other client certificates not associated with a
device to be issued by the Onboard certificate authority.
Click on a certificate request to select it. You can then select from one of these actions:
 View request – Displays the properties of the certificate request. Click the Cancel button to close
the certificate request properties.
 Export request – Displays the Export Certificate Request form.
Use the Format drop-down list to select the format in which the certificate signing request should be
exported. The following formats are supported:
 PKCS#10 Certificate Request (.p10) – Exports the certificate signing request in binary format.
 Base-64 Encoded (.pem) – Exports the certificate signing request as a base-64 encoded text file.
This is also known as “PEM format”.

If you choose Base-64 Encoded, the form expands to include the Trust Chain row. You can use this
option to create and export a certificate bundle that includes the Intermediate CA and Root CA and can
be imported in ClearPass Policy Manager as the server certificate (ClearPass Policy Manager does not
accept PKCS#7). To include the trust chain in a certificate bundle that can be imported as the server
certificate in ClearPass Policy Manager, mark the Include certificate trust chain check box, then
click the Export Certificate button.
Click the Export Request button to download the certificate signing request file in the selected format.
 Sign request – Displays the Sign Request form. Use this action to approve the request for a
certificate and issue the certificate.
Use the Expiration text field to specify how long the issued certificate should remain valid.
Mark the Sign this request check box to confirm that the certificate should be issued, and then click
the Sign Request button. The certificate will be issued and will then replace the certificate signing
request in the list view.

 Reject request – Displays the Reject Request form. Use this action to reject the request for a
certificate. Rejected requests are automatically deleted according to the data retention policy.
Mark the Reject this request check box to confirm that the certificate signing request should be
rejected, and then click the Reject Request button.
 Delete request – Removes the certificate signing request from the list. This option is only available if
the data retention policy is configured to permit the certificate signing requests’s deletion. See
“Configuring Data Retention Policy for Certificates”.
The Delete Request form is displayed. Mark the Delete this request check box to confirm the
certificate signing request’s deletion, and then click the Delete Request button.

Importing a Code-Signing Certificate
Onboard supports importing a code-signing certificate chain and private key for signing the Windows
provisioning application. Certificates can be uploaded as PFX, PKCS-12, SPC, or PKCS-7, and can include a
chain of certificates. An operator’s profile must include the Import Code-Signing Certificate privilege in
order to access this feature.
To import a code-signing certificate:
1. Go to Onboard > Certificate Management or Onboard > Provisioning Settings and click the
Upload a code-signing certificate link at the top of the page. The Code-Signing Certificate Import
form opens.
2. In the Certificate Type drop-down list, choose the file type—either PFX, PKCS-12, SPC, or PKCS-7.
The form expands to include the Certificate area, with fields for uploading the certificate, uploading the
private key, and entering the passphrase.
For PFX and PKCS-12 files, the private key must be included in the certificate file, so the Private Key
upload option is not available in the form. The private key passphrase is required.
For SPC and PKCS-7 files, a PEM-encoded private key must be uploaded separately using the Private
Key upload option on the form. If it is encrypted, the passphrase must also be provided.
3. Click Upload Certificate. The certificate chain is displayed.

To use the certificate for code-signing:
1. Go to Onboard > Provisioning Settings and scroll to the Windows Provisioning section of the form.
2. In the Code-Signing Certificate drop-down list, select the uploaded certificate.
To create a test certificate:
1. Go to Onboard > Certificate Management and click the Generate a new certificate signing
request link. The Certificate Request Settings form opens.
2. In the Certificate Type drop-down list, choose Code-Signing.
3. Complete the rest of the form with your information. Mark the Issue this certificate immediately
check box, then click Create Certificate Request.
The test certificate is displayed in the list on the Certificate Management page, and can be selected on
the Provisioning Settings form.
Requesting a Certificate
From the Certificate Management page, click the Upload a certificate signing request link to access
the Certificate Signing Request form.
Providing a Certificate Signing Request in Text Format
If you have a certificate signing request in text format, click the Copy and paste certificate signing
request as text radio button.

Paste the text into the Certificate Signing Request text field. Be sure to include the complete block of
text, including the beginning and ending lines.
A complete certificate signing request looks like the following:
-----BEGIN CERTIFICATE REQUEST-----
MIIB7DCCAVUCAQAwgasxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRIwEAYDVQQHEwlTdW5ueXZhbGUxFzAVBgNVBAoTDkFDTUUgU3Byb2NrZXRzMRkw
FwYDVQQLExBWaXNpdG9yIFNlcnZpY2VzMR4wHAYDVQQDExVBdXRoZW50aWNhdGlv
biBTZXJ2ZXIxHzAdBgkqhkiG9w0BCQEWEGluZm9AZXhhbXBsZS5jb20wgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBALR4wRSH26wlcf3OEPEIh34iXRQIUrnYnDfo
+ZezeB/i4NZUhRvLMvhPW7DcLpiZJ17ILj3aPPUXWDBYYiiuOkmuFX3dG7eKCLMH
Z4E9z1ozK5Znm8cWIj56kg69le7QrAZBYrd5QaBTMxEe0F9CGFsYbFx1viMUMxN6
EJILaCTBAgMBAAGgADANBgkqhkiG9w0BAQUFAAOBgQB8/So9KU5BS3oxjyxftIwF
dWvNP2CNruKyQaba5RQ1ixdHAsPE+3uYIHNvlqqIpSzBlfYkr21S4DdR3SSC3bXy
t4l/fyMuC1cEG/RpPSxdDALpeT8MuoGV1JonKo2BDitOEd4y5SXGmHmDBHrPW2Nd
gthkrtBb/a2WAkNcRfDuiQ==
-----END CERTIFICATE REQUEST-----
Providing a Certificate Signing Request File
Alternatively, if you have the certificate signing request as a file, click the Upload certificate signing
request file radio button.
Use the Certificate Signing Request field to select the appropriate file for upload.
Note: The file should be a base-64 encoded (PEM format) PKCS#10 certificate signing request.
Specifying Certificate Properties
Select the type of certificate from the Certificate Type drop-down list. Choose from one of the following
options:
 TLS Client Certificate – Use this option when the certificate is to be issued to a client, such as a user
or a user’s device.
of “Client Auth”, indicating that the certificate may be used to identify a client.
 TLS Server Certificate – Use this option when the certificate is to be issued to a network server, such
as a Web server or as the EAP-TLS authentication server.
of “Server Auth”, indicating that the certificate may be used to identify a server.

 Certificate Authority – Use this option when the certificate is for an subordinate certificate authority.
 When this option is selected, the issued certificate will contain an extension identifying it as an
intermediate certificate authority, and the extended key usage property will contain the three values
“Client Auth”, “Server Auth” and “OCSP Signing”.
Mark the Issue this certificate immediately check box to automatically issue the certificate.
Click the Submit Certificate Signing Request button to save your changes.
 If the “Issue this certificate immediately” check box is marked, the certificate will be issued immediately
and will be displayed in the Certificate Management list view.
 If the “Issue this certificate immediately” check box is not marked, the certificate request will be
displayed in the Certificate Management list view. The certificate can then be issued or rejected at a later
time.
Configuring Provisioning Settings
To configure basic device provisioning settings, go to Onboard > Provisioning Settings, or click the
Provisioning Settings command link. The Device Provisioning Settings page opens.
This page is used to configure the settings for ClearPass Onboard device provisioning, including:
 The organization name displayed during device provisioning
 Properties for the certificates issued to devices when they are provisioned
 Which operating systems should be supported
 Authorization properties – the number of devices that a user may provision
Configuring Basic Provisioning Settings
The first part of the Device Provisioning Settings form is used to specify basic information about the
Onboard provisioning.
The Name and Description fields are used internally to identify this set of Onboard settings for the
network administrator. These values are never displayed to the user during device provisioning.
Use the Organization field to provide the name of your organization; this will be displayed to the user
during the device provisioning process.

Configuring Certificate Properties for Device Provisioning
The second part of the Device Provisioning Settings form is used to specify the properties for certificates
issued to devices.
The Certificate Authority drop-down list can be used to select a different certificate authority. By default,
there is only a single certificate authority.
Use the Validity Period text field to specify the maximum length of time for which a client certificate
issued during device provisioning will remain valid.
The Clock Skew Allowance text field adds a small amount of time to the start and end of the client
certificate’s validity period. This permits a newly issued certificate to be recognized as valid in a network
where not all devices are perfectly synchronized.
For example, if the current time is 12:00, and the clock skew allowance is set to the default value of 15
minutes, then the client certificate will be issued with a “not valid before” time of 11:45. In this case, if the
authentication server that receives the client certificate has a time of 11:58, it will still recognize the
certificate as valid. If the clock skew allowance was set to 0 minutes, then the authentication server would
not recognize the certificate as valid until its clock has reached 12:00.
The default of 15 minutes is reasonable. If you expect that all devices on the network will be synchronized
then the value may be reduced. A setting of 0 minutes is not recommended as this does not permit any
variance in clocks between devices.
When issuing a certificate, the certificate’s validity period is determined as follows:
 The “not valid before” time is set to the current time, less the clock skew allowance.
 The “not valid after” time is first calculated as the earliest of the following:
 The current time, plus the maximum validity period.
 The expiration time of the user account for whom the device certificate is being issued.
 The “not valid after” time is then increased by the clock skew allowance.
The Key Type drop-down list specifies the type of private key that should be created when issuing a new
certificate. You can select one of these options:
 1024-bit RSA – lower security
 2048-bit RSA – recommended for general use
 4096-bit RSA – higher security

Note: Using a private key containing more bits will increase security, but will also increase the processing
time required to create the certificate and authenticate the device. The additional processing required will
also affect the battery life of a mobile device. It is recommended to use the smallest private key size that is
feasible for your organization.
Mark the Include device information in TLS client certificates check box to include additional fields
in the TLS client certificate issued for a device. These fields are stored in the subject alternative name
(subjectAltName) of the certificate. Refer to Table 7 on page 52 for a list of the fields that are stored in the
certificate when this option is enabled.
Storing additional device information in the client certificate allows for additional authorization checks to
be performed during device authentication.
Note: If you are using an Aruba Controller to perform EAP-TLS authentication using these client
certificates, you must have Aruba OS 6.1 or later to enable this option.
Note: Object Identifier. These OIDs are relative to the ClearPass Guest base OID, which is 1.3.6.1.4.1.14823.1.5.1.
Specify one of the following options in the Authority Info Access drop-down list to control automatic
certificate revocation checks:
 Do not include OCSP responder URL – The Authority Info Access extension is not included in the
client certificate. Certificate revocation checking must be configured manually on the authentication
server. This is the default option.
 Include OCSP responder URL – The Authority Info Access extension is added to the client
certificates, with the OCSP responder URL set to a predetermined value. This value is displayed as the
“OCSP URL”.
Table 7 Device Information Stored in TLS Client Certificates
Name Description OID
Device ICCID Integrated Circuit Card Identifier (ICCID) number from the
Subscriber Identity Module (SIM) card present in the device. This is
only available for devices with GSM (cellular network) capability,
where a SIM card has been installed.
mdpsDeviceIccid (.4)
Device IMEI International Mobile Equipment Identity (IMEI) number allocated to
this device. This is only available for devices with GSM (cellular
network) capability.
mdpsDeviceImei (.3)
Device Serial Serial number of the device. mdpsDeviceSerial (.9)
Device Type Type of device, such as “iOS”, “Android”, etc. mdpsDeviceType (.1)
Device UDID Unique device identifier (UDID) for this device. This is typically a 64-
bit, 128-bit or 160-bit number represented in hexadecimal (16, 32,
or 40 characters, respectively).
mdpsDeviceUdid (.2)
MAC Address IEEE MAC address of this device. This element may be present
multiple times, if a device has more than one MAC address (for
example, an Ethernet port and a Wi-Fi adapter).
mdpsMacAddress (.5)
Product Name Product string identifying the device and often including the
hardware version information.
mdpsProductName (.6)
Product Version String containing the software version number for the device. mdpsProductVersion (.7)
User Name String containing the username of the user who provisioned the
device.
mdpsUserName (.8)

 Specify an OCSP responder URL – The Authority Info Access extension is added to the client
certificates, with the OCSP responder URL set to a value defined by the administrator. This value may be
specified in the “OCSP URL” field.
Configuring Provisioning Settings for iOS and OS X
The third part of the Device Provisioning Settings form is used to specify provisioning settings related to
iOS devices.
Mark the Enable iOS and OS X 10.7+ (Lion or later) device provisioning check box to enable
provisioning for these devices.
Mark the Enable device authentication check box to enable an additional authorization step to be
performed during device provisioning. See “Advanced: Device Authentication During Provisioning” for
details about this process.

Use the Display Name and Profile Description text fields to control the user interface displayed during
device provisioning.
Select one of the following options in the Profile Security drop-down list to control how a device
provisioning profile may be removed:
 Always allow removal – The user may remove the device provisioning profile at any time, which will
also remove the associated device configuration and unique device credentials.
 Remove only with authorization – The user may remove the device provisioning profile if they also
provide a password. The administrator must specify the password in the “Removal Password” and
“Confirm Removal Password” fields.
 Never allow removal – The user cannot remove the device provisioning profile. This option should be
used with caution, as the only way to remove the profile is to reset the device to factory defaults, and
destroy all data on the device.
Use the Profile Signing text field to specify the display name of the certificate used to sign the
configuration profile. This certificate will be automatically created by the certificate authority, and appears
as the “Signed” field on the device when the user authorizes the device provisioning.
Mark the Change the profile ID check box to change the unique value associated with the configuration
profile. This value is used to identify the configuration settings as being from a particular source, and
should be globally unique.
When an iOS device receives a new configuration profile that has the same profile ID as an existing profile,
the existing profile will be replaced with the new profile.
Note: Changing the profile ID will affect any device that has already been provisioned with the existing
profile ID. The default value is automatically generated and is globally unique. You should only change this
value during initial configuration of device provisioning.

Configuring Provisioning Settings for Mac OS X, Windows, and Android Devices
The fourth part of the Device Provisioning Settings form is used to specify provisioning settings related to
Onboard-capable devices.
Mark the appropriate check boxes here to enable device provisioning on the respective platforms:
 Enable OS X 10.5 (Leopard) and 10.6 (Snow Leopard) device provisioning
 Enable Windows XP, Vista and 7 (or later) device provisioning
 Enable Android device provisioning
Select one of the options in the Provisioning Address drop-down list to control where a device is directed
to during provisioning:
 The system’s hostname (requires DNS resolution) – Select this option to use the system hostname
for device provisioning.
Note that this option requires that the device be able to resolve the listed hostname at the time the
device is provisioned.
 The system’s IP address (network adapter name) – Select this option to use the IP address of the
system for device provisioning. The drop-down list includes one option for each of the IP addresses
detected on the system.
Use this option when DNS resolution of the system’s hostname is not available for devices that are in a
provisioning role.

 Other IP address or hostname… – Select this option to override the hostname or IP address to be
specified during device provisioning. The administrator must enter the hostname or IP address in the
“Address” text field.
Use this option when special DNS or NAT conditions apply to devices that are in a provisioning role.
The Provisioning Access warning message is displayed when HTTPS is not required for guest access.
HTTPS is recommended for all deployments as it secures the unique device credentials that will be issued
to the device.
Note: When using HTTPS for device provisioning, you must obtain a commercial SSL certificate. Self-
signed SSL certificates, and SSL server certificates that have been issued by an untrusted or unknown root
certificate authority, will cause iOS device provisioning to fail with the message “The server certificate for
… is invalid”.
The Validate Certificate drop-down list is used to specify whether the SSL server’s certificate should be
validated as trusted. When this option is set to “Yes, validate this web server’s certificate (recommended)”,
a certificate validation failure on the client device will cause device provisioning to fail. This is the default
option.
You should change this option to “No, do not validate this web server’s certificate” only during testing, or if
you are waiting for a commercial SSL certificate.
Configuring User Interface Options for Mac OS X, Windows, and Android Devices
The Device Provisioning section of the Device Provisioning Settings form allows you to customize the user
interface displayed by the QuickConnect app.
To display your enterprise’s logo, select an image from the list in the Logo Image field. Navigate to
Administrator > Content Manager to upload new images for use as the logo.
The native size of the logo used in the QuickConnect client is 188 pixels wide, 53 pixels high. You may use
an image of a different size and it will be scaled to fit, but for the best quality results it is recommended that
you provide an image that is already the correct size.
The Wizard Title text field may be used to specify the text displayed to users when they launch the
QuickConnect app to provision their device.
If provided, the Password Recovery URL and Helpdesk URL fields may be used to provide additional
resources to users who encounter trouble in provisioning their devices.
Note: Ensure that users in the provisioning role can access these URLs.

Configuring Authorization Settings for Device Provisioning
The fifth part of the Device Provisioning Settings form is used to specify authorization settings for device
provisioning.
Enter a number in the Maximum Devices field to limit the maximum number of devices that each user may
provision.
Devices are recognized as unique when they have a different MAC address, or a different device identifier
(when the MAC address is not available).
Configuring Network Settings for Device Provisioning
To configure the network settings that will be sent to a provisioned device, go to Onboard > Network
Settings, or click the Network Settings command link. The Network Settings page opens with the
Network Access tab displayed.
This page is used to configure the network settings that will be provisioned to devices.
Note: Some devices do not support all possible combinations of network settings. If you make a selection
that is incompatible with a certain type of device, a message will be displayed in the Onboard user interface.
The Network Access form is divided into several tabs:
 Access – Specifies basic network properties, such as the name of the wireless network and the type of
security that is used. See “Configuring Basic Network Access Settings”.
 Protocols – Specifies the 802.1X authentication protocols that are used by the network. See
“Configuring 802.1X Authentication Network Settings”.
 Authentication – Specifies the type of device authentication to be used for the network. See
“Configuring Device Authentication Settings”.
 Trust – Specifies options related to mutual authentication. See “Configuring Mutual Authentication
Settings”.
 Windows – Specifies networking options used only by devices using the Windows operating system.
See “Configuring Windows-Specific Network Settings”.
 Proxy – Specifies a proxy server to be used by devices connecting to the network. See “Configuring
Proxy Settings”.
 Post Install – Specifies additional information and instructions to users after the network is
configured. See “Configuring Post-Installation Instructions”.
Note: Navigating between different tabs will save the changes you have made. The modified settings are
indicated with a “#” marker in the tab. The settings used for device provisioning are not modified until you
click the Save Changes button.

Configuring Basic Network Access Settings
Click the Access tab to display the Network Access form.
The options available in the Network Type drop-down list are:
 Both — Wired and Wireless – Configures both wired (Ethernet) and wireless network adapters. Use
this option when you have 802.1X configured for all types of network access.
 Wireless only – Configures only wireless network adapters.
 Wired only – Configures only wired (Ethernet) network adapters.
The options available in the Security Type drop-down list are:
 Enterprise (802.1X) – Use this option to setup a network that requires user authentication.
This option is the only available choice when the Network Type is set to “Wired only”.
 Personal (PSK) – Use this option to setup a network that requires only a pre-shared key (password) to
access the network.
This option is only available when the Network Type is set to “Wireless only”.
The Security Type field lets you set the encryption version for the wireless network to WPA or WPA2.
If you have selected the Personal (PSK) security type, you must provide the pre-shared key in the
Password field. Selecting this security type will hide the Protocols, Authentication, and Trust
tabs.

Click the Next button to continue to the Protocols tab. Click the Save Changes button to make
the new network configuration settings take effect. Click the Cancel button to discard your changes and
return to the main Onboard configuration user interface.
Configuring 802.1X Authentication Network Settings
Click the Protocols tab to display the Enterprise Protocols form.
Use this form to specify the authentication methods required by your network infrastructure.
 The Legacy OS X EAP option supports only PEAP with MSCHAPv2.
 The Windows EAP option supports only PEAP with MSCHAPv2.
These best practices are recommended when choosing the 802.1X authentication methods to provision:
 Configure PEAP with MSCHAPv2 for Onboard devices – Android, Windows, and legacy OS X (10.5/10.6).
 Configure EAP-TLS for iOS devices and OS X (10.7 or later).
 Other EAP methods, while possible, are limited in their applicability and should only be used if you have
a specific requirement for that method.
The Windows EAP options that may be specified include:
 Enable Fast Reconnect – Fast Reconnect is a PEAP property that enables wireless clients to move
between wireless access points on the same network without being re-authenticated each time they
associate with a new access point.
 Enable Quarantine Checks – Enable this option to obtain a system statement-of-health (SSoH) from
the OnGuard or Microsoft NAP Agent and send it to the authentication server during the 802.1X
authentication process. Use this option to enforce network access control (NAC) protections on the
network.

 Enforce Cryptobinding – Cryptobinding is a process that protects the authentication protocol
negotiation against man-in-the-middle attacks. The cryptobinding request and response performs a two-
way handshake between the peer and the authentication server using key materials.
Click the Previous button to return to the Access tab. Click the Next button to continue to the
Authentication tab. Click the Save Changes button to make the new network configuration settings
take effect. Click the Cancel button to discard your changes and return to the main Onboard
configuration user interface.
Configuring Device Authentication Settings
Click the Authentication tab to display the Enterprise Authentication form.
Select one of these options in the iOS & OS X Credentials drop-down list:
 Certificate – A device certificate will be provisioned and used for EAP-TLS client authentication. When
this option is selected, EAP-TLS must be selected on the Protocols tab.
 Username & Password – A device certificate will be provisioned, but the client authentication will use
unique device credentials (as for Onboard devices). When this option is selected, EAP-TTLS or PEAP
must be selected on the Protocols tab.
The Windows Authentication options that may be selected are:
 Machine Only – Use computer-only credentials.
 User Only – Use user-only credentials
 Machine Or User – Use computer-only credentials or user-only credentials. When a user is logged on,
the user's credentials are used for authentication. When no user is logged on, computer-only credentials
are used for authentication.
 Guest – Use guest-only credentials.
Click the Previous button to return to the Protocols tab. Click the Next button to continue to the
Trust tab. Click the Save Changes button to make the new network configuration settings take effect.
Click the Cancel button to discard your changes and return to the main Onboard configuration user
interface.

Configuring Mutual Authentication Settings
Click the Trust tab to display the Enterprise Trust form.
In the Trusted Certificates row, mark the check box for each server certificate that the client should
trust.
Use the Upload Certificate field to upload additional server certificates. These certificates will be
displayed in the certificate management list view with the type “tls-server”.
These best practices are recommended for enterprise trust options:
 Provide the certificate for each authentication server that a provisioned device will use, and select it in
the Trusted Certificates list.
 Avoid marking the Allow trust exceptions check box – the network administrator should make all
trust decisions. Users will not generally review certificates for potential issues before accepting them.
 Mark the Validate the server certificate check box for Windows. This ensures that the provisioned
device will check the server certificate is valid before using the server for authentication.
In the Android Trust row, the default setting is for Android devices to automatically provision Onboard’s
Root CA certificate to the device. You can choose to provision a custom certificate instead. To provision a
custom certificate for an Android device, mark the Use custom certificate trust settings check box. The
form expands to include the Trusted Certificate row. In the drop-down list, choose the certificate the device
should trust.
Click the Previous button to return to the Authentication tab. Click the Next button to continue to
the Windows tab. Click the Save Changes button to make the new network configuration settings
take effect. Click the Cancel button to discard your changes and return to the main Onboard

Configuring Windows-Specific Network Settings
Click the Windows tab to display the Windows Network Settings form.
Network Access Protection (NAP) is a feature in Windows Server 2008 that controls access to network
resources based on a client computer’s identity and compliance with corporate governance policy. NAP
allows network administrators to define granular levels of network access based on who a client is, the
groups to which the client belongs, and the degree to which that client is compliant with corporate
governance policy. If a client is not compliant, NAP provides a mechanism to automatically bring the client
back into compliance and then dynamically increase its level of network access.
Deploying NAP requires a NAP-compatible authentication server, so that appropriate policies may be
implemented based on the statement of health provided by the NAP client.
To enable NAP for Microsoft Windows clients, mark the Enable NAP services check box on this tab. You
will also need to mark the Enable Quarantine Checks check box on the Protocols tab.
Click the Previous button to return to the Trust tab. Click the Next button to continue to the
Proxy tab. Click the Save Changes button to make the new network configuration settings take
effect. Click the Cancel button to discard your changes and return to the main Onboard configuration
user interface.

Configuring Proxy Settings
Click the Proxy tab to display the Proxy Settings form.
Select one of these options in the Proxy Type drop-down list:
 None – No proxy server will be configured.
 Manual – A proxy server will be configured, if the device supports it. Specify the proxy server settings
in the Server and Server Port fields.
 Automatic – The device will configure its own proxy server, if the device supports it. Specify the
location of a proxy auto-config file in the PAC URL text field.
Click the Previous button to return to the Windows tab. Click the Next button to continue to the
Post Install tab. Click the Save Changes button to make the new network configuration settings take
effect. Click the Cancel button to discard your changes and return to the main Onboard configuration
user interface.

Configuring Post-Installation Instructions
Click the Post Install tab to display the Post-Installation form.
The Instructions text field can be used to provide more information or instructions to an iOS or OS X user
immediately after device provisioning has completed.
For example, if you have provisioned Wi-Fi network settings for an SSID that is separate from the initial
provisioning SSID, you could add a message requesting that the user now switch to the new SSID in order to
complete setup.
Click the Previous button to return to the Proxy tab. Click the Save Changes button to make the
new network configuration settings take effect. Click the Cancel button to discard your changes and
return to the main Onboard configuration user interface.
Configuring an iOS Device VPN Connection
To configure the VPN settings that will be sent to a device, go to Onboard > VPN Settings, or click the
VPN Settings command link. The VPN Settings page opens.
This page is used to automatically configure virtual private networking (VPN) settings on the iOS device.
Use this option when you have deployed a VPN infrastructure and want to automatically provide the secure
connection settings to users at the time of device provisioning.
Note: Onboard VPN settings can only be used with iOS 4 and iOS 5 devices. Other platforms are not
supported.

Mark the Add this VPN to the device profile check box to enable provisioning of VPN settings.
The Display Name text field specifies the name for this VPN connection. This will be displayed on the
device in the Settings app. To help the user identify the connection easily, include your organization’s name
in the Display Name field. For example, use “ACME Sprockets VPN”.
Select the appropriate Connection Type from the drop-down list:
 L2TP – Connection uses the Layer 2 Tunneling Protocol. Complete the fields shown in the L2TP
Connection Settings section of the form.
 PPTP – Connection uses the Point-to-Point Tunneling Protocol. Complete the fields shown in the PPTP
Connection Settings section of the form.
 IPSec – Connection uses the Internet Protocol with security extensions. Complete the fields shown in
the IPSec Connection Settings section of the form.
The Authentication Type drop-down list provides these options when configuring an IPSec VPN:
 Identity Certificate – The client certificate issued during device provisioning will also be used as
the identity certificate for VPN connections. This option requires configuring your VPN server to
allow IPSec authentication using a client certificate.

 Shared Secret / Group Name – An optional group name may be specified. A shared secret (pre-
shared key) is used to establish the IPSec VPN. Authentication is performed with a username and
password.
The Proxy Settings section of the form specifies a proxy server that is used when the VPN connection is
active. Select one of these options in the Proxy Setup drop-down list:
 None – No proxy server will be configured with this VPN profile.
 Manual – A proxy server will be configured with this VPN profile. Specify the proxy server settings in
the Server and Port fields.
If authentication is required to access this proxy, you may specify the username and password using the
Authentication and Password text fields.
 Automatic – The proxy server will be automatically configured with this VPN profile. Specify the
location of a proxy auto-config file in the Proxy Server URL text field.
Click the Save Changes button to save the VPN connection profile and return to the main Onboard
Configuring an iOS Device Email Account
To configure the Exchange ActiveSync settings that will be sent to a device, go to Onboard > Exchange
ActiveSync, or click the Exchange ActiveSync command link. The Exchange ActiveSync Settings page
opens.
This page is used to automatically configure an email account on the iOS device. Use this option when you
have an Exchange mail server and want to automatically provide the email settings to users provisioning
their mobile devices.
Note: Onboard Exchange ActiveSync settings can only be used with iOS 4 and iOS 5 devices. Other
platforms are not supported.

Mark the Add this ActiveSync configuration to the device profile check box to enable email account
provisioning.
The Account Name text field specifies the name for this email account. This will be displayed on the device
in the Settings app, and also within the Mail app to identify the mailbox. To help the user identify this
mailbox easily, include your organization’s name in the Account Name field. For example, use “ACME
Sprockets Mail”.
In the Account Settings group, choose one of the following options from the Account Details drop-down
list:
 User provided — entered by user on device. This option requires the user to enter their credentials
on the device to access their email.
 Identity certificate — created during provisioning. This option uses the device’s TLS client
certificate to authenticate the user. Using this option requires configuration of the ActiveSync server to
authenticate a user based on the client certificate.
 Shared preset values — testing only. This option provides a fixed set of credentials to the device.
These settings cannot be modified for each user when provisioning a device, so it is recommended that
these settings only be used when testing Exchange integration.

In the Sync Settings group, choose one of the following options from the Days of Mail drop-down list:
 No Limit
 1 day
 3 days
 1 week
 2 weeks
 1 month
Click the Save Changes button to save the Exchange ActiveSync profile and return to the main Onboard
Configuring an iOS Device Passcode Policy
To make changes to the Passcode Policy configuration that will be sent to a device, go to Onboard >
Passcode Policy, or click the Passcode Policy command link. The Passcode Policy Settings page opens.
This page is used to configure a passcode policy that is applied to iOS devices when provisioned.
Typically, you would enable this policy when provisioning a corporate-owned device, or if you are allowing
a user to access sensitive information remotely.
NOTE: Onboard Passcode Policy settings can only be used with iOS 4 and iOS 5 devices. Other platforms
are not supported.

To enable the passcode policy on all iOS devices, mark the Enable passcode policy check box and
configure the remaining options according to your enterprise’s security requirements.
Click the Save Changes button to save the passcode policy settings and return to the main Onboard

Resetting Onboard Certificates and Configuration
To delete certificates, re-create the Onboard Web login page, or reset configuration to factory default
settings, go to Onboard > Reset to Factory Defaults, or click the Reset to Factory Defaults command
link. The Reset to Factory Defaults page opens.
This page is used to delete certificates, or restore the default configuration for Onboard. These options are
useful while trialing the Onboard workflow with a set of test devices.
Select one of the following options in the Reset Type drop-down list:
 Delete all client certificates – Removes all client certificates from Certificate Management. The
certificate authority’s root certificate, intermediate certificate, profile signing certificate, and any server
certificates are not affected. The provisioning settings for iOS and Onboard-capable devices are not
modified.
 Delete all certificates – Removes all certificates from Certificate Management, including the
certificate authority’s root certificate, intermediate certificate, profile signing certificate, and any server
certificates. The default certificate authority certificate will be recreated. The provisioning settings for
iOS and Onboard-capable devices are not modified.
 Re-create the Onboard weblogin page – Select this option to create the default device_provisioning
Web login page, if it has been deleted or has been modified and no longer functions correctly. All
certificates and settings are left unmodified.
 Delete all certificates and reset configuration to factory defaults – Removes all certificates from
Certificate Management, including the certificate authority’s root certificate, intermediate certificate,
profile signing certificate, and any server certificates. The provisioning settings for iOS and Onboard-
capable devices are restored to the default settings. The default certificate authority will be recreated.
Mark the Reset the specified items check box to indicate that the reset operation should be performed,
and then click Reset to Factory Defaults to perform the operation.

Advanced: Device Authentication During Provisioning
When the Enable device authentication check box is marked, a RADIUS request is performed during the
device provisioning step. The local RADIUS server is always used for this request.
The attributes sent with the RADIUS request are listed in Table 8 on page 71.
Note: This is a vendor-specific attribute with vendor ID 14823.
If the RADIUS server responds with an Access-Reject, then the device provisioning will fail. The value of the
Reply-Message attribute, if one was included in the Access-Reject message, will be used to construct the
error message.
If the RADIUS server responds with an Access-Accept message, then the device provisioning proceeds as
normal.
Table 8 RADIUS Attributes Included with a Device Authentication Request.
RADIUS Attribute Value
User-Name (1) The username for the current device provisioning process.
User-Password (2) Password credentials supplied by the user during device provisioning.
Calling-Station-Id (31) MAC address of the device being provisioned.
This attribute is omitted if the MAC address information is unavailable.
If multiple MAC addresses are available, only the first MAC address will be
included in the RADIUS request.
Framed-IP-Address (8) IPv4 address of the device being provisioned.
NAS-IP-Address (4) Always set to “127.0.0.1”.
NAS-Identifier (32) Set to the hostname of the Onboard server.
NAS-Port (5) Always set to “0”.
NAS-Port-Type (61) Always set to “Ethernet” (15).
Service-Type (6) Always set to “Authorize-Only” (17).
Event-Timestamp (55) Set to a value indicating the current time.
Mdps-Device-Name1 (19) Type of device, such as “iOS”, “Android”, etc.
Mdps-Device-Product1 (20) Product string identifying the device and often including the hardware version
information.
Mdps-Device-Version1 (21) Software version number for the device.
Mdps-Device-Udid1 (15) Unique device identifier (UDID) for this device. This is typically a 64-bit, 128-bit or
160-bit number represented in hexadecimal (16, 32 or 40 characters,
respectively).
Mdps-Device-Imei1 (16) International Mobile Equipment Identity (IMEI) number allocated to this device.
Mdps-Device-Iccid1 (17) Integrated Circuit Card Identifier (ICCID) number from the Subscriber Identity
Module (SIM) card present in the device.
Mdps-Device-Serial1 (22) Serial number of the device.

Onboard Troubleshooting
If you encounter a problem that is not listed here, refer to the “Onboard Deployment Checklist” and check
each of the configuration steps listed there.
iOS Device Provisioning Failures
Symptom: Device provisioning fails on iOS with the message “The server certificate for https://… is
invalid”.
Resolution: When using HTTPS for device provisioning, you must obtain a commercial SSL certificate.
Self-signed SSL certificates, and SSL server certificates that have been issued by an untrusted or unknown
root certificate authority, will cause iOS device provisioning to fail with the message “The server certificate
for … is invalid”.
A workaround for this issue is to install an appropriate root certificate on the iOS device. This root
certificate must be the Web server’s SSL certificate (if it is a self-signed certificate), or the certificate
authority that issued the SSL certificate. This is not recommended for production deployments as it
increases the complexity of deployment for users with iOS devices.

Onboard Deployment Guide 3.9.6

More Related Content

What's hot

Viewers also liked

Similar to Onboard Deployment Guide 3.9.6

More from Aruba, a Hewlett Packard Enterprise company

Recently uploaded

In this document

Onboard Deployment Guide 3.9.6