RADIUS Authentication with Azure AD

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.

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.

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

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. To create an IDP, log in to the JoinNow MultiOS Management Portal.
  2. Go to Identity Management > Identity Providers and click Add Identity Provider.
  3. In the Name field, type name for the provider.
  4. From the Type drop-down list, select SAML.
  5. From the Saml Vendor drop-down list, select Azure.
  6. Click Save.The following screen is displayed.
  7. Click the Configuration tab. Copy the Entity ID and ACS URL to your clipboard and save it in a word/text file. 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.

To configure single sign on in Microsoft Azure:

  1. In the left pane, navigate to Manage > Single sign-on. The following screen is displayed.
  2. From the Single Sign-on page, select SAML-based Sign-on.
  3. In the Basic SAML Configuration section, click the Edit button.
  4. For the Identifier and Reply URL fields, enter the Entity ID and ACS URL values obtained earlier. (See Creating a SAML IDP, step 7.)
  5. For the Sign on URL field, enter the same value as the Reply URL obtained from ACS URL.
  6. Click Save.
  7. Under the SAML Signing Certificates section, click the Download button to obtain the Federation Metadata XML file from Azure.

To upload the Azure metadata to SecureW2:

  1. In the JoinNow MultiOS Management Portal, go to Identity Management > Identity Providers. Click the Edit link of the newly created SAML IDP.
  2. Click the Configuration tab. In the Identity Provider (IDP) Info section, click Choose File to select the Metadata XML file you downloaded from Azure.
  3. Click Upload.

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.

  1. From your Microsoft Azure Portal, go to the JoinNow Connector Application, or the SAML application you created in the section “Create a SAML Application in Azure”.
  2. Go to Manage > Users and groups.
  3. Click Add User.
  4. In the Users and groups pane, use the Select field to search for the user by name or email.
  5. Select the user, and then click Select.
  6. In the Add Assignment pane, click Assign.
  7. For creating a group navigate to Manage > Users and groups.
  8. Type “Groups” in the search box and click Groups.
  9. Click + New group to add a new group. You will be directed to the following screen:
  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 Membership type drop-down, select Assigned.
  14. For the Members field, click No members selected.
  15. In the Add members window, search for one or more members. Click on desired member/members from the list and click Select. The member/members are added to the group.
  16. Click Create.
    • NOTE: Repeat steps 4-9 to create additional groups and add members, as required.
  17. On the displayed screen, search for the group(s) created and copy the Object Id(s) of the group/groups to your clipboard . and save it on a word/text file to be used later.

To allow your SAML application to access Active Directory:

  1. From your Microsoft Azure Portal, use the search feature to go to App registrations.
  2. Next to the search field, click the dropdown and select All apps. This displays a list of all available applications.
  3. Click your application.
  4. In the pane that appears for your application, scroll under Manage and click API Permissions.
  5. Under Configured Permission, click Add A Permission.
  6. In the Request API permissions pane, select Microsoft Graph and Delegated Permission.
  7. Select the following permissions:

    1. Directory.Read.All

    2. Group.Read.All
    3. User.Read.All
  8. Click Add Permissions. You should see the following image.
  9. In the pane for your application, click Settings.
  10. Click Manifest > Edit.
  11. In the Edit manifest pane, in the source code:
    • For the ‘groupMembershipClaims‘ variable, change the value to ‘All‘.
  12. Click Save.

 

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.

