Home Knowledge Base SecureW2 Documentation Configuring Dynamic RADIUS with Azure to Support WPA2-Enterprise

Configuring Dynamic RADIUS with Azure to Support WPA2-Enterprise

1. Introduction

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 Entra ID. Users are able to use their AD credentials to enroll for certificates for 802.1x authentication, and CloudRADIUS can additionally validate their identity at the moment of authentication and use that information to authorize varying levels of access.

2. Registering a New App

To register a new application in Azure, perform the following steps:

    1. Log in to the Microsoft Azure portal.
    2. Type App registrations in the search box and click App registrations.
    3. On the App registrations page, click New registration.
    4. On the Register an application page, enter the name of the application in the Name field.
    5. In the Supported account types section, specify who can use the application by selecting any one of the following options:
      1. Accounts in this organizational directory only (MSFT only – Single tenant)
      2. Accounts in any organizational directory (Any  Microsoft Entra ID tenant– Multitenant)
      3. Accounts in any organizational directory (Any  Microsoft Entra ID tenant– Multitenant) and personal Microsoft accounts (e.g., Skype, Xbox)
      4. Personal Microsoft accounts only
    6. In the Redirect URI (optional) section, from the Select a platform drop-down list, select Web and in the URL field, enter a unique SecureW2 Organization URL such as https://myorganization-auth.securew2.com/auth/oauth/code
    7. Click Register. The following screen is displayed.
    8. Copy the Application (client) ID, Object ID, and Directory (tenant) ID values to your console.

3. Creating a Client Secret

To create a client secret, perform the following steps:

  1. On the left pane, go to Manage and click Certificates & secrets.
  2. Click New client secret.
  3. In the Add a client secret pop-up window, enter a description for the client secret in the Description field.
  4. From the Expires drop-down list, select the expiration date of the client secret.
  5. Click Add.
  6. The client’s secret is displayed under the Value column.

    NOTE: Ensure that you save the client secret on your console properly, as this secret is non-recoverable.

4. Creating a Provider URL and Client ID

To create a provider URL and client ID, perform the following steps:

  1. Navigate to the Overview section.
  2. Copy the Application (client) ID and Directory (tenant) ID values to your console.
  3. Insert it into the following URL: https://login.microsoftonline.com/{Directory (tenant) ID}. This should look like this:
    https: //login.microsoftonline.com/561bc66f-1d86-4244-8bc4-5eb12cba45ac
  4. Save this for later.

5. Providing API Permissions

Finally, provide this application permission to access the data in our Entra ID.

  1. On the left pane, go to Manage and click API permissions.
  2. Click Add a permission.
  3. After adding the permissions, the configured APIs are displayed under the Configured permissions section.
  4. Click Grant admin consent for {your organization} to grant consent for the requested permissions.
  5. In the Grant admin consent confirmation pop-up window, click Yes.
  6. The configured APIs are granted consent, and the following screen is displayed.

6. Configuring SecureW2 for Azure

Now that we’ve created an App in Azure, we need to create a Core Platform in the JoinNow Management Portal to communicate with Azure, and, lastly, create the user and group policies we want to implement for our network authentication.

6.1 Getting Started

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

NOTE: If you have already configured the JoinNow Management Portal for your network, you may skip this step.

  1. Log in to the JoinNow Management Portal.
  2. Navigate to Device Onboarding > Getting Started.
  3. On the Quickstart Network Profile generator page, from the Generate Profile for drop-down list, select Internal User Authentication
  4. From the Profile Type drop-down list, select Wireless.
  5. In the SSID text box, enter a suitable name for the SSID.
  6. From the Security Type drop-down list, select WPA2-Enterprise.
  7. From the EAP Method drop-down list, select EAP-TLS.
  8. From the Policy drop-down list, retain DEFAULT.
  9. From the Wireless Vendor drop-down list, select a vendor.
  10. From the RADIUS Vendor drop-down list, select a RADIUS vendor.
  11.  Click Create. The Getting Started wizard typically takes 60-90 seconds to create the profile.

7. Configuring RADIUS Lookup in Cloud RADIUS

A Core Provider is the system that proves a user’s or device’s identity. Creating a core provider 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 Core Provider.

7.1 Creating an Entra ID Signal Source

