RADIUS Authentication with Azure/Entra ID

Introduction

Many organizations today are adopting cloud-based network solutions for their networks. Microsoft created Azure AD to help clients move their directories from an on-premise Active Directory (AD) server to the cloud.

Some have adapted by syncing their Azure AD with an LDAP server, but this solution still uses PEAP-MSCHAPv2 for authentication.

EAP-TLS (certificate-based authentication) requires a Public Key Infrastructure to enroll and manage certificates to be used for Wi-FI. That’s why Cloud RADIUS was designed to easily integrate with Azure AD, so organizations can easily use their Azure AD for WPA2-Enterprise. Below we break down the solution into three steps:

  1. Tie your PKI Infrastructure to Azure AD.
  2. Tie your RADIUS Infrastructure to Azure AD.
  3. Tie your Device Management platform to the SecureW2 (Parent of Cloud RADIUS) cloud PKI.

Configuring a SAML Azure Application for WPA2-Enterprise

End-users can enter their credentials into the SAML app, which are then sent to and verified by Azure AD. Once Azure AD sends back attributes, the SAML app will share them with SecureW2 PKI to issue certificates.

Creating a SAML Application in Azure

The SAML application is a crucial connection between the IDP and JoinNow MultiOS Management Portal. The application allows a user to enter their credentials, which are then passed to the IDP for verification.

To create a SAML application in Microsoft Azure:

  1. Log in to the Microsoft Azure portal.
  2. Type Enterprise applications in the search box and click Enterprise applications.
  3. Click New Application.

  4. On the Browse Azure AD Gallery page, type SecureW2 JoinNow Connector.

  5. Select SecureW2 JoinNow Connector and in the pop-up window type a name for the application and click Create.

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 MultiOS 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.
  9. The page refreshes and displays the Configuration, Attribute Mapping, and Groups tabs.
  10. Select the Configuration tab.
  11. In the Service Provider (SP) Info section, select and copy the Entity ID and ACS URL values to your console or clipboard. This will be used later while connecting with your SAML application.

Now, SecureW2 Cloud Connector knows how to exchange information with your Azure user database.

Configuring Single-Sign-On in Azure

To configure single sign-on in Microsoft Azure:

  1. In the left pane, navigate to Manage > Single sign-on.
  2. From the Single Sign-on page, select SAML based Sign-on.
  3. On the Set up Single Sign-On with SAML page, in the Basic SAML Configuration section, click the Edit button.
  4. In the Identifier (Entity ID) and Reply URL (Assertion Consumer Service URL) fields, enter the Entity ID value obtained earlier (refer the Creating an Identity Provider in SecureW2 section, step 11).
  5. In the Sign on URL field, enter the ACS URL value obtained earlier (refer the Creating an Identity Provider in SecureW2 section, step 11).
  6. Click Save.
  7. Under the SAML Certificates section, download the Federation Metadata XML file.

Configuring the IDP with Azure Metadata

To upload the Azure metadata to SecureW2:

  1. Log in to the JoinNow MultiOS Management Portal.
  2. Navigate to Identity Management > Identity Providers.
  3. On the Identity Providers page, click the Edit link for the IDP you created earlier (refer the Creating an Identity Provider in SecureW2 section).
  4. Select the Configuration tab.
  5. Under the Identity Provider (IDP) Info section, in the Metadata field, click the Choose File button and select the Metadata XML file you downloaded from Microsoft Azure.
  6. Click Upload and then click Update.

Integrating Active Directory with the Azure SAML Application

After you’ve configured your SAML Application in Azure and SecureW2, it’s time to assign users to it. You can do this by directly assigning users, if you have them stored in Azure, or you can integrate it with your Active Directory. Below we will show you how to do both.

Adding Users to the SAML Application

  1. Log in to the Microsoft Azure portal.
  2. Navigate to Manage > Users and groups.
  3. Click Add user/group.
  4. On the Add Assignment page, under the Users and groups section, click None Selected.
  5. On the Users and groups window, use the Search field to search for the user by name or email.
  6. Select the user, and then click Select.
  7. Click the Assign button.
  8. To create a group, enter Groups in the search box and click Groups.
  9. Click + New group to add a new group.
  10. From the Group type drop-down list, select Security.
  11. In the Group name field, type a suitable name for the group.
  12. In the Group description field, type a description for the group.
  13. From the Membership type drop-down list, select Assigned.
  14. Under the Members section, click No members selected.
  15. On the Add members window, use the Search field to search for the members.
  16. Select the member, and then click Select.
  17. Click Create.

    NOTE: Repeat steps 8-17 to create additional groups and add members, as required.
  18. On the All groups page, click the group that you created earlier.
  19. Copy the Object Id of the group to your console or clipboard and save it to be used later.

