Wi-Fi web authentication. Configuring Certificate Authentication for a Wireless Network

Configuring Certificate Authentication for a Wireless Network

Recently we had a customer who wanted to pilot the use of certificate-based authentication for their wireless network.

They had a new internal Public Key Infrastructure (PKI) capable of issuing required certificates and built a new Network Policy (NPS) server. Their wireless access points were Cisco Meraki devices, and the network team had created a new SSID with the relevant configuration on the network side.

The customer had Windows 10 devices and wished to have machines automatically connect to the new Wi-Fi network when in the office, only allowed on if they have the appropriate certificates present. They wanted to use PEAP with Certificates (EAP-TLS) which requires the presence of a computer certificate and a user certificate on the Windows 10 device and they wanted the Windows 10 devices to be able to authenticate to the Wi-Fi before user logon, so that various domain based scripts and processes were able to run before the user logged in. Currently they are using group policy to manage Windows 10 rather than Intune although this is coming in the near future.

So, the job was to make it work given the current setup. There are some reasonable bits and pieces of info out there about it, but we could not really find anything that collected everything in one place, so in this blog I’m trying to summarise the steps we performed in each area.

There were several areas we had to look at:

• NPS server configuration
• Group Policy (for deployment of wireless settings)
• Client certificates
• Meraki Configuration

This blog assumes some understanding of the components we configured and shows how we dealt with some of the “gotchas”. It may not be applicable for every scenario.

NPS server

The things to consider when configuring the NPS server (we looked at these as pre-requisite checks)

• The NPS server should be a domain joined server.
• It should be in the RAS and IAS servers AD group; this will allow it to enrol for a server a certificate from the RAS and IAS servers Certificate template (assuming this template has been published on your Certificate Authority).
• Following on from this, ensure the NPS server has the appropriate root CA / issuing CA certs in the appropriate local stores and there is an autoenrollment policy that enrols the NPS server cert from the RAS and IAS certificate template. If you don’t have a valid chain of trust you will hit issues, and if you don’t have autoenrollment you’ll need to remember to manually renew the NPS server certificate around the end of the validity period.
• The NPS server will need to be authorised in AD from NPS console.
• Enable NPS logging to full range of events can be seen in event viewer auditpol /set /subcategory:”Network Policy Server” /success:enable /failure:enable – a useful thing from another risual blog!

The first thing we did in the NPS console was create a RADIUS client for the Meraki Wireless Access point working with the network team – this is fairly straightforward; we gave the Radius client a friendly name, IP address and working with the network team entered a shared secret. This shared secret the network team generated was 60 characters, it did not have any special characters just a mix of upper and lower case and numbers. Further down the line when testing connectivity, we found we were getting NPS errors Event ID 18 every time we tried to connect to the Wi-Fi.

This is indicative of a shared secret issue. I’m not sure where the limitation lies, the Meraki or the Microsoft side, but when we generated a 30-character secret and updated both ends, we no longer had an issue.

The following NPS settings were deployed via the setup wizard, which gave us two polices – a connection request policy and a network policy.

The rest of the Wizard was completed with default settings.

There is not a great deal to look at in the Connection Request Policy created. It shows the use of Wireless 802.1x and the requests being authenticated on the server.

In the network policy, we made sure that in the constraints that PEAP is the only authentication method and all the less secure authentication methods are unchecked and these settings reflect what was chosen in the NPS 802.1x wizard.

This should be sufficient configuration on the NPS server side.

GPO for Wireless settings

The following settings were configured in GPO to apply Wireless 802.11 settings to some test clients

In a GPO: Computer configuration Policies Windows settings Security settings Wireless Network IEEE (802.11) Settings

We created a new policy and gave it a friendly name and added a new Infrastructure profile to this. The SSID created on the Meraki was hidden, and the Profile name in this GPO is what the clients could see as a wireless network.

A couple of things to note here:

We had an issue when testing where we could see on the NPS server logs the computer account being denied certificate logon via NPS, but the user was granted. We found that in the GPO on the security tab of the profile, advanced settings, checking the ‘Enable Single Sign on’ check box and the radio button ‘Perform immediately before user logon’ sorted this issue. This setting specifies 802.1x authentication happens before user logon, and meant that we could see after this was applied a successful grant of access on the computer logon on the NPS server. After this when the user logged on, we could see that some computer-based scripts were running successfully as the domain connectivity was there though the Wi-Fi before the user logged on.

