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 Azure AD. Users are able to use their AD credentials for 802.1x authentication, but we can take it one step further. Azure customers no longer need to be shackled to password-based authentication methods now that SecureW2 offers the first Azure passwordless solution.

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

This article covers how to implement Dynamic RADIUS in Azure. We published documentation on How To Configure WPA2-Enterprise With Microsoft Azure AD, as well.

Registering a New App

  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 Azure AD directory – Multitenant)
    3. Accounts in any organizational directory (Any Azure AD directory – Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
    4. Personal Microsoft accounts only
  6. In the Redirect URI (optional) field, from the Select a platform drop-down list, select Web and in the URL field, enter an 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

  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

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

  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. The value is set to “True” if the account is enabled; otherwise, “False“. The default value is “True“. The attribute supports the $filter with these 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 identity providers. This is a mandatory attribute and supports the $filter with these 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 these 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 it easier to manage devices.
    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 one of the documents explains the various components of the device attributes.
    deviceOwnershipThe deviceOwnership attribute indicates the ownership of the device. This attribute is set by Intune. The 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 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 that are joined to Hybrid Azure AD. This attribute is set by Intune.
    enrollmentProfileNameThe enrollmentProfileName attribute indicates the enrollment profile that is 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 enrollment type of the device. This attribute is set by Intune. The 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 supports the $filter with these operators such as eq, not, startsWith, and eq on null values.
    idThe id attribute is the unique identifier for the device. It is inherited from directoryObject and is a key that cannot be null. This attribute is read-only and supports the $filter with these operators such as eq, ne, not, in.
    isCompliantThe isCompliant property indicates whether the device is in compliance with 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 and supports the $filter with these 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 these operators such as eq, ne, not, and in.
    isRootedThe isRooted attribute indicates 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 management channel of the device. This attribute is set by Intune and the value can be one of the following: eas, mdm, easMdm, intuneClient, easIntuneClient, configurationManagerClient, configurationManagerClientMdm, configurationManagerClientMdmEas, unknown, jamf, 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 these 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 these 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 these operators such as eq, ne, not, in, and eq on null values.
    operatingSystemThe operatingSystem attribute specifies the operating system type on the device. This is a mandatory attribute and supports the $filter with these operators such as eq, ne, not, ge, le, startsWith, and eq on null values.
    operatingSystemVersionThe operatingSystemVersion attribute specifies the operating system version of the device. This is a mandatory attribute and supports the $filter with these 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 Azure AD).

Configuring SecureW2 for Azure

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

Getting Started

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

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

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

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 Name field, enter the name of the IdP.
  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

  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. 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
    2. 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).
    3. In the Client Secret field, enter the Client secret you generated in Azure Portal earlier (refer to the Creating a Client Secret section).

      NOTE: After updating the Identity Provider, the client secret will not be retrievable. Therefore, make sure that you save it in a secure place.
    4. Click Update.
  10. Click the Authorize link on the Identity Lookup Provider created earlier.


    This will test the connection between JoinNow Management Portal and your Azure App. This is a mandatory step, because it grants our application the final authorization to call the Azure API to grant User Information.

Configuring Groups

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

  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.

    NOTE: This name shows up later as your ‘Group’ in the JoinNow Management Portal when we configure 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 as necessary for any Group you wish to create Network Policies around.

Configuring Policies

Dynamic RADIUS allows the RADIUS to segment users and restrict/allow resources based on information stored in their directory entry. Since enforcement occurs at runtime, changes made to a user’s permissions are propagated throughout the system immediately rather than a day or two later, as is typical with most RADIUS servers.

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

To configure SecureW2 to lookup Device Identity during RADIUS authentication, you need to make a few changes to the Account Lookup Policy.

  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, if necessary.
  7. Click Update.

Configuring User Role Policies

The following user role policies need to be configured:

User Role Policy for Enrollment

The first User Role Policy 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 > Roles Policies.
  2. Click Add Role.
  3. In the Name field, enter the name of the role policy.
  4. In the Display Description field, enter the suitable description for the role policy.
  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.
User Role Policy 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 > Roles Policies.
  2. Click Add Role.
  3. In the Name field, enter the name of the role policy.
  4. In the Display Description field, enter the suitable description for the role policy.
  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 Role Policy for Network Authentication

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

  1. Navigate to Policy Management > Roles Policies.
  2. Click Add Role.
  3. In the Name field, enter the name of the role policy.
  4. In the Display Description field, enter the suitable description for the role policy.
  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 that you want to apply this Role to. The group names that show up here are the Local Groups that we configured previously in our Identity Lookup Provider (refer to the Configuring Groups section).
  10. Click Update.

Default Fallback Role Policy

You may notice that there is a DEFAULT FALLBACK ROLE POLICY in your User Role policies after you create an Identity Lookup Provider. The purpose of this policy is that if the Identity Lookup fails, allow the user to still authenticate to the network but assign them a unique role.

This ensures that both users 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 an authentication criteria. In the case explained here, we are selecting Match All.
  9. Click Add rule.
  10. Expand Identity and click Select adjacent to 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 User Role Policy for Enrollment section). You can select multiple User Roles 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.

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

Conclusion

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

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

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