To create an Entra ID Signal Source, perform the following steps:

  1. Navigate to Integration Hub > Core Platforms.
  2. Click Add.
  3. In the Name field, enter the name of the signal source.
  4. In the Description field, enter a suitable description for the signal source.
  5. From the Type drop-down list, select Entra ID.

  6. Click Save.
  7. The page refreshes and displays the Configuration, Attribute Mapping, and Groups tabs.
  8. Click the Configuration tab.
  9. Under the Configuration section, provide the following information.
    1. From the Access Token Grant Flow drop-down list, select one of the following options.
      • Client Credentials – The Client Credentials option doesn’t require frequent authorization of token updates from the Azure portal. This is the recommended method.
      • Authorization Code – The Authorization Code option requires authorization of token updates from the Azure Portal every 90 days.
    2. In the Provider URL field, enter the URL you created earlier using the Directory (tenant) ID: https://login.microsoftonline.com/{Directory (tenant) ID}. This should look like this:
      https://login.microsoftonline.com/561bc66f-1d86-4244-8bc4-5eb12cba45ac
    3. In the Client Id field, enter the Application (client) ID that you retrieved from Azure Portal earlier (refer to the Registering a New App section).
    4. In the Client Secret field, enter the Client secret you generated in Azure Portal earlier (refer to the Creating a Client Secret section).
    5. In the Validity Period field, select the client secret’s expiry date.
    6. Under the Lookup Configuration section, from Device Lookup via drop-down list, select the required device lookup attribute from the options listed below:
      • Entra ID Device ID – Lookup is performed using Entra ID. 
      • Entra ID Name – Lookup is performed using device name. For Additional Search Filters, check the required check-box for:
        1. Is Managed – checks if the device is managed
        2. Is Compliant – checks if the device is compliant
    7. Click Update.

7.1.1 Configuring Attribute Mapping

