Configuring Dynamic RADIUS with Azure to Support WPA2-Enterprise

Configuring Dynamic RADIUS with Azure to Support WPA2-Enterprise

Azure customers have had a difficult time implementing a RADIUS solution because Azure is more limited than Active Directory (AD) in supporting WPA2-Enterprise and 802.1x. Luckily, SecureW2 offers a PKI solution that integrates with Azure AD. Users are able to use their AD credentials for 802.1x authentication, but we can take it one step further. Azure customers no longer need to be shackled to password-based authentication methods now that SecureW2 offers the first Azure passwordless solution.

SecureW2 has rolled out Dynamic RADIUS, which introduces a revolutionary way to authenticate users and enforce policies to create and strengthen a WPA2-Enterprise network. Once configured in Azure, Dynamic RADIUS can perform enhanced certificate-based authentication, runtime-level policy enforcement, and security redundancies.

This article covers how to implement Dynamic RADIUS in Azure. We published documentation on how to configure WPA2-Enterprise in Azure, as well.

New App Registration

  1. Login to Azure.
  2. Navigate to App Registrations.
  3. Click New Registration.
  4. Configure the following settings:

Note: Use your unique SecureW2 Organization URL as the Redirect URL like so; https://myorganization-auth.securew2.com/auth/oauth/code

Create a Client Secret

  1. Navigate to Manage.
    • Then click Certificates & secrets.
  2. Click New client secret.
    • Enter in a name under Description.
    • Select an expiration date under Expires.
    • Click Add.
    • Now you should see your Client Secret under the Value column.
      • Make sure to save this somewhere safe, as this secret is non-recoverable!

Create a Provider URL and Client ID

  1. Navigate to the Overview section and you will see a screen like below:
  2. Copy your Application (client) ID and save this for later.
  3. Copy your Directory (tenant) ID.
    • Insert it into the following URL:
      • https://login.microsoftonline.com/{Directory (tenant) ID}
      • Should look like this:
        • https://login.microsoftonline.com/561bc67f-1c86-4244-8bd4-5eb23cba44ac
      • Save this for later.

API Permissions

Lastly, we need to give this application permission to access the data in our Azure directory.

  1. Navigate to API Permissions under the Manage section.
  2. Click Add a permission and add the following permissions:
  3. After adding the permissions, click Grant admin consent for {your organization}.

Configuring SecureW2 for Azure

Now that we’ve created an App in Azure, we need to run the Getting Started Wizard, create an Identity Lookup Provider in SecureW2 to communicate with Azure, and lastly create the user and group policies we want to implement for our network authentication.

Getting Started

The Getting Started Wizard creates everything you need for 802.1x. It will generate a RADIUS Server, Network Profiles, a Landing Page for Device Onboarding, and all the default network settings you will need for 802.1x.

Note: If you have already configured SecureW2 for your network, you may skip this step.

  1. Navigate to Getting started under the Device Onboarding section.
  2. Configure the following settings:
    • Keep all the settings the same, except:
      • SSID: Change this to the SSID name you wish to authenticate users with.
      • Wireless Vendor: Change this to your Wireless Infrastructure Vendor.
  3. The Getting Started wizard will typically take 60-90 seconds to create everything required, so please be patient before moving on to the next steps.

Create an Identity Lookup Provider

An identity provider (IDP) is the system that proves the identity of a user/device. Creating an IDP in SecureW2 tells the Cloud Connector system how to connect to your Azure user database, verify user credentials, and issue certificates.

During the authentication process, identity lookup validates that a user is active within the organization by checking the identifying information against the existing users in the Identity Provider.

  1. Navigate to Identity Providers in the Identity Management section.
  2. Click Add Identity Provider.
    • Enter a Name.
    • Description is optional.
    • Select Type as:
      • Identity Lookup Provider
        1. AZURE
  3. Click Configuration while still in the Identity Provider edit menu.
    • For Provider URL enter the URL we created before using the Directory (tenant) ID.
      • https://login.microsoftonline.com/{Directory (tenant) ID}
      • Which should look something like this: https://login.microsoftonline.com/561bc67f-1c86-4244-8bd4-5eb23cba44ac.
    • For Client ID enter in the Client ID that you retrieved from Azure previously.
    • For Client Secret enter in the Client secret you generated in Azure previously and saved in a secure place.
      • After updating the Identity Provider, this secret will not be retrievable, so make sure this is saved in a secure place.
    • Click Update.
  4. Lastly, click Authorize on your new Identity Lookup Provider.
  5. This will test the connection between SecureW2 and your Azure App.
  6. This is a mandatory step, as it grants our application the final authorization to call our Azure API to grant User Info.

