Configuring Single-SSID BYOD Policy with ISE (Internal CA)

As Bring Your Own Device (BYOD) trends continue to grow, organizations face the challenge of securing diverse personal devices accessing their corporate networks. Identity Services Engine (ISE) offers a comprehensive solution for managing and securing BYOD environments, allowing users to connect their devices safely while maintaining stringent access control policies. Configuring ISE for BYOD enhances network security and improves the user experience by automating device onboarding and applying dynamic policies. In this post, I will guide you through configuring ISE policies for BYOD, ensuring that personal devices can access your network securely and seamlessly.

In this post, I will walk through the configuration of the BYOD policy and show you how to use the internal ISE Certificate Authority for the BYOD certificates.

We will start by walking through some parts of the ISE Certificate Authority so you can familiarize yourself.

Navigate to Administration>System>Certificates>Certificate Authority>Certificate Authority Certificates.

Here, you can see the Certificate Authority Certificates already pre-configured, so you don’t have to do anything.

If you navigate to Certificate Templates from this page, you will also notice that ISE already has a pre-created ISE Certificate Template created for EAP.

Navigate to Administration>Identity Management>External Identity Sources.

You will find a Certificate Authentication Profile already pre-created from ISE’s Internal CA.

As you can see, ISE already has many of the pieces pre-configured for us if we are using the internal ISE Certificate Authority.

I’ll walk through some of the different options you can configure in this policy, but overall, I will keep the policy pretty simple.

We will start by editing some default identity source sequences. To do so, navigate to Administration>Identity Management>Identity Source Sequences.

Click on the MyDevices_Portal_Sequences name.

Add your Active Directory join point(s) or All_AD_Join_Points to the Selected column. Then, make sure it is on the top of the list.

Click Save.

After saving the MyDevices_Portal_Sequence, click on the Guest_Portal_Sequence in the Identity Source Sequences menu.

Add your Active Directory join point(s) or All_AD_Join_Points to the Selected column. Then, make sure it is on the top of the list.

Click Save.

Next, we shall modify the My Devices portal.

Navigate to Administration>Device Portal Management>My Devices.

Click on My Devices Portal (default).

Note: If you don’t want to use the default portal, you can always copy it or create a new one.

Under Portal Settings, make sure that the MyDevices_Portal_Sequence is selected for the Authentication Method.

That’s the only thing I’m going to change for this portal, but I’d like to point out some different things you can change depending on your environment.

Portal Settings –

• HTTPS port: The default is 8443, but you can change it to whatever you want for this portal. Just be sure to update any ACLs or firewalls to open these ports.
• Allowed interfaces—This is pretty self-explanatory. I usually keep this at default, but if you have an ISE appliance and a large ISE deployment, you might want to direct this traffic to a different interface.
• Certificate group tag – This is a unique identifier that helps ISE identify the certificate that has to be used when communicating with this portal.
• Fully qualified domain name (FQDN) – FQDN for this portal. You need to make sure that this matches with DNS if you fill this option in
• Endpoint identity group – This is the logical group that the endpoints will be placed in after being registered.
• Purge endpoints in this identity group – How many days this endpoint will remain in this identity group before being timed out
• Authentication Method – This is the identity source sequence that will be used
• Idle timeout – This is the timeout for the portal
• Display language – Pretty self-explanatory

Login Page Settings –

• Maximum failed login attempts before rate limiting – Default is 5
• Time between login attempts when rate limiting – Default is 2 minutes
• Include an AUP – You can check this box if you’d like to include it as a link or on the page and you can also require acceptance of the AUP.

Acceptance Use Policy (AUP) Page Settings –

• Here, you can choose to include an AUP page, which requires scrolling to the end of the AUP, and specify to show the AUP on the first login, every login, or during a certain number of days starting at the first login.

Post-Login Banner Page Settings –

• This is where you can specify to include a post-login banner page

Employee Change Password Settings –

• This is where you can specify that internal users can change their passwords.

Support Information Page Settings –

• You can include specific fields for support information, such as the MAC address, IP address, policy server, etc, and even display empty fields.

Click on the Portal Page Customization tab at the top of the screen.

On this tab, you can customize the My Devices Portal’s look and content for your users. After you have completed any customizations, you can preview it here as well.

Click Save once completed.

Now that we have finished modifying the MyDevices portal, I will create a native supplicant profile.

Navigate to Policy>Policy Elements>Results>Client Provisioning>Resources.

Click Add>Native Supplicant Profile.

This is where we will configure the template for the native supplicant. These settings will be configured on the endpoint as it is onboarded for BYOD.

We will start with creating one for mobile devices.

I’ll name the Native Supplicant Profile MOBILE-TLS. 

I will change the operating system to All.

Under Wireless Profiles, I will click Add

Then I will configure the following:

• SSID Name – SecurityLabCorp
• Security – WPA2 Enterprise
• Allowed Protocol- TLS
• Certificate Template – EAP_Authentication_Certificate_Template

Click Save.

The final result will look the below screenshot.

Click Submit.

Next, we will create a Native Supplicant Profile for macOS.

Click Add>Native Supplicant Profile.

