Those of you using cisco WLC - what are YOU doing for employee wireless

[LynK]

For those of you running cisco WLC, what are you using for associate wireless . Are you using a guest portal, just a PSK, 802.1X?

Reason I am asking is cisco's webpage portal sucks... and rarely works on anything that is not mobile (and also times out all of the time requiring users to re-authenticate).

802.1x is great in theory, if you force everyone to install the certs....

PSK in my opinion is not a secure or reliable method of security.

[deanwebb]

I'm seeing a range between 802.1X (best, most secure) and PEAP with an AD username/password (any device employee owns gets on wireless).

You want a secure, corporate-only wireless network, you have to lay down the law and go dot1x. You spin up the CA and you just do it.

Major NAC solutions will feature a customizable, high-functioning web portal for wireless networks. It's recommended primarily for guest registration, but some firms will use it also for corporate networks and PEAP logon methods. Again, though, dot1x is where it's at.

GPO will get the cert on the Windows boxes, MDM will provision to the corporate mobile devices, Casper will fix the Macs, and I'm sure there's a script somewhere to push certs to Linux boxes.

[wintermute000]

The default position in the market for employee wireless (vs straight up guest) appears to be PEAP to AD, internet only (maybe exception for citrix and other DMZ hosted services), turn on server certificate validation and its "good enough" as long as it only drops onto an internet only segment. Others go further and just say use the guest portal and give them permanent guest accounts (makes sense if you regard their devices as the same classification, not so much if you BYOD).

Not many clients have gone the whole dot1x hog with non-SOE, as that involves full guest onboarding NAC (i.e. full blown ISE/Forescout/Clearpass) and pushing certs etc. even with self-enrolment portals there's always minor OS/platform/device dependent niggles. Even clients with ISE/Clearpass etc. are often not bothering. The ones that do are typically going or allowing BYOD and then its usually accompanied by posture assessment etc.

Dot1x for SoE is totally different story. Push the certs via AD and MDM, standard solutions abound, its a standard build so none of the wild west issues you face with onboarding any old guest or BYOD device of indeterminate OS/platform. It works and its proven. I've seen a few working wired implementations now and its pretty awesome. Its actually at the heart of all the new SD-Access stuff (i.e. identity).


I'm fairly sure re: your timeout issues that they can be fixed, I haven't heard any general blanket complaints re: WLC guest portal.

[deanwebb]

It all comes down to your use cases... if the associates need to access the corporate network, it's a question of either providing them with corporate resources for that access or if they'll be allowed to use their personal or associate-issued devices. In regulated environments, you'll want them to have corporate resources unless you like failing audits.

In non-regulated environments, it's still a risk element to allow unmanaged devices on your network.

I usually see things in terms of corporate wireless and guest wireless, one or the other, no messing around with a middle level of access. I can compromise on that middle level if the outsider device is onboarded with an MDM.

[wintermute000]

