Emoji Wi-Fi on Cisco C9800 Catalyst

A nice feature for some situations is to use an Emoji SSID instead of a plain text SSID. Many Wi-Fi controllers support this by allowing cut and paste into the GUI but this is not true for the Cisco C9800 Catalyst wireless controllers. 

The WLAN edit screen only permits "Only english alpha-numeric characters, spaces and special characters ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~ are allowed."

 

However, it is possible to configure an emoji SSID from the CLI.

First determine the UTF-8 HEX encoding of the chosen emoji. For example to use a pretzel https://symbl.cc/en/1F968/ shows that the UTF-8 HEX would be F0 9F A5 A8. Each byte then needs to be escaped with a backslash and x to indicate hex to give \xF0\x9F\xA5\xA8

To configure on the CLI:

EWC(config)#wlan emoji 2 \xF0\x9F\xA5\xA8
EWC(config-wlan)#no shutdown

Then add the new WLAN to a policy tag so that it is broadcast

EWC(config)#wireless tag policy policy-tag-1
EWC(config-policy-tag)#wlan emoji policy policy-prof-1

The new SSID will now transmit and show the chosen emoij, here is the pretzel as shown on Windows

 

 

 

One thing to note is that although the SSID was entered as hex it is not read back this way. The CLI and WLAN overview screen show it one way and the WLAN edit screen another.