We also had an issue where sometimes the computer appeared to connect to the Wi-Fi profile at the logon screen, sometimes not it almost seemed like sometimes the network was there, sometimes it wasn’t. We used the check box on the connection tab of the profile ‘connect even if the network is not broadcasting’. After this was applied, the computer consistently always automatically connected to the Wi-Fi profile.

Clients and users

The Microsoft documentation states that if using PEAP-TLS to have User certificate and computer certificate; we did try testing without a user certificate deployed and got the error “You do not have a valid certificate” when trying to connect to the Wi-Fi.

There doesn’t seem to be much guidance as to what certificate templates to use, so as a test we duplicated the default User and Computer templates in PKI. They both have uses of client authentication in their properties. For ease of management there should be some sort of autoenrollment mechanism configured in AD GPOs to get these user and computer certs out and also the root / intermediate certificates to clients.

Note also if in the Certificate templates, the option to publish in AD has been enabled, and the setting which says ‘don’t allow duplicate certificates against an account’ is checked then a user logging on to a second machine won’t get a certificate on the 2nd machine. May be something to look out for if you are having trouble getting certificates issued. Also remember if you are adding users and computers to groups then there may need to be a logoff / on or reboot to update permissions and a Gpupdate before you see a certificate in the appropriate personal store.

Meraki

We didn’t have much visibility of what the configuration was here but was assured for the Meraki we had it was up to date with all the latest firmware (this has bitten me before when working with 802.1x having creaking old network kit!). Also assured that the right ports were configured for communicating with the NPS server and there was nothing in the way.

As mentioned above we had the issue with the SSID. The Meraki was set to not broadcast its network SSID – we did find that checking the IEEE 802.11 GPO setting to “connect if network not broadcasting” seemed to solve the intermittent connectivity issues we had and connectivity to the new network at the logon sceen was consistent after that.

Summary

With this all in place, we were able to see:

• Client connecting automatically to the wireless profile at logon screen
• On the NPS server could see a granted event on Protected EAP / Smart card or other certificate against the computer account.
• User logged on; could see one of the customers own logon processes running as we would if the machine was connected to the wired network before user logon
• On the NPS server, could see granted event on Protected EAP / Smart card or other certificate against the user account
• The user could access network resources as per being on the corporate network, and the network team could see us connected on the Meraki side.

Contact Sales

When deploying a wireless LAN, it is very important to deploy secure methods for authentication and encryption so that the network can only be used by those individuals and devices that are authorized. This article takes a look at the commonly used methods of wireless LAN authentication as well as the available encryption methods.

WLAN Authentication Methods

It is important to understand that there is a distinction between being authenticated onto a wireless network and then having the traffic passed be encrypted. It is possible to be authenticated onto a network and pass open unencrypted traffic; this section looks at the commonly used methods of authentication.

There are three main methods of authentication that are used on today’s wireless LANs:

The open authentication method is the simplest of the methods used and only requires that the end device be aware of the Service-Set Identifier (SSID) used on the network, as long as the SSID is known then the device will be allowed onto the network. The problem with this method is that the SSID is typically broadcast and if it is not, it can be easy to figure out with passive capturing techniques.

The shared authentication method is commonly used on individual and small business wireless LAN implementations; this method uses a shared key (Pre-Shared Key – PSK) that is given to both sides of the connection; if they match then the device is allowed onto the network.

The third method uses the Extensible Authentication Protocol (EAP) and is the most common method used by enterprises. The EAP method utilizes an authentication server that is queried for authentication using a variety of credential options.

WLAN Encryption Methods

Along with the method used for authentication, the choice of encryption method is a very important part of deploying a wireless LAN. Many of the encryption methods that were implemented in earlier wireless LAN standards have been proven insecure and have been depreciated by more modern methods. As time goes on, this is sure to happen with all encryption techniques as they are used more commonly (thus becoming a target for exploitation) and as processing power continues to increase.