I’ll name the Native Supplicant Profile MACOS-TLS. 

I will change the operating system to Mac OSX.

Under Wireless Profiles, I will click Add

Then, I will configure the following:

• SSID Name – SecurityLabCorp
• Security – WPA2 Enterprise
• Allowed Protocol- TLS
• Certificate Template – EAP_Authentication_Certificate_Template

Click Save.

If you are doing wired access for BYOD devices, check the box next to Wired Profile.

Choose TLS for the Allowed Protocol.

Select your EAP_Authentication_Certificate_Template Certificate Template from the dropdown.

The screenshot below is what your final configuration should look like.

Click Submit.

Next, we will create a Native Supplicant Profile for macOS.

Click Add>Native Supplicant Profile.

I’ll name the Native Supplicant Profile WIN-TLS. 

I will change the operating system to Windows All.

Under Wireless Profiles, I will click Add

Then, I will configure the following:

• SSID Name – SecurityLabCorp
• Security – WPA2 Enterprise
• Allowed Protocol- TLS
• Certificate Template – EAP_Authentication_Certificate_Template

Click Save.

If you are doing wired access for BYOD devices, check the box next to Wired Profile.

Choose TLS for the Allowed Protocol.

Select your BYOD Certificate Template from the dropdown.

The screenshot below is what your final configuration should look like.

Click Submit.

We should now see the following Native Supplicant Profiles configured for use in a Client Provisioning Policy.

Next, we will configure the Client Provisioning Policy.

This policy tells ISE how to configure different types of endpoints that connect to the network. This policy is primarily used for BYOD and posture.

Navigate to Policy>Client Provisioning. 

Some default Client Provisioning Policy rules should already exist, but I will delete them all for this post and start from scratch.

For the rule name, I will name the device IOS-Device.

I will leave the identity group at Any.

However, you can change this to any identity group if you have a specific subset of profile devices you would like to add to it.

For the Operating System, choose Apple iOS All.

We will not choose anything for Other Conditions.

However, if you were to configure this, you have several conditions that you can to this group here including the following:

• Active Directory group
• WLAN-id
• Certificate details
• VPN Tunnel Group Name
• Network Device Group
• SSID
• Network Access Conditions
• EAP Type
• EAP Tunnel
• And so much more…

For the Results, we will pick the MOBILE-TLS Native Supplicant Profile that we previously created.

The final rule should look like this.

Click the downward arrow next to the Edit and choose Insert new policy below.

Create the following rules:

• Rule Name: Android-Device
• Operating System: Android
• Result>Native Supplicant Configuration: MOBILE-TLS

• Rule Name: Windows-Device
• Operating System: Windows All
• Result>Native Supplicant Configuration: WinSPWizard and WIN-TLS

• Rule Name: MacOS-Device
• Operating System: Mac OSX
• Result>Native Supplicant Configuration: MacOSXSPWizard and MACOS-TLS

The final rules should appear as below.

Click Save. 

Next, I will create some ACLs in the wireless controller specifically for our BYOD policies. I’m going to create ACLs for Web Redirect and Blackhole. Androids are a special case in which they must reach the Google Marketplace during onboarding. Android devices require it to be downloaded from the Google Marketplace. Part of the reason is that logging in for BYOD access already requires AD credentials.

In the Wireless Controller, navigate to Configuration>Security>ACL.

We are going to name this  ACL as BYOD_Flow. 

Add the following rules

Click Add again.

We will create an ACL for devices that are lost or need to have their traffic blackholed.

We are going to name this  ACL as BLACKHOLE. 

Add the following rules

Next, we will create URL filters.

Navigate to Configuration>Security>URL Filters.

We will start by creating a URL filter for the BYOD flow. For Android devices, they will need to access the Google Play Store during onboarding so we will create a URL filter that will allow this.

Click the Add button.

We are going to name this rule BYOD-URL-Filter.

From the Type dropdown, choose PRE-AUTH.

Move the Action slider to Permit.

Add the following URLs in the URL field:

*.google.com
accounts.youtube.com
gstatic.com
*.googleapis.com
*.appspot.com
ggpht.com
gvt1.com
market.android.com
android.pool.ntp.org
*.googleusercontent.com
*.google-analytics.com

Click the Apply to Device button.

Navigating back to ISE, we will create the authorization profiles for use in our ISE policy.

Navigate to Policy>Policy Elements>Results>Authorization>Authorization Profiles.

Click Add.

We are going to name this Authorization Profile as Wireless_Blackhole.

Under the Advanced Attributes Settings, create two settings:

Cisco:cisco-av-pair = url-redirect=https://ip:port/blockedportal/gateway?portal=24adc791-7fb9-4b3f-aaf9-080680804fee

Cisco:cisco-av-pair = url-redirect-acl=BLACKHOLE

Click Submit.

If you plan on using BYOD for wired, I would recommend making the following ACL on the switches:

ip access-list extended BLACKHOLE
remark Deny DNS from being redirected to ISE
deny udp any any eq 53
remark Redirect all applicable traffic to ISE
permit tcp any any eq 80
permit tcp any any eq 443
remark All other traffic will be denied from redirection

