Security

I thought I'd share an idea I came up with and tested with a customer (with the assistance of one of my Aruba contacts) in case it is useful to anybody. It applys to BOYD as the scenario shows.

Historically, the customer in question had a guest service, and a trusted service. These were standard in that the trusted service was authenticating via 802.1x into AD using PEAP. The guest service was intended for everything other than corporate people on corporate devices and the role was limited in terms of bandwidth contract and allowed protocols.

As a result, word had got out into the employee base that if you created a manual dot1x profile you could leverage your credentials on your own device (ipad/iphone/pc whatever) and do what you liked.

The customer IT team obviously didn't like this due to associate risks, but were told by management they couldn't take action against individuals. They needed to provide a group solution.

The added complexity in this case was that the corporate service needed to continue to support Mac laptops and PCs (so machine auth enforcement is not an option), and they didn't want to do EAP-TLS or look at supplicants for the Macs as they didn't have time to implement or support either.

Initial Solution?

Took a while, but we came up with the following.

The trusted service was split into two. One for Macs, one for PCs. Not ideal, but managable. The Macs one was augmented with a Mac-auth (mac address) profile leveraging the internal database. We There were only 20 or so proper corporate Macs, so this was seen as ok. The PC corporate service had machine-auth enforcement added to it (and you get tar-pitted essentially if you don't machine auth). Both the trusted Mac and PCs still authenticate in addition into the AD as normal.

Final challenge!

The existing guest service (web-auth) was also using the internal database. In addition, the customer also pointed out that certain client devices on this service (of key staff) should be given more flexible access! We could leverage mac-auth on that service to achieve, but that might overlap the corporate Mac part.

Solution...

We set the Corporate Mac MAC-auth profile to be dash delimited. The guest service Mac-auth was set as colon delimited.

Everything else left as is.

Moving forward, the only thing they needed to remember was to enter local database entries in the correct delimited format, and hey-presto!

Enjoy! Thanks.

Just a couple of thoughts for anyone in similar situations. that may read this thread.

- In this scenario, since you ultimately enabled machine authentication on the Corporate PC network as well as setup the Corporate Mac network to use MAC authentication (thus entering the MACs in the internal DB already), why not just have one Corporate network?......When using machine authentication, you can trick the system into thinking Macs and other non-Windows machines successfully authenticated by adding their MAC to the internal DB (since you have already done that for MAC-auth, it is no additional work).  This would reduce the need for the 2nd corporate SSID.

- For those guests that need additional/more flexible access, could User Defined Rules be used rather than MAC-auth?  If so, this would eliminate the need to add those client's MACs to the internal DB; and avoid confusion with the suggestion above.

Hi,

Yeah, the first point was discussed actually with the customer in question. I forgot that. Actually, the customer preferred to have the two as they found it more simple to understand (they don't consider themselves experts and rarely used the kit), even though I prefered what you said.

On the second point, we actually did that. The mac-auth'd clients got a much more flexible role than "normal" or other guests as a result.

Cheers.