To configure attribute mapping in SecureW2:

  1. From your SecureW2 Management Portal, go to Identity Management > Identity Providers.
  2. Click Edit for the IDP you created in the section “Create an Identity Provider in SecureW2”.
  3. Select the Attribute Mapping tab.
  4. Click Add.
  5. For Local Attribute, enter ‘upn‘.
  6. Click the Remote Attribute dropdown and select USER_DEFINED.
  7. In the field that appears, enter ‘http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name‘.
  8. Click Next.
  9. Click Add.
  10. For Local Attribute, enter ‘email‘.
  11. Click the Remote Attribute dropdown and select USER_DEFINED.
  12. In the field that appears, enter ‘http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress‘.
  13. Click Next.
  14. Click Add.
  15. For Local Attribute, enter ‘displayName‘.
  16. Click the Remote Attribute dropdown and select USER_DEFINED.
  17. In the field that appears, enter ‘http://schemas.microsoft.com/identity/claims/displayname‘.
  18. Click Next.
  19. Select the Basic tab.
  20. For Group Map Attribute, enter ‘http://schemas.microsoft.com/ws/2008/06/identity/claims/groups‘.
  21. Select the Groups tab.
  22. Click Add.
  23. For Local Group, enter a name.
  24. In a new browser tab/window, log into your Microsoft Azure Portal and go to Azure Active Directory > Groups > All groups.
  25. Use the Name field to search for the group.
  26. Click the group, and then go to Properties.
  27. For Object ID, copy the value.
  28. Return to your SecureW2 Management Portal.
  29. For Remote Group, paste the Object ID value.
  30. Click Create.
  31. Click Update.

To update the profile policy in SecureW2:

  1. From your SecureW2 Management Portal, go to Policy Management > Profile.
  2. Click Edit for the profile policy.
  3. Select the Settings tab.
  4. Click the Identity Provider dropdown and select the IDP you created in the section “Create an Identity Provider in SecureW2”.
  5. Click Update.

To update the user role policy in SecureW2:

  1. From your SecureW2 Management Portal, go to Policy Management > User Roles.
  2. For DEFAULT ROLE POLICY 1, click Edit.
  3. Select the Conditions tab.
  4. Click the Identity Provider dropdown and select the IDP you created in the section “Create an Identity Provider in SecureW2”.
  5. Click Update.

To add a user role policy in SecureW2:

  1. Go to Policy Management > User Roles click Add Role.
  2. In the Name field, enter a name.
  3. Click Save.You will be directed to the Conditions tab.
  4. Select the Conditions tab.
  5. In the Identity Provider drop-down list, select the Identity provider created in section 1.2
  6. Click Update.

To add an enrollment policy in SecureW2:

  1. Navigate to Enrollment, and click Add Enrollment Policy.
  2. In the Name field, enter a name and click Save.
  3. In the Conditions tab, for the User Role list, select the user role created in the previous section.
  4. In the Device Role list, select the DEFAULT DEVICE ROLE policy or a newly created policy according to your need.
  5. Click Update.

To republish your network profile:

  1. Navigate to Device Onboarding > Network Profiles and for the network profile click Publish or Republish if already published.This might take upto 60 to 90 seconds.
  2. After publishing successfully, click View.
  3. Click the JoinNow button. It downloads a Wi-Fi wrapper package.
  4. Open the downloaded file and enter your Azure credentials when the system prompts.
  5. 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.

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.

New App Registration

  1. Login to Azure.
  2. Navigate to App Registrations.
  3. Click New Registration.
  4. Configure the following settings:

Note: Use your unique SecureW2 Organization URL as the Redirect URL like so; https://myorganization-auth.securew2.com/auth/oauth/code

Create a Client Secret

  1. Navigate to Manage.
    • Then click Certificates & secrets.
  2. Click New client secret.
    • Enter in a name under Description.
    • Select an expiration date under Expires.
    • Click Add.
    • Now you should see your Client Secret under the Value column.
      • Make sure to save this somewhere safe, as this secret is non-recoverable!

Create a Provider URL and Client ID

  1. Navigate to the Overview section and you will see a screen like below:
  2. Copy your Application (client) ID and save this for later.
  3. Copy your Directory (tenant) ID.
    • Insert it into the following URL:
      • https://login.microsoftonline.com/{Directory (tenant) ID}
      • Should look like this:
        • https://login.microsoftonline.com/561bc67f-1c86-4244-8bd4-5eb23cba44ac
      • Save this for later.

API Permissions