Next, we will create the wired Blackhole Authorization Profile.

Click Add.

We are going to name this Authorization Profile as Wired_Blackhole.

Under the Advanced Attributes Settings, create two settings:

Cisco:cisco-av-pair = url-redirect=https://ip:port/blockedportal/gateway?portal=24adc791-7fb9-4b3f-aaf9-080680804fee

Cisco:cisco-av-pair = url-redirect-acl=BLACKHOLE

Click Submit.

Note: For extra security, you can also create a blackhole VLAN and add it to this authorization profile

Click Add again.

We will create a new Authorization Profile named BYOD-SUPP

Check the box for Web Redirection (CWA, MDM, NSP, CPP) and choose Client Provisioning (Posture) from the drop-down.

For the ACL, type in BYOD_Flow.

Click Submit.

Now we will piece this all together by configuring the policy set.

Navigate to Policy>Policy Set.

Click on the + to create a new policy set above the default policy set.

We will name this policy set as Wireless Dot1x.

Click on the + under conditions to bring up the Conditions Studio.

In the Conditions Studio, drag the Wireless_802.1x condition from the Library into the Editor.

Click Use.

Note: You may also want to add an SSID in this condition to segment policy sets by specific SSID. If you want to do that, you can also add the following condition:

Radius:Called-Station-ID CONTAINS SSID

However, I am not adding the SSID in this demo.

For the Allowed Protocols, choose Default Network Access from the drop-down.

Click Save to save the new policy set.

Expand our new policy’s Authentication and Authorization Policy by clicking the > next to the policy set.

If you plan on using wireless for corporate-owned machines, you could always add an authentication rule above the default rule specifying that anything using PEAP-EAP-TLS or TEAP-EAP-TLS will use your Cert_AD_ISS Identity Source Sequence.

Name the rule Corporate PEAP-EAP-TLS.

Click the + under Conditions to pull up the Conditions Studio.

For the conditions, choose the following conditions:

Network Access-EapTunnel equals PEAP

Network Access-EapAuthentication equals EAP-TLS

Click Use.

Change the result of the rule to Cert_AD_ISS for the identity store.

Expand Authorization Policy – Local Exceptions. 

Click the + to add a new rule.

Name the new rule Wireless Blackhole.

Click + to pull up the Conditions Studio

Add the following condition:

IdentityGroup:Name EQUALS Endpoint Identity Groups:Blocked List

Click Use.

Choose your Wireless_Blackhole Authorization Profile from the Results.

Scroll down to your Authorization Policy.

We will start by creating a rule for the corporate employee devices.

Click the + to create a new rule above the default rule.

We will first start by creating a rule for just non-BYOD corporate-owned devices.

Name the rule Employee Access.

Click the + under conditions to pull up the Conditions Studio.

Choose the following conditions:

Network Access:EapTunnel EQUALS PEAP

Network Access:EapAuthentication EQUALS EAP-TLS

AD-Domain:ExternalGroups EQUALS AD-Group-For-Employees

Click Use.

Under the results for the rule, choose whatever authorization profile you use for your employees on corporate-owned computers.

We did not configure that for this post, but the below screenshot is an example.

Click on the gear next to the rule. Choose the Insert new row below option.

We will name this rule BYOD Registered.

Click + to add conditions.

Choose the following conditions in the Conditions Studio:

Endpoints:BYODRegistration EQUALS Yes

Network Access:EapAuthentication EQUALS EAP-TLS

Click Use.

From the Results drop-down, choose an authorization profile granting the user the appropriate level of access after registering as a BYOD user. This authorization profile should be the level of access you want a fully registered BYOD device to have. For some organizations, that might be full internal network access. For others, it might be a reduced network surface. We did not create this authorization profile as part of this exercise since it can vary depending on the organization, but if you are deploying BYOD for the first time, I would urge you to think about what level of internal network access (if any) you would grant your registered devices.

The last thing I will do is change the default result for this policy from DenyAccess to BYOD-SUPP.

That will redirect all devices that authenticate with 802.1x to the wireless that are NOT corporate-owned devices or BYOD-registered to the client-provisioning portal to onboard them.

Click Save to save this policy set.

After configuring ISE and the wireless controller, you can test out BYOD.

Below is the sample user workflow as a user’s Android device is onboarded for BYOD.

Step 1 – Redirect and AUP

Step 2 – Adding Device Information

Step 3 – Prompt and link to install the Cisco Network Assistant from Google Marketplace

Step 4 – Installation of Cisco Network Assistant

Step 5 – Network Setup Assistant downloads and installs the certificate from ISE

Step 6 – Connecting to the Network

From the user perspective, the flow is almost identical except with Apple, the supplicant configuration is native to Apple iOS so there is no need to download the Network Setup wizard. You will get to Step 3 and this the flow from there in Apple iOS.

One note, I am using the default portal in ISE for BYOD. If you would like to customize it, you may navigate to Administration>Device Portal Management>BYOD to customize this portal.

Alternatively, you may use the online ISE portal builder by clicking here and creating a portal you can upload in minutes. If you want to use the free ISE Portal Builder, navigate to this page.