The Lookup Attributes allow you to specify how to map a user’s identity from a Core Provider to the user in the JoinNow Management Portal. 

  1. Click the Attribute Mapping tab. 
  2. From the Attribute Mapping Type drop-down, select the category to display the recommended attributes. The following are the attribute types offered by JoinNow for Entra ID Signal Source:
    1. Device 
    2. User
    3. Custom
  3. Click Update after selecting the required attributes.

    NOTE: The Entra ID Signal Source Lookup Attributes allow you to specify how to map a user’s identity from Entra ID to the user in the JoinNow Management Portal. You can select “User Defined” in the Remote Attribute filed and use any of the following attributes:
    AttributeDescription
    accountEnabledThe accountEnabled attribute indicates whether the user account is enabled or disabled. If the account is enabled, the value is set to “True”; otherwise, it is “False. ” The default value is “True. ” The attribute supports the $filter with operators such as eq, ne, not, and in. Only callers who have the Global Administrator or Cloud Device Administrator role can set this attribute.
    alternativeSecurityIdsThe alternativeSecurityIds attribute indicates a single user identity or a collection of user identities from one or more external Core Platforms. This is a mandatory attribute and supports the $filter with operators such as eq, not, ge, and le.
    approximateLastSignInDateTimeThe approximateLastSignInDateTime attribute indicates the timestamp type in ISO 8601 format and UTC time for both date and time information. This is a read-only attribute and supports the $filter with operators such as eq, ne, not, ge, le, $orderBy, and eq on null values.
    complianceExpirationDateTimeThe complianceExpirationDateTime attribute indicates the timestamp when the device is no longer compliant. Using the ISO 8601 format, the timestamp type shows date and time information always in UTC time. This is a read-only attribute.
    createdDateTimeThe createdDateTime attribute indicates the creation date of the user object. This is a read-only attribute.
    deletedDateTimeThe deletedDateTime attribute indicates the date and time when the user object was deleted, or null if the object has not been deleted.
    deviceCategoryThe deviceCategory attribute is a user-defined attribute set by Intune. This attribute automatically adds devices to groups and makes device management easier.
    deviceIdThe deviceId attribute is the unique identifier that the Azure Device Registration Service assigns to the device when it registers. You can use this identifier as an alternate key to reference the device object. This attribute supports the $filter with these operators such as eq, ne, not, and startsWith.
    deviceMetadataA device metadata package contains multiple XML documents, each explaining the various components of the device attributes.
    deviceOwnershipThe deviceOwnership attribute indicates the device’s ownership. This attribute is set by Intune. Possible values are unknown, company, and personal.
    deviceVersionThis attribute indicates the version of the device.
    displayNameThe displayName attribute indicates the display name for the device and supports the $filter with these operators such as eq, ne, not, ge, le, in, startsWith, $search, $orderBy, and eq on null values. This is a mandatory attribute.
    domainNameThe domainName attribute indicates the on-premises domain name for devices joined to a Hybrid Entra ID. This attribute is set by Intune.
    enrollmentProfileNameThe enrollmentProfileName attribute indicates the enrollment profile applied to the device. This attribute is set by Intune. Examples of enrollment profiles are Apple Device Enrollment Profile, Device Enrollment- Corporate device identifiers, and Windows Autopilot profile name.
    enrollmentTypeThe enrollmentType attribute indicates the device’s enrollment type. This attribute is set by Intune. Possible values are unknown, userEnrollment, deviceEnrollmentManager, appleBulkWithUser, appleBulkWithoutUser, windowsAzureADJoin, windowsBulkUserless, windowsAutoEnrollment, windowsBulkAzureDomainJoin, and windowsCoManagement.
    extensionAttributesThe device has 1-15 extension attributes. You cannot select the individual extension attributes and these attributes are stored in the cloud. You can set them when you create or update a device object in Entra ID and support the $filter with these operators such as eq, not, startsWith, and eq on null values.
    idThe id attribute is the device’s unique identifier. It is inherited from directoryObject and is a key that cannot be null. This attribute is read-only and supports the $filter with operators such as eq, ne, not, and in.
    isCompliantThe isCompliant property indicates whether the device is compliant with a Mobile Device Management (MDM) app. The value is “True” if the device is compliant or “False” if not. This can only be updated by Intune for any device OS type or by an approved MDM app for Windows OS devices. It supports the $filter with operators such as eq, ne, not, and in.
    isManagedThe isManaged attribute indicates whether the device is managed by a Mobile Device Management (MDM) app. The value is “True” if the device is managed, or “False” if not. This can only be updated by Intune for any device OS type or by an approved MDM app for Windows OS devices and supports the $filter with operators such as eq, ne, not, and in.
    isRootedThe isRooted attribute indicates whether the device is rooted if the value is “True“or jailbroken if the value is “False. ” This value can only be updated by Intune.
    managementTypeThe managementType attribute indicates the device’s management channel. This attribute is set by Intune, and its value can be one of the following: eas, mdm, easMdm, intuneClient, easIntuneClient, configurationManagerClient, configurationManagerClientMdm, configurationManagerClientMdmEas, unknown, jamf, or googleCloudDevicePolicyController.
    manufacturerThe manufacturer attribute specifies the device manufacturer. This is a read-only attribute.
    mdmAppIdThe mdmAppId attribute specifies the application ID that registers the device in MDM. This is a read-only attribute and supports the $filter with operators such as eq, ne, not, and startsWith.
    modelThe model attribute indicates the device model. This is a read-only attribute.
    onPremisesLastSyncDateTimeThe onPremisesLastSyncDateTime attribute indicates the last time that the object synchronized with the on-premises directory. The attribute uses the Timestamp type, which represents date and time information in UTC time and ISO 8601 format. For example, 2014-01-01T00:00:00Z is midnight UTC on January 1, 2014. This is a read-only attribute and supports the $filter with operators such as eq, ne, not, ge, le, and in.
    onPremisesSyncEnabledThe onPremisesSyncEnabled attribute specifies whether the object synchronizes from an on-premises directory. The value is “True” if the object synchronizes from an on-premises directory, “False” if the object used to synchronize from an on-premises directory but no longer does, or “Null” if the object has never synchronized from an on-premises directory. The default value is “Null“. This is a read-only attribute and supports the $filter with operators such as eq, ne, not, in, and eq on null values.
    operatingSystemThe operatingSystem attribute specifies the device’s operating system type. It is mandatory and supports the $filter with operators such as eq, ne, not, ge, le, startsWith, and eq on null values.
    operatingSystemVersionThe operatingSystemVersion attribute specifies the device’s operating system version. It is mandatory and supports the $filter with operators such as eq, ne, not, ge, le, startsWith, and eq on null values.
    physicalIdsThe physicalIds attribute specifies the unique values that identify the device. This is a mandatory attribute and supports the $filter with these operators such eq, not, ge, le, startsWith, /$count eq 0, /$count ne 0.
    profileTypeThe profileType attribute indicates the device profile type. The possible values are RegisteredDevice (default), SecureVM, Printer, Shared, or IoT.
    registrationDateTimeThe registrationDateTime attribute specifies the date and time that the device registered. The attribute uses the timestamp type, which represents date and time information in UTC time and ISO 8601 format. For example, 2014-01-01T00:00:00Z is midnight UTC on January 1, 2014. This is a mandatory read-only attribute.
    systemLabelsThe systemLabels attribute indicates the list of labels that the system applies to the device. This attribute supports the $filter with these operators such as /$count eq 0, /$count ne 0.
    trustTypeThe trustType attribute specifies the trust type for the joined device. This is a read-only attribute and can have one of the following values: Workplace (for personal devices), AzureAd (for cloud-only joined devices), or ServerAd (for on-premises domain joined devices that are also joined to Entra ID).

