Deep undercover in enemy territory

Main menu

Category Archives: Wireless

So you’ve got Clearpass Guest and you want to allow any guest users to connect and register for an account. To stop anyone from accessing the guest network you enable the “Require sponsor confirmation prior to enabling the account” setting. Then perhaps it would be nice to allow the sponsor to be able to extend guest account expiry time when they enable the account…

This is what I was thinking any way.

So I enabled it on my guest registration page:

Excellent! Or so I thought.

It transpires that when you enable sponsor confirmation and enter something into the “Extend Expiration” section any new guest accounts will be automatically enabled!

I had a quick word with Aruba TAC who informed me that this was not a bug and was in fact by design. Hmm. Strange design.

I really wanted this to work the way I assumed it should, so spent a little bit of time playing around with the form settings on the guest registration page.

I modified the “enabled” field as follows:

Set it to enabled, ensure the user interface option is Drop-down list, modify the description if necessary and remove the “1 | Enable visitor account” from the Options.

There we are. You’ll now get the expected behaviour.

Here’s what the Visitor registration page looks like after making this change.

You guest enters their details, clicks register and gets directed to the Visitor receipt page:

Your sponsor will receive the following email:

“Click here” takes you to this page where you can authorize the guest and extend the expiry time if desired.

Confirmed:

Your Visitor receipt page will now update to allow the new guest to login…

Note: I hard coded my sponsor email address as we always wanted it to go to the same distribution list.

Thin AP (with controller)

Power on the AP and get into apboot mode. You’ll see the option to go into AP boot mode when the AP is booting. You will have to press Enter within a 1-2 second window so pay attention to console messages during bootup.

From the apboot prompt, enter the following commands
apboot> purgeenv
apboot> saveapboot> print (To check that the setting were really purged! There should be no identifying IP addresses)apboot> boot

AP to controller connectivity

An AP will use 4 different method to connect to a controller:

AP Boot command (we don’t tend to do this)

DHCP option 43 (a DHCP option which contains the IP address of the controller can be configured)

ADP multicast & broadcast (If APs are on the same layer 2 subnet as the controller they can use this method)

DNS aruba-master (Create a DNS a record of aruba-master and the APs will use this to find the controller if other methods fail)

So if an AP is failing to connect to the controller it’s a good idea to pull the network cable out of the back of the AP and patch it into your laptop. Run ipconfig and check that you’ve got an IP address in the expected range. If you don’t get an IP address for the correct range or you get an APIPA address then you’ll need to start looking at the wired network.

Also it’s very important that the DHCP DNS Name is configured correctly. AP will try to connect to aruba-master.<DHCP DNS Domain>

Because of this you must ensure that the DNS Domain given out by DHCP matches one of the customers DNS zones and that the zone includes the DNS A record aruba-master that resolves to the IP address of the controller.

How to provision an AP

This is only applicable to thin APs (with a controller). Instant APs will self-provision.

Login to the controller

Go to Configuration > AP Installation

The AP that needs provisioning will likely have a U Flag. See below for details of an example of APs with different Flags.

I’ve removed some identifying information from the image, hence the whitespace..

Select the AP using the tick box on the left and click Provision

Select the appropriate AP group from the dropdown lost (If not self-explanatory, ask someone who knows!)

Give the AP a name (copy the standard of the other APs.)

Click Apply and Reboot.

Wait a couple of minutes and you should see the AP re-appear in the AP Installation page with the new name you set.

Here are some helpful wireless settings that are particularly useful in deployments where there are dense amounts of clients logging in at the same time.

When lots of clients are connected at the same time e.g. in a school, the AP does not immediately start to load balance them as it waits 30 seconds to evaluate each time. The setting is Spectrum Load Balancing Update Interval. Set this at a low level such as 2 seconds and the hand off should be really fast.

This setting is in RF Management > Radio Profile

Secondly, a problem in some places is that by default ARM is client aware and will not change channel if a client is connected. If there’s a device that is always connected this can cause channel issues with APs interfering with each other as they were not allowed to change. I would recommend changing this setting unless you’re using VoIP over your wireless.

This setting is in the ARM profile:

