ZyXEL Nebula access points and Active Directory MSCHAPv2 authentication

As a system administrator you want to create a way to give users a simple access to network resources without exposing the corporate environment. Complexity may also be an issue, so using tools that are generally available and free of additional costs would be something that you will like to achieve as well.

ZyXEL Nebula access points and Active Directory MSCHAPv2 authentication

I am a fan of simplification of authentication processes and increasing the minimum levels of security within corporate environments. I started using cloud-controlled switches and access points by ZyXEL that goes by the name of “Nebula” last year and am getting quite fond of their features.

ZyXEL Nebula

Nebula is the product line of cloud-controlled switches and access points by ZyXEL. They debuted a couple of years ago on the market and evolved over the time into a solid and stable solution. If you have a distributed environment of branch offices around the world and you wish to have an easy and reliable way of managing your switches and access-points, Nebula is among the choices you might want to embrace.

About this how-to

As a system administrator you want to create a way to give users a simple access to network resources without exposing the corporate environment (too much). Complexity may also be an issue, so using tools that are generally available and – possibly - free of additional costs would be something that you will like to achieve as well.

One of the weak points of wireless networks is the adoption of weak protection mechanisms, such as “pre-shared keys” or – even worse – open access with MAC access control lists.

A relatively simple solution is implementing Active Directory authentication to access your corporate SSID. In this how-to I’d like to present a simple way of achieving this goal using commonly available tools on Microsoft Windows Servers and Nebula Cloud Controller and access-points. For the means of this part of the tutorial I will show how to implement a MSCHAPv2 authentication against a Network Policy Server. A more secure and reliable solution that requires the use of certificates and a Certification Authority server will be published in a near future.

Your RADIUS server

RADIUS authentication is a quite common and generally available mechanism, but implementing a RADIUS server from scratch can be, say… tricky. Microsoft Windows Server carries along a role called “Network Policy Server” that emulates the required features, and it’s bundled within the operating system, which means you don’t need to purchase additional products or licenses.

The good thing about NPS is that it’s native on Microsoft Windows environments, meaning that there is no further effort required to make it work with Active Directory. Once configured you can refer to user groups from AD to grant access to the network just by adding and removing users to that group.

(A how-to on how to configure the NPS server will be available soon as well).

From the NPS perspective, each single access-point is a client that needs to be defined in the configuration. From the Server Manager you can browse to Roles, Network Policy Server, RADIUS clients and servers, RADIUS Clients.

By double clicking on each item, or when adding a new RADIUS client you should see a details screen like the following.

The configuration of each client is quite simple. A descriptive name (usually the same as the host-name to avoid confusion), the IP address of the device and a pre-shared key that will be configured in the controller as well (it would be a good practice if you had a reverse DNS mapping in your DNS server for the AP address).

At the current version of the Nebula Cloud Controller you should set the same pre-shared key for all access-points in your environment.

Nebula Control Center

Once you have your NPS ready and configured, you can switch to the Nebula Control Center to configure your access-points. Once you registered all your devices, you should see something like this.

Hover on AP and from the dropdown menu choose “Authentication” to access the authentication configuration page.

You should access a screen that looks like the following screenshot.

From the very top, you have a drop-down menu that shows you the list of available or configured SSIDs. If you didn’t configure an SSID yet it’s not a problem. Just select one of the proposed (Disabled) ones and you will set it up later on.

You can choose either to broadcast the SSID or keep it hidden. This You can also choose a schedule to turn off the SSID during closure times.

In the Network Access group, you have a set of choices. The one we are looking for is “WPA2 Enterprise”. If you check the radio button you will be given the possibility of selecting between “Nebula Cloud Controller” and “My RADIUS Server”. Choose the second one and the RADIUS Server field will appear below.

In the RADIUS Server field insert the parameters of your NPS server. The IP address, the port (1812 by default) and the pre-shared key you set up in the client configuration.

Once your authentication settings are set up, save the settings and switch to the Configure SSIDs page.

In the SSIDs page you can change the SSID name and see how it is configured. You should have something like this as a result.

In this page you can also set the VLAN ID for your SSID network.

Once saved the settings, it can take up to 2 minutes for your access points to get the configuration and apply the changes. You can check if the AP has applied the new configuration by accessing the “monitor Access Points” page.

By default the list does not show the configuration status, so my suggestion is to add a column to your visualization to show that. Click on the gear on top right part of the table and choose “configuration status”.

The column will be immediately visible and it’s much more handy than checking each single access-point and this is what you should be seeing.

Once the configuration is “up to date”, you can test accessing the network by entering the domain username and password: if the configuration is working correctly, your user should be able to access the SSID by his or her own credentials.

Some Architecture and Security Guidelines

Unless you have your own consolidated guidelines in network configurations, I would suggest you keep a few key elements in mind.

• Access point management IP addresses should be kept in a separate VLAN where no WiFi traffic is bridged. This should prevent any undesired attempts of accessing the management pages of the access points (and switches as well).
• Nebula devices needs to access the Internet to connect to the NCC. The required ports are:
  • port 53/tcp and 53/udp (for DNS network name resolution)
  • port 443/tcp (firmware downloads)
  • port 6667/tcp (cloud controller messages)
• For the means of this how-to, your access points (or management-network) needs to access the RADIUS server on port 1812/tcp and 1812/udp
• Do not use “Domain Users” to allow access to the network: create a dedicated group where only users allowed to access the SSID are members of.

Disclaimer

This how-to is supplied as-is with no warranty of correct functioning in different environments. It is not officially supported by any of the mentioned vendors. The solution suggested is fruit of my own experience and field application. Further troubleshooting or configuration could be needed should the described scenario be working not correctly.

I have been working as an IT professional since late 1990s. I had the chance to build a horizontal skillset that allowed me to approach almost any IT related project. Since 2005 my role has mainly been as CTO in different companies, spacing between small ISPs and System Integrators. Since 2017 I am workig on a new platform for Intellectual Property and Copyright assets protection and management.

Do you have any questions, or is there I could help you with? Please feel free to contact me throughout one of the companies listed below or throughout one of the social media channels.