Want to learn the best practice for configuring Chromebooks with 802.1X authentication?

Sign up for a Webinar!
Branding
Branding Branding
Login Check our Prices

Using VLANS to Keep Students off the Staff Network

Key Points
  • Segmenting your network into different VLANs exponentially reduces the risk of threats moving laterally across your network.
  • K-12 schools are required to keep students and staff separated on the network so their content can be filtered differently, a requirement to receive E-Rate funding.
  • With SecureW2, you can automate VLAN assignment based on a user/device’s real-time status in your IDP or MDM. This article shows how to segment based on the current group a user is in Google Workspace.

Keeping your students off the staff network is among the daily challenges IT administrators face monitoring their domain. Especially as we continue to integrate technology with education, many institutions are adopting methods such as 1:1 to assist students further in completing their homework and efficiently completing daily tasks and learning assignments. However, implementing these additional teaching methods can also lead to issues outside the classroom, such as students accessing the staff network.

Allowing students on the staff network can compromise various categories of intellectual property and information that could affect the school district, setting back teachers’ curriculums and district plans. SecureW2 has a mutual understanding of upholding educational standards to keep students and faculty in a promising environment without malicious acts to disrupt education. Here is a guide to using our solutions to Keep students off the staff network and segment them into multiple VLANs on the same SSID. 

Creating Automated Policies for Segmenting Students and Staff Devices on the Network

To start automating network segmentation for your organization, we’ll need to create two to three policies based on the IDP you’ll be using with SecureW2, whether for BYOD enrollment or the Identity Lookup Provider Feature. 

Segmentation from this policy works in two different ways:

  • Identity Lookup searches for the groups that we mapped in the Identity lookup provider and segments users based on their dynamic user attributes 
  • If you’re not using an Identity Lookup,  segmentation can be done using the static attributes encoded in your certificates. SecureW2 Network Policies can look into the attributes in the cert or the user’s email domain and segment based on what it sees there.

This may raise the question of what is better overall. We recommend using the Identity Lookup Provider because it uses dynamic attributes and provides a more convenient means of updating devices in real-time. If a user were to become noncompliant or have a status change, there would not be a lapse in security. So, in this guide, we will show you how to configure segmentation using SecureW2’s Identity Lookup Provider.

Setting up an Identity Lookup Provider

SecureW2 can look up the real-time status of users and devices when a network authentication request comes in. To set this up, we must create an Identity Lookup Provider. This is what establishes an API connection between SecureW2 and your identity system.

Depending on your organization’s identity system, you must upload specific files/information to link SecureW2 with that IDP. For example, Azure requires the Provider Secret, Client ID, and Client Secret, and Google Workspace requires Service Account Key FIle and Delegated Domain Authority Email. Here’s a list of IDPs with which our Lookup Provider is compatible. 

  • Azure
  • Okta
  • Google Workspace
  • OneLogin Generic OAuth
  • JAMF Generic HTTP

Once this step is completed and you’ve successfully linked SecureW2 to the IDP, we have to configure Cloud RADIUS to look up the user within your IDP and validate the user’s attributes and group. To do this, navigate to Attribute Mapping and configure The following:

  • Local Attribute: What name will the attribute have encoded in the certificate
    • Commonly, this will be UPN and email. 
  • Remote Attribute: For most, you will select User Defined and have the value be equal to email.

 

Attribute mapping allows Cloud RADIUS to search for users when they connect to the network. Next, we will map Groups. This will enable us to check who is a student and who is a staff user and then apply a different network policy to each group. You’ll see two options for the Local Group and Remote Group. In the remote group, you’ll input the same group name you have in place in the directory, and locally, you’ll just match it and input the group’s name, such as Seniors, Juniors, Math Department, etc. For this example, we will keep it simple as students and Staff.

 

 

So whenever a student named John Smith attempts to connect to the network, Cloud RADIUS will check against the IDP to validate that the user with the email johnsmith@k-12school.org is an active student or staff member. Once that is complete, the Policy Engine Workflow process will begin to invoke set policies for that designated group the user is in. 

Create the Account Lookup Policy

After setting up our Identity Lookup Provider, we will configure the RADIUS server to perform a lookup during authentication. To identify when users attempt to connect to the network, we’ll need to head to the Account Lookup Policy Module, select our Identity Provider, choose Certificate-SAN-Email, and enter our domain email.

 

You may also use Username, CommonName, and UPN as attributes. For this example, we decided on email because of what we chose earlier when configuring the value for the IDLP to search for. Once this step is complete, we’ll move on to settings.

 

In the settings, you’ll configure the search method. You’ll select the Identity Provider Lookup, lookup type, lookup purpose, and the option to revoke your certificates on failure if the user account is found to be inactive or not in compliance with your MDM/IDP.  

Here, we’ll specify the IDLP we’ll use and the lookup type that occurs during authentication. First, we have Auto.



You’ll see in Auto that it automatically searches for the user based on the email address and checks the IDP during authentication. But if you choose custom instead, you can filter even further and create lookup conditions to designate what to do for the Cloud RADIUS when looking up the user identity to specify what to search for. For example, by doing this sort of search, the user connects to the network using their username.

Cloud RADIUS will ensure that the user using that username contains a matching email value attribute to that user based on the conditions. Once we’ve established the account lookup policy, we will create the Policy Engine Workflow. 

Create Policy Engine Workflow

A policy engine workflow assigns roles and designates user access to domain resources during RADIUS authentication. The Policy Engine maps this, either matching a user’s regular expression input or assigning the role based on the user input that equals the IDP attribute. To direct the RADIUS server later on on how to segment our two groups of users, we will need to create two separate policy workflows—one for students and one for Staff. 

Student Policy Engine Workflow

We will create a workflow for the user groups, starting with students. To set up the student policy, select the IDP, IDLP, or API token you have set up in the management portal and select the student attribute.