Here are the WLAN encryption methods we’ll review today:

The first widely used standard for wireless LANs was 802.11 (prime); this included the Wired Equivalent Privacy (WEP) algorithm which was used for security. WEP utilizes RC4 for encryption and has been depreciated because of vulnerabilities that can be used to find the security keys.

In response to the vulnerabilities found in WEP, Wi-Fi Protected Access (WPA) was defined. WPA utilizes the Temporal Key Integrity Protocol (TKIP) which utilizes dynamic keys that were not supported with WEP and RC4 for encryption. The TKIP method used with WPA was utilized until vulnerabilities were found in TKIP. These vulnerabilities center on the fact that TKIP uses some of the same mechanisms that WEP does which allow similar attacks.

In response to the vulnerabilities in WPA/TKIP, the IEEE 802.11i standard was defined and implemented; the IEEE 802.11i standard is also referred to as WPA2. WPA2 replaced TKIP with Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP) which is based on Advanced Encryption Standard (AES); it is common for the WPA2 encryption method to be referred to as AES. As of this writing, there are no easy methods that have been found to break AES.

Summary

How secure a wireless LAN is, greatly depends on a number of different configuration parameters that must be entered correctly. The problem with many existing wireless LANs is that the people that are implementing them simply do not have the security knowledge required to maintain a secure wireless network.

All existing and future wireless LAN implementers should make the effort to learn about the most secure methods provided by the chosen equipment (and quite possibly be part of the equipment selection process). The advantage that most modern equipment has is that the WPA2 standard is supported and not that hard to implement.

Hopefully this article can act as a primer to this education and will provide current and future WLAN administrators some information they need to secure their networks.

Wireless Security Training Resources:

If you’re interested in learning more about Wireless LAN security, then take a look at these course offerings to see which one is right for you:

CWA. Central Web Authentication with Cisco ISE

Cisco Identity Services Engine (ISE) may be used for guest management when paired with Meraki Access Points. Cisco ISE is another option for authorizing users, enabling many additional business use cases.

Meraki APs will pass necessary information over to Cisco ISE using MAC-based authentication and honor a Uniform Resource Locator (URL) redirect that is received from the Cisco ISE Server. Using change of authorization (CoA), the Cisco ISE server can ensure that the correct authorization is applied to the end user devices based on the authentication status.

Expected Packet Flow

Configuration

The following sections of this guide will outline a configuration example with using Cisco ISE as the guest management system which is also hosting the captive portal.

Meraki Access Point Dashboard Configuration

The Meraki Access Point configuration is outlined below all on the Access Control Page for a particular SSID (Wireless Configure Access Control).

Configure MAC-Based Authentication

Select MAC-based access control from the Security section of the access control page.

Enter the details for the RADIUS server including the IP address, port, and secret. If using Group Policies select Airspace-ACL-Name for the RADIUS attribute specifying the group policy name. The Airspace-ACL-Name must match the name of one of your group policies configured under Network-wide Group Policies. Enable CoA support if there is a requirement to change the attributes of an authentication, authorization, and accounting (AAA) session.

Configure CWA for Splash page

Select Cisco Identity Services Engine (ISE) Authentication in the Splash Page section of the access control page. This setting will honor the Cisco custom url-redirect attribute sent from Cisco ISE.

Configure the Walled Garden

The IP address of the Cisco ISE server needs to be added to the Walled garden under Advanced splash settings to ensure that a client will be permitted through the Walled garden before being authenticated by the Cisco ISE server.

Note: DNS traffic is permitted by default through the Walled garden

An access policy type of Hybrid Authentication with the Increase Access Speed option enabled will result in CWA failing. Please uncheck the Increase Access Speed option if you are planning to use CWA.

Disable CNA

As of Cisco ISE 2.2, Apple CNA is supported for Guest and BYOD. Beginning July 26th, 2017, Apple CNA and Android captive portal detection are enabled by default on Cisco Meraki MR access points. On iOS 7 and OS X, the client will automatically launch a mini-browser (CNA) that takes the user to the splash page to complete authentication and gain access to the network. Android devices will display a notification on the device prompting the user to sign into the Wi-Fi network. Tapping the notification will launch the device browser and direct the user to the splash page. To disable CNA and captive portal detection, append the following 17.0.0.0/8 IP range and domain names to the walled garden below the ISE server address as shown below (192.168.140.37/32 being the ISE IP address in this example):

