Skip to main content
Matrix42 Self-Service Help Center

WPA Enterprise Settings for Apple and Android Enterprise

Overview

With Silverback, you can create profiles with specific Wi-Fi settings for WPA, WPA2, and WPA3 Enterprise security standards, and then deploy these profiles to your managed devices. Silverback offers many features, including protocol level configurations, authentication options, proxy and trust settings. Before you start with the configuration, we recommend contacting your Network or IT Administrator for receiving the requirements for your network configuration. This Knowledge Base article provides an overview about all Enterprise Settings for Android Enterprise and Apple devices. If you are using a non-certificate based authentication for your Wi-Fi network on Samsung Knox devices, you can also configure the Wi-Fi profiles with the Knox Service Plugin.

Protocols

After selecting a Security Type for Enterprise security standards within the Wi-Fi configuration, you can select your required protocol and configure additional settings based on the selected protocol.  

Protocols

In the Protocols settings, you can enable the authentication framework that is used in your network. As there are many methods defined by RFCs and vendor-method methods, Silverback supports the below shown Extensible Authentication Protocol (EAP) configurations. The TTLS and PEAP Protocol offer additional configurations for the inner authentication / phase 2 authentication and these options vary based on the operating system. 

Option Apple Android Samsung Knox
Protocols
  • TLS
  • LEAP
  • TTLS
  • PEAP
  • EAP-FAST
  • EAP-SIM
  • EAP-AKA
  • TLS
  • TTLS
  • PEAP
  • PWD
  • TLS
  • LEAP
  • TTLS
  • PEAP
  • FAST
  • PWD
Inner Authentication / Phase 2 Authentication
  • TTLS
    • OS Default
    • PAP
    • CHAP
    • MSCHAP
    • MSCHAPv2
    • EAP
  • TTLS
    • PAP
    • MSCHAP
    • MSCHAPv2
    • GTC
  • PEAP
    • MSCHAPv2
    • GTC
    • SIM
    • AKA 
    • AKA PRIME
  • TTLS
    • PAP
    • MSCHAP
    • MSCHAPv2
    • GTC
  • PEAP
    • MSCHAPv2
    • GTC

Protected Access Credentials

EAP-FAST supports as defined in RFC 4507 the TLS extension to support the fast re-establishment of a secure tunnel without having to maintain per-session state on the server. The EAP-FAST-based mechanisms are defined to provision the credentials for the TLS extension. These credentials are called Protected Access Credentials (PACs). The following options applies to the EAP-FAST configuration for Apple devices

Option Description Supported Platforms
Use Pac
  • Options: Enabled or Disabled
  • Description: If enabled, the device uses an existing PAC if it's present. Otherwise, the server must present its identity using a certificate.
  • iPhone
  • iPad
  • iPod
  • macOS 
  • Apple TV
Provision PAC
  • Options: Enabled or Disabled
  • Description: This value is only applicable if Use Pac is enabled. This value must be enabled for the EAP-FAST PAC usage to succeed because there is no other way to provision a PAC.
  • iPhone
  • iPad
  • iPod
  • macOS 
  • Apple TV
Provision PAC Anonymously
  • Options: Enabled or Disabled
  • Description: If enabled, provisions the device anonymously.

Note that there are known machine-in-the-middle attacks for anonymous provisioning. 

  • iPhone
  • iPad
  • iPod
  • macOS 
  • Apple TV

Authentication

Depending on which authentication method is required for your network, Silverback offers the following settings for both user-based authentication and certificate-based authentication. 

Username, Password, and Identity

In general, you can configure within this section the pre-configuration of usernames (identities) and passwords for the authentication process. The Username and Password configuration applies to the following protocols: LEAP, TTLS, PEAP, EAP-FAST, PWD, and partly for TLS on Android and Samsung Knox. Some settings, like the Use Per-connection password applies only to Apple devices.

Option Description Supported Platforms
Use Individual Username
  • Options: Enabled or Disabled
  • Description: If enabled, the username for the authentication process will be prefilled with the system variable {UserWifi}. 
  • Variable: The {UserWifi} variable is captured during the enrollment and taken from the following fields:   
    • For local users, the Wi-Fi Username is used and can be edited in the Users Tab
    • For LDAP Users, the configured Wi-Fi Username Field attribute is taken from the LDAP attributes configuration
  • iPhone
  • iPad
  • iPod
  • Android
  • Samsung Knox
  • macOS 
  • Apple TV
