Guest, internal and hybrid wireless access solution using ISE

[stefan11]

I have three major categories of wireless access "allowance" I am contemplating deploying:

1. "true" guest (CWA + sponsor) => guest SSID and guest DMZ (Internet only access)

2. employee BYOD (trust the employee based on AD user membership) - different SSID, in a different DMZ, which allows Internet access similar to guest, but may also allow access to some internal NAT-ed resources

3. regular internal access network SSID (AD users + certs on devices, etc.)

Here is my Q: assuming a foreign + anchor WLC type of deployment, can I have a set of PSNs in the guest DMZ (completely - all interfaces), to which I redirect "true" guest connections for guest portal and CWA (scenario 1, above), while having the BYOD scenario (#2, above) somehow directing to the internal PSNs (instead of the guest DMZ ones), as that would be allowed to access AD, internally, verify user's credentials, and accommodate an ACL to put the client into the BYOD DMZ? All client connections will start on the foreign WLC, of course.

[Jason Kunst · Accepted solution]

Yes

You can setup each portal (guest, BYOD) with different interfaces and even port numbers. Your authorization rule would return the appropriate portal to the controller depending on the SSID that is connected to.

Guest SSID would match authorization and return guest portal to interface running in DMZ

Same for BYOD

[stefan11]

That was fast :-) Thank you! Here is a little more, which I may have missed in my original Q (pointers to data flow diagrams would help, if you know of such): I can only allow the internal PSNs to talk to AD, but if ALL guests (true, and BYOD) need to be anchored in the DMZ WLCs, then how am I going to force the AD validation internally, vs true guest staying in the DMZ, and getting the portal from there?

Now that I read the above, it may not make sense :-), so I'll try differently:

- SSIDs *guest* and *BYOD* both broadcast

- I bring in a device and connect to *guest* -> go through foreign WLC -> ... -> guest portal coming from the DMZ PSNs ... -> anchored in the DMZ and going to the Inernet. Once my sponsored access expires, access stops

- I bring in a device, and I am an AD user, so I connect to *BYOD* -> what is the path from here so, while still having to be anchored to the DMZ WLC, I have the internal PSNs check my AD membership, instead of being redirected to the DMZ PSNs portal? My access, once successful, should live for the duration of my AD credentials validity

Is it even possible, as described above? Thx again!

[Jason Kunst]

I can only allow the internal PSNs to talk to AD, but if ALL guests (true, and BYOD) need to be anchored in the DMZ WLCs, then how am I going to force the AD validation internally, vs true guest staying in the DMZ, and getting the portal from there?

JAK - BY BYOD I assume you're talking about ISE BYOD with supplicant and certificate provisioning and onboard?

if they are guests why do they need access to AD? guest accounts live in the guest database.

Now that I read the above, it may not make sense :-), so I'll try differently:

- SSIDs *guest* and *BYOD* both broadcast

- I bring in a device and connect to *guest* -> go through foreign WLC -> ... -> guest portal coming from the DMZ PSNs ... -> anchored in the DMZ and going to the Inernet. Once my sponsored access expires, access stops

JAK - yes, make sure guest portal is running on its own port and interfaces if needed

- I bring in a device, and I am an AD user, so I connect to *BYOD* -> what is the path from here so, while still having to be anchored to the DMZ WLC, I have the internal PSNs check my AD membership, instead of being redirected to the DMZ PSNs portal? My access, once successful, should live for the duration of my AD credentials validity

JAK - if your BYOD employees are connecting thru DMZ then you're correct that PSN would need to talk to AD but why? they are trusted users connect using Single SSID flow PEAP and once onboarded use EAP-TLS. Either you move BYOD internally since they are employees

otherwise you will need to create special accounts in the guest database for them to use a portal in the DMZ if really concerned about this

[paul]

A quick thought on this.  I like to minimize SSIDs wherever possible.  I usually would do what you describe with two SSIDs for the company.

SSID #1 is the true Guest SSID.  If you want the guest PSNs to be dedicated PSNs sitting in the DMZ or using secondary NICs on the internal PSNs that is up to you.  None of this would require AD connectivity.

SSID #2 is the secure corporate SSID that would allow 3 types of connections:

1. Connections from corporate domain joined devices.  Usually I do PEAP computer auth to ensure this, but however you are doing ensuring corporate domain joined devices is up to you.
2. Corporate mobile devices- you can either do an MDM integration, which I rarely do, or trust the certificate issued by the MDM to the mobile devices (could be MDM asking as CA or acting as SCEP proxy to internal customer CA).  The second option is very appealing to the customer as it doesn't consume an APEX license.
3. Employee BYOD- users attaches to the SSID with their AD user credentials and then on the backside ISE signals the WLC to move them to the Employee BYOD interface (or guest wireless interface).  Very employee friendly method for giving employees Internet access on their personal device.

[stefan11]

Thank you for the follow-ups.

More comments: guest connections (via "true" or "BYOD") should not land on the internal network => I need to put them in the DMZs IP space, because of security concerns. Creating other subnets/VLANs/routes, in the internal network, to then only allow Internet access for the BYOD, seems more difficult compared to placing them straight into a guest DMZ, already controlled to be Internet only. The only difference between "true guest" and "BYOD" (maybe I am using a different terminology than the Cisco one??) should consist in the fact that the BYOD should rely on access dependent on the user's membership in AD, w/out requiring a sponsor intervention, and provide access for as long as their AD account is valid (some checking of PSN, against AD, in the backend, would be desired, either continuous, upon every time the BYOD device connects, or at set intervals), whereas the "true guest" allowance will be dictated by the duration defined by the sponsors.

[stefan11]

EDIT: looks like my definition of BYOD is confusing, as I do not mean it in the sense of Cisco! I am not planning to onboard employee devices. Just to give them a more lenient Internet access, w/out the constraints of time and sponsor bound requirements - guest access for as long as they can prove AD membership.

[Jason Kunst]

OK yes BYOD has 2 meanings, traditional sense is i just want straight internet access for my employees personal devices.  with ISE BYOD means on boarding their supplicants and provisioning a certificate for more security.

What you're explaining you use AD for BYOD employee internet. You have 3 options

1. DMZ then AD creds are exposed

2. DMZ, have the users create their own accounts, self-sponsor themselves

3. Non DMZ with AD

[paul]

Just to follow on to Jason’s message. If you want to use AD credentials but not join your guest PSNs in the DMZ to the domain (I wouldn’t join them do the domain). You have a couple options assuming you are using an anchor controller:

1) Use a PEAP SSID that is sent to the anchor controller. Have the anchor controller use the internal PSNs to authenticate this SSID. The only thing you need to open up on the firewall is anchor controller to internal PSNs RADIUS.

2) Use an open SSID with a portal setup for the employees. Setup the portal to use RADIUS authentication to the internal PSNs as the authentication mechanism. In this case you would need to allow the guest PSNs to have RADIUS access to the internal PSNs.

Also, if your firewalls are FirePower you don’t necessarily need two different DMZs to separate guests and employees. You could use SGT tags applied to the session by ISE, communicated to FMC via pxGrid and sent to the FirePower firewalls to create simple SGT tag rules:

1) Guest tag allowed Internet only.

2) Employee tag allowed some internal application access plus Internet access.

Many options available both in ISE and at the WLC layer.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250