17.0.0.0/8 captive.Apple.com Apple.com appleiphonecell.com ibook.info itools.info airport.us thinkdifferent.us clients3.google.com gstatic.com

Disabling CNA will require that users manually open their web browser before being presented with the splash page. Applications on the user’s device that require Internet connectivity will not function as expected until the user has opened their web browser and completed authentication via the splash page. If your network contains Apple devices running iOS 14/macOS Big Sur and newer operating systems. DHCP option 114 can be leveraged instead of Apple’s legacy Captive Portal networks. For additional info, please see Apple’s How to modernize your captive network documentation.

Cisco ISE Configuration

The following sections focuses on Cisco ISE 2.4 and it will present a basic configuration with default web portal from Cisco ISE. For more information about web portal customization please look into ISE documentation.

Adding Managed Network Devices

MR access points acting as authenticators (devices through which AAA requests are sent to Cisco ISE) need to be added to ISE before Access-Request will be answered, it will by default not answer any requests.

• In Cisco ISE, choose Administration Network Resources Network Devices.
• From the Network Devices navigation pane on the left, click Network Devices.
• Click Add, from the action icon on the Network Devices navigation pane or click an already added device name from the list to edit it.
• In the right pane, enter the Name and IP Address. As for the mask, you can add devices inside a network using /24, or as needed to avoid manually importing several APs.
• Check the Authentication Settings check box and define a Shared Secret for RADIUS authentication. This must match the Secret entered for the RADIUS server when configuring the SSID in Dashboard.

Once a device is added, it will show up on the device list in ISE.

Creating Results for Rules

A new results needs to be created where the redirection will be specified.

To do this, go to “Policy Results”. Click on Authorization and Authorization Profiles.

Click on “Add”

