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

Sign up for a Webinar!

Configuring Dynamic RADIUS with Azure to Support WPA2-Enterprise

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 can 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 also published documentation on How to Set Up Passwordless WPA2-Enterprise and Tie Azure AD to Network Security

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.

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.

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.

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.

    The Azure IDP Lookup Attributes allow you to specify how to map a user’s identity from Entra ID to the user in the JoinNow Management Portal.
    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 with 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 identity providers. 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 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).

Configuring JoinNow Management Portal

Now that we’ve created an App in Azure, we need to create an Identity Lookup Provider in the JoinNow Management Portal to communicate with Azure, and, lastly create the various policies we want to implement for segmenting the users/devices and for network authentication accordingly.

Configuring an Identity Lookup Provider

An Identity Lookup Provider is a system that proves a user’s or device’s identity. Configuring an IDP in the JoinNow Management Portal helps in integrating to your Azure user database for verification during certificate issuance and wifi authentication.

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

Creating an Identity Lookup Provider

To create an Identity Lookup Provider, perform the following steps:

  1. Navigate to Identity Management > Identity Providers.
  2. Click Add Identity Provider.
  3. In the Name field, enter the name of the identity lookup provider.
  4. In the Description field, enter the suitable description for the identity lookup provider.
  5. From the Type drop-down list, select Azure Identity Lookup.
  6. Click Save.
  7. The page refreshes and displays the Configuration, Attribute Mapping and Groups tabs.
  8. Select 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. Under the Lookup Configuration section, from Perform Device lookup using drop-down list, select the required device lookup attribute from the options listed below:
          • Azure Device ID – Lookup is performed using Azure ADID
          • Azure Device Name – Lookup is performed using the device name. For Additional Search Filters, check the required checkbox for:
            1. Is Managed – Checks if the device is managed
            2. Is Compliant – Checks if the device is compliant

    After updating the Identity Provider, the client secret will not be retrievable. Therefore, make sure that you save it in a secure place.

  10. Click Update.

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. Navigate to Identity Management > Identity Providers.
  2. Click the Edit link on the Identity Lookup Provider created earlier (refer to the Creating an Identity Lookup Provider section).
  3. Select the Groups tab.
  4. Click Add.
  5. On the displayed page, in the Local Group field, enter the name of the group. This group name can be used to configure the Network Policies.
  6. In the Remote Group field, enter the Object ID that you retrieved from Azure Portal earlier (refer to the Registering a New App section).
  7. Click Create.
  8. Click Update.
  9. Repeat all the steps above as needed to create as many groups as required.

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.

Configuring Account Lookup Policy

The Account Lookup policy is used for user or device lookup during RADIUS authentication.

To configure an Account Lookup Policy, perform the following steps:

  1. Navigate to Policy Management > Account Lookup Policies.
  2. Click Add Account Lookup Policy.
  3. In the Name field, enter the name of the account lookup policy.
  4. In the Display Description field, enter a suitable description of the account lookup policy.
  5. Click Save.
  6. The page refreshes and displays the Conditions and Settings tabs.
  7. Select the Conditions tab.
  8. Under the Conditions section, from the Provider drop-down list, select the Identity Provider used for authentication during certificate issuance.
  9. From the Identity drop-down list, select any one of the following options as per requirement:
    1. Username
    2. Certificate-CommonName
    3. Certificate-SAN-UPN
    4. Certificate-SAN-Email
  10. Configure Regex to match the values of your devices configured in the Identity field.
  11. Click Update.

Configuring Device Lookup

You need to make a few changes to the Account Lookup Policy to configure the JoinNow Management Portal to lookup Device Identity during RADIUS authentication.

  1. Navigate to Policy Management > Account Lookup Policies.
  2. Click the Edit link on the Account Lookup Policy created earlier (refer to the Configuring Account Lookup Policy section).
  3.  Select the Settings tab.
  4. Under the Settings section, from the Provider drop-down list, select the Identity Lookup Provider created in the previous section (refer to the Creating an Identity Lookup Provider section).
  5. From the Identity drop-down list, select any one of the following options based on your requirements:
    1. Certificate-SAN-DNS
    2. Client ID
    3. Computer Identity
  6. In the Lookup Purpose field, check the required checkbox:
    1. Certificate Issuance – To lookup user/device accounts during Certificate Issuance.
    2. RADIUS Authentication – To lookup user/device accounts during RADIUS Authentication.
  7. Select the Revoke On Failure checkbox to automatically revoke a certificate if an account lookup fails, if necessary.
  8. Select the Revoke On Failure checkbox to automatically revoke a certificate if an account lookup fails, if necessary.
  9. Click the Validate Configuration button to check if the lookup configuration is valid.
  10. On the Validate Configuration pop-up window, in the Enter a valid identity field, enter the identity (user/device) to validate the lookup configuration and click Validate.
  11. After the successful validation, the associated attributes and groups of the Identity Provider Lookup are displayed on the Lookup Details prompt. The admin can use this information to configure the network policies and verify the user’s validity.
  12. When the Admin enters an invalid identity on the Validate Configuration pop-up window, the following error message is displayed: “Account lookup failed.”
  13. Click Update.

Configuring Policy Engine Workflow

Policy Engine Workflow can segment users and devices based on defined criteria or attributes. These segmented groups can then be assigned specific network access configurations according to organizational requirements or privileges. Once the Policy Engine Workflow is established, Cloud RADIUS can dynamically enforce the configured Network Policies, which will be set up in the subsequent steps.

To create Policy Engine Workflow, follow these steps:

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

Configuring 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, “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:

  1. Navigate to Policy Management > Network Policies.
  2. Click Add Network Policy.
  3. In the Name field, enter the name of the network policy.
  4. In the Display Description field, enter the 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 Add rule.
  10. Expand Identity and select the Role option.
  11. Click Save.
  12. The Role option appears under the Conditions tab.
  13. From the Role Equals drop-down list, select the Policy Engine Workflow you created earlier (refer to the Configuring Policy Engine Workflow section). You can select multiple Policy Engine Workflows to assign to a Network Policy.
  14. Select the Settings tab.
  15. Click Add Attribute.
    1. From the Dictionary drop-down-list, select an option: Radius:IETF or Custom.
    2. From the Attribute drop-down-list, select any of the following options based on your requirements:
      1. Framed-Protocol
      2. Framed-IP-Address
      3. Framed-IP-NetMask
      4. Framed-Routing
      5. Filter-Id
      6. Framed-MTU
      7. Framed-Compression
      8. Reply-Message
      9. Framed-Route
      10. Framed-IPX-Network
      11. State
      12. Class
      13. Session-Timeout
      14. Tunnel-Type
      15. Tunnel-Medium-Type
      16. Tunnel-Private-Group-ID
      17. Framed-Pool
    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.
  16. Click Save.

This completes all the necessary configurations to enable the Dynamic RADIUS solution in your infrastructure.

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 for further details.