Granting SAML Application Access to Active Directory

To allow your SAML application to access Active Directory:

  1. From your Microsoft Azure Portal, type App registrations in the search box and click App registrations.
  2. On the App registrations page, select All applications. This displays a list of all available applications.
  3. Select the application you created earlier (refer the Creating a SAML Application in Azure section).
  4. In the left pane, navigate to Manage > API permissions.
  5. Under the Configured permissions section, click Add a permission.
  6. On the Request API permissions page, click Microsoft Graph.
  7. Click Delegated permissions.
  8. Select the following permissions:
    1. Directory.Read.All
    2. Group.Read.All
    3. User.Read.All


  9. Click Add permissions, the permissions will be added.
  10. To modify the application by using a JSON file, navigate to Manage > Manifest.
  11. Change the value of the groupMembershipClaims variable to “All” in the source code.
  12. Click Save.

Configuring Attribute Mapping and Policies for 802.1x Certificates

Certificates attach a name or device ID to every network connection, establishing device and user trust with a high degree of assurance. They can also be encoded with Azure AD attributes, making it easy to implement group policies and establish strong role-based access control.

Configuring Attribute Mapping in SecureW2

To configure attribute mapping in SecureW2:

  1. Log in to the JoinNow MultiOS Management Portal.
  2. Navigate to Identity Management > Identity Providers.
  3. On the Identity Providers page, click the Edit link of the IDP you created earlier (refer the Creating an Identity Provider in SecureW2 section).
  4. Select the Attribute Mapping tab and then click Add.
  5. In the Local Attribute field, enter email as the name of the variable.
  6. From the Remote Attribute drop-down list, select User Defined and enter http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress in the field that appears next to the Remote Attribute field.
  7. Click Next
  8. Click Add.
  9. In the Local Attribute field, enter displayName as the name of the variable.
  10. From the Remote Attribute drop-down list, select User Defined and enter http://schemas.microsoft.com/identity/claims/displayname in the field that appears next to the Remote Attribute field.
  11. Click Next.
  12. Click Add.
  13. In the Local Attribute field, enter upn as the name of the variable.
  14. From the Remote Attribute drop-down list, select User Defined and enter http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name in the field that appears next to Remote Attribute field.
  15. Click Next.
  16. Select the Basic tab.
  17. In the Group Map Attribute field, enter http://schemas.microsoft.com/ws/2008/06/identity/claims/groups.

  18. Click Update.
  19. On the Identity Providers page, click the Edit link of the IDP you created earlier (refer the Creating an Identity Provider in SecureW2 section).
  20. Select the Groups tab.
  21. Click Add.
  22. In the Local Group field, enter a name.
  23. In the Remote Attribute field, enter the Object ID that you retrieved from the Microsoft Azure portal earlier (refer the Adding Users to the SAML Application section, step 19).
  24. Click Create.

  25. Click Update.

Creating a Network Profile

To create a network profile, perform the following steps:

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

Configuring an Authentication Policy

To add an authentication policy, perform the following steps:

  1. From your JoinNow MultiOS Management Portal, navigate to Policy Management > Authentication Policies.
  2. On the Authentication Policies page, click the Edit link for your network profile’s authentication policy.
  3. Select the Settings tab.
  4. From the Identity Provider drop-down list, select the IDP that you created earlier (refer the Creating an Identity Provider in SecureW2 section).
  5. Select the Enable User Self Service checkbox, if required.
  6. Click Update.

Adding a User Role Policy in SecureW2

To add a user role policy in SecureW2:

  1. Navigate to Policy Management > Role Policies.
  2. On the Role Policies page, click Add Role.
  3. In the Basic section, enter a name and description for the policy in the corresponding fields.
  4. Click Save.
  5. The page refreshes and displays the Conditions tab.
  6. Under the Conditions section, from the Identity Provider drop-down list, select the IDP that you created earlier (refer the Creating an Identity Provider in SecureW2 section).
  7. Click Update.

Adding an Enrollment Policy in SecureW2

To add an enrollment policy in SecureW2:

  1. Navigate to Policy Management > Enrollment Policies.
  2. Click Add Enrollment Policy.
  3. In the Basic section, enter the name of the enrollment policy in the Name field.
  4. In the Display Description field, enter a suitable description for the enrollment policy.
  5. Click Save.
  6. The page refreshes, and the Conditions and Settings tabs are displayed.
  7. Select the Conditions tab.
  8. In the Conditions section, from the Role drop-down list, select the role policy you created earlier (refer the Adding a User Role Policy in SecureW2 section).
  9. From the Device Role drop-down list, select DEFAULT DEVICE ROLE POLICY.
  10. Click Update.

