Staff BYOD

[ITB0SS]

Hi

 

I require Staff to be able to connect any device to the schools WiFi.

 

The simplest way I can think to achieve this is where by Staff use there existing AD credentials to connect, rather than a pre shared key that ends up being obtained the Students all the time. We have a Guest VLAN setup on the Smoothwall and then Unifi acts as a Guest Hotspot with portal page and WiFi vouchers, just a bit to much over head for me having to manage Staff codes all the time. It's fine for the occasional guest, but then also it's fully transparent on the filtering too and unauthenticated.

 

I have so far achieved this with Smoothwall and NPS using the Smoothwall for RADIUS accounting and the schools DC/NPS server for the RADIUS authorization server, I have a test security group with a test user in and can join the network with AD username and password, great.

 

However this opens up our network for any member of Staff to bring in a laptop that's not managed onto the schools network, how have others got around this?

 

I understand how VLANS work, however I find the Smoothwalls GUI interface confusing, the schools network is Unifi and I'm looking at getting a Unifi Gateway as currently we only have CloudKey that is limited and does not act as the gateway, the Smoothwall is the gateway, I'd look at setting the Unifi Gateway as they gateway and doing VLANS on that and then just using the Smoothie for filtering, unless any other simpler ideas?

 

This is Smoothwalls response

 

Hi James,
 
Typically, BYO devices aren't mixed in with school managed devices - it's one of the basic principles for network security, really. How a given school goes about achieving this very much depends on their network design and what options they have. In many 'flat' networks the design may make use of an entirely separate interface on the Smoothwall, for example, to provide a dedicated Wi-Fi network with sane firewall rules permitting only the strictest required access across zones to allow for authentication or other critical services. 
In cases where VLANs are employed, it's normal t have the Wi-Fi system allocate the client device to a specific VLAN based on what SSID is joined or other factors. How you go about it really depends on what you have to accomplish the goal with. 
 

[Davit2005]

vLans in themselves on their own are not necessarily secure. Most layer 3 switches route traffic between all subnets unfiltered and without ACL as standard.

 

You don't need to necessarily have one PSK, there is an MPSK version which can have a PSK per device. Strongly against PSK as too many devices make this easy to share and one it gets out there you would need to change any devices using PSK.

 

For Wifi you will be hard to beat 802.1x with a self-signed cert for domain/managed devices. Any devices joined via captive portal could be treated differently depending on whether staff/student/guest?

 

 

Edited October 23, 2025 by Davit2005

[dmj]

Our solution to this was to create a VLAN and put BYOD devices on it. We'd treat that VLAN as if it was originating from the internet; so nobody would have access to any internal resources.

It worked well because all our resources were accessible from home anyway. 

[ITB0SS]

Yes this is my goal and currently works "For Wifi you will be hard to beat 802.1x with a self-signed cert for domain/managed devices"

 

Just my concern is that if I enable this currently any unmanaged device would be on the main schools network authenticated with the Staff users AD credentials.

[chris11256]

I went down the Certificate Authority route for this. For background we have a single SSID and then NPS directs things(based on policy) onto the appropriate vlan. Domain joined devices have a certificate from our CA and authenticate themselves with that, then get assigned our domain laptop vlan. BYOD users authenticate with their own username & password, then get put on our BYOD network which is almost it's own walled garden except a setup that allows papercut mobile printing. Guests using issued guest credentials then go into the guest vlan. ACL's on the core switch prevent BYOD or guest devices from getting onto anything internally(except the papercut thing for BYOD).

 

I can't comment on the smoothwall side of things as that's not something we use. We've got a Palo Alto box and the Aruba ap's integrate directly and pass the username & IP Address of devices as they connect/disconnect, that sort out the filtering side of things.

Edited October 23, 2025 by chris11256

[tom_newton]

I am not sure if I am reading this correctly - but sounds like you have everything working, you just want to stop staff adding arbitrary devices using their username and password?

One way to do this would be to go the certificate route, as someone above suggested. however your question is not super clear to me, because on one hand, you say you want them to add any device, and on the other, you say you want to restrict

[ITB0SS]

I want them to be able to connect any device with there AD username & password, but as that's an unmanaged device it could have a virus on or anything dodgy and then it's on the schools main network.

[Davit2005]

I'm too confused.

 

I think you need to split this up a bit??

 

On the one hand you have what machines are allowed to join the network and on the other the user authentication i.e. what the user can get to on the network.

 

Is this a 1:1 device org?

 

 

 

Edited October 23, 2025 by Davit2005

