Obscuring corporate credentials while implementing BYOD onboarding

[jcatanzaro9]

Wondering if there is some experience out there with something I'm looking to accomplish related to BYOD and the ever changing security/audit requirements we face in the enterprise.

Problem:  Corporate users currently connect to a 'Mobile' with direct PEAP authentication, subjecting their active directory credentials to interception (as noted during a recent security audit).  There is no business purpose for this network, it's purely to allow employees to use the wireless network instead of their cell data.  An internet only access policy would be plenty sufficient once a user is fully authenticated.  We are on ISE 2.3 with no immediate plans to go up to 2.4 just yet but it is a possibility in the future. 

The main priority for this revamp is to obscure those AD credentials in the initial logon process.  This puts me a little at odds with regard to how best to move forward.

Single SSID:  Certainly better from a UX perspective for people with Apple iOS devices, which naturally make up a significant portion of the landscape.  However, according to the prescriptive setup guide it looks like the user would still be passing AD credentials as part of the initial authentication/association to the network.  This provides the BYOD registration functionality we'd like, but doesn't really fix the problem of passing AD creds.

Dual SSID:  Benefit being the AD creds are passed through an SSL secured portal page, as opposed to directly from the device.  Downsides being the UX of manual SSID switching for apple iOS, unless that's been changed.  Also would require some significant groundwork to convert our existing single SSID setup to multiple.

So, best case scenario, does anyone know if it's possible to use a single SSID method while obscuring the corporate credentials in transit?  Or if not, any suggestions on how to handle such a situation?

[Jason Kunst]

How about this?

http://cs.co/ise-byod

look for Cisco ISE Sponsored BYOD<>

[jcatanzaro9]

That looks promising, but as an alternative is there any other way to accomplish this without the sponsor portion?

Personally I like the sponsored method, it puts responsibility and manager visibility on employees registering devices.  But I guess I do have one more curveball to throw in, two separate situations:

1.) employee-owned device, no access to corporate resources, only needs internet

2.) employee-owned device, managed by Microsoft Intune, need access to corporate exchange 365

As simple as different authorization policies because ISE will recognize them, or more complex?

[Jason Kunst]

---

@jcatanzaro9 wrote:

That looks promising, but as an alternative is there any other way to accomplish this without the sponsor portion?

JAK> not that i know of. otherwise you're requiring some sort of trusted credentials... You could have some internal way to do it perhaps using API and creating internal ISE accounts?

Personally I like the sponsored method, it puts responsibility and manager visibility on employees registering devices.  But I guess I do have one more curveball to throw in, two separate situations:

1.) employee-owned device, no access to corporate resources, only needs internet

2.) employee-owned device, managed by Microsoft Intune, need access to corporate exchange 365

JAK> you can do that right but then have to use AD creds? Or have them create their own guest credentials to use for internet only and then require them to onboard and redirect them to instructional page on how to do this?

As simple as different authorization policies because ISE will recognize them, or more complex?

---

[paul]

How are you handling your normal guest users?  Typically I use self-registering with sponsor approval.  If you have a login process for guests you can also allow employees to log into that portal using their AD credentials to give them Internet access.  For the employee mobile devices registered with Intune you can push certificates from your internal CA and do EAP-TLS authentication to the secure SSID and give them access to the Internet and Exchange.

[jcatanzaro9]

Guest users go through the standard captive portal w/ sponsored accounts.

The 'mobile' network was created specifically in response to the complaint from employees that they had to enter guest credentials every day for their personal devices, so they now enter AD creds as part of authentication/association direct to the WLAN, which of course opens those credentials up to interception for an attacker with the right tools.

Having them login to that portal is no problem since the guest portal is already there, if it's as simple as using the 'Guest' SSID as my second SSID in a dual setup, employee logs in with AD creds then gets pushed the certs and profiles that works too.  But wouldn't that still require manually switching SSID's for the Apple users?  Or has that been fixed more recently?

[paul]

You have the Guest SSID setup incorrectly if the complaint was the employees had to enter their credentials every day. Each guest gets mapped to a guest type. I usually setup:



Daily (1 day of access from first logon)

Weekly (1 week of access from first logon)

Custom (1 week default access from logon, but sponsor can allow up to 30/90/180 days of access depending on customer requirements)