• Name this authorization profile.
• On Common Tasks, select “Web Redirection (CWA, MDM, NSP, CPP)”, choose Centralized Web Auth, on ACL “NULL” and Value “Self-Registered” (These values can change depending on your needs.

Optionally, Static IP can be used to not used a DNS server, however, this is not recommended because the IP of the ISE server will be clear text and visible for the end client.

Enabling Policy Sets

Cisco ISE supports policy sets, which allow grouping sets of authentication and authorization policies, as opposed to the basic authentication and authorization policy model, which is a flat list of authentication and authorization rules. Policy sets allow for logically defining an organization’s IT business use cases into policy groups or services, such as VPN and 802.1X. This makes configuration, deployment, and troubleshooting much easier.

In Cisco ISE, choose Administration System Settings Policy Sets.

Creating a Policy Set

• Click the plus sign or click on the settings icon and Create above to create a new policy set.
• Enter the Name, Description and a Condition for this group policy.
• Click on Condition, a new menu will show, match the condition necessary, per SSID policy sets are recommended, therefore, attribute “Radius·Called-Station-ID” ENDS WITH “ ” is the preferred option. Click “Use” after configuring this step.
• Define allow protocols, by default “Default Network Access” can be used.
• Click on “Save”

Create Authentication Policy

• Click on “View” policy by clicking on the right arrow.
• Click on ”Options”
• Change “If user not found” to CONTINUE

Create Authorization Policy

Two rules are required in Authorization Policies for Central Web-Auth, one rule will prompt the redirection and the second rule will grant access once the client machine has passed web page authentication.

• Click on the sign or on the settings Icon to create a new rule.
• Click on “Condition”. a new window will pop up. In this window, the method of the client requesting access can be selected.
• Look for Called-Station-ID, and match it to the name of the SSID.
• Click “Use”
• Select on “Results”, the name of the profile created for redirection, in this case it is “CWA”.

For second rule click on the Action Icon and select “Insert new row above”

• Click on “Condition” a new window will pop up, in this window the method of the client requesting access can be selected.
• Look for “IdentityGroup:Name”

Both rules should be created and should look like the image below, order is very important.

Note: If Active directory is being used, it is a recommended practice to match the AD group where most of the users exist for better security and functionality.

Within the Passed Web conditions, Network Access-Use Case EQUALS Guest Flow is not supported with Meraki APs. If this condition is used, the client’s session is reset every time they roam and will have to reauthenticate.

Thankfully, you have a few tricks to force-start the process when these login pages won’t load.

Depending on where you live, there are tons of places that offer free Wi-Fi connections so you can work or study remotely, or avoid cutting into your data limits on your smartphone. However, some public networks are pretty annoying about the connection process, with all sorts of interstitial login pages getting between you and that sweet wireless networking.

A number of these public Wi-Fi networks require users to log in with an email or other credentials, watch ads, and/or agree to usage restrictions before accessing the internet—even after they’ve already successfully connected. It’s a tedious extra step, but it’s even worse when these login pages won’t show up in the first place. You might be connected to a Wi-Fi network, but you might as well have turned your device off for all the bits and bytes you’ll be receiving.

Thankfully, you have a few tricks to force-start the process when these login pages won’t load.

Restart your device or Wi-Fi settings

The first and simplest suggestion we have is to restart your device. If you don’t want to do a full restart, turning your device’s Wi-Fi on and off may also work. Once you’ve done either (or both), try reconnecting to the wireless network and pulling up a website to begin the cumbersome login process.

Redirect to the login page

If that doesn’t work, the next step is to try forcing the router’s default login page to load, and there are a few web addresses that could redirect you to the router’s login page. Pull up your web browser while connected to the Wi-Fi network and type in routerlogin.net, one of the most common options. And if that doesn’t work, try these:

If neither of the above methods seem to work, check the following settings, then try again:

• Clear your web browser cache. This can usually be done from your browser’s history menu.
• Temporarily turn off any alternate DNS servers you’re using and switch back to the defaults.

Updated 3/4/22 with new details.

Wireless Security Wi-Fi Authentication Modes

In this chapter, we will briefly go through the possible authentication schemes that are used in the wireless deployments. They are: Open Authentication and Pre-Shared Key (PSK)-based authentication. The former one is based on EAP frames to derive dynamic keys.

Open Authentication

The term Open Authentication is itself very misleading. It suggests, that some kind of authentication is in place, but in fact, the authentication process in this scheme is more like formal step, rather than authentication mechanism. The process looks like how it is shown in the following diagram −

In plain English, what this exchange is saying is that, in authentication request the wireless client (supplicant) is saying Hi AP, I would like to authenticate and authentication response from the AP is stating OK, here you go. Do you see any kind of security in this setup? Neither do I…

That is why, Open Authentication should be never used, since it simply allows any client to authenticate to the network, without the right security check.

EAP-based 4-way handshake (with WPA/WPA2)

When a wireless client authenticates to the AP, both of them go through the 4 step authentication process called 4-way handshake. During those message exchanges, the shared password is derived between AP and wireless client, without being transmitted in any of those EAP messages.

The Pairwise Master Key (PMK) is something a hacker would like to collect, in order to break the network encryption scheme. PMK is only known to the Supplicant and Authenticator, but is not shared anywhere in transit.

HOWEVER, the session keys are, and they are the combination of ANonce, SNonce, PMK, MAC addresses of Supplicant and Authenticator. We may write that relation, as the mathematical formula −

Sessions_keys = f(ANonce, SNonce, PMK, A_MAC, S_MAC).

In order to derive a PMK from that equation, one would have to break AES/RC4 (depending whether WPA2 or WPA is used). It is not that easy as the only practical approach is to perform a brute-force or dictionary attack (assuming you have a really good dictionary).

It is definitely a recommended authentication approach to use, and definitely safer than using Open Authentication.

Wi-Fi Chalking

Wi-Fi chalking was a very funny concept in the history of wireless LAN history, mainly used in the USA. The main idea was to mark the places, where open-authentication or WLANs with weak authentication were implemented. By doing that, everyone who finds out this sign somewhere on the wall or ground, written with a chalk, then he can log in to the Wi-Fi system without authentication. Smart, right?

You may just ask yourself. why chalk and not some kind of marker, spray or other more permanent way of marking? The answer is simple and comes from criminal law. writing with chalk was not considered as an act of vandalism.