Securing Your Access Points
Securing your wireless networks doesn’t mean much if your APs are not secured as well. If anyone can join an access point to your network and start broadcasting your WLANs in unwanted places, you have a problem. If your wired network simply has strict security guidelines, you need to set some policies in place for the wireless network to fit in with the existing policies.
AP Authorization
If any AP plugged to your network is allowed to join your WLC and broadcast the configured SSIDs, that configuration is considered quite insecure. Even if you don’t consider this a concern because somehow your wired network is physically very secure, you may have several WLCs in your network and may still look for a way to make sure which WLC an AP can join and which WLC it can’t. Some people think DHCP Option 43 covers this requirement, but Option 43 only allows the AP to learn about WLC IP addresses. If the AP learns another WLC IP address (via broadcast or via the mobility group), it tries to discover it too. Enabling AP authorization on a WLC means that globally, no AP is allowed to join until its MAC address is verified by the WLC. MAC addresses have to be entered in the Device Authentication page under the AAA Advanced section in the aabbccddeeff format, that is, without any separator.
The AP Policy page under AAA Advanced allows you to enable the authorization of APs against MAC addresses globally and to pick the AAA method that authenticates them (you can use a list on the WLC itself or use a AAA server). The AAA method you need to select refers to the command aaa authorization credential-download.
An option to authorize APs against their serial number has also been available since IOS-XE 17.3.2.
Here’s a summary of the CLI commands required:
9800# config t 9800(config)# aaa new-model 9800(config)# aaa authorization credential-download <method name> local 9800(config)# ap auth-list authorize-mac 9800(config)# ap auth-list method-list <method name> 9800(config)# username <aaaabbbbcccc> mac
This topic is covered in more detail in the configuration example titled Catalyst 9800 Wireless Controllers AP Authorization List on cisco.com.
Whether or not you have configured AP authorization, any AP that is in Bridge mode has to be added to the device authentication list. This explains the confusion people experience when they order an outdoor AP like a 1562 or a 9124, receive it as a local mode AP, and have no problems joining it to the WLC. Then, when converting the AP to Bridge mode or Flex+Bridge mode, the AP does not join anymore. If checking the wireless join statistics (from the widget in the WLC home page that tells you some APs are disjoined), you see they are stuck in “AP auth pending” status.
On top of having their Ethernet MAC address verified when they join, the Bridge mode APs need to authenticate themselves either through PSK or through 802.1X to the controller. The reason is that anyone could be joining a Mesh mode AP to your backhaul and joining your WLC, so some form of authorization is always required.
The configuration example titled Configuring Mesh on Catalyst 9800 Wireless LAN Controllers is a good resource to learn more about configuring Bridge mode APs.
AP 802.1X Authentication
A secure wired network often means implementing security at the switchport level. Having good physical security on your premises is one thing, but even your own employees could be plugging unwanted devices in the network. And if you think about it, if the only thing it takes to get access to sensitive resources or a management VLAN is to find the right switchport and connect to it physically, you can understand that this is vastly unsecure by today’s standards. Many networks implement 802.1X authentication on most wired ports accessible to access devices. There are often exceptions for server ports or IoT devices that cannot perform 802.1X authentication, but that’s another story. Considering how easy it is to climb on a chair and remove an AP from the ceiling and use its network cable, securing the AP switchport is definitely good sense. Enabling 802.1X on the switchports where APs are connected means that when the cable gets plugged in, the only traffic that is allowed to pass is the EAP authentication protocol until the authentication succeeds, and only then can the AP get an IP address and send some traffic. Not much is required to configure on the wireless to achieve this: the main thing required is to configure credentials on the access points. You obviously need to configure those credentials somewhere in the user database that your RADIUS server uses and need to configure that RADIUS server appropriately from an authorization policy standpoint.
You can configure 802.1X credentials for the access points in the AP join profile under the Management > Credentials tab (not globally anymore, as was the case in AireOS controllers). You simply have to set a username and password, and the AP tries to trigger an EAP-FAST authentication with those credentials when connected to the network. There is no harm in configuring the 802.1X credentials even if the AP is connected to a non-802.1X switchport. Now the problem is that this only works for APs that join the WLC once to get this configuration provisioned on the AP. That can work if your APs are staged or provisioned on an unsecured port before being placed in the secure network. Alternatively, you can enter the credentials directly on the AP console if it is plugged directly to an 802.1X-enabled port. The command is capwap ap dot1x username <user> password <password>.
The 802.1X is typically used on access switchports to authenticate hosts, but an access point can also be in FlexConnect mode and therefore connected on a trunk port. Having the AP perform 802.1X authentication on a trunk port is also supported, provided that the switchport authentication is set to multihost mode. First of all, this allows several MAC addresses to be seen on the switchport (802.1X normally limits every switchport to communicate with only one MAC), and only the first MAC address (logically the AP) is authenticated. All the extra MAC addresses learned afterward are applied the same authorization result as the AP.
Using 802.1X to authenticate access points is also a great way of assigning a specific VLAN dynamically to the AP. This means you do not need to have static VLAN configurations on your ports, and depending on the username authenticating, the right VLAN (a user VLAN or the AP management VLAN) is dynamically assigned. Another way to achieve a similar goal is to use smartport macros that detect whether an AP is connected via CDP learning and is able to apply more switchport configuration lines. However, the CDP detection mechanism is probably a bit less secure than a full-blown 802.1X authentication.
One important point for AP 802.1X to work on trunk ports is that if you configure periodic reauthentication on your switchport, you need to make sure to configure Termination action (RADIUS attribute 29) to be Radius-request (a value of 1). If left to the default, it means that the AP loses network connectivity for the time of the reauthentication. When you set this attribute, the AP is able to keep sending traffic during the reauthentication until the reauthentication completes successfully.
Securing the AP Join Process Using Locally Significant Certificates
The concept of configuring LSC is simple: you decide to issue certificates yourself to each and every access point you own, and the WLC allows only APs with such a certificate to join, therefore securely preventing any new APs from joining without your authorization. LSC requires owning an enterprise PKI that automatically issues a certificate to each access point. This certificate distribution happens during a provisioning phase that you define where any AP that joins is automatically provided with a custom certificate signed by your enterprise CA. When you determine that provisioning phase to be over, only APs with a valid enterprise-signed certificate are allowed to join. This certificate supersedes the typical Cisco-manufactured MIC certificate (which isn’t deleted but stays as backup) for establishing the DTLS connection.
This solution is much more secure than relying on a MAC address as well as much more scalable, but it requires an enterprise PKI supporting Simple Certificate Enrollment Protocol (SCEP). This procedure is covered in the document titled Configure SCEP for Locally Significant Certificate Provisioning on 9800 WLC on cisco.com.
Until 17.5.1, there was a limitation where the enterprise CA used for SCEP had to be a root CA, but intermediate CAs are now supported as well.