Username
  • Options: Predefined name
  • Description: If Use Individual Username is not enabled, enter here a static username that will be used for the authentication process. 
  • iPhone
  • iPad
  • iPod
  • Android
  • Samsung Knox
Use Per-connection Password
  • Options: Enabled or Disabled
  • Description: If enabled, users receive a prompt for a password each time they connect to the network.
  • iPhone
  • iPad
  • iPod
  • macOS 
  • Apple TV
Use User Password
  • Options: Enabled or Disabled
  • Description: This option is available, when Use Individual Username is enabled (Android & Samsung Knox). On Apple device, its not available if Per-connection Password is enabled. If this setting is enabled, the password for the authentication process will be prefilled with the system variable {UserPassword} .
  • Variable: To use the Use User Password option, it is required to enable Password Caching 
  • iPhone
  • iPad
  • iPod
  • Android
  • Samsung Knox
  • macOS 
  • Apple TV
Password
  • Options: Predefined password
  • Description: If Use Per-connection Password and Use User Password is not enabled, enter here a static password that will be used for the authentication process. 
  • iPhone
  • iPad
  • iPod
  • Android
  • Samsung Knox
Outer Identity / Anonymous Identity
  • Available for: TTLS, PEAP, and EAP-FAST.
  • Description: The outer identity / anonymous identity can increase security because an attacker can't see the authenticating user's name in the clear. Enter here a name that hides the user's true name. The user's actual name appears only inside the encrypted tunnel. For example, you might set this to anonymous or anon, or anon@imagoverum.com
  • iPhone
  • iPad
  • iPod
  • Android
  • Samsung Knox
  • macOS 
  • Apple TV

Certificate-based authentication

Silverback offers three different levels of certificate-based authentication for your Wi-Fi networks. You can use the basic certificate distribution and distribute only certificates from your Certification Authority to your devices or you can use the extended methods, which requires additional templates and configurations. With the extended methods, you can populate certificates either to Active Directory user or device objects. 

Option Description Supported Platforms
Basic options for certificate-based authentication  
Certificate Type
  • Options: Enterprise Certificate or Individual Client Certificate
  • Description: Depending if you want to perform the authentication with an Enterprise or an Individual Client Certificate, select your desired certificate type. 
  • iPhone
  • iPad
  • iPod
  • Android
  • Samsung Knox
  • macOS 
  • Apple TV
Individual Client Certificates
  • Options: Enabled or Disabled
  • Description: If this option is enabled, a certificate will be requested from the Certification Authority and distributed to devices for the authentication process. Use Individual Client Certificates uses the easiest way for the distribution of client certificates, as the certificates won't be added to the Active Directory User Object. Please refer to Certification Authority Integration and locate the guides named as Add Certification Authority and Assign Certificates
  • Requirement: To use the certificate-based authentication, you need to select the Individual Client Certificate Type.  
  • Template: Certificates will be created on the template, which is added to the Template section under Settings Admin > Certificates. Ensure to add here only the template created for the Add Certification Authority and Assign Certificates method.
  • iPhone
  • iPad
  • iPod
  • Android
  • Samsung Knox
  • macOS 
  • Apple TV
Individual Client Certificate subject
  • Description: This option is available, when Use Individual Username is enabled. In this field, the Subject Name for the certificate is configured. The subject name field supports text strings and system variables and a combination of both.
  • Subject: Please get in contact with your Wi-Fi Administrator to find the proper value for the certificate Subject Name. 
  • Variables: When distributing individual client certificates, the certificates values for Issued to, Subject, Principal Name, RFC822 Name are influenced by the following:
    • Issued to, Subject and Principal Name are taken from the added content in the Subject field. If the Subject field is not provided in the profile, the {UserCert} variable is used as a fallback
    • The {UserCert} variable is reflected by the Certificate Username Field from the LDAP attributes configuration and for local users by the Certificate Username field.
    • RFC822 Name is taken from the {DeviceEmail} variable, which is reflecting the Email Address for local and Device Email Field for LDAP users.  
    • The {DeviceEmail} is reflected by the Device Email Field from the LDAP attributes configuration and for local users by the provided Email field.
  • iPhone
  • iPad
  • iPod
  • Android
  • Samsung Knox
  • macOS 
  • Apple TV
Upload Enterprise Certificate
  • Description: If you want to use one certificate for all client authentications, you can upload with the Choose File button the corresponding certificate containing the public and private key. 
  • Requirement: To use this certificate-based authentication method, you need to select the Enterprise Certificate Type.  
  • iPhone
  • iPad
  • iPod
  • Android
  • Samsung Knox
  • macOS 
  • Apple TV
