Networking-Forums.com

Professional Discussions => Wireless => Topic started by: deanwebb on June 24, 2019, 09:07:34 AM

Title: Hello Wireless, Meet NAC
Post by: deanwebb on June 24, 2019, 09:07:34 AM
Wireless admins are finding out more and more that a PSK for WPA2 access is *not* the way to pass a security audit for corporate network access. You gotta go with 802.1X.

Then they find out that they can still get dinged if they use PEAP, as that allows any device with a username/password combo that checks out to get on the network.

So they head over to EAP-TLS. And even though the 802.1X protocol does not *specify* that RADIUS must be used, it sure does drop a lot of hints about it... so you need a RADIUS back-end.

And that's when the NAC vendors' ears perk up, as they like to supply those RADIUS services to wireless as part of their feature suite.

My experience with the switching team and NAC was pretty much one and done. Here's the config changes, make the changes, and oh yeah there will be some new VLANs.

When it came to wireless, I found it fortunate that I sat directly across from the main wireless guy, because we were constantly pulled into troubleshooting both the corporate wireless and guest wireless stuff because OH YEAH NAC also acts as the guest wireless gateway!
Title: Re: Hello Wireless, Meet NAC
Post by: Dieselboy on June 25, 2019, 01:44:38 AM
I'm using PEAP. I have Apple Macs and Linux desktops to support  :'(
Title: Re: Hello Wireless, Meet NAC
Post by: wintermute000 on July 04, 2019, 04:42:16 AM
You can try to get them to set server cert checking for a bit more security, but that can be changed back client side.

Fairly sure EAP-TLS is a solved problem for all main OSes for WLAN, its LAN where its a total mess of drivers and OS specific things. But you'll need some kind of MDM (again solved problem, but effort/$) to consistently push all the configs and certs.We've certainly done a ton of WLAN deployments where OSX was a main use-case, except they get their policies/profiles/certs via MDM (JAMF or something like that) instead of GPO.
Title: Re: Hello Wireless, Meet NAC
Post by: Dieselboy on July 05, 2019, 02:55:43 AM
Thanks for the name-dropping ;) Will come in handy in the near future I think.
Title: Re: Hello Wireless, Meet NAC
Post by: deanwebb on July 08, 2019, 10:14:56 AM
Quote from: wintermute000 on July 04, 2019, 04:42:16 AM
You can try to get them to set server cert checking for a bit more security, but that can be changed back client side.

Fairly sure EAP-TLS is a solved problem for all main OSes for WLAN, its LAN where its a total mess of drivers and OS specific things. But you'll need some kind of MDM (again solved problem, but effort/$) to consistently push all the configs and certs.We've certainly done a ton of WLAN deployments where OSX was a main use-case, except they get their policies/profiles/certs via MDM (JAMF or something like that) instead of GPO.

^ Quoted for truth.

Get thine Macs on an MDM, forthwith!
Title: Re: Hello Wireless, Meet NAC
Post by: Dieselboy on July 10, 2019, 03:42:33 AM
We're phasing out macs at the objection of users. However there's a push to use Linux for the devs desktops, so will need mdm anyway.
Title: Re: Hello Wireless, Meet NAC
Post by: deanwebb on July 10, 2019, 10:57:47 AM
What's your MDM solution?
Title: Re: Hello Wireless, Meet NAC
Post by: LynK on September 25, 2019, 09:33:05 AM
Right now I am having a heck of a time with this exact issue. We use microsoft NPS for our radius server, and I am getting more and more frustrated with it, which is causing me to learn to use either freeradius or our forescout solution.

Currently we have a PEAP based auth, and I cannot get the two MACs to connect to save my life. Even if I try to use profile creator or apple configurator, they will not connect. So I have then tried to go with a eap-tls based wireless to see if the MACs will connect, and nothing is working, neither MAC or windows on the test SSID.  :wall: :wall: :wall: :wall: :wall:
Title: Re: Hello Wireless, Meet NAC
Post by: SimonV on September 25, 2019, 09:56:04 AM
Quote from: LynK on September 25, 2019, 09:33:05 AMCurrently we have a PEAP based auth, and I cannot get the two MACs to connect to save my life. Even if I try to use profile creator or apple configurator, they will not connect. So I have then tried to go with a eap-tls based wireless to see if the MACs will connect, and nothing is working, neither MAC or windows on the test SSID.  :wall: :wall: :wall: :wall: :wall:

What's your RADIUS server, is it NPS? Is the certificate AD-signed? Do your MACs have your AD CA and intermediates in their list of Trusted Root CA and Intermediate CA?

Title: Re: Hello Wireless, Meet NAC
Post by: LynK on September 25, 2019, 02:34:29 PM
Quote from: SimonV on September 25, 2019, 09:56:04 AM
Quote from: LynK on September 25, 2019, 09:33:05 AMCurrently we have a PEAP based auth, and I cannot get the two MACs to connect to save my life. Even if I try to use profile creator or apple configurator, they will not connect. So I have then tried to go with a eap-tls based wireless to see if the MACs will connect, and nothing is working, neither MAC or windows on the test SSID.  :wall: :wall: :wall: :wall: :wall:

What's your RADIUS server, is it NPS? Is the certificate AD-signed? Do your MACs have your AD CA and intermediates in their list of Trusted Root CA and Intermediate CA?

Microsoft NPS, Public signed through digicert, yes the MAC do have the servers bundled cert (server, inter, and root) installed and trusted. Macs are running the latest mojave.


Sent from my iPhone using Tapatalk
Title: Re: Hello Wireless, Meet NAC
Post by: SimonV on September 26, 2019, 12:17:17 PM
Can you take a packet capture, perhaps you can find out where in the EAP process it halts?
Title: Re: Hello Wireless, Meet NAC
Post by: deanwebb on September 26, 2019, 01:56:00 PM
Quote from: SimonV on September 26, 2019, 12:17:17 PM
Can you take a packet capture, perhaps you can find out where in the EAP process it halts?

This. Do a capture both on the Mac and at the WAP, or on the traffic from the WLC to the RADIUS server. You'll see where the conversation terminates and for what reason.

If you have an externally-signed cert and the pre-connect ACL doesn't permit HTTPS traffic to the CA for that external cert, then the Mac can't validate the cert and will stop participating in EAP negotiations. It will start them again no problem, but will stop after it can't get to the CA. Solution is to add a permit line on the pre-connect ACL to allow the HTTPS traffic to the public CA for the cert.