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

Sign up for a Webinar!
Branding
Branding Branding
Login Check our Prices

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 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 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 application’s name 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 allows you to specify how to map a user’s identity from Azure AD 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 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. Intune sets this attribute. 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 Azure AD. Intune sets this attribute.
    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. Intune sets this attribute. 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 Azure AD 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 read-only attribute 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 the object synchronized with the on-premises directory. The attribute uses the Timestamp type, representing 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, representing 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 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 Azure AD).

Configuring SecureW2 for Azure

Now that we’ve created an App in Azure, we need to 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.

Creating an Identity Provider in SecureW2

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.

To create an IdP in SecureW2:

  1. Log in to the JoinNow Management Portal.
  2. Navigate to Identity Management > Identity Providers.
  3. Click Add Identity Provider.
  4. In the Basic section, enter the name of the IdP in the Name field.
  5. In the Description field, enter a suitable description for the IdP.
  6. From the Type drop-down list, select SAML.
  7. From the SAML Vendor drop-down list, select Azure.
  8. Click Save.

Configuring RADIUS Lookup in Cloud RADIUS

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.

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. It 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).

      After updating the Identity Provider, the client secret will not be retrievable. Therefore, make sure that you save it in a secure place.
    5. 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 to a user’s permissions are propagated 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.

  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 Identity Provider drop-down list, select the Identity Provider created in the previous section (refer to the Creating an Identity Provider in SecureW2 section).
  9. From the Identity drop-down list, select any one of the following options:
    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 Policies section).
  3.  Select the Settings tab.
  4. Under the Settings section, from the Identity Provider Lookup 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:
    1. Username
    2. Certificate-CommonName
    3. Certificate-SAN-UPN
    4. Certificate-SAN-Email
    5. Client ID
    6. Computer Identity
  6. Select the Revoke On Failure checkbox to automatically revoke a certificate if an account lookup fails, if necessary.
  7. Click the Validate Configuration button to check if the lookup is valid.
  8. On the Validate Configuration pop-up window, in the Enter a valid identity field, enter the identity (user/device) to validate the lookup, and click Validate.
  9. 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.
  10. When the Admin enters an invalid identity on the Validate Configuration pop-up window, the following error message is displayed: “Account lookup failed.”
  11. Click Update.

Configuring Policy Engine Workflow

The following Policy Engine Workflows need to be configured:

Policy Engine Workflow for Enrollment

The first Policy Engine Workflow to be created is for enrollment. JoinNow MultiOS will use this policy when the end users enroll 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 set this up already. Once you have your SAML IdP, start here:

  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 identity provider you created earlier (refer to the Creating an Identity Provider in SecureW2 section).
  9. Click Update.
Policy Engine 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 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.
Group Policy Engine 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 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. In the Groups field, select the group you want to apply to this Policy Engine Workflow. The group names that appear here are the Local Groups that we previously configured in our Identity Lookup Provider (refer to the Configuring Groups section).
  10. Click Update.

Default Fallback Policy Engine Workflow

You may notice that there is a DEFAULT FALLBACK ROLE POLICY in your Policy Engine Workflow after you create an Identity Lookup Provider. 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 disconnects if there is a small disruption 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 to the DEFAULT NETWORK POLICY.

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 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 Policy Engine Workflow for Enrollment 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:
      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.

Schedule a Demo

Sign up for a quick demonstration and see how SecureW2 can make your organization simpler, faster, and more secure.

Schedule Now

Pricing Information

Our solutions scale to fit you. We have affordable options for organizations of any size. Click here to see our pricing.

Check Pricing