I'm attempting to set up a Dual-SSID flow on a test deployment of ISE. I initially tried a Single-SSID flow but ran into a chicken or the egg issue with Android and certificates (want to do a long private cert but then Android wants a public one for the initial PEAP connection and seems to be in the process of removing the "Do Not Validate" cert options).
I believe the Dual-SSID flow is working for Android now via signing in to a guest portal that only allows AD logins and then presents the BYOD pages to get the certificate onboarding done.
However, I'm running into issues with the iPad I'm testing and the CNA/mini browser.
I believe I have the ACLs set correctly on the 9800-CL.. the initial one is set up to trigger the redirect and then the second one should get switched to when it detects the Apple Mini Browser flow (deny ip any to 126.96.36.199 and then a permit ip any to any).
I found another solution that recommended using the ISE portal builder. I created a test portal, uploaded it to ISE, and set up the basic options. Testing this with my iPad gets stuck even earlier... I enter my credentials and then click Sign On and nothing happens. It never proceeds to the next page. ISE radius logs seem to show an active session with my username though.
I'm using ISE 3.1 with patch 5 currently and I've tried 15.7 and updating to 16.3 on my iPad.
Hi @ahollifield and thanks for the reply!
We're not using an MDM. My original goal was to provide some additional security options for true BYOD (so personally owned staff, faculty, and student devices). Currently we use PEAP/MsCHAPv2 with our main SSID but that presents several issues:
To solve these, I wanted to allow the SSID to also support EAP-TLS and give users an option to onboard their devices or choose to stick with PEAP and the associated password changes. Domain-joined university owned machines would be moved up to EAP-TLS. To prevent users from having to onboard or update their cert multiple times, I want to use a certificate we generated from our internal PKI and then issue certs to the client devices with lifespans of something like 5 years (for most students, this means just one onboarding per device during their time at the university).
I started looking at Single-SSID first but ran into the issues with Android not trusting the internal PKI certificate (as expected) but, unlike iOS, Mac, and Windows it doesn't even give the user the option to use it. On my Android phone, I can select "Do Not Validate" for the certificate and that works but I've read that it may be removed in the future (might already be removed for Pixel.. not sure).
My concern with CNA bypass is won't users have to try opening a page in Safari or something to get redirected at that point? We've done that in the past with a more traditional hotspot setup and the issue was that users think they're connected and try to use an app that doesn't redirect (Facebook or something) and then it just seems like the wifi doesn't work.
I'm considering writing instructions just to have the iOS users connect to the 802.1x SSID directly, sign in to PEAP, and then maybe give them a link to a BYOD portal so that they can choose which security option to use but I hate having to give divergent instructions for different device types.
Yes they would but that is the only option here; IIRC BYOD is not supported on the embedded browser.
Does it make sense from a security prospective to deploy certificates for an internal PKI to unmanaged devices though? Why not just use a guest flow for this?
I would use a public PKI but I've heard that isn't a great security practice either and I don't believe I can do a certificate from a public entity that is longer than a year anymore or that can itself sign certificates. I've put in a feature request with Cisco to allow for multiple EAP certs so that even a yearly public one can be offered on the PEAP authentication and then our internal one can be offered for EAP-TLS signing/negotiation.
Another reason for more security may be things such as Eduroam. We've talked about implementing this a few times already and the research I'm doing now on these non-production/trial ISE and WLC instances is helping me map this out. With our own SSID, or with Eduroam, PEAP is less recommended because of the security issues (I believe the same reason Microsoft wants to prevent you using it automatically with your credentials you signed into the machine with). EAP-TLS seems to be the preference.
I figured this out and wanted to post what I found.
First and most importantly, I did indeed have my redirect ACL incorrect on the WLC. The initial ACL to redirect to the Guest portal was fine, but the one designed to handle the Apple CNA browser post-login was backwards on the permit/deny. The 9800 is reversed from the older AireOS WLC (which is what the available instructions online show). I had remembered this previously but, when I was testing and it didn't work before, I made it match the instructions. Whatever the reason it wasn't working before has apparently been revolved as putting it back to the correct way for an IOS-XE WLC now works. I came to this conclusion when seeing traffic that should have been blocked/redirect for 188.8.131.52 hitting our firewall.
Apple CNA ACL for the 9800 is:
1 - Permit IP protocol from any to host 184.108.40.206
2 - Deny IP protocol from any to any
The above ACL solved the issue with the Cancel button never changing to Done. It now changes to Done almost immediately.
The next issue was, after it changes to Done and you click the link, it would prompt to open in Safari. Doing this then showed it trying to reach 192.0.2.123 with a session ID. Looking this up, I thought I could fix this by changing the Retry URL setting in ISE but nothing I did there would ever seem to impact it and the iPad continued to try to load that IP. Finally, I just added another line to the Apple CNA ACL to include that IP as a redirect. So the updated ACL now looks like:
1 - Permit IP protocol from any to host 220.127.116.11
2 - Permit IP protocol from any to host 192.0.2.123
3 - Deny IP protocol from any to any
This then worked to redirect the iPad Safari browser to resume the BYOD segment. The OS was incorrectly identified as Mac but I changed it to iPad, added a device name, and then was able to proceed through the certificate profile downloads/installs and then connect via EAP-TLS to the test 802.1x SSID.
Next I probably need to investigate session timeouts on this Onboarding SSID as I think it currently gives virtually full access after they authenticate in the guest portal and until the session expires or is terminated.
Out of curiosity, what is the trigger for that part (the 18.104.22.168 or the 192.0.2.1)? Is the Apple device pre-programmed as part of the CNA to reach out to these which triggers the redirect based on the ACL? I remember 22.214.171.124 used to be a default virtual IP for at least the AireOS controllers and that it was recommended to change that but I guess I'm a bit unclear on how the device knows to request it and, therefore, trigger the redirect ACL.
Also, is it beneficial to use the DHCP option 114 with this either side-by-side or a replacement?
In the redirect access-list
Lines 1 and 2 are to trigger web redirect when accessing the two destination IP addresses, and Line 3 is to not redirect the rest so permit the traffic through.
In our dCloud demo ISE Enterprise and Security, we have been using the combinations of a web-redirect ACL and a DACL even though DACL is only recently vetted officially with IOS-XE 17.10.1, such that a web-redirect ACL is only for redirect and a DACL is to use for what to allow. For example, consider the following:
A. Redirect-ACL ACL_WEBAUTH_REDIRECT
1 2 3
ip access-list extended ACL_WEBAUTH_REDIRECT 10 permit tcp any any eq www 40 deny icmp any any
Line 2 is to trigger URL redirect on any hit to HTTP (TCP/80) and Line 3 is to allow ICMP through for network ping tests.
B. Downloadable ACL ISE_PROVISION_ACCESS
1 2 3 4 5 6
permit udp any host 198.18.133.1 eq domain permit tcp any host 198.18.133.27 eq 8443 permit tcp any host 198.18.133.27 eq 8905 permit tcp any host 198.18.133.27 eq 8084 permit icmp any any deny ip any any
Line 1 is to allow DNS queries; Lines 2 ~ 4 are for the connections to ISE during provisioning phrase; Line 5 is for ICMP networking testing.
So, I am seeing where the Apple browser is getting redirect to CloudFlare (126.96.36.199). Sometimes it happens and sometimes not. I guest just depends on the version of the device. I know I can change that address (to 192.0.2.1) in the Guest Portal > Portal Page Customization > Apple Mini Browser page in the html code, is that the correct way to change that? I also added the address (192.0.2.1) to the ACL on the anchor WLC. What else needs to change for the devices to use that address to open the portal using the new 192.0.2.1? Do I need to add the address to the global Web Auth policy on the 9800 WLC anchor.