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

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:
   a. Accounts in this organizational directory only (MSFT only – Single tenant)
   b. Accounts in any organizational directory (Any  Microsoft Entra ID tenant– Multitenant)
   c. Accounts in any organizational directory (Any  Microsoft Entra ID tenant– Multitenant) and personal Microsoft accounts (e.g., Skype, Xbox)
   d. 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.
   

Configuring SecureW2 for Azure

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

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.

Creating an Identity Provider in the JoinNow Management Portal

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 the JoinNow Management Portal:

1. Log in to the JoinNow Management Portal.
2. Navigate to Integrations Hub > Core Platforms.
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 a user’s or device’s identity. 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 a Core Platform for Identity Lookup with Azure

To create a Core Platform, perform the following steps:

1. Navigate toIntegrations Hub > Core Platforms.
2. Click Add.
3. In the Name field, enter the name of the Core Platform.In the Name field, enter the name of the Core Platform.
4. In the Description field, enter the suitable description for the Core Platform.
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. Click the Configuration tab.
9. Under the Configuration section, provide the following information.
   a. 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.
   b. 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
   c. 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).
   d. In the Client Secret field, enter the Client secret you generated in Azure Portal earlier (refer to the Creating a Client Secret section).
   e. Under the Lookup Configuration section, from Perform Device Lookup Using dropdown, 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 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
   
   After updating the Identity Provider, the client secret will not be retrievable. Therefore, make sure that you save it in a secure place.
   f. Click Update.

Configuring Attribute Mapping

The Lookup Attributes allow you to specify how to map a user’s identity from an Identity 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 Azure Lookup:
   a. Device
   b. User
   c. Custom
3.  
4.  
5.  
6. Click Update after selecting the required attributes
   
   NOTE: 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. You can select “User Defined” in the Remote Attribute filed and use any of the below given attributes:
   
   

   Attribute	Description
   accountEnabled	The 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.
   alternativeSecurityIds	The 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.
   approximateLastSignInDateTime	The 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.
   complianceExpirationDateTime	The 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.
   createdDateTime	The createdDateTime attribute indicates the creation date of the user object. This is a read-only attribute.
   deletedDateTime	The deletedDateTime attribute indicates the date and time when the user object was deleted, or null if the object has not been deleted.
   deviceCategory	The deviceCategory attribute is a user-defined attribute set by Intune. This attribute automatically adds devices to groups and makes device management easier.
   deviceId	The 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.
   deviceMetadata	A device metadata package contains multiple XML documents, each explaining the various components of the device attributes.
   deviceOwnership	The deviceOwnership attribute indicates the device’s ownership. This attribute is set by Intune. Possible values are unknown, company, and personal.
   deviceVersion	This attribute indicates the version of the device.
   displayName	The 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.
   domainName	The domainName attribute indicates the on-premises domain name for devices joined to a Hybrid Entra ID. This attribute is set by Intune.
   enrollmentProfileName	The 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.
   enrollmentType	The 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.
   extensionAttributes	The 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.
   id	The 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.
   isCompliant	The 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.
   isManaged	The 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.
   isRooted	The 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.
   managementType	The 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.
   manufacturer	The manufacturer attribute specifies the device manufacturer. This is a read-only attribute.
   mdmAppId	The 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.
   model	The model attribute indicates the device model. This is a read-only attribute.
   onPremisesLastSyncDateTime	The 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.
   onPremisesSyncEnabled	The 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.
   operatingSystem	The 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.
   operatingSystemVersion	The 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.
   physicalIds	The 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.
   profileType	The profileType attribute indicates the device profile type. The possible values are RegisteredDevice (default), SecureVM, Printer, Shared, or IoT.
   registrationDateTime	The 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.
   systemLabels	The 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.
   trustType	The 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).

   1. Click Next.
   2. Click Add.
   3. In the Local Attribute field, enter displayName as the name of the variable.
   4. From the Remote Attribute drop-down list, select User Defined. Enter FirstName in the field that appears next to the Remote Attribute field.
   5. Click Next.
   6. Click Add.
   7. In the Local Attribute field, enter upn as the name of the variable.
   8. From the Remote Attribute drop-down list, select User Defined. Enter Email in the field that appears next to the Remote Attribute field.
   9. Click Next.
   

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 toIntegrations Hub > Core Platforms.
2. Click the Edit link on the Core Platform created earlier (refer to the Creating a Core Platform section).
3. Select the Groups tab.
4. Click Add.
   
5. On the displayed page, in the Local Group field, enter the group’s name. 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.

The following policies need to be configured:

• Configuring Security Signal Sources
• Configuring Policy Workflow
• Configuring Network Policies

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 account lookup policy.
4. In the Display Description field, enter the suitable description for 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 created in the previous section (refer to the Creating an Identity Provider in the JoinNow Management Portal section).
9. From the Identity drop-down list, select the required identity type.
10. Configure Regex to match the values of your devices configured in the Identity field.
    
11. Select the Settings tab.
12. Under the Settings section, from the Identity drop-down list, select the Core Platform created in the previous section (refer to the Creating a Core Platform section).
13. From the Lookup Type drop-down list, select the required lookup type.
14. From the Identity drop-down list, select the required Identity for the lookup.
15. Select the Revoke On Failure checkbox to automatically revoke a certificate if an account lookup fails, if necessary.
    
16. Click the Validate Configuration button to check if the lookup is valid.
17. 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.
    
18. 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. When the Admin enters an invalid identity on the Validate Configuration pop-up window, the following error message is displayed: “Account lookup failed”.
19. Click Update.

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

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 set this up already. Once you have your SAML IdP, start here:

1. Navigate to Policy Management > Policy Workflows.
2. Click Add Policy Workflows.
3. In the Name field, enter the name of the Policy Workflow.
4. In the Display Description field, enter the 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 Identity Provider drop-down list, select the identity provider you created earlier (refer to the Creating an Identity Provider in the JoinNow Management Portal section).
   
9. Click Update.

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 Workflows.
3. In the Name field, enter the name of the Policy Workflow.
4. In the Display Description field, enter the 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 Identity Provider drop-down list, select the Azure Core Platform created in the previous section (refer to the Creating a Core Platform section).
   
9. Click Update.

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 Workflows.
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 Identity Provider drop-down list, select the Azure Core Platform created in the previous section (refer to the Creating a Core Platform section).
9. In the Groups field, select the group to which you want to apply for this Policy Workflow. The group names that show up here are the Local Groups that we previously configured in our Core Platform (refer to the Configuring Groups section).
   
10. Click Update.

Default Fallback Policy Workflow

You may notice that your User Role policies have a DEFAULT FALLBACK ROLE POLICY after you create an 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 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 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 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 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.
    
14. Select the Settings tab.
    
15. Click Add Attribute
    a. From the Dictionary drop-down list, select an option: Radius: IETF or Custom.
    b. 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
    c. 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 integrate Entra ID with CloudRADIUS.