Employee (the length of time allowed in the guest type doesn't matter)



Each guest type maps to its own endpoint identity group:



Guest-Daily-Devices

Guest-Weekly-Devices

Guest-Custom-Devices

Employee-BYOD-Devices



Then you decide how often you want each guest type to see the guest portal based on your endpoint purge policy:



Guest-Daily-Devices (purge every day)

Guest-Weekly-Devices (purge every day or maybe once a week)

Guest-Custom-Devices (purge every day, once a week, once a month, whatever customer a wants)

Employee-BYOD-Devices (purge at 30 days/90 days/match customer password change policy, whatever)



If employees can't handle putting in their AD credentials at a portal once every 30 or 90 days then it is time to get new employees imo.

[jcatanzaro9]

I should also qualify that this is very much an inherited network, and a lot of it is not how i would have set it up to begin with. The guest network used to use a daily password generated by a script running with ACS 5.6 when I first started. That password used to get printed and posted each day in every conference room. So yeah, we've come pretty far but have a ways to go still.

Matching password change probably wouldn't be an issue since they have to re-login to the Mobile SSID every time they change passwords anyway. Only problem being everyone's password cycle is different, so once a month is probably safe if we can get them to tolerate it. I understand what you're saying, but users complain and are given way too much slack when it comes to complying with stuff like this. I guess the only issue would be the user changing their AD password prior to their endpoint being purged, in which case they'd have to use the old password for the wireless access which isn't super clean.

Essentially, if I'm understanding you correctly, we would simply add a guest type for employees with whatever device limit and duration we see fit, map it to an internet only policy and acl, and adjust the guest authentication policy to look for the accounts in the AD identity store ahead of the rule that matches against sponsored guest accounts. Then we wouldn't have to worry about pushing certs or any of that, but it does accomplish the goal of obscuring the AD creds from the original 802.11 authentication/association process.

[jcatanzaro9]

And one further question, if we went this route would it be possible to allow them to stay on that single SSID setup but force the employees through the device onboarding for certs via the internal CA?

Meaning, employee joins Guest SSID, logs in with AD creds.  Gets forced through onboarding, receives certs and profiles from ISE, and then they're good to go until the cert expiry as defined within ISE? 

So we set the cert to 90 days, guaranteeing that the user will change their password sometime within those 90 days, but the cert will be valid even though the AD creds have changed.  Once cert expires, user has to re-authenticate in the same manner (portal, pull certs etc.)

Four times a year doesn't seem too much of a burden to me.  Add to that if they complain they're really complaining that we're making it inconvenient for them to browse social media on company time.

[Jason Kunst]

No you can’t have them use the guest portal and stay on same SSID as WLC doesn’t allow 802.1x and MAB on same SSID

Guest SSID is OPEN and BYOD secure is using EAP-TLS

Did you look at the http://cs.co/ise-byod page and the guide there?

[paul]

You guest rules should be based strictly off endpoint identity group assignments. Using my endpoint identity groups in my last response your guest authorization rules would like this:



If MAC address is in Guest-Daily-Devices then grant guest Internet access

If MAC address is in Guest-Weekly-Devices then grant guest Internet access

If MAC address is in Guest-Custom-Devices then grant guest Internet access

If MAC address is in Employee-BYOD-Devices then grant guest Internet access plus any additional access granted to Employees

Else redirect to guest portal



No AD lookups or anything. Just manage your purge policies accordingly. I think 30 day purge for Employee-BYOD-Devices is adequate. This is honestly a better setup then using PEAP. The problem with PEAP is when their AD password changes they forget their phone is using it and their account is getting locked.

[jcatanzaro9]

Ok, I think I get you now.  That's making more sense.

So, employee joins SSID, logs into portal for first time with AD creds.  Gets redirected to my devices portal, self registers device which places the MAC in the Employee-BYOD endpoint ID group.  Create purge policy to require re-registration periodically, accounting for password changes and the like, and then no worries about certs or anything else just strictly going off device MAC and endpoint validity.

How do the users then show up in the auth logs and on the WLC?  Does ISE somehow push the user's identity to the WLC or is it only the MAC that shows up?

Spot on about PEAP and account lockouts.  Happens all the time, getting rid of that would be a welcome bonus.

[Jason Kunst]

Send me a PM and lets chat

[paul]

No need to the mydevices portal. Look at your portal settings and you will see a setting for "Employees using this portal" and a spot to a assign a guest type. You create an employee guest type as I outlined and tie that guest type to an endpoint identity group.

[jcatanzaro9]

So this all makes sense to me, I've begun clicking around in my PAN and locating and building some of this out.

Question now is, how to I get it to where the employee logs into the portal with their AD creds, and is there a way to lock it down to a specific AD group for testing?

Am I configuring the authentication policy within my existing guest authentication policy set, or is there somewhere else to do this?