Every administrator is familiar with the dreaded No Logon Servers Available error message. While the symptoms are the same as a broken trust relationship, the solution is completely different. Simply stated, find out where the network broke to fix the No Logon Servers Available error. Wireless devices make this problem a bit more difficult to fix. Wireless devices without physical NICs can make fixing the problem even harder. Adding a backup wireless network can help you fix these issues faster (or even automatically)!

Creating a backup wireless network involves two main steps.  First, you have to configure your wireless infrastructure to broadcast and allow access to this secondary connection. These steps are very specific to the network devices that you have. The guidance in this section will be high-level. The second phase of configuration is making your clients aware that a backup connection is available. This is done in Group Policy and these steps will be specific to Windows Vista+ machines.

Creating a Backup Wireless Network – Parameters and Security

Ideally, your backup wireless network functions completely independent of your primary connection. If you are using WPA2 Enterprise with computer authentication, your backup connection should not rely on Active Directory, Certificates, etc. For a secondary wireless connection, WPA2 PSK with an insanely long key works wonderfully. To prevent users from trying to use this network, it’s advisable to prevent the SSID from broadcasting itself. Though security through obscurity is not real security, it does prevent your users from doing things they shouldn’t. Along with a hidden SSID, I also like to set the SSID name to a relatively complex value as SSIDs are case sensitive.

These settings do not make for a secure connection though. Once that key and SSID value become available, clients could connect to your network without any central authentication. Clients connected to a backup SSID should be segmented from your normal network traffic. Most enterprise wireless providers provide the ability to specify a unique VLAN for each SSID. Some wireless setups can get much more complex. For example, you might be able to restrict bandwidth usage on the backup wireless network or prevent clients on that AP from communicating with other devices. You will probably want to take a few additional steps to tighten down this backup network. Below are two solutions:

• access control lists/routing modification to prevent clients on the backup SSID from contacting anything but the services required for authentication on the primary network. In AD environment, you would need to ensure clients can contact their closet DC. If you use Chromebooks or devices managed by an MDM, you would need to allow a connection to those external resources. Once setup, this method provides an automatic way for clients to retrieve any policies or settings needed to connect to your primary network.
• MAC address filtering to restrict clients to known devices. I do not like this solution as much because it isn’t automatic. Someone has to let you know that the device is broken before you can add it to your MAC address whitelist. If your infrastructure doesn’t support option 1 or you prefer additional security, setup MAC address filtering.

Finally, be sure to regularly review a client connection list. Ensure that just a few clients are ever connected to this backup SSID. Many clients connected probably means something has gone wrong somwhere.

 

Configuring a Backup Wireless Network Profile in Group Policy

Wireless profiles contains all of the instructions that a client would need to connect to a wireless network. Normally, you would configure a Group Policy wireless profile under Computer Configuration\Policies\Windows Settings\Security Settings\Wireless Network (802.11) Policies. If you use Group Policy Wireless Networks, ensure that you don’t restrict allowed networks to just deployed Group Policy profiles (see unchecked box  in the picture below).

For your backup network, you will need a way to import that pre-shared key that you created in part 1. Group Policy Wireless Network policies (and SCCM WI-FI profiles) do not allow you to do that. Oddly, you can import pre-shared keys for Chrome OS devices in the Google Management console though.

You can import the wireless network profile with a Group Policy shutdown script. Doing so isn’t very straight forward though. First, you need a domain joined wireless machine running your latest deployed OS. This ensures that any network options will match your other clients. Manually connect this device to your backup wireless network. I always use the Manually Connect to a Wireless Network option. This can be found in the Network and Sharing Center in Control Panel. When creating your profile, be sure to enable the Connect Automatically when this network is in range and the Connect even if the network is not broadcasting option.

After your profile is created, you should see it when you run netsh wlan show profiles from an administrative command prompt. If you have any Group Policy profiles, you will see those as well. Export your profile by using the following command: netsh wlan export profile name=PROFILENAME folder=.\

Change PROFILENAME to match your profile. If you don’t want to save the profile to your working directory (which is probably C:\Windows\System32), change it to a new location. As a note, the folder does have to exist (netsh won’t create the folder for you). Copy your wireless profile to a network location. You also store it in the Shutdown scripts folder in your Wireless Configuration GPO. The pre-shared key is stored in clear text. Be sure that only domain computers can read this file In a GPO, add a new shutdown batch script that runs the following (just be sure to change the filename= parameter to point to your exported profile).

netsh wlan add profile filename="\\SERVER\Share\wirelessprofile.xml" user=all

When your clients next process shutdown scripts, they will add your backup wireless profile for all users on the machine. You can verify this by running the netsh wlan show profiles command again. For fun, you can try the following tests:

• Disable your primary wireless network on a single access point. Machines actively connected to your primary network should automatically fall back to your secondary network.
• Reset the password for a wireless computer’s Active Directory account. If you are using WPA2-Enterprise with computer authentication, the client should no longer be able to connect to your primary network. It should fall back to your secondary network (which would allow you to troubleshoot the connection issue remotely).

Have you ever needed a backup wireless connection? Do you have improvements or an alternative to this method? If so – I would love to hear about it in the comments below.