Republishing Network Profile

To republish your network profile:

  1. Navigate to Device Onboarding > Network Profiles.
  2. Click the Re-publish link.
  3. On the Republish Network Profile pop-up window, in the Name field, enter the name of the network profile that needs to be republished.
  4. Click OK. This might take up to 60 to 90 seconds.
  5. After publishing successfully, click the View button against your network profile.
  6. Click JoinNow to start the onboarding process. A new .exe file for the application is downloaded.
  7. Click Next in the application.
  8. Open the downloaded .exe file and enter your Azure credentials when the system prompts.
  9. The system tries to enroll and connect. Check if enrollment is successful.

NOTE: You should republish your network profile every time you make a significant change. The process takes 60-90 seconds.

Creating an App in Azure for RADIUS Lookup

SecureW2’s Cloud RADIUS has the industry-unique ability to perform directory lookups at the moment of authentication. This enables more policy enforcement options and a more robust authentication security.

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.

Attribute Description
accountEnabled The 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.
alternativeSecurityIds The 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.
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 these 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 it easier to manage devices.
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 one of the documents explains the various components of the device attributes.
deviceOwnership The deviceOwnership attribute indicates the ownership of the device. This attribute is set by Intune. The 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 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 that are joined to Hybrid Azure AD. This attribute is set by Intune.
enrollmentProfileName The 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.
enrollmentType The 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.
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 Azure AD and supports the $filter with these operators such as eq, not, startsWith, and eq on null values.
id The 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.
isCompliant The 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.
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 these operators such as eq, ne, not, and in.
sRooted The 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.
managementType The 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
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 these 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 these 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 these operators such as eq, ne, not, in, and eq on null values.
operatingSystem The 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.
operatingSystemVersion The 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.
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 Azure AD).

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. Log in to the JoinNow MultiOS Management Portal.
  2. Navigate to Identity Management > Identity Providers.
  3. Click Add Identity Provider.
  4. In the Name field, enter the name of the identity lookup provider.
  5. In the Description field, enter the suitable description for the identity lookup provider.
  6. From the Type drop-down list, select Azure Identity Lookup.
  7. Click Save.
  8. The page refreshes and displays the Configuration, Attribute Mapping and Groups tabs.
  9. Select the Configuration tab.
  10. 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 the Registering a New App section).
    3. In the Client Secret field, enter the Client secret you generated in Azure Portal earlier (refer 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.
  11. 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 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 MultiOS Management Portal when we configure policies.

  6. In the Remote Group field, enter the Object ID that you retrieved from Azure Portal earlier (refer 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 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 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 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 > Role 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 > Role 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 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 > Role 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 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 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 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 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:
      • 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
    3. In the Value field, enter the appropriate value for the attribute.
  16. Click Save.

Setting up 802.1X authentication for WPA2-Enterprise with Azure is easy when you use SecureW2. Most importantly, it keeps your network and its users secure. SecureW2 is also regarded as one of the most cost-effective solutions in its class. Click here to learn about our pricing.

Microsoft Azure is a registered trademark of Microsoft Corporation in the United States and/or other countries. Other trademarks, logos and service marks used in this site are the property of SecureW2 or other third parties.

RADIUS Authentication with Azure AD/Entra ID FAQs

How does RADIUS authentication work with Azure Active Directory?

Both parties must work together using Azure Active Directory (Azure AD) for RADIUS (Remote Authentication Dial-In User Service) authentication. Azure AD validates user identities while the RADIUS server manages authentication requests. The network device sends the user's authentication request, which may contain credentials or certificates, to the RADIUS server whenever the user tries to connect to a network. After that, the RADIUS server sends this request to Azure AD, which verifies the user's identity by comparing certificate characteristics or credentials to its directory. Following validation, Azure AD replies to the RADIUS server with information about the success or failure of the authentication.

In this configuration, the RADIUS server is a mediator to facilitate communication between the network device and Azure AD; it does not retain user credentials or certificates. Since certificates are more difficult to copy or steal, using them instead of conventional credentials improves security. Azure AD verifies identities and establishes access levels using a variety of factors, including user roles and device compliance status. This integration combines the powerful identity management features of Azure AD with the RADIUS server's authentication capabilities to enable smooth and safe network access.

Do we need an external RADIUS server to Use Azure AD/Entra ID?

Indeed, an external RADIUS server is usually required to use Azure AD (Entra ID) for network authentication. Azure AD serves as an identity provider; it does not directly offer RADIUS services. Azure AD and the external RADIUS server interact to verify user credentials and control network access. This configuration facilitates safe and centralized authentication without needing an on-premises Active Directory by utilizing Azure AD's cloud-based identity management.

Can I Use NPS (Network Policy Server) with Azure AD?

Network Policy Server (NPS) may be used with Azure AD; however, more configuration is needed. Since NPS is usually connected with on-premises Active Directory, synchronizing on-premises AD with Azure AD through the deployment of Azure AD Connect is generally required to use NPS with Azure AD. Furthermore, you may set up NPS to authenticate to Azure AD with third-party RADIUS solutions that support Azure AD or federated services. Azure AD may manage identity with this hybrid method while leveraging the current NPS infrastructure.

However this hybrid arrangement can be complicated and cause more security issues than the benefits provided by the new RADIUS solution. There are often 50+ Windows server vulnerabilities reported each year, a big reason why organizations are moving away from on-prem servers. Using Cloud RADIUS services engineered to work with Azure AD can simplify setup and offer greater scalability and administration for a more streamlined and cloud-friendly solution. This method offers a more direct and effective way to combine Azure AD with network access control, avoiding the complexities of hybrid installations.

Can I join an on-premise RADIUS server to Azure AD without having Active Directory?

Without Active Directory, directly attaching an on-premises RADIUS server to Azure AD is difficult. Azure AD functions mainly as a cloud-based identity provider; it does not provide native support for an on-premises RADIUS connection unless synchronization tools like Azure AD Connect or services like Azure AD Domain Services are used. The short answer is, yes it is technically possible, but it’s not a future-proof solution, especially when technologies like CloudRADIUS are becoming better and better every year.

How Do You Perform a RADIUS Lookup with Azure AD as IDP (Identity Provider)?

CloudRADIUS is able to lookup the status of users and devices directly with Azure / Entra ID. It is able to achieve this by using an OAuth API, combined with SecureW2’s class-leading Policy Engine. This allows organizations to automate the process of validating identities at the moment of authentication. It also opens the door for dynamic authorization, like automatically segmenting different Groups, or devices that have been uncompliant in Intune for extended periods of time.

When an authentication request is received from a network device, Cloud RADIUS performs an identity check with Azure / Entra ID. Cloud RADIUS confirms that the user exists in Azure AD. If the user exists and is active, the authentication procedure continues. However, if the user is disabled or does not exist in Azure AD, the access request is immediately rejected. This real-time verification guarantees that changes in user status, such as an employee departing the organization, are promptly reflected in network access permits, ensuring that access control is always current and safe.

How Do You Sync Your Azure AD (Microsoft Entra ID) with an LDAP server?

Azure AD Connect or an identical synchronization tool is necessary to sync Azure AD (Microsoft Entra ID) with an LDAP server. The purpose of Azure AD Connect is to synchronize password hashes, identities, and characteristics between Azure AD and your on-premises LDAP directory (like Active Directory). This ensures that user IDs are identical in all contexts, making identity management and authentication easy. Establishing a connection, mapping properties, and establishing synchronization rules are usually part of the sync process, guaranteeing constant alignment between the directories. This however is not necessary with CloudRADIUS, as it was designed to talk directly with Azure / Entra ID without the need for an LDAP server.

What is RadSec, and how does it work to improve the security of wireless networks tied to Azure AD?

RadSec (RADIUS over TLS) encrypts RADIUS traffic using TLS, improving RADIUS authentication's security. This stops someone from intercepting RADIUS communications or altering the authentication data while it's being sent. RadSec offers a secure route for network devices to send authentication requests to a RADIUS server, which connects to Azure AD to verify users. It’s commonly used for roaming and remote authentication purposes. Cloud RADIUS supports RadSec in empowering organizations with remote workforces or employees who need to access sensitive resources while traveling.

Does RadSec Work with NPS/AD Setups?

RadSec requires extra configuration to function with Active Directory (AD) and Network Policy Server (NPS) configurations. For NPS, which has historically used plain RADIUS to enable RadSec, TLS certificates must be set up, and the server must be configured to handle RadSec traffic. This configuration ensures that RADIUS communications are encrypted, improving the security of the NPS/AD system. Another degree of protection is added when RadSec is integrated with Azure AD. The authentication process is protected from the client device via the RADIUS server and Azure AD.

Free DemoCheck Pricing
CTA Background