7.2 Configuring Groups

Finally, Cloud RADIUS can perform a User Group Lookup, allowing you to create network access policies based on a user’s group membership.

  1. Click the Groups tab.
  2. Click Add.

  3. On the displayed page, in the Local Group field, enter the group’s name. This group name can be used to configure network policies.
  4. In the Remote Group field, enter the Object ID that you retrieved from Azure Portal earlier (refer to the Registering a New App section).
  5. Click Create.
  6. Click Update.
  7. Repeat all the steps above as needed to create as many groups as required.

7.3 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 Security Signal Sources
  • Configuring Policy Workflow
  • Configuring Network Policies

7.3.1 Configuring Security Signal Sources

Lookup Policies are the ways to tie the new Core Platform to domains. Here, you create a condition that ties our domain to the new Core Platform created in the previous section.

  1. Navigate to Policy Management > Security Signal Sources.
  2. Click Add Security Signal Source.

  3. In the Name field, enter the name of the Security Signal Source.
  4. In the Display Description field, enter a suitable description for the Security Signal Source.
  5. Lookup Purpose – Purpose of Account Lookup
    1. Certificate Issuance – To lookup the user/device account during Enrollment.
    2. RADIUS Authentication – To lookup the user/device account during RADIUS Authentication.
  6. Click Save.
  7. The page refreshes and displays the Conditions and Settings tabs.
  8. Select the Conditions tab.
  9. From the Provider drop-down list, select the Signal Source created in the previous section (refer to the Creating an Entra ID Signal Source section).
  10. From the Identity drop-down list, select the required identity type.
  11. Configure Regex to match the values of your devices configured in the Identity field.

  12. Select the Settings tab.
  13. From the Provider drop-down list, select the Signal Source created in the previous section (refer to the Creating an Entra ID Signal Source section).
  14. From the Lookup Type drop-down list, select the required lookup type.
  15. From the Identity drop-down list, select the required Identity for the lookup.
  16. Select the Revoke On Failure checkbox to automatically revoke a certificate if an account lookup fails, if necessary.

  17. Click the Validate Configuration button to check if the lookup is valid.
  18. On the Validate Configuration pop-up window, in the Enter a valid identity field, enter the identity (user/device) to validate the lookup, and then click Validate. 

  19. After the successful validation, the associated attributes and groups of the Signal Source are displayed on the Lookup Details prompt. The admin can use this information to configure the network policies and verify the user’s validity. When the Admin enters an invalid identity on the Validate Configuration pop-up window, the following error message is displayed: “Account validation failed”.
  20. Click Update.

7.3.2 Configuring Policy Workflow

The following Policy Workflows need to be configured:

  • Policy Workflow for Enrollment
  • Group Policy Workflow for Network Authentication
  • Default Fallback Policy Workflow
7.3.3.1 Policy Workflow for Enrollment

The first Policy Workflow to be created is for enrollment. JoinNow MultiOS will use this policy when the end users enroll themselves for certificates. MultiOS will not use the OAuth application you previously created in Azure. Instead, you need to use a separate SAML Application in Azure.

NOTE: Refer to one of our SAML Identity Provider configuration guides if you have not already set this up. Once you have your SAML IdP, start here:

  1. Navigate to Policy Management > Policy Workflows.
  2. Click Add Policy Workflow.
  3. In the Name field, enter the name of the Policy Workflow.
  4. In the Display Description field, enter a suitable description for the Policy Workflow.

  5. Click Save.
  6. The page refreshes and displays the Conditions tab.
  7. Select the Conditions tab.
  8. From the Core Provider drop-down list, select the core provider you created earlier.

  9. Click Update.