[dmj]

36 minutes ago, ITB0SS said:

I want them to be able to connect any device with there AD username & password, but as that's an unmanaged device it could have a virus on or anything dodgy and then it's on the schools main network.

See my earlier response, you should treat the BYOD devices as if they are coming from the internet, they don't gain access to internal networks. 

[Roberto]

52 minutes ago, ITB0SS said:

I want them to be able to connect any device with there AD username & password, but as that's an unmanaged device it could have a virus on or anything dodgy and then it's on the schools main network.

 

Yes. Then don't do that. 

 

BYOD might work for letting them use an isolated internet connection to hop on to your cloud provider of choice to work on documents that way, that sort of thing, but you'd have to be insane to let them connect to your actual LAN because of security, safeguarding and GDPR. And that's just 3 show-stoppers I've thought of in about 40 seconds of reading this.

[ITB0SS]

17 minutes ago, dmj said:

See my earlier response, you should treat the BYOD devices as if they are coming from the internet, they don't gain access to internal networks. 

But they need to be so that they can authorise against NPS and AD, it's a flat network at the moment aside from Guest VLAN on Smoothwall and PSK from Unifi

[ITB0SS]

2 minutes ago, Roberto said:

 

Yes. Then don't do that. 

 

BYOD might work for letting them use an isolated internet connection to hop on to your cloud provider of choice to work on documents that way, that sort of thing, but you'd have to be insane to let them connect to your actual LAN because of security, safeguarding and GDPR. And that's just 3 show-stoppers I've thought of in about 40 seconds of reading this.

Yes exactly that, I know it works as I've tested with my test account, but no one else is in the security group, is this even a good way? How's everyone else doing NYPD, Radius makes sense but ofc they need to access the DC so that they can authorise there AD creds

[ITB0SS]

52 minutes ago, Davit2005 said:

I'm too confused.

 

I think you need to split this up a bit??

 

On the one hand you have what machines are allowed to join the network and on the other the user authentication i.e. what the user can get to on the network.

 

Is this a 1:1 device org?

 

 

 

No, no device is just allowed to join the network, this is just so that Staff can access the WiFi using there AD credentials 

[Davit2005]

Just now, ITB0SS said:

Yes exactly that, I know it works as I've tested with my test account, but no one else is in the security group, is this even a good way? How's everyone else doing NYPD, Radius makes sense but ofc they need to access the DC so that they can authorise there AD creds

The captive portal sends requests to the radius server and the radius server authenticates users against AD. BYOD should not need to talk to the DCs directly.

[Roberto]

4 minutes ago, ITB0SS said:

Yes exactly that, I know it works as I've tested with my test account, but no one else is in the security group, is this even a good way? How's everyone else doing NYPD, Radius makes sense but ofc they need to access the DC so that they can authorise there AD creds

Ah ok. Perhaps we're focusing too much on the "BYOD". Let's back up a bit

 

Radius auth - you should be able to authenticate trusted devices (AD joined) via RADIUS or Certificate auth to a SSID reserved for those trusted devices. So you authenticate the device to join the WiFi network and login proceeds in the normal manner once that's happened. You'd want to isolate this SSID for LAN connectivity.

 

For users with BYOD devices, phones or whatever, you'd have a second SSID with some firewalling/VLAN config that just routes them to the internet so they can use whatever you've published for essentially home use. 

 

This is pretty much "how it's done" these days... except my employer's actually gone with captive portal for the BYOD network rather than having to deal with people wanting support for getting their unexpanded VIC=20 to connect to wifi via an AD account...

Edited October 23, 2025 by Roberto

[psydii]

For EAP-TLS (user/device certificate authentication) / PEAP ( user/password auth) the devices don't need line of sight to AD, unless they are needing to access shares and printers. But they do need to see a DHCP and DNS server, but this does not need to be the same ones used for your AD Domain.

 

We have one ssid, and if you auth with a username/password you end up in the BYOD/Guest VLAN, firewalled off from everything bar the internet.  If you auth with a valid domain issued computer cert that correctly maps to a computer account in AD, you've proven you're a domain managed device and you get the normal workstation level access to the network.

 

Actually we are more granular depending on group membership of the account used,  so we can make you can hit different filtering rules/requirement based your/devices role too.

[ITB0SS]

Ok, so yes I think I'm getting a bit confused with BYOD.

 

All I'm trying to accomplish is Staff users bringing in a device mainly a phone and then authenticating them the easiest way without using a PSK or temporary guest passes.

 