Here’s the scenario:

The customer wanted to provide wireless network access to 2 different groups of users, say sales and technical. The sales and technical user groups have their network privileges restricted by use of VLANs and the customer envisioned have 2 SSIDs, one per user VLAN. Wireless authentication was going to be via a pre-shared key (not my idea!!!).

Here’s the hardware:

I work for an Aruba Networks partner and know that there’s a more elegant solution to what the customer is asking to do when using an Aruba wireless controller but wasn’t aware of a way to do this with a Cisco Wireless LAN Controller.

Solution:

I installed the Certificate Services role on one server and then installed Network Policy Server role on the other.
Created 1 SSID on the Cisco WLC and put it in a guest VLAN which only has Internet access. Configured the SSID to use 802.1x authentication and pointed it at the NPS server and enabled Allow AAA Override. This override setting is key! It allows you to send back RADIUS attributes from NPS which will specify which VLAN users will be put into upon authentication.

Next NPS was configured with 3 Network Policies. One for sales users, one for technical users and one for domain computers.

Now here’s the good bit:

By configuring the following 3 RADIUS standard attribute types in each Network Policy, NPS tells the Cisco WLC that users authenticated should be placed in a VLAN specified in the “Tunnel-Pvt-Group-ID” RADIUS attributes.

Here are the 3 attributes:

[64] Tunnel-Type (Set this to VLAN)
[65] Tunnel-Medium-Type (set this to 802)
[81] Tunnel-Pvt-Group-ID (Set this to the VLAN ID you wish to put the user in)

Next a wireless group policy was configured with the SSID, Encryption, Authentication and single sign on settings and applied to domain computers.

Note: The domain computers NPS Network Policy is essential so that machines can login before the user attempts to authenticate and therefore computer group policy applies and users can authenticate against the domain.

I’ve been working deploying Aruba wireless solutions for some time now and as no 2 clients network infrastructure are the same it offers some challenges and it keeps me on my toes.

Pretty much all of the installations that I do use 802.1x authentication for their corporate SSID and most of the clients use Windows server 2003 & Windows XP SP3. The deployment of the wireless solution is usually pretty smooth as it’s all tried and tested.

Recently I’ve come across an issue with a deployment where the users struggle to authenticate. The machines authenticated but once the user logged in they couldn’t authenticate.

The main difference in the deployment was the IAS server which was Windows server 2008 (so it’s NPS rather than IAS) but the client OS was Windows XP SP3 which is still pretty normal to see.

I double checked the configuration of NPS and it was all fine. The administrator could connect to the wireless and any new users I created could also connect.

I checked the existing user account and noticed that they all used the same mandatory profile which is stored on the server. A bit of investigation via the power of the mighty google and a few minutes later I found a Microsoft KB titled “A Windows XP Service Pack 3-based client computer cannot use the IEEE 802.1x authentication when you use PEAP with PEAP-MSCHAPv2 in a domain“.

Looking at the title this seemed promising and while reading the KB (see below) this is exactly the configuration and what’s occuring.

You configure a Windows Server 2008-based computer as the Network Policy Server (NPS).

You enable IEEE 802.1x authentication in the network.

You use Protected Extensible Authentication Protocol (PEAP) with Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MSCHAPv2) in the network.

In this scenario, when a Windows XP Service Pack 3 (SP3)-based client computer tries to join the network by using the IEEE 802.1x authentication, the IEEE 802.1x authentication fails.

Notes

This problem occurs when you use a user account that uses a mandatory user profile.

This problem does not occur when you use a user account that uses a roaming user profile.

You’ll need to call Microsoft to get hold of the hotfix and make sure you don’t believe them if they say “This hotfix is included in XP SP3″ because it isn’t. They tried to fob be off with that.

The hotfix also comes with a disclaimer…

WARNING: This fix is not publicly available through the Microsoft website as it has not gone through full Microsoft regression testing. If you would like confirmation that this fix is designed to address your specific problem, or if you would like to confirm whether there are any special compatibility or installation issues associated with this fix, you are encouraged to speak to a Support Professional in Product Support Services.

It worked just fine on my clients machines though which made me and them happy.