Wireless Access

We have a lot of users that undock their laptops (w/o powering them down) and take them to a conference room in another building on our campus.  When the users lift the lid of their laptop, they're presented with the Windows lock screen.  After they log in, they may or may not have full connectivity to the wireless network.  Often, I find that the user has full bars on their wireless icon, but they're not able to access network resources.  If I look up the users current role, they don't have the 802.1x default role. Instead, they have a lesser role assigned, such as when user authentication fails.   Also, if I look at the current AP they're associated with, it's an AP on a different controller than the controller they were on before they left their desk.  I believe the issue is with the mobility setup, which I've already reconfigured and am waiting to hear back from users.

What I want to know is if I should expect a proper mobility configuration to fix the issue or if this is possibly a whole other issue?  Should the laptop be able to connect back onto the network without issues after it's been in a standby state for a few minutes?

What you describe seems to be a inter controller mobility issue. And i belive that the users that connect to the SSID X on controller A will be placed in a different VLAN than the users who connect to SSID X on controller B. If this is the case then L3 mobility should be enabled across controllers. This way the users can succesfully roam to the forgien controller and still retain thier home IP and access all the required resources. The campus VRD has a Chapter on Mobility. This VRD is available at http://www.arubanetworks.com/pdf/technology/VRD_Campus_Networks.pdf

Two most important things required for configuring L3 mobility are

• Configuring the HAT table and making it active
• Enabling mobile IP on the VAP (This should be enabled by default on a VAP unless you turned it off).

Normally, the controller has a user idle time out (this is configurable- 5 min default). Before this time expires the contorller will make sure whether the client is still on the network using ICMP . However, if the laptop is asleep or if the client firewall blocks ICMP , then it won't reply to the ICMP and the controller will remove the client from the user table. The device will have to reconnect to the network when it wakes up. In most cases this happens seamlessly  once the network settings are properly set in the client's wireless configuration utility.

Regards,

Sathya

You don't happen to have "enforce machine authentication" enabled ("machine-authentication enable" in the CLI) within your dot1x profile do you? And running PEAP maybe? It's also important to know what code level you're running.

---

@The.racking.monkey wrote:

You don't happen to have "enforce machine authentication" enabled ("machine-authentication enable" in the CLI) within your dot1x profile do you? And running PEAP maybe? It's also important to know what code level you're running.

 

 

---

Yes, two both questions.

Version 5 code.

I've seen what you're describing a few times, but for different reasons.

In your scenario, are the controllers the user is moving between a master/local, or master and different master (or in fact a local off another master)? i.e. are they moving between controllers that don't have a direct relationship (I'm not talking about mobility relationship)?

If so (and if I remember how this works correctly), the machine-auth enforce won't always kick even if you have mobility configured etc. The machine auth-enforce works by adding a mac to the local user database (of the host) during initial boot-up. It's important to note that most MS OS hosts typically only do this when it thinks no user has ever logged on (i.e. during boot). When a subsequent user auth comes in (when a user roams or logs in initially), the controller actually checks the local database for a host mac (which gets added when the host connected during boot up). If it's not there, the user gets a restricted role. Note that in this scenario, a

Let's look at what happens to you. You say sometimes this works, and sometimes not? If so, I'm guessing this might also be determined by the time it took the user to move and where they went (out of APs range or not). Check your user AAA and firewall idle timeouts as a guide for this too. When a user does roam to the new controller, the machine will most likely still send a dot1x when the user logs back in. This is irrespecitive of if the WiFi nic is on or off. I've observed different client nic behaviour, but most often the host/nic combo will send another fresh dot1x when the user logs in (after lifting the lid). You could confirm this by looking at your radius logs. If this is happening, and the controller database that the user moved to doesn't have their mac in it, they'll get restricted UNLESS an original user entry is on the previous controller with a full role. So...

1. User does initial log on. All good.

2. User moves (at this point, the original controller might also start idle timers (if it sees no user packets)).

3. User opens lids and tries to logon.

IF the user sent no packets between steps 2 and 3 (very likely with lid shut), and the length of time taken was greater than the user timeout;

A. The original session on the first controller would have aged out and been removed. The result would be mobility wouldn't help, as this isn't a roam anymore (client isn't roaming, they're silent moving).

B. When the laptop wakes up at the new location, it starts a fresh dot1x on a new controller (which doesn't have the host mac in the DB potentially) using user credentials (instead of host) and gets restricted. You reboot (which causes a host auth) to resolve the issue.

Point B might also be affected by the role of the second controller. I'm a bit sketchy on my memory of this, but I'm pretty sure in v5 the controllers always leverage their own databases for machine-auth enforce. However, it might be that locals check against a master (but I'm not sure they'd be able to add macs to it). Note this feature changed massively in v6 (now uses local key caches etc in addition).

So... you should do a controlled test.

1. Check your user idle timeouts.

2. Get a user to "roam" having made a note of the original controller type, second controller type and time they took. Actively watch on the controllers for the user as they idle out on the original and get added to the second.

3. When they open the lid, if they get restricted (before rebooting) record how long they took, and whether the first idled them out before the second saw them. Also, check the new hosting controller local-user db. Is their host mac there?

If the user idle timeout didn't purge the user, and they did achieve proper mobility in this case, I'd expect them to get their original role. However, I'm wondering if either;

1. The machine-auth enforce is over-riding the mobility (user role during handover doesn't get preserved)

2. and/or the user entry is aging out on the original before the new one starts, therefore this isn't a roam at all and you start as a user (get restricted).

I'm also asking the other questions to refresh my memory about where v5 local-db macs for hosts get added (local dbs or up to the masters)! :-)

---

@The.racking.monkey wrote:

In your scenario, are the controllers the user is moving between a master/local, or master and different master (or in fact a local off another master)? i.e. are they moving between controllers that don't have a direct relationship (I'm not talking about mobility relationship)?

 

If so (and if I remember how this works correctly), the machine-auth enforce won't always kick even if you have mobility configured etc. The machine auth-enforce works by adding a mac to the local user database (of the host) during initial boot-up. It's important to note that most MS OS hosts typically only do this when it thinks no user has ever logged on (i.e. during boot). When a subsequent user auth comes in (when a user roams or logs in initially), the controller actually checks the local database for a host mac (which gets added when the host connected during boot up). If it's not there, the user gets a restricted role. Note that in this scenario, a

 

---

There are 2 local controllers that the user may roam between.

I called technical support yesterday and my Aruba system engineer today, and they both told me that what I'm experiencing is the expected behavior when "enforce machine authorization" is enabled.  With machine and user auth enabled, a user can not roam between controllers.  The explanation being that machine auth only occurs once, during bootup, so the user will only be able to authenticate to the other controller with their user credentials.  This will result in getting the user auth role, which is what I'm seeing.

I understand the explanation, but find it hard to believe that there isn't some way that roaming w/machine auth isn't possible.  I would think most organizations want machine authorization and need to provide roaming as well.

I'm not sure I believe that, but wouldn't be sure without testing. I would have thought that the local database check (which is what the machine auth enforce does) looking for the host mac of the machine added during bootup would have been checked by the local controller against the master database but maybe not.

There's an easy way to check. Try manually adding the host mac of a test client (look in the master internal database for it just after boot-up), to the local controller you are going to move to. Then simulate a walk. It that test works, then the answer is right.

Then, it's just a case of working out what to do next. Prepare yourself for EAP-TLS as a solution possibly!

If you're doing machine auth, as well as user auth, in your PEAP implementation, that sometimes causes authentication problems like you're describing.

If you're doing User or Computer Authentication, Windows only sends its machine credentials once; on boot.  After that, it will send user credentials whenever asked.  So machine auth actually passes before the user hits CTRL-ALT-DEL to log in.

That being said, one way to make this troubleshooting a bit easier is to distinguish between which authentication mechanisms have passed, and which have failed.

We have 4 user roles for our employees:  logon (if neither auth has passed), machine-only (if machine auth passes, but user auth does not), user-only (if user auth passes, but machine auth doesn't), and employee (if both machine and user auth pass).

This way, we can distinguish between the different authentication errors by looking at the user's current role.  If our helpdesk sees that the person is in the 'user-only' role, then they need to reboot their laptop.

Also, you should be able to see both RADIUS auth requests hit your RADIUS server.  If you don't see two individual auth requests; then something isn't right.  

I hope this helps!

- Jay

---

@jwadleigh wrote:

If you're doing machine auth, as well as user auth, in your PEAP implementation, that sometimes causes authentication problems like you're describing.

 

If you're doing User or Computer Authentication, Windows only sends its machine credentials once; on boot.  After that, it will send user credentials whenever asked.  So machine auth actually passes before the user hits CTRL-ALT-DEL to log in.

 

That being said, one way to make this troubleshooting a bit easier is to distinguish between which authentication mechanisms have passed, and which have failed.

 

We have 4 user roles for our employees:  logon (if neither auth has passed), machine-only (if machine auth passes, but user auth does not), user-only (if user auth passes, but machine auth doesn't), and employee (if both machine and user auth pass).

 

This way, we can distinguish between the different authentication errors by looking at the user's current role.  If our helpdesk sees that the person is in the 'user-only' role, then they need to reboot their laptop.

 

Also, you should be able to see both RADIUS auth requests hit your RADIUS server.  If you don't see two individual auth requests; then something isn't right.  

 

I hope this helps!

 

- Jay

---

We are set up identically: machine/user auth, PEAP, and 4 possible roles.   I often tell people to reboot if they're not able to connect, but it's something that the user doesn't want to have to do.  I would like to believe that this shouldn't be a requirement. When have you noticed issues with this configuration?

I did confirm that some of the laptops are setup to "Do nothing" when the laptop lid is closed.  This would mean that the radio stays active while the lid is shut, so if the user is walking around the campus, it's possible that they will roam between controllers.

I've gone ahead and enabled VLAN mobility which should work for our environment.  IP mobility was configured, but it wasn't correct, which is why I believe mobility wasn't working in the first place.

We're running 5.0 code.