I've not seen any large enterprise setups allow non-SOE onto corporate without full EAP-TLS which means MDM and device onboarding.
Typically its machine certs, enables WLAN before login, and also stops people manually importing the cert and CA trustchain onto a non-SOE device (correct me if I'm wrong?). Though I believe you can be uber-paranoid and require both machine AND user certs via EAP chaining which isn't supported in NPS and requires full blown identity/NAC (ISE/Clearpass/Forescout).

To be blunt I've not seen any large enterprise setups allow corporate WLAN on anything short of EAP-TLS.

Mid-market different story, plenty of PEAP to AD setups with zero device authentication, just username/pw. 

[deanwebb]

Correct, set it up so there's no cert export and certainly no export of private keys.

[wintermute000]

Can you issue a non-exportable user cert?

If so I know a few companies that need some security lessons. Stat......

[deanwebb]

Can you issue a non-exportable user cert?

If so I know a few companies that need some security lessons. Stat......

Yes you can. You can copy the cert from one device to the other, but without the private key, it's useless. GPO locks down the private keys and the corporation can be fairly certain that those certs aren't going anywhere. At that point, it's more effective for an attacker to look for an unsecured corporate device and use that for getting at corporate resources.

[LynK]

I was way over looking the idea of using just PEAP. Which does make the most sense (deployed a test this morning). Kind of funny actually because I deployed this like 2 years ago for a different corp, and I didn't even think of it. My mind has been fixed on .1x as of late.


yeah I do not care about EAP-TLS, as this is just for internet. I am not going through the hassle. Even if I did attempt to create a sandbox splash page to allow users to install then proceed to connection. It is just not worth my time.

Currently we are using web-auth and it works like garbage on anything non mobile (and honestly... it sucks for mobile too).

Not to mention... I would be hard-pressed to ever go with ISE in the future. Left a very bad taste in my mouth after we spent hundreds of thousands and the AAA was not working (in a previous thread on this forum). That coupled with 4.5 hour upgrades = no go for me (as well as other monotonous things)

[deanwebb]

Not to mention... I would be hard-pressed to ever go with ISE in the future. Left a very bad taste in my mouth after we spent hundreds of thousands and the AAA was not working (in a previous thread on this forum). That coupled with 4.5 hour upgrades = no go for me (as well as other monotonous things)

Hello, I work for $VENDOR where $VENDOR = {"ForeScout Technologies"}. Perhaps we can be of assistance?

[deanwebb]

I was way over looking the idea of using just PEAP. Which does make the most sense (deployed a test this morning). Kind of funny actually because I deployed this like 2 years ago for a different corp, and I didn't even think of it. My mind has been fixed on .1x as of late.


yeah I do not care about EAP-TLS, as this is just for internet. I am not going through the hassle. Even if I did attempt to create a sandbox splash page to allow users to install then proceed to connection. It is just not worth my time.

Currently we are using web-auth and it works like garbage on anything non mobile (and honestly... it sucks for mobile too).

Not to mention... I would be hard-pressed to ever go with ISE in the future. Left a very bad taste in my mouth after we spent hundreds of thousands and the AAA was not working (in a previous thread on this forum). That coupled with 4.5 hour upgrades = no go for me (as well as other monotonous things)

Now for the "But seriously, folks..." response.

If the wireless is for Internet-only, then you're talking about a guest network, plain and simple. BYOD devices can connect to it and then use the Internet access to VPN on in, if they need to. Pretty simple to put together, but you have to do a lot of complicated stuff before it's simple... let me explain...

Getting dot1x put together can be a trick and a half, but can be done. In the meantime, the guest network can be set up to admit everyone and put them on a MAR, so they don't have to authenticate with normal dot1x means. However, the devices also have a pre-connect ACL that only allows communications pretty much to the RADIUS server and a server (could be the same as the RADIUS server, if that box is also running a web server) that will have the registration page set up on it. User registers, submits form, and then is granted access. It could be from another employee approving it, or it can be self-approval with either a text or email sent to the device via the LTE network - or to an employee's device able to access that email account - that contains the password for the user.

Once the user submits an approved username/password, then the RADIUS server can send a Change of Authority (CoA) to the WLC that switches the device from the corporate wireless with an ACL to an SSID run by the foreign WLC in the DMZ and the device is guestin' away.

As an alternative, devices first connecting to the guest SSID face a DNS hijack for everything except "phone home" traffic to Google, Apple, and Microsoft, and the CA for the cert on the web server that all HTTP/HTTPS traffic gets pointed to... where, whaddya know, there's a web portal! Registered devices are then no longer subjected to the DNS hijack and are then allowed to actually go to web sites and stuff with all the other cool kids.

Of the two methods, I prefer the CoA, as there's less ability to circumvent it through either using raw IPs or experimental protocols like QUIC.

[wintermute000]

what's the security after the CoA handoff to the foreign WLC in the DMZ's SSID?
And is the WAP in this case directly CAPWAP to this foreign WLC or are you talking about guest anchoring?

Yeah this is typically the arrangement for EAP-TLS onboarding, are you suggesting doing just a little bit less and granting them immediate access after enrolling/authenticating? If so what is the EAP method utilised after the initial authentication and then CoA?

[deanwebb]

what's the security after the CoA handoff to the foreign WLC in the DMZ's SSID?
And is the WAP in this case directly CAPWAP to this foreign WLC or are you talking about guest anchoring?

Yeah this is typically the arrangement for EAP-TLS onboarding, are you suggesting doing just a little bit less and granting them immediate access after enrolling/authenticating? If so what is the EAP method utilised after the initial authentication and then CoA?

Once the CoA does the handoff, we're looking at a device that is permitted to be on that SSID as long as the authentication system permits it to be that way. It can still deauthenticate the device by sending further 802.1X commands to the WLC in the DMZ.

I admit I'm shakier on my Wireless terminology than my dot1x, so if I say this wrong, don't hire me as your wireless engineer. I want to say that the session goes to the foreign WLC after the CoA goes through, so if that's what you said with the CAPWAP business, that's what it is.

EAP method after auth and CoA is MAC-Bypass, but since it goes to a guest environment, most organizations accept the risk with that method.

[wintermute000]

Thanks for clarification esp re: its Mac-bypass - my real question is what is the encryption. I guess it still open?

[deanwebb]

Thanks for clarification esp re: its Mac-bypass - my real question is what is the encryption. I guess it still open?

My guess is that without a trusted cert or pre-shared password key, it's a NAK on the EAP-type and then it goes to MAC bypass... it's up to the registration page to offer up a proper HTTPS portal, although there are firms out there that opt for pure HTTP, because of ease of use.