Configuring Network Segmentation Based on Intune/Azure Groups
Cyber attacks are getting more vicious, and a flat network that is not segmented is like an open invitation to hackers. Even a tiny loT device, such as a smart refrigerator in the cafeteria, can be a hacker's medium to infiltrate your works to release viruses that can potentially cause severe damage. That's where virtual networks and segmentation come in.
While segmenting our network into smaller virtual networks requires a proper network segmentation strategy, it doesn't need to be complex like micro-segmentation. We should instead take action on what is feasible today because every virtual network we implement reduces the threats our network is vulnerable to exponentially.
Probably the most popular security policy we see used for segmentation is Device Trust. Organizations want to place their trusted managed devices, which are in active compliance, in separate network security groups from untrustworthy devices like BYODs or uncompliant devices. Another way to segment your virtual networks is through your existing Azure Groups. This is great because Azure Groups are often created for the various roles in an organization, and certain roles like DevOps should certainly be in a separate network security group from risky users and devices.
How Will We Create Virtual Networks Based on Azure Groups
So while all of this is great in theory, how will actually apply this? Most organizations we work with have really solid security policies but struggle to actually create virtual networks with them. There aren't dedicated Azure services or Azure resources to So, how do we go about creating these "Azure virtual networks"?
SecureW2 achieves this solution by providing a managed service that does the following:
- Issue Unique digital certificates that contains attributes from Intune and Azure, using software and APIs, to accurately identify all our network traffic
- Authenticate all our users and devices using SecureW2's Cloud RADIUS server and Policy Engine, which looks up their status in Intune and Azure in real-time to place them in the proper Virtual Network
Prerequsites to Implementing Intune Network Segmentation
In order to use Cloud RADIUS to lookup users in Azure AD during the network authentication process, they need to have been enrolled for a certificate that contains identifiable information from Azure. To assign the most appropriate Intune/Azure VLAN group, Cloud RADIUS uses x.509 certificates that provided a better identity context for authenticating the client with a greater degree of accuracy. Most readers will be using JoinNow Connector PKI to enroll devices for certificate-based authentication. Documentation can be found below:
Configuring Cloud RADIUS to Segment Intune/Azure Groups into Different VLANs
SecureW2's Cloud RADIUS has an industry-unique ability to perform directory lookups at the moment of authentication, and use the information for enforcing certificate lifecycle management, and network authentication and authorization policies. This is achieved by creating an Identify Lookup Provider in SecureW2, which then uses the Microsoft Graph API through an App Registration to access the data in your Azure portal. This data is then accessible to the Policy Engine in SecureW2.
The following are the high-level tasks required to configure Azure:
- Registering a New App
- Creating a Client Secret
- Creating a Provider URL and Client ID
- Providing API Permissions
The following are the high-level tasks required to configure SecureW2:
- Creating an Identity Lookup Provider
- Mapping Group Attributes
- Configuring Policies for VLAN Segmentation
NOTE: As mentioned in the prerequisites, this document requires you to have already successfully enrolled users for certificates that they can use for RADIUS authentication.
Registering a New App in Azure
Registering a new app in Azure AD is crucial to be able to identify and authenticate the App when it is interacting with Azure. To do that, the application has to be first registered in Azure. The following steps are to be followed to register an application in Azure.
- Log in to Azure
- Navigate to App Registrations
- Click New Registration
- Configure the settings as shown in the following screen.
NOTE: Use your unique SecureW2 Organization URL as the Redirect URL like the following: https://myorganization-auth.securew2.com/auth/oauth/code.
Creating a Client Secret in Azure
Creating a Provider URL and Client ID
The Client secret is one of the most crucial pieces of identity context components for designing an 802.1x network for Cloud RADIUS passwordless authentication. The client secret, which is the unique identifier value assigned to the application by Azure, helps in authenticating and diverting network connection through the appropriate Azure/Intune Groups VLAN. Follow the steps below to create a client secret for an application in the Azure profile.
- Navigate to Manage > Certificates & secrets.
- Select the Client secrets tab.
- Click New client secret.
- For the Description field, enter the suitable description for the client secret.
- From the Expires drop-down list, select an expiration date.
- Click Add.
- The client secret value is displayed under the Secret ID column.NOTE: The client secret is non-recoverable. Make sure you save it safely somewhere.
With client ID, the provider URL is crucial for network segmentation as they are used at the time of authentication and authorization. To establish a secure connection and to safely access user information from Azure to implement network segmentation policies based on Intune/Azure groups, SecureW2 would need both these elements. Below are the steps to create a Provider URL.
- Navigate to the Overview section. The following screen appears.
- Copy your Application (client) ID and save this for later.
- Copy your Directory (tenant) ID.
- Insert it into the following URL: https://login.microsoftonline.com/{Directory (tenant) ID}
This should look like this: https://login.microsoftonline.com/561bc67f-1c86-4244-8bd4-5eb23cba44ac - Save this for later.
Providing API Permissions
Finally, provide this application permission to access the data in our Azure directory.
- Navigate to API Permissions under the Manage section.
- Click Add a permission.
- Click Microsoft Graph.
- Add the following permissions:
- After adding the permissions, click Grant admin consent for {your organization}
Creating an Indentity Lookup Provider
- Navigate to Identity Management > Identity Providers.
- Click Add Identity Provider.
- For the Name field, enter the name of the Identity lookup provider.
- For the Description field, enter the suitable description for the identity lookup provider.
- From the Type drop-down list, select Azure Identity Lookup
- Click Save.
- Provide the following information under the Configuration tab.
- For Provider URL, enter the URL you created earlier using the Directory (tenant) ID by using the format: https://login.microsoftonline.com/{Directory (tenant) ID. It should look something like this: https://login.microsoftonline.com/561bc67f- 1c86-4244-8bd4-5eb23cba44ac
- For Client Id, enter the Client ID that you retrieved from Azure earlier.
- For Client Secret, enter the Client secret you generated in Azure earlier and saved in a secure place.NOTE: After updating the Identity Provider, the client secret will not be retrievable. Therefore, make sure that you save it in a secure place.
- Click Update.
- Click Authorize on your new Identity Lookup Provider.
This will test the connection between SecureW2 and your Azure App. This is a mandatory step, because it grants our application the final authorization to call the Azure API to grant User Information.
Adding Attributes to Create an Intune Group VLAN
Adding Attributes, one of the critical parts of 802.1X authentication, allows you to automate network segmentation and group policy such as Intune/Azure Groups. To add a custom attribute to the IDP, do the following:
- In the Attribute Mapping tab, click Add.
- In the Local Attribute field, enter a name for the attribute.
- In the Remote Attribute field, select the attribute to be mappped to the Local Attribute. If you select User Defined enter a value to be mapped.
- Click Next to create the custom attribute with the appropriate mapping.
- Click Update.
Configuring Groups in SecureW2 for our Azure Group VLANs
Finally, Cloud RADIUS can perform a User Group Lookup so you can create network access policies based on the Azure & Intune Groups a user is in.
- Navigate to the Groups tab.
- Click Add.
- Create any name for Local Group. This name will show up later as your 'Group' in the JoinNow MultiOS Management Portal when we configure policies.
- In the Remote Group field, paste the Object ID configured in Azure.
- Click Create.
- Click Update.
- Repeat as necessary for any Group you wish to create Network Policies around.
Configuring Policies
Dynamic RADIUS allows the RADIUS to segment users and restrict/allow resources based on information stored in their directory entry. Since enforcement occurs at runtime, changes made to a user's permissions are propagated throughout the system immediately rather than a day or two later, as is typical with most RADIUS servers.
The following policies need to be configured.
Configuring Account Lookup Policies
Lookup Policies are the ways to tie the new Identity Lookup Provider to domains. Here, you create a condition that ties our domain to the new Identity Lookup Provider created in the previous section.
- Navigate to Policy Management > Account Lookup Policies.
- Click Add Account Lookup Policy.
- For the Name field, enter the name of the account lookup policy.
- For the Display Description field, enter the suitable description for the account lookup policy.
- Click Save.
- Select the Settings tab.
- From the Identity Provider Lookup drop-down, select the Lookup IDP created earlier in Creating an Identity Lookup Provider.
- From the Lookup Type drop-down, select Custom.
- From the Identity drop-down, select Client ID.
- Click Update.
Configuring Device Lookup
To configure SecureW2 to lookup Device Identity during RADIUS authentication, you need to make a few changes to the Account Lookup Policy.
- Navigate to the Settings tab.
- From the Identity Provider Lookup drop-down list, select the Identity Lookup Provider created in the previous section (refer Creating an Identity Lookup Provider).
- From the Identity drop-down list, select Client ID.
- Select the Revoke On Failure checkbox, if necessary.
- Click Update.
Configuring User Role Policy
Group Role Policy for Network Authentication – Create Role Policies for any Groups that you want to give differentiated network access. You can then leverage Cloud RADIUS’ Dynamic Policy Engine to send unique RADIUS attributes based on the Group users belong to with your Network policies.
- Navigate to Policy Management > Roles Policies.
- Click Add Role.
- For the Name field, enter the name of the role policy.
- For the Display Description field, enter the suitable description for the role policy.
- Click Save.
- Select the Conditions tab.
- From the Identity Provider drop-down list, select the Azure Identity Lookup Provider created in the previous section (refer Creating an Identity Lookup Provider).
- For Groups field, select the group that you want to apply this Role to. The group names that show up here are the Local Groups that we configured previously in our Identity Lookup Provider (refer Configuring Groups).
- Click Update.
Creating a Network Policy to Segment Groups into Virtual Networks
The purpose of a Network Policy is to specify how Cloud RADIUS will authorize access to a particular User Role. A typical Network Policy would say something like: “If User Role = Staff, authorize access and assign them to VLAN 2”. You can configure any RADIUS Attribute to be sent to the wireless controller. If you leave the attribute section blank, it will just send Access-Accept.
To create and configure the Network Policy, perform following steps.
- Navigate to Policy Management > Network Policies.
- Click Add Network Policy.
- For the Name field, enter the name of the network policy.
- For the Display Description field, enter the suitable description for the network policy.
- Click Save.
- Select the Conditions tab.
- Select Match All or Match Any based on your requirement to set an authentication criteria. In the case explained here, we are selecting Match All.
- Click Add rule.
- Expand Identity and click Select adjacent to the Role option.
- Click Save.
- The Role option appears under the Conditions tab.
- From the Role Equals drop-down list, select the role policy you created earlier (refer User Role Policy for Enrollment section). You can select multiple User Roles to assign to a Network Policy.
- Select the Settings tab.
- Click Add Attribute.
- From the Dictionary drop-down-list, select an option: Radius:IETF or Custom.
- From the Attribute drop-down-list, select Filter-Id.
- In the Value field, enter the appropriate value for the attribute.
- Click Save.
Enhanced Network Security Based Azure & Intune Groups with SecureW2
Building a secure network infrastructure, to a great extent, depends on how your network is segmented. It ultimately decides who has what degree of access and how the traffic flows in your network. Especially in a cloud environment, well-defined network segmentation can make a network more efficient and secure and, with the right solutions, can help you freeze the movement of any breaches in the event of a cyber attack.
SecureW2 solutions can help optimize network segmentation to enhance the security and efficiency of any organization. Our onboarding solution, JoinNow MultiOS, can automatically configure your BYODs with the necessary settings, including installing trusted server certificates at the time of onboarding. For managed devices, SecureW2 solutions include creating certificate auto-enrollment Gateways APIs and pushing configuration profiles to every managed device. Once your endpoints are enrolled for certificates, Cloud RADIUS can apply policies to them at the time of authentication, such as segmenting your Azure and Intune groups to different VLANs.
Our solutions are vendor-neutral and, therefore, can be integrated with any existing network infrastructure, including existing Wi-Fi, VPN, Web, and Firewall infrastructure, without the need for technology forklift upgrades. This means network segmentation can be achieved without overhauling the existing network setup. Read one of our customer success stories to know how SecureW2 helped them achieve improved network security in a hybrid Active Directory and Azure AD environment.
Schedule a Demo
Sign up for a quick demonstration and see how SecureW2 can make your organization simpler, faster, and more secure.
Schedule NowPricing Information
Our solutions scale to fit you. We have affordable options for organizations of any size. Click here to see our pricing.
Check Pricing