Configuring Groups

Lastly, Cloud RADIUS can perform a User Group Lookup so we can create network access policies based off of the Groups a user is in.

  1. Navigate to the Groups tab.
  2. Click Add.
    • Create any name for Local Group.
      • This name will be what shows up later as our ‘Group’ in the SecureW2 Management Portal when we configure policies.
    • In Remote Group enter in the name of your Group as it is configured in Azure.
  3. Click Update.
  4. 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.

Account Lookup Policy

Lookup Policies are how we tie our new Identity Lookup Provider to domains. Here we will create a condition that ties our domain to the new Identity Lookup Provider we just created in the previous section.

  1. Select Lookup under Policy Management.
  2. Click Add Identity Lookup Policy.
  3. Create a Name and click Save.
  4. Navigate to the Conditions tab.
    • Configure the following settings:
  5. Navigate to the Settings tab
    • Select the Identity Lookup Provider we just created in the previous section.

User Role Policy

User Role Policy for Enrollment

The first User Role Policy we will need to create is one for enrollment. This is what MultiOS will use when end users are enrolling themselves for certificates. MultiOS will not use the OAuth application you previously created in Azure, but instead need to use a separate SAML Application in Azure.

Please refer to one of our SAML Identity Provider configuration guides if you haven’t set this up already. Once you have your SAML IDP, start here:

  1. Add a Role.
  2. Create a Name.
    • Because we need multiple User Roles, specifying this is for Enrollment is recommended.
  3. Click Save.
  4. Navigate to Conditions.
  5. Under Identity Provider: select your Azure SAML Identity Provider.
    • Make sure not to select the Azure OAuth Application we just previously created.
  6. Click Update.

User Role Policy for Network Authentication

Next, we need to create a User Role Policy for Network Authentication. This policy will be used by Cloud RADIUS’ Dynamic Policy Engine to lookup user status at the moment of authentication. Then Cloud RADIUS can dynamically apply Network policies, which we will configure next.

  1. Add a Role.
  2. Create a Name.
    • Because we need multiple User Roles, specifying this is for User Network Authentication is recommended.
  3. Click Save.
  4. Navigate to Conditions.
  5. Under Identity Provider: select the Azure Identity Lookup Provider that we just created in the previous section.
  6. Click Update.

Group Role Policy for Network Authentication

Lastly, we need to create Role Policies for any Groups that we want to give differentiated network access. We can then leverage Cloud RADIUS’ Dynamic Policy Engine to send unique RADIUS attributes based on the Group users belong to with our Network policies.

  1. Add a Role.
  2. Create a Name.
    • Because we need two User Roles, specifying this is for Group Network Authentication is recommended.
  3. Click Save.
  4. Navigate to Conditions.
  5. Under Identity Provider: select the Azure Identity Lookup Provider that we just created in the previous section.
  6. Under Groups select the group that we 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.
  7. Click Update.

DEFAULT FALLBACK ROLE POLICY

You may notice that there is a “DEFAULT FALLBACK ROLE POLICY” in your User Role policies after you create a Identity Lookup Provider.

The purpose of this policy is: If the Identity Lookup fails, allow the user to still authenticate to the network but assign them a unique role.

This ensures that both users don’t experience disconnects if there’s a small hiccup in the connection between Azure and Cloud RADIUS, but your network can remain secure and you can have those users auto-assigned into a Guest VLAN.

Note: DEFAULT FALLBACK ROLE POLICY is by default assigned the DEFAULT NETWORK POLICY

Network Policy

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, follow the steps below:

  1. Click Network in the Policy Management section.
  2. Click Add Network Policy.
  3. Enter a Name.
  4. Click Save.
  5. Navigate to Conditions.
    • Select the User Role you want assigned this Network Policy.
      • For this guide, it would be the policy you created in the User Role Policy for Network Authentication section.
      • You can select multiple User Roles to assign a Network Policy to.
  6. Navigate to Settings.
    • Click Add Attribute.
      • Select the Attribute you wish to send to the wireless controller.
      • Enter in the Value appropriate for your attribute.
      • Click Update.
    • Repeat as necessary for all the attributes you want to send for your User Role.

Conclusion

Dynamic RADIUS will revolutionize the way certificate-based WPA2-Enterprise networks are run. Azure customers implementing certificate-based authentication no longer need to worry about certificate management and will benefit from runtime-level policy enforcement and security redundancies. Overall, the user experience will be vastly improved on all fronts.

SecureW2 has affordable options for organizations of all sizes. Click here to see our pricing.