VLANs are a great way to increase security because they reduce the risk of threats spreading throughout the network. A threat can quickly move around the network if users/devices are not segmented adequately, which can cause serious harm. This article will cover Network Segmentation best practices using the top use cases we’ve seen amongst RADIUS users.
- Segmenting Devices Using Mac Authentication on the Network
- Segmenting Unmanaged Devices (BYOD) VS Managed Devices (MDM)
- Segmenting the Network Based on Roles/Groups
For this example, we’ll use Microsoft Azure/Entra ID as our go-to IDP, Jamf as our MDM, and how they’ll integrate with Cloud RADIUS service to show how an organization can easily automate network segmentation based on real-time information from their Identity Provider and MDM.
Segmenting Devices Using Mac Authentication on the Networks
Smart devices, printers, and other IoT devices can lead to a compromised network, as they often have weaker security than a traditional computer.
To do this, we’ll first have to configure SecureW2 to determine what devices will be segmented and what group of IoT devices will belong in that VLAN by creating a Mac AuthIDP in SecureW2. Once we’ve completed this step, we will then make the Policy Engine Workflow and Network Policy to direct the RADIUS server on what Policy Workflow to enforce upon a group and the conditions it will follow.
Create a Mac Auth IDP in SecureW2
Creating a Mac Auth Identity Provider in SecureW2 will allow Cloud RADIUS to whitelist the Mac Addresses that belong to your groups to put the Mac Addresses in to segment them into different VLANs.
- We’ll first head to Identity Management
- Select Identity Provider
- Choose to create a Mac Auth IDP
- Depending on how you organize your IoT devices, click Groups and add the device groups for your organization.
Then click on configuration and view the options to either:
- Manually input the Mac Addresses of our IoT Devices / Printers or
- Upload them as a .csv file.
Once you’re done inputting the Mac addresses, you’ll specify which groups each Mac Address should be in. We recommend uploading the addresses because using a .csv file will speed up the whole process. Once uploaded, select the group to which the Mac Addresses or Addresses belong and choose save.
Once this is completed, we will map out these Mac Addresses/Groups into Policy Engine Workflows that can then be mapped to Network Policies.
Policy Engine Workflow
A Policy Engine Workflow assigns roles and can be used as a condition by the Network Policy to designate users to gain access to domain resources during RADIUS authentication. The Policy Engine maps this, either matching a user’s regular expression input or using which IDP a user came from and/or the group they are a part of.
To create the Policy Engine, we’ll head to policy management:
- Select Policy Engine Workflow.
- Type in the name of your Mac Auth group.
- For this example, we’ll start with Mac Auth IoT Workflow
- Select our Mac Auth IDP we created in the first step
- Select the IoT group that we intend this workflow to enforce our policies
Then we’re done! We have established our IoT device group policy workflow.
We’ll repeat this process and create a group for managed devices.
Once this is complete, we will direct the user group for VLAN assignments by directing the RADIUS server in the network policies to segment the network based on the policy workflow. To ensure the VLANS are adequately segmented, you’ll need to create a Policy Engine Workflow per each group in the IDP.
Network Policy
After creating the Policy Engine Workflow, we’ve established for the RADIUS what workflow will target this group, and now we will create the Network Policy to enforce these.
This is how you’ll segment VLANS for your network based on the user groups configured in your IDP. Some of the conditions that you can use to segment the users/devices are:
- RADIUS Client
- User and Device Roles
- Device during Certificate enrollment
- Certificate used for authentication (SAN attributes )
- Metadata, such as time of day
When creating a Network Policy, you decide what conditions you want to enforce and then select the group’s policy workflow for which you wish to designate the conditions. For the first Network Policy, we’ll create the Mac Auth IoT Network Policy.
To do this, we will:
- Create the network policy by clicking Add New
- Naming our policy to match the respective user group
- In conditions, we will select Mac Auth IoT Policy Workflow
Once we’ve set the conditions to enforce policies, we can configure the Settings that control the RADIUS attributes the Network Policy sends back to the network infrastructure.
Here, you can see the settings for our Mac Auth IoT devices, which are set to be segmented in VLAN 1. After this, we’ll repeat the same actions to create the VLAN for MDM devices, but instead of having the Private ID group as 1, we’ll use 2.
Now you know how to use SecureW2 to automate the segmentation of Mac Auth devices on your network. Next, we will cover how to segment BYODs from Managed Devices on your network.
Segmenting Unmanaged Devices (BYOD) VS Managed Devices (MDM)
Having unmanaged devices on your network is necessary to offer a Secure Wi-Fi connection for employees, but that can lead to huge risks if you don’t have them segmented from your managed devices or, worse, your servers. This diagram shows how to segment our BYOD devices into separate VLANs using SecureW2.
The most common way this is done is by using the method of enrollment as a way to segment the devices. Here, we will create a policy to segment a device if it uses one of our API Gateways or a SAML enrollment with our MultiOS self-service client for BYODs.
If you don’t already have your domain set up for MultiOS enrollment, look at our instructions for setting up passwordless authentication for Azure AD. It is a standard SAML integration, and once set up, your users can use their credentials to self-service themselves for a certificate. If Azure/Entra ID is not your domain’s IDP, you can find the corresponding IDP here in our integration documentation instructions.
Managed Devices will use an API Gateway connected to their MDM to enroll themselves for a certificate. We will use this to identify which devices are managed and put them into their own VLAN. 
For this example, we’ll use an API Gateway for MDMs using a SCEP enrollment protocol like Jamf. This can also be configured with an Account Lookup policy, enabling SecureW2 to check Jamf to ensure the device is still active before letting it connect to the network. This isn’t necessary to segment managed devices into their own VLAN.
Mapping the Policy Workflow
The next step is configuring policy workflows for the particular roles and user groups to specify to the Cloud RADIUS server what type of user device will be going to this VLAN and what condition is required for that user/device to gain access and segment.
We’ll create several policies to configure SecureW2 to communicate with the Enterprise MDM/IDP or create an IDP with SecureW2 itself. Below, we’ll cover the policies for attribute mapping:
- Account Lookup
- Policy Engine Workflow
- Network Policies
Account Lookup Policy
While it’s not necessary to configure for segmenting devices, the Account Lookup Policy is how you’ll direct Cloud RADIUS to validate a user/device identity at the moment of authentication. It’ll search through either your IDP or MDM. After creating a policy, you’ll select the IDP or MDM and set the condition of the identity attribute you want Cloud RADIUS to look up.
Then, in settings, you’ll see in the auto that it’ll automatically search for the user based on the email address and check the IDP/MDM 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.
Next, we will create the Policy Engine Workflow.
Policy Engine Workflow
We will now create two Policy Engine Workflows. One will select the SAML IDP to identify and segment our BYOD devices, and the second will select our API Gateway to identify and segment our managed devices. Here is what the BYOD Policy Engine Workflow will look like.
Here is what the Managed Device Policy Engine Workflow will look like.
Once complete, we can segment the device groups by mapping our Policy Engine Workflows to Network Policies.
Create Network Policies
The Network Policy creation process will be very similar to what we did before when creating the Mac Auth Network Policies. We will create a new policy, name it, and then select the Policy Workflow we’ve created in the previous step to segment the BYOD users.
Once this is complete, we will once again configure the attributes in the settings to specify whether our users/devices should be allowed/denied access to the network and what RADIUS Attributes we will return, which will be the ones necessary to put them into unique VLANs.
We’ll repeat this sequence for the MDM workflow, and once it is complete, we will segment our network to separate our BYOD and MDM into two different VLANS based on the Issuing Intermediate CA. 
You’ll see that Network Policies will segment based on the Issuing Intermediate CAs, ensuring that none of the BYOD users are on the same network. This will have completed the workflow for our BYOD/MDM devices. Lastly, we will cover how to segment the network based on the roles/groups that exist in our Identity Provider.
Segmenting the Network Based on Roles/Groups
An excellent way to accomplish this is to mitigate risk by segmenting your network based on user groups and roles. Particularly which users/groups should be on the same VLAN as on-prem infrastructure. This section will cover how to segment your enterprise network based on user groups, starting with the previous sections by creating your IDP/IDLP. For this example, we will use an IDLP to simplify the process.
Create an IDLP
We will first create an Identity Lookup Provider, which will look up users/devices at the moment of authentication and share information about them so we can segment them.
In Attribute Mapping, we just need to map the user’s email so SecureW2 knows how to look up our users.
The next step is to enter the user groups designated to be segmented and searched whenever a user attempts to access the network. Here, we’ve configured some as an example, but configure whatever group you want to use to segment the network. We find the most important thing is to keep access to the VLAN of your on-prem infrastructure limited to only those who need it.
Policy Engine Workflows
After establishing the IDP, we’ll begin mapping out the Policy Engine Workflow for our user groups.
- Click Policy Management and choose the Policy Engine Workflow. After you name your Policy Engine, you’ll choose the IDLP you’ve created.
- Choose the attribute the policy engine will apply to and enter the search value you want for the email.
- Choose the matching group and click update.
Repeat this process for each group you want to segment.
Now, we will map these to our Network Policies.
Network Policy
As in the previous sections, we will segment the user groups using their respective policy workflows to designate which group will be segmented to their respective VLAN. We will begin by using DevOps as the first policy flow.
Once this step is complete, we must assign the RADIUS attribute values to define the VLAN configurations and segment them to their respective VLANS. This is done by clicking on the next tab and configuring the RADIUS values you wish to send. To segment the network, you must at least have the Tunnel Type and Private Group ID attributes added.
Once you’ve completed this step for the rest of the groups, your network is completely segmented!
Conclusion
Keeping your users and devices unsegmented in the network is an unnecessary risk that should be addressed immediately. Automating this process can be a strenuous task. Luckily, using SecureW2’s PKI Service and Cloud RADIUS can complete this within a few hours. If you have any questions about any of the steps we talked about in this article, please reach out to us with our Contact Us form or email us at sales@securew2.com.
