Configure WiFi Profiles and Policies
Okta offers two different WiFi features, detailed below. You can implement only one of these features in an orgThe Okta container that represents a real-world organization.. The WiFi Policies feature is Generally AvailableGenerally Available features are available to all orgs automatically according to each customer's SKU. You don’t need to enable them in the console or contact Okta Support. (GA) to most orgs, but it is not available if the WiFi Profiles Early AccessEarly Access (EA) features are opt-in features that you can try out in your org by asking Okta Support to enable them. Additionally, the Features page in the Okta Admin Console (Settings > Features) allows Super Admins to enable and disable some EA features themselves. (EA) feature is enabled for your org. The features are located in different areas of the AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. console. To determine which WiFi feature your org implements, mouse over this screenshot:
Note: The Devices menu is available to orgs that implement Okta Mobility Management (OMMAn acronym for Okta Mobility Management. OMM enables you to manage your users' mobile devices, applications, and data. Your users enroll in the service and can then download and use managed apps from the Apps Store. Managed apps are typically work-related, such as Box or Expensify. As an administrator, you can remove managed apps and associated data from users' devices at any time. You can configure policies, such as data sharing controls, on any of your managed apps. See Configuring Okta Mobility Management for more information.).
This is an Early Access feature. To enable it, please contact Okta Support.
WiFi Profiles is Okta's latest WiFi feature. It allows you to create multiple WiFi profiles and assign them to OMM-enrolled mobile devices so that usersIn Okta literature, we generally refer to "users" as the people who serve as Okta administrators. When we refer to "end users" we are generally referring to the people who the administrators serve. That is, those who use Okta chiclets to access their apps, but have no administrative control. are no longer limited to just one WiFi profile per device. It also supports the WPA/WPA2 Enterprise protocol to enable the following:
- Username and password authentication with a RADIUS server (you are no longer limited to shared key authentication)
- The option to add one or more server certificates needed to establish a secure connection to the WiFi network
For important information about this feature, including limitations and workarounds, see Known Issues.
For details about the Generally Available WiFi Policies, see WiFi Policies.
- A directory service such as Active Directory (AD) or LDAP (other directory services may also work).
If you have integrated your AD or LDAP environment with Okta:
The latest version of the Okta AD or LDAP agentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations. must be installed on your designated domainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https). server(s).
Delegated Authentication must be enabled on all AD or LDAP instances.
RADIUS server that supports the PEAP/MSCHAPv2 authentication protocol (the current Okta RADIUS agent does not support this protocol)
The password that your users enter to sign in to Okta must be the same as the password they enter to log in to your network.
- CA Certificates (WPA/WPA2 Enterprise networks).
OMM enrolled iOS, OSX, and Android mobile devices
- Okta Mobile for Android verison 2.12 or later
- Any version of Okta Mobile for iOS
- Android devices must be configured with a passcode (assumes a WPA/WPA2 Enterprise security network).
- Go to Devices > WiFi.
- Click Add (or Edit) WiFi Network.
- Enter (or edit) information in the Add WiFi Network modal:
- Network SSID – Enter the name of the WiFi network.
- Description – Enter a description for this WiFi profile.
- Hidden – Select this option if you want to establish a WiFi profile for a hidden Network SSID.
- Auto join – Select this option If you want your OMM-enrolled users to join this network automatically. If multiple WiFi network profiles are configured for your org, auto join priority is given to the network with the strongest signal.
Note: The auto join option is not supported on Android devices.
Select the security type that has been configured for this Network SSID.
- None – This option provides no network security (not recommended).
- WEP or WPA/WPA2 Personal – These networks authenticate users via a pre-shared key. See the Shared key field under Network Authentication.
- WPA/WPA2 Enterprise – This network authenticates users via username and password credentials. See the corresponding fields under Network Authentication.
- Authentication protocol (currently supports PEAP-MSCHAPv2 only)
(WEP or WPA/WPA2 Personal networks only)
- Shared key – Enter the pre-shared key for this SSID.
(WPA/WPA2 Enterprise networks only)
- Username – Select the format that matches the network username format used in your environment to authenticate users. The generated username based on this format will be used to log on to the WiFi network.
For example, given a username firstname.lastname@example.org:
- Email — Okta user's email address. For example, email@example.com.
- AD Employee ID — The user's AD employee ID. For example, 223.
- AD SAM account name — For example, jdoe.
- AD SAM account name + domain — For example, firstname.lastname@example.org.
- AD user principal name — For example, email@example.com.
- AD user principal name prefix — For example, john.doe.
- Email prefix — For example, john.doe.
- Okta username — For example, firstname.lastname@example.org.
- Okta username prefix — For example, john.doe.
- Okta password – Users are authenticated via their Okta password and connected to the network automatically without the need to enter a password (except as detailed in Known Issues).
- Trusted server certificates – (Optional) Specify one or more certificates as needed to grant secure access to the WiFi network. If your WiFi network access is secured by two or more CAs or a chain of trust, click Add Another to add as many certificates as necessary. If editing a profile to add and delete certificates, see Known Issues.
Note: In order to be assigned a WiFi profile secured by a trusted server certificate, Android devices must be configured with a passcode. Otherwise, assignment of the WiFi profile will fail.
- Click Save.
- Assign the WiFi profile to People and GroupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups..
Applicable to all network security types
Password prompts — When users sign in to Okta Mobile, we cache their password for 10 minutes. If you assign WiFi profile(s) to users before the cache expires, users are not prompted to enter their password to complete the profile assignment. If you assign a WiFi profile after the cache has expired, users are prompted to enter a password to complete the assignment. iOS and Android device users are prompted for passwords at different times:
Apple allows us to complete WiFi profile assignment before the user enters their password. In such cases, iOS device users are prompted to enter their password when their device attempts to connect to the WiFi network.
Google requires the user's password before we can complete the profile assignment. If the cache has expired, Android users are prompted to enter their password at the time the profile is being assigned.
Auto join — The auto join option is not supported on Android devices.
Applicable to WPA/WPA2 enterprise networks
Android passcode is required — Android devices must be configured with a passcode in order to be assigned a WiFi profile secured by a trusted server certificate. Otherwise, WiFi profile assignment will fail.
Always enter the correct password — End usersIn Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using chiclets to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control. should take special care to enter their password correctly during WiFi network authentication. Okta's WiFi profile authentication process does not detect incorrect passwords immediately, but connection to the WiFi network will fail at some point. iOS users who enter an incorrect password are prompted to re-enter it when their device attempts to connect to the network; Android users who enter an incorrect password are not re-prompted in this case and connection to the network simply fails.
Certificate prompts — If you specify one or more certificates for a WiFi network, users are prompted to install every certificate on Android and Samsung SAFE devices. If you assign users of these devices more than one WiFi profile secured by multiple certificates, additional install prompts are repeated for each WiFi network.
Deleting certificates from devices — In WiFi profiles configured with the security type WPA/WPA2 Enterprise, whether or not deleting a certificate in Okta also deletes the certificate from devices depends on the device type:
- Native Android — Google does not support the ability for Okta to delete certificates from Native Android devices.
- Samsung SAFE — Deleting certificates from Okta does not delete certificates from Samsung SAFE devices running Okta Mobile version 2.14.0 or earlier. Okta is working toward removing this limitation for Samsung SAFE devices in the next release of Okta Mobile for Android.
- AfW — If you delete some but not all certificates from Okta, the certificates you delete in Okta are deleted from AfW devices. However, if you delete all installed certificates through Okta, none are deleted from AfW devices. Okta is working toward removing this limitation for AfW devices in the next release of Okta Mobile for Android.
Do not add and delete certificates in the same editing session — If you add and delete certificates in a single editing session and/or in the wrong order, the deletion task will succeed but the add task will fail. In this state, your end users will lose their connection to the WiFi network. If you need to edit a WiFi profile to add one or more certificates and delete one or more certificates, treat adding and deleting as separate operations and edit the profile in the following order:
- Click Edit to enter edit mode.
- Add the certificate(s) and then click Save.
- Click Edit again to re-enter edit mode.
- Delete the certificate(s) by clicking the X next to the certificate(s).
- Click Save.
Okta WiFi Policies is Okta's initial WiFi feature. It allows you to configure one or more WiFi policies and push them automatically to end users enrolled in Okta Mobility Management (OMM). This allows end users to join an established WiFi network without having to enter any security information.
WiFi policies are similar to sign-on policies. You can add, delete, and edit WiFi policies and their associated rules.
- Your can implement either WiFi Policies or WiFi Profiles, but you cannot implement both. The WiFi Policies feature is Generally Available (GA) to most orgs, but it is not available if the WiFi Profiles Early Access (EA) feature is enabled for your org. The features are located in different areas of the Admin console. To determine which WiFi feature your org implements, mouse over this screenshot:
- The shared key is currently unmasked.
- Authentication with user credentials is not supported.
- Certificate-based authentication is not supported.
- Connection to hidden networks is not supported on Android devices.
- The WiFi Policies feature supports only one WiFi policy on a device at one time. To support multiple WiFi profiles on a device, see Configure a WiFi profile.
Go to Security > Policies, then click the Wifi Config tab.
Click Add New Policy and enter the following information::
For new policies
Policy Name: Enter a unique name.
Policy Description: Enter a description.
Assign to groups: Type in the name of the group this policy applies to.
For all policies
SSID: Enter the WiFi network name.
Encryption Type: Enter one of: None, WPA/WP2, or WEP.
Shared Key: Enter the shared key (password) for this WiFi network.
Click Update, or Create Policy.
WiFi rules determine whether users can access a WiFi connection. For orgs in which a Default Policy is present (legacy orgs), WiFi Access is set to Disabled. For new WiFi policies, you need to create at least one active rule where access is enabled. The Default Rule cannot be edited.
- Either click the pencil icon to edit an existing rule (for the non-default policy only), or click Add Rule to create a new rule that gives users WiFi access.
- Use the Access is dropdown menu to specify that WiFi access is enabled.
- Click Update Rule or Create Rule.
- Once you have created a rule, select Status from the dropdown menu to Activate it.