7.3.3.2 Policy Workflow for Network Authentication

Next, 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 you will configure next.

  1. Navigate to Policy Management > Policy Workflows.
  2. Click Add Policy Workflow.
  3. In the Name field, enter the name of the Policy Workflow.
  4. In the Display Description field, enter a suitable description for the Policy Workflow.
  5. Click Save.
  6. The page refreshes and displays the Conditions tab.
  7. Select the Conditions tab.
  8. From the Core Provider drop-down list, select the Entra ID Signal Source created in the previous section (refer to the Creating an Entra ID Signal Source section).

  9. Click Update.
7.3.3.3 Group Policy Workflow for Network Authentication

Finally, create Role Policies for any Groups to which you want to give differentiated network access. You can then leverage Cloud RADIUS Dynamic Policy Engine to send unique RADIUS attributes based on the Groups users belong to with your Network policies.

  1. Navigate to Policy Management > Policy Workflows.
  2. Click Add Policy Workflow.
  3. In the Name field, enter the name of the Policy Workflow.
  4. In the Display Description field, enter a suitable description for the Policy Workflow.
  5. Click Save.
  6. The page refreshes and displays the Conditions tab.
  7. Select the Conditions tab.
  8. From the Core Provider drop-down list, select the Entra ID Signal Source created in the previous section (refer to the Creating an Entra ID Signal Source section).
  9. In the Groups field, select the group to which you want to apply this Policy Workflow. The group names listed here are the Local Groups that we previously configured in Core Platform (refer to the Configuring Groups section).

  10. Click Update.

7.3.4 Default Fallback Policy Workflow

You may notice that your User Role policies have a DEFAULT FALLBACK ROLE POLICY after you create a Core Platform. This policy allows the user to still authenticate to the network, but assigns them a unique role if the Identity lookup fails.

This ensures that both users do not experience disconnections if there is a small disruption in the connection between Azure and Cloud RADIUS. Your network can remain secure, and you can have those users automatically assigned to a Guest VLAN.

NOTE: The DEFAULT FALLBACK ROLE POLICY is by default assigned to the DEFAULT NETWORK POLICY.

7.4 Configuring Network Policies

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 the following steps:

  1. Navigate to Policy Management > Network.
  2. Click Add Network Policy.
  3. In the Name field, enter the name of the network policy.
  4. In the Display Description field, enter a suitable description for the network policy.

  5. Click Save.
  6. The page refreshes and displays the Conditions and Settings tabs.
  7. Select the Conditions tab.
  8. Select Match All or Match Any based on your requirement to set authentication criteria. In the case explained here, we are selecting Match All.
  9. Click the Add rule and select the role you want to assign to this network policy. It is essential to select the appropriate policy workflow, as it triggers the network policy. This menu offers various rules that you can select based on your business requirements.

  10. Click Save.
  11. The Policy Workflow option appears under the Conditions tab.
  12. From the Policy Workflow Equals drop-down list, select the role policy you created earlier (refer to the Policy Workflow for Enrollment section). You can select multiple User Roles to assign to a Network Policy.
  13. Select the Settings tab.
  14. From the Access drop-down list, select any one of the options to allow or deny authentication requests. The default value is “Allow”.
  15. To configure MFA, select the checkbox to enable MFA.
  16. From the Perform MFA Using drop-down list, select a Core Provider for MFA.
  17. Click Add Attribute.
    1. From the Dictionary drop-down list, select an option:
      • Radius: IETF – This is what we will use for the following attributes, as we are using standard RADIUS attributes for VLAN assignment.
      • Custom: Used for any VSAs (Vendor-Specific Attributes).
    2. From the Attribute drop-down list, select any of the following options:
      • Framed-Protocol
      • Framed-IP-Address
      • Framed-IP-NetMask
      • Framed-Routing
      • Filter-Id
      • Framed-MTU
      • Framed-Compression
      • Reply-Message
      • Framed-Route
      • Framed-IPX-Network
      • State
      • Class
      • Session-Timeout
      • Tunnel-Type
      • Tunnel-Medium-Type
      • Tunnel-Private-Group-ID
      • Framed-Pool
      • User-Name
    3. In the Value field, enter the appropriate value for the attribute.

      Repeat as necessary for all the attributes you want to send for your User Role.
    4. Click Save

  18. Click Update.

This completes all the necessary configurations to integrate Entra ID with CloudRADIUS.

More Microsoft Entra ID Explainers