TLS Minimum Version
  • Available for: TLS, TTLS, PEAP, and EAP-FAST.
  • Options: None, 1.0, 1.1, 1.2, 1.3
  • Description: Defines the minimum TLS version for the EAP authentication. If None is selected, the minimum TLS version defaults to 1.0.
  • iPhone
  • iPad
  • iPod
TLS Maximum Version
  • Available for: TLS, TTLS, PEAP, and EAP-FAST.
  • Options: None, 1.0, 1.1, 1.2, 1.3
  • Description: Defines the maximum TLS version for the EAP authentication. If None is selected, the maximum TLS version defaults to 1.2.
  • iPhone
  • iPad
  • iPod
Extended options for certificate-based authentication  
Populate into Active Directory
  • Options: Enabled or Disabled
  • Description: If this option is enabled, a certificate will be requested from the Certification Authority and distributed to devices for the authentication process. In addition, the certificate will be added to the individual user object in the Active Directory. Please refer to Certification Authority Integration and locate the guides named as Assign Certificates to Active Directory User Objects
  • Additional Configuration items: Certificate Template Name, Requester Name LDAP Attribute, and Agent Certificate
  • iPhone
  • iPad
  • iPod
  • Android
  • Samsung Knox
  • macOS 
  • Apple TV
Use Computer Object 
  • Available for: iPhone and iPad
  • Description: Silverback has the ability to create Computer Objects in your Active Directory during the Enrollment on your behalf. If you want to add distributed Wi-Fi certificates to the created computer object in your Active Directory based on computer certificate templates. To achieve the adding of certificates to computer objects a couple of steps needs to be done. 
  • iPhone
  • iPad
Certificate Template Name
  • Description: For the extended options for certificate-based authentication, the Certificate Template(s) requires a different configuration (e.g. with enabled Publish certificate in Active Directory option) than the template for the basic option for the certificate-based authentication. You need to explicitly add here the certificate template name created during the Certification Authority Integration for the Assign Certificates to Active Directory User Objects or Create Computer Objects and Assign Certificates methods. 
  • iPhone
  • iPad
  • iPod
  • Android
  • Samsung Knox
  • macOS 
  • Apple TV
Requester Name LDAP Attribute
  • Description: As part of the assigning certificates to Active Directory User Objects, this field contains the Requester Name that will be captured from the Active Directory to match the requester with the user object in the directory. Here you need to enter always SamAccountName
  • iPhone
  • iPad
  • iPod
  • Android
  • Samsung Knox
  • macOS 
  • Apple TV
Agent Certificate
  • Description: For the Assign Certificates to Active Directory User Objects or Create Computer Objects and Assign Certificates methods, the enrollment agent creates and signs the initial certificate requests. Then the enrollment agent submits the signed request to the CA and the CA returns the issued certificate to the enrollment agent, who then provides the issued certificate to Silverback, which then will distribute the certificate to the device. During the setup for both methods, you will create and import the certificate, which you need to select here. 
  • iPhone
  • iPad
  • iPod
  • Android
  • Samsung Knox
  • macOS 
  • Apple TV

Trust

Next to the configuration of the Authentication options, the Trust section allows you to create the certificate chain of trust to ensure that both the client and RADIUS server are legitimate. You can configure here accepted server certificate common names or upload certificates for the chain of trust. As the settings differ between platforms, the configuration is divided into two sections. 

For Android Enterprise Devices 

Option Description
Trust Configuration
  • Options: None, CA Certificate, Trust on First Use
  • Description: Here you can define your chain of trust configuration. If CA Certificate is selected, additional options will be shown to upload and handle your trusted certificates and to add the domain domain suffix match. For devices running Android 13 or higher, Android supports the Trust on First Use authentication approach (RFC7435), which lets users trust an enterprise (EAP) network by installing the root CA used by the server and setting its domain name in a saved network. It allows the device to obtain an unauthenticated public key when a user first connects to an enterprise network and retain the key for subsequent connections.
Upload Certificate
  • Options: Choose File to upload
  • Description: Here you can upload your trusted certificates (e.g. *.pem or *.cer files) to ensure the trusted chain for the connection.
  • Requirement: Trust Configuration is set to CA Certificate
Certificates
  • Description: This part displays the list of uploaded trust certificates.
  • Handling: Use the - button to remove certificates
  • Requirement: Trust Configuration is set to CA Certificate