EWC#sh run wlan emoji
wlan emoji 2 p^_%(
 no shutdown

Also note that once the SSID is created in this way you can no longer configure any paramters via the GUI as it checks the SSID against the rules again so all configuration must be via CLI.

NB. Screenshots and behaviour on IOS-XE 17.12.1

 

Importance of Enforcing Correct Usernames on eduroam

On a recent job there were frequent complaints from users that were unable to connect to eduroam when roaming at other universities. (eduroam for those who don't know about it is one of the great wonders of the modern world. It is a federated Wi-Fi network around the world for the international research and education community.) The reason usually because they are authenticating without using a correct username format recognised by the eduroam proxies.

In order for authentications to be routed correctly from a visited location to the home institution the domain suffix @institution.ac.uk is used to route the user authentication request back to the correct location. It is analogous to dialling a local phone number within a town but needing to add the STD code to dial a phone number in a different town.

At some point in the past this particular university had decided to be helpful for their users and allow them to authenticate using just the username or DOMAIN\username. The problem this has created is that most people have now setup their eduroam connection in this way so that when they roam it doesn't work and we have no way of seeing this as the national proxies don't know they are our users.

As a result in comparison with other UK universities UoX was only seeing a fraction of the roaming connections.

Looking at the breakdown of authentications on Clearpass it could be seen only 14% of the local authentications were to eduroam in a format that would work when roaming. UoX WiFi was another legacy 802.1X network that served no longer served any purpose. So for the users making 77% of the Wi-Fi connections on campus would have issues when roaming at other universities and eduroam locations. No wonder the roaming statistics are so small.

So in conclusion, it is important to consider what customer service actually means. Is it really helping them to be able connect locally a few seconds more quickly but then that prevents them for roaming without further issues.

Transmit AP Name in Aruba Instant

Having the Wi-Fi infrastructure transmit the AP name is one of those useful things that not everyone knows about. It means that a network engineer can see the system assigned name rather than a BSSID saving valuable troubleshooting time. Each vendor does it in a slightly different, proprietary way that means that it is usually only professional tools that will decode them. Until recently Aruba Instant deployments didn't have this functionality but this changed with release 8.4.0.0. Interestingly there was no mention of this addition in the release notes, however, the CLI reference guide does describe it.

All that is required is to add the command advertise-ap-name to each SSID profile required. Here is an example:

CORP-AP01# conf t
We now support CLI commit model, please type "commit apply" for configuration to take effect.
CORP-AP01 (config) # wlan ssid-profile AyeFi_CORP
CORP-AP01 (SSID Profile "AyeFi_CORP") # advertise-ap-name
CORP-AP01 (SSID Profile "AyeFi_CORP") # end
CORP-AP01# commit apply
committing configuration...
configuration committed.

As a consequence the APs will transmit their name as a VSA in the beacon frame as shown below:

Clearpass Authenticating using userPrincipalName or SAMaccountname

By default new Active Directory authentication sources added to Clearpass are set to check user authentication against samAccountName. As part of an effort to make 802.1x wireless authentications match domain joined machine logins we needed to change to check users against userPrincipalName instead. Some differences between these two are listed below:

samAccountName

historic user login name used pre-Win2k

format is Domain\User

userPrincipalName

used with newer Windows versions

format is username@DomainName.co.uk

Change to the AD Source

The first step is to change the filter that is used by ClearPass to query the AD source. 

This is located here: Auth > Sources > My Source > Attributes, click on Authentication > Configuration, 

Then change Filter Query from:

(&(sAMAccountName=%{Authentication:Username})(objectClass=user)) 

to 

(|(&(objectClass=user)(sAMAccountName=%{Authentication:Username}))(&(objectClass=user)(userPrincipalName=%{Authentication:Username})))

as shown here:

This query allows both samAccountName and userPrincipalName to be checked but they will need different ClearPass services as the former would require any domain to be stripped whilst the latter needs the domain to be present. If only UPN is required then the query can be shortened to just:
(&(objectClass=user)(userPrincipalName=%{Authentication:Username})))

New Services

Then to implement the change a new service was required above the existing services to handle the users logging in with UPN. Our existing eduroam login is username@domain.ac.uk and thus to match samAccountName the username is stripped out before comparison. However, now using UPN this wouldn't work so a new service was required.

This implements a regular expression on the username that is more specific than for the previous service so will only match usernames in the new format. The existing format will still be matched to the old service for a temporary period of co-existence until all users migrate to the new format. This regular expression is looking for a prefix containing numbers, lower case letters, at least one dot and optionally apostrophes and hyphens.

Beware

One thing to be aware of is that I couldn't get ClearPass to do the authorization part correctly from the AD source following authentication. This is necessary to determine the role that each user should be assigned. It seems that if there are multiple AD sources being queried by Clearpass then this doesn't work.

Connect to WPAx-Personal Wi-Fi using QR code

Our new home broadband router from Vodafone arrived with a QR code on the base. I hadn't realised what it was until I took a photo of the router password and the Samsung camera app read the QR code and offered to fill out the Wi-Fi network details.
A bit of research revealed that it was quite simple to create your own QR code with the Wi-Fi details and there are many sites to help. I liked this one for its simplicity: https://qifi.org/

Then scan with your phone camera or QR scanning app: 

If you click on the arrow it imports the data into the Wi-Fi setup screen.

So now there should be no excuses for not using long, complicated passphrases for your home network. Of course you should be using 802.1X in the enterprise.

Aruba Clearpass Custom Analysis & Trending

Our large UK university campus uses Aruba Clearpass for authentication. We had a situation recently when a large number of wireless authentications were failing at certain times of the day. One of the great features of Clearpass is the Access Tracker that lists all the authentication attempts with lots of useful information. It is found on Policy Manager - Monitoring - Live Monitoring - Access Tracker

I could see in the policy manager access tracker that at the times when the issue was occurring that many of the connections were failing with a timeout. One of the very useful parts of the access tracker are its filters and I was able to filter for "Login Status equals TIMEOUT". However, what I really wanted to see was the number of login timeouts vs successful authentications graphed over time to get an understanding of the scale of the problem and its frequency.

Policy Manager has a graphing function to be found at: Policy Manager - Monitoring - Live Monitoring - Analysis & Trending. An example of the supplied filters is this, simply showing total requests, successes and failures:

However, in my case I needed to see the authentication timeouts and not just all the failures. What I needed was a data filter which are found at Policy Manager - Monitoring - Data Filters. These can filter on any of the parameters present in the access tracker and can use Boolean logic to construct more complex queries. The query can then be used to build a graph in the Analysis & Trending module.

My first filter was quite simple just looking for RADIUS authentication where the Login-Status EQUALS TIMEOUT:

and another that showed the timeouts from a group of Meru controllers by filtering on the NAS IP address of the wireless controller(s):

Then applying these filters in Analysis & Trending provided the graphical representation required:

Aruba AOS8 Cluster Grouping

On a new job working with an existing Aruba AOS 8 deployment I came across a cluster of four 7240XM controllers clustered as a single cluster but with the controllers configured with two different group IDs. This wasn't a parameter I was familiar with and the documentation wasn't much help either. In the online user guide here this is the explanation

group <group_id>

The value of the parameter is an integer and the range is 1-12. The value 0 is the unset value if you do not want to group the managed devices

This explanation from David Westcott explains it perfectly here. "The use is to assign controllers in the same physical location the same group ID. Then the cluster places User anchor controller (UAC) and Standby User anchor controller (S-UAC) for each client in different groups so that if a whole physical location goes offline then the standby connections are already established."

This is confirmed on our cluster. For this cluster controllers xxCL-01 and xxCL-03 are in group 1 whilst controllers xxCL-02 and xxCL-04 are in group 2. The last octet of the IP address corresponds to the controller name.

lc-cluster group-profile uni-cluster
  controller 172.17.101.1 priority 128 mcast-vlan 0 vrrp-ip 0.0.0.0 vrrp-vlan 0 group 1
  controller 172.17.101.2 priority 128 mcast-vlan 0 vrrp-ip 0.0.0.0 vrrp-vlan 0 group 2
  controller 172.17.101.3 priority 128 mcast-vlan 0 vrrp-ip 0.0.0.0 vrrp-vlan 0 group 1
  controller 172.17.101.4 priority 128 mcast-vlan 0 vrrp-ip 0.0.0.0 vrrp-vlan 0 group 2

Looking at the cluster from the MM GUI: Managed Network - Infrastructure - Clusters it shows that clients active on xxCL-01 are standby on xxCL-02 and vice versa. Clients active on xxCL-03 are standby on xxCL-04 and vice versa.