Wireless H-REAP with local switching

Hello everyone, I have moved my blog postings so they are viewed directly on my site. I will not be making any more postings on wordpress, but you can get my full content including old postings as well as the new stuff here:

http://wozney.ca/blog

And here is a link to the original article that you were looking for!
http://wozney.ca/2009/11/05/wireless-802-1x-machine-authentication/

See you there!

Paul

Wireless 802.1x Machine Authentication

Last week a client of mine asked me to put together an interesting wireless configuration.  The requirement was 802.1x wireless authentication, but when we first set it up they found that if a technician stepped over to someone else’s (wirelessly connected) desktop, they would be unable to log in because their credentials were not cached on the system.  Only by connecting the computer to a wired port to allow the OS to talk to the AD server were they able to finally log into a user’s laptop.

They asked me if we could setup the laptops to maintain a wireless network connection using machine authentication when at the login screen, and revert to user authentication when somebody logs into the laptop — allowing them to control who has access to the wireless network.  I have to admit, I was initially skeptical that this would work but despite the complexity of the configuration I managed to do it.

Before I go into the details, here are the caveats as I see them.

  1. Because laptops will connect to wireless even when nobody is logged in, they will be actively using their radio all the time and this could potentially drain the battery of a laptop much more quickly than might be expected otherwise.
  2. There is always a security risk of an always-connected computer, and this is made more significant if that network is wireless.  We are currently pretty safe with WPA2, but this situation could change.
  3. Lastly, there are some fairly in-depth Windows configurations going on here.  I’m not an expert in Windows systems; these solutions I’m going to describe below are done by hand — and I expect that you will want to script these changes into Group Policy instead of visiting every laptop in your domain one by one.

First you should get 802.1x user level authentication working.  See the following links for some guidance:

The configuration on the wireless controller is pretty trivial, just configure a radius server and set the WLAN to WPA/WPA2 with 802.1x authentication.

The first policy I created in MS IAS radius restricted authentication to the groups Domain Computers, and Wireless Users.  Next I created a second radius policy on IAS to restrict authentication to the Domain Computer group only.

You need to configure a CA on your domain.  My client used their Domain Controller, but there might be a better way to do this.  From the CA, we exported a certificate that was loaded onto a laptop with a USB key — you could probably do this via GPO.  Importing the certificate posed some problems, as the default behaviour is to store the certificate in a user profile.  This meant that the systems were able to connect to wireless when a user was logged in, but after a reboot it wouldn’t work — so when installing the certificate we placed it manually.

  • install CA server certificate on laptop
  • Do NOT choose automatic installation.
  • Place all certificates in the following store: (click the checkbox to show physical stores)
  • Select Trusted Root Certification AuthoritiesLocal Computer

Next we had to configure the laptops to connect to wireless even when nobody was logged into the computer.  To do this, I used this MS Support article: http://support.microsoft.com/kb/309448

  • HKEY_LOCAL_MACHINESOFTWAREMicrosoftEAPOLParametersGeneralGlobalAuthMode DWORD=1

Finally I configured the WLAN on the client to handle this configuration.

  • Association Tab
  • network authentication — wpa2
  • data encryption — aes
  • Authentication Tab
  • EAP type — PEAP
  • CHECK auth as computer
  • CHECK auth as guest
  • PEAP Properties
  • CHECK validate server certificate
  • CHECK YOUR-CA-HERE in the list of Trusted Root Certification Authorities
  • Select Auth Method — Secured password EAP-MSCHAP v2
  • CHECK Enable Fast Reconnect
  • EAP-MSCHAPv2 Properties
  • CHECK automatically use my windows logon name and password
  • set to automatically connect

After all these steps, we had the laptops connecting properly.  We passed the laptop around the room, having people who had never touched it before log in with their AD credentials.  If one of these users were not in the Wireless Users AD group they would not be permitted wireless access when logged in.

Downgrade from Lightweight to Autonomous Using Linux

Hello world,

I recently came across a solution for a small problem I was working on, and I thought I would share.

I have a Cisco 1131 AG lightweight access point that I wanted to downgrade to autonomous mode. Now this is easy if you have a WLC (Wireless LAN Controller) that these APs are designed for, but if you don’t you have to perform a downgrade manually.

There are lots of instructions on the Internet, but this is the Cisco documentation for this issue.

What Cisco leaves out is what the AP is expecting out of your TFTP server. When the AP loads up into recovery mode it is going to be attempting to connect to a tftp server at the broadcast address: tftp://255.255.255.255 — essentially this means that the AP will attempt to connect to an address that every device on the LAN has.

My laptop is running Ubuntu (a flavour of Linux) and I have the tftpd-hpa package as my TFTP server. Normally I like the setup I have, but today it wasn’t enough — the AP wasn’t connecting.

The CLI was throwing this error:

[code]]czoyMTY6XCJpbWFnZV9yZWNvdmVyeTogRG93bmxvYWQgZGVmYXVsdCBJT1MgdGFyIGltYWdlIHRmdHA6Ly8yNTUuMjU1LjI1NS4yNTV7WyYqJl19L2MxMTMwLWs5dzctdGFyLmRlZmF1bHQNCmV4YW1pbmluZyBpbWFnZeKApg0KZXh0cmFjdGluZyBpbmZvICgyODAgYnl0ZXMpDQpQcntbJiomXX1lbWF0dXJlIGVuZCBvZiB0YXIgZmlsZQ0KRVJST1I6IEltYWdlIGlzIG5vdCBhIHZhbGlkIElPUyBpbWFnZSBhcmNoaXZlLlwiO3tbJiomXX0=[[/code]

And when I used wireshark to look at the traffic I found that the tftp server wasn’t responding to the requests from the AP. So I configured tftpd-hpa to specifically listen on the broadcast address like this:

[code]]czoxNDQ6XCIkIGNhdCAvZXRjL2RlZmF1bHQvdGZ0cGQtaHBhDQojRGVmYXVsdHMgZm9yIHRmdHBkLWhwYQ0KUlVOX0RBRU1PTj0mIzN7WyYqJl19NDt5ZXMmIzM0Ow0KT1BUSU9OUz0mIzM0Oy1jIC1sIC1zIC92YXIvbGliL3RmdHBib290IC1hIDI1NS4yNTUuMjU1LjI1NSYjMzQ7XCJ7WyYqJl19O3tbJiomXX0=[[/code]

And restarted tftpd with /etc/init.d/tftpd-hpa.

Once I did that, the AP was able to connect and all was well in the world.