Domain
  • Example: imagoverum.com
  • Description: This field is required since Android 11 QPR1 and sets the domain for the server certification validation that is required in order to successfully connect. The provided value will include a domain name (FQDN or suffix-only) that is used as a suffix match requirement for dNSName element(s) of the certificate presented by the authentication server. If a matching dNSName is found, this constraint is met. If no dNSName values are present, this constraint is matched against SubjectName CN using same suffix match comparison.
  • Requirement: Trust Configuration is set to CA Certificate

For Apple Devices

Option Description
Allow Trust Exceptions
  • Options: Enabled or Disabled
  • Description: If enabled, it allows a dynamic trust decision by the user. The dynamic trust is the certificate dialogue that appears when the system doesn’t trust a certificate. If disabled, the authentication fails if the system doesn’t already trust the certificate. 

As of iOS 8, Apple no longer supports this key.

Server
  • Examples:  wpa.imagoverum.com or mywifiserver
  • Description: This setting contains the list of accepted server certificate common names. If a server presents a certificate that isn't in this list, the system doesn’t trust it. If you specify your accepted server certificate common names, the system disables dynamic trust (the certificate dialog) unless you also enable Allow Trust Exceptions. 
  • Handling: Use the + and - buttons, to add or remove accepted server certificate common names
  • Additional Information: If necessary, use wildcards to specify the name, such as wpa.*.imagoverum.com
Upload Certificate
  • Options: Choose File to upload
  • Description: Here you can upload your trusted certificates (e.g. *.pem or *.cer files) to ensure the trusted chain for the connection. 
Certificates
  • Description: This part displays the list of uploaded trust certificates.
  • Handling: Use the - button to remove certificates

Proxy 

If you have a proxy server in your organization for having a gateway between you and the internet, you can configure the following Proxy options. As the settings differ between platforms, the configuration is divided into two sections. 

For Android Enterprise Devices

Option Description
Enable Proxy
  • Description: Enables a group of policies to specify the global proxy setting using a specified server host and port.
Server
  • Example: 10.0.0.22
  • Description: Enter the proxy server information in this field.
Port
  • Example: 8080
  • Description: Enter the port number of the proxy server host in this field.
Exclusion List
  • Description: Specify any Hosts (IP Addresses, URLs, Domains) you want to bypass the proxy. Enter the values as a comma separated list, for example, “10.0.1.50, 10.0.1.55,*.imagoverum.com”. 

For Apple Devices

Option Description
Proxy Type
  • Options: None, Manual, Auto
  • Description: Select here your proxy type. If you select manual as proxy type, you need to provide the proxy server address, including its port and optionally a username and password into the proxy server. If you select Auto as proxy proxy type, you can enter a proxy auto-configuration (PAC) URL.
Server
  • Example: 10.0.0.22
  • Description: Enter here the proxy server's network address.
Port
  • Example: 8080
  • Description: Enter here the proxy server's port number. Supported values are 0-65535
Individual Usernames
  • Options: Enabled Individual Usernames or predefined dedicated proxy users
  • Description: In this section, you can define the username used to authenticate to the proxy server. You can either enable the Individual Usernames option or add a dedicated proxy user.  If Individual Usernames is enabled, the username for the authentication process will be prefilled with the system variable {UserWifiProxy} .
  • Variable: The {UserWifiProxy} variable is captured during the enrollment and taken from the following fields:   
    • For local users, the Username is used
    • For LDAP Users, the configured Wi-Fi Proxy Username Field attribute is taken from the LDAP configuration
Username
  • Example: Maria
  • Description: If Individual Usernames is not enabled, enter here a static username that will be used for the authentication process. 
Individual Passwords
  • Options: Enabled Individual Password or predefined dedicated proxy user password
  • Description: In this section, you can define the password used to authenticate to the proxy server. You can either enable the Individual Passwords option or add a dedicated proxy user password. If Individual Passwords is enabled, the password for the authentication process will be prefilled with the system variable {UserPassword} .
  • Variable: To use the Use User Password option, it is required to enable Password Caching 
Password
  • Example: Pa$$w0rd
  • Description: If Individual Passwords is not enabled, enter here a static password that will be used for the authentication process. 
PAC URL
Allow Direct Connection if PAC is Unreachable
  • Options: Enabled or Disabled
  • Description: If the Proxy Type is set to Auto, you can use this configuration to allow devices connecting directly to the destination if the PAC file is unreachable.