Which is why I've started playing around with the Smoothwall for accounting and then AD for radius Authentication

[dmj]

15 hours ago, ITB0SS said:

 

 

All I'm trying to accomplish is Staff users bringing in a device mainly a phone and then authenticating them the easiest way without using a PSK or temporary guest passes.

 

Think of it like:

Staff phone gets DHCP and then authenticates against RADIUS on an isolated portion of you network. The RADIUS server passes that off to the Active Directory and lets them onto the network. Once they are on the network, all they can access is the smoothwall server that directs them back out to the internet again. You will need to fix the flat network issue.

[ITB0SS]

Ok so how can I go about isolating my network? They need initial access to authorise there AD creds, but then yes after that all they need is access out through Smoothwall to internet.

 

 

[dmj]

14 minutes ago, ITB0SS said:

Ok so how can I go about isolating my network? They need initial access to authorise there AD creds, but then yes after that all they need is access out through Smoothwall to internet.

 

 

broadly speaking, you need to setup a VLAN on your wireless network, and extend it across to your smoothwall to do the firewalling. 

Edited October 24, 2025 by dmj

[Davit2005]

54 minutes ago, ITB0SS said:

Ok so how can I go about isolating my network? They need initial access to authorise there AD creds, but then yes after that all they need is access out through Smoothwall to internet.

 

 

They don't need to. The NPS/Radius server does it and whatever you have i.e. Captive Portal which is configured to point to the NPS as long as the NPS server is authorized in AD, jus a click on the drop down on NPS server 🙂

 

If you want total seperation you can put DHCP and DNS on the smoothwall too. If you want internal servers to handle DHCP and DNS you will need to set a DHCP relay option and typically allow the DNS and DHCP ports through. I have always jus allowed ports 67 and 68 both ways but it might only need 67 and 68 specific ways i.e. client to server and server to client.

Edited October 24, 2025 by Davit2005

[ITB0SS]

Ok thank you so I guess my question is how do I do that on NPS?

 

I'm guessing I'd need to setup security groups whereby only certain computer names can access on prem managed infrastructure, and then if it does not match then just goes to Smoothwall.

[psydii]

It’s late, and I’m three beers down, and I actually paid a consultant to set this up 15 years ago, and I’ve riffed on it ever since.

 

So, I just tried these out two prompts in my LLM Chat Bot of choice and it did a decent job of describing our config:

 

1) How do I configure ad groups, a CA and nps to put members of different groups onto different vlans when they authenticate to the wireless network ssid?

 

2) I also need byod devices to be able to authenticate using a username and password without having a device or user certificate.

 

Be careful, the bit where you configure vlan/tunnel type in the nps policies is actually vendor specific, so you should refer to the specific documentation about this from your wireless vendor.

 

On the device that routes your internal vlan/subnet you will need to make rules that ensure traffic from the Boyd vlan can only get to the internet, DHCP servers and DNS Servers.

 

And because I’ve had my nose in my phone writing this, I have just been made to read it out loud. Which explains the minimal typos.

[ITB0SS]

All is well in the world ChatGPT advised me

[KK20]

we have two SSID, "secure" and "guest".  Secure is 802.1x with machine certificates, used for our domain devices (there is a fudge for chromebooks).  Guest uses packetfence NAC.  The native VLAN for guest pops a request to packetfence which checks to see if that client is authenticated, if so then the authenticated user is put on an appropriate vlan - student and staff go on a vlan that needs securly authentication via their 365, pure guests or visitors get dropped on a dns heavily filtered securly vlan.  Firewall filters DNS so only our internal DNS or securly can be used.

 

Packetfence works with 365 logons or guest accounts, the guest accounts are dished out to guests when they inventry in.  A pair of radius servers do the autheticating.  Packetfence sends the controllers an appropriate VLAN for the user depending on their logon.  Each VLAN is set up and firewalled appropriately with settings on the APs determining which vlans allow interclient communication etc.   Some "swiss cheese" for our papercut mobile print server, DNS and DHCP relay.

 

This was a real shite to set up with unifi originally but it does work.  I now have this running with TWO controllers onsite as we have a rough 50/50 split of ruckus unleashed and unifi EFG.  Both communicate to packetfence.

 

Im in the process of setting up ethernet through packetfence with our switches so I can guard against rogue ethernet devices too.

 

When BYOD is considered, think along the lines of what people can bring in.  TFTP server and DHCP server? yep.  DNS server?  yep.  Seen both of these.  So make sure you have appropriate firewall and DHCP snooping etc.