Lastly, we need to give this application permission to access the data in our Azure directory.

  1. Navigate to API Permissions under the Manage section.
  2. Click Add a permission and add the following permissions:
  3. After adding the permissions, click Grant admin consent for {your organization}.

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.

  1. Navigate to Identity Providers in the Identity Management section.
  2. Click Add Identity Provider.
    • Enter a Name.
    • Description is optional.
    • Select Type as:
      • Identity Lookup Provider
        1. AZURE
  3. Click Configuration while still in the Identity Provider edit menu.
    • For Provider URL enter the URL we created before using the Directory (tenant) ID.
      • https://login.microsoftonline.com/{Directory (tenant) ID}
      • Which should look something like this: https://login.microsoftonline.com/561bc67f-1c86-4244-8bd4-5eb23cba44ac.
    • For Client ID enter in the Client ID that you retrieved from Azure previously.
    • For Client Secret enter in the Client secret you generated in Azure previously and saved in a secure place.
      • After updating the Identity Provider, this secret will not be retrievable, so make sure this is saved in a secure place.
    • Click Update.
  4. Lastly, click Authorize on your new Identity Lookup Provider.
  5. This will test the connection between SecureW2 and your Azure App.
  6. This is a mandatory step, as it grants our application the final authorization to call our Azure API to grant User Info.

Configuring Groups

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

  1. Navigate to the Groups tab.
  2. Click Add.
    • Create any name for Local Group.
      • This name will be what shows up later as our ‘Group’ in the SecureW2 Management Portal when we configure policies.
    • In Remote Group enter in the name of your Group as it is configured in Azure.
  3. Click Update.
  4. 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.

Account Lookup Policy

Lookup Policies are how we tie our new Identity Lookup Provider to domains. Here we will create a condition that ties our domain to the new Identity Lookup Provider we just created in the previous section.

  1. Select Lookup under Policy Management.
  2. Click Add Identity Lookup Policy.
  3. Create a Name and click Save.
  4. Navigate to the Conditions tab.
    • Configure the following settings:
  5. Navigate to the Settings tab
    • Select the Identity Lookup Provider we just created in the previous section.

User Role Policy

Next, we need to 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 we will configure next.

  1. Add a Role.
  2. Create a Name.
    • Because we need multiple User Roles, specifying this is for User Network Authentication is recommended.
  3. Click Save.
  4. Navigate to Conditions.
  5. Under Identity Provider: select the Azure Identity Lookup Provider that we just created in the previous section.
  6. Click Update.

Group Role Policy 

Lastly, we need to create Role Policies for any Groups that we want to give differentiated network access. We can then leverage Cloud RADIUS’ Dynamic Policy Engine to send unique RADIUS attributes based on the Group users belong to with our Network policies.

  1. Add a Role.
  2. Create a Name.
    • Because we need two User Roles, specifying this is for Group Network Authentication is recommended.
  3. Click Save.
  4. Navigate to Conditions.
  5. Under Identity Provider: select the Azure Identity Lookup Provider that we just created in the previous section.
  6. Under Groups select the group that we 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.
  7. 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 a Identity Lookup Provider.

The purpose of this policy is: 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 don’t experience disconnects if there’s a small hiccup 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 the DEFAULT NETWORK POLICY

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, follow the steps below:

  1. Click Network in the Policy Management section.
  2. Click Add Network Policy.
  3. Enter a Name.
  4. Click Save.
  5. Navigate to Conditions.
    • Select the User Role you want assigned this Network Policy.
      • For this guide, it would be the policy you created in the User Role Policy for Network Authentication section.
      • You can select multiple User Roles to assign a Network Policy to.
  6. Navigate to Settings.
    • Click Add Attribute.
      • Select the Attribute you wish to send to the wireless controller.
      • Enter in the Value appropriate for your attribute.
      • Click Update.
    • Repeat as necessary for all the attributes you want to send for your User Role.

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.

Free DemoCheck Pricing
CTA Background