client classification - tricky request.

  • 1
  • Question
  • Updated 2 years ago
I have some ppsk users,separated into user groups and pushed to differring vlans which has worked extremely well for years. Each user has 3 available connections and I am trying now to use client classification to separate the phones from the laptops so that I can schedule the phones connections only. I have tested client classification and it is working I can see phones changed to a new scheduled test profile ok. I understand the user profile scheduling and that works fine. the issue is I need the phones directed to a new scheduled user profile but keep the existing vlans to keep the same dhcp scopes available.

I have tried cloning the original user profiles,adding schedule and assigning new user attributes which pushed out ok but then created errors in hive "The module auth cannot get the user profile for attribute ##"
Im guessing the user profile attribute doesn't match an existing user group attribute?

I have tried cloning the network policy, the SSID and then creating a new scheduled user profile with the original user attribute/vlan which normally would work (have that working in another hive)
client classification will let me assign the new user profile but the network policy errors out with a duplicate user attribute number

Am rather stuck now and beginning to think this is not possible,except maybe with radius instead of ppsk?
Photo of Kevin Whelan

Kevin Whelan

  • 53 Posts
  • 2 Reply Likes

Posted 2 years ago

  • 1
Photo of Christopher Tawes

Christopher Tawes

  • 14 Posts
  • 2 Reply Likes
After pushing out the changes, did you reboot the APs in question? It seems silly, but when I get missing attributes I do a complete update and then reboot. Give it a shot.
Photo of Kevin Whelan

Kevin Whelan

  • 53 Posts
  • 2 Reply Likes
I have removed all the new user profiles, basically reverted everything back to my original setup, have pushed complete updates 2x and rebooted all aps and am still getting constant errors "The module auth cannot get the user profile for attribute 72" which is annoying because those profiles were deleted over 12 hours ago now, there are no user  attribute 72 anywhere in the system
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
Hi Kevin,

Are you using HiveManager NG or HiveManager 6?

You can get the "module auth cannot get the user profile for attribute xx" error if there is an entry in the roaming cache referencing an attribute which is not present in the running configuration. Even when you reboot an AP, it will re-learn the roaming cache entry from its neighbours when it comes back online, so rebooting the APs one at a time doesn't necessarily clear this condition. Did you reboot all the APs simultaneously or one at a time?

If you issue the command "show roaming cache" on an AP which is reporting this error, can you see any entries which still have 72 in the "UID" column? If you do, use HiveManager to deauth those clients and check the checkbox to clear the roaming information. Alternatively, reboot all the APs at the same time so they basically all start from a fresh state.

As for your original requirement, you can certainly have multiple PPSK groups associated with the same user profile attribute. However you cannot have two different user profiles objects referenced in the same network policy that use the same attribute, as the attribute is what is used internally to uniquely identify the user profile. So your client classification profiles would certainly need to have their own unique attribute, though they can map to the same default VLAN as other profiles.

From what you've described, it sounds like what you originally configured should work. When you add a client re-classification rule against an existing user profile, it should automatically generate the relevant configuration to create that user profile on the AP (and in HM6, you will see the reassigned user profile appear in an expandable list under the original user profile). So it should not be the case that the AP configuration is "missing" the necessary configuration. Unless there is a bug in the version of HM you are running I suppose, and I've only looked at this on HM 6, so maybe there is an issue with NG if that's what you're using.

I wonder if making these config changes while you had users connected may have caused a conflict between the configuration and the roaming cache - again, maybe just clearing the roaming cache across all the APs is what was needed.

The only other thing I can think of is that it might balk at assigning a user profile on a PPSK SSID when there is no PPSK user group that references the attribute used by that profile. This doesn't seem logical to me, but I guess it's possible. You could therefore try creating a PPSK user group using the attribute of the reclassification profile (don't create any actual users in that group, just create the group) and add that group to the list of PPSK user groups against the SSID. You should then see this group when you do a "show user-group" on the AP CLI.
Photo of Kevin Whelan

Kevin Whelan

  • 53 Posts
  • 2 Reply Likes
Thank you roberto for your considered thoughts.
I suspect you have  the issue with the roaming cache and will investigate that thanks. I do always reboot the whole system at once but the HM is so unresponsive in New Zealand this is impossible. I can spends 4-5 hours before I can successfully get 78 aps rebooted or uploaded successfully and I have tried many different high speed internet connections. The issues apart from some 121s which seem to get overloaded and fail at 33 or 66 % are always timeouts or long queues and multiple multiple retries. My uploads can end up on queues 3x longer than #devices we have and just never process. takes 20 mins+ for the system to reset enough to be able to hit cancel or retry on stalled items.
It is beyond frustration and I wondered whether it is because we aren't NG and have been left behind.
I didn't make a new user profile group originally and was about to try again with this option when I read your reply so that's reassuring and I will  pay more attention to the roaming cache this time.
Will keep you updated
Photo of Kevin Whelan

Kevin Whelan

  • 53 Posts
  • 2 Reply Likes
Follow up-
making a new empty user profile group to match the new scheduled user profile has worked and the system has works perfectly.

process for anyone who stumbles on this thread

I have an existing  group of ppsk users in their own user group and user profile with matching attribute number
created Clone of user group and user profile and assigned new matching numbers to both( vlan still same)
new group is left empty of users
applied schedule to this new cloned user profile

in original user profile- assign 3x client classification for android,windows phones and iphones to the new cloned user profile.

Outcome
students can connect to same vlan as original on same SSID using same ppsk, their laptops have permanent access and their phones are controlled by schedule,(disabled during class times)
client manager shows laptops on original profiles attribute number and phones when active show up on new attribute number.