Receiving a minor alarm "The module auth cannot get the user profile for attribute 2011"

  • 2
  • Question
  • Updated 6 months ago
  • Answered
I recently changed my User Profile groups and successfully uploaded the configuration profile to my APs. But now, on some of my APs, I receive a minor alarm, "The module auth cannot get the user profile for attribute 2011". 2011 being my attribute number. Not sure what this error means because my users can successfully authenticate and connect to the network using their PPSK.

Please advise.
Photo of Bob Ogden

Bob Ogden

  • 11 Posts
  • 0 Reply Likes
  • confused

Posted 4 years ago

  • 2
Photo of Andrew Garcia

Andrew Garcia, Official Rep

  • 368 Posts
  • 120 Reply Likes
Sounds like one of the Local PPSK User groups you have assigned to your SSID is returning an attribute number for which you have not defined a corresponding user profile attribute.

Do you have more than one PPSK user group defined for your SSID?

For instance, in the below image, I have 2 local user groups defined (group 1, passing attribute 1111 and group2, passing attribute 2222).  But for the user profiles, I have only defined a user profile with attribute 1111.  I would get the same error message that you are getting, because group2 does not have an associated user profile.

Photo of Farzan Qureshi

Farzan Qureshi

  • 5 Posts
  • 0 Reply Likes
Excellent explanation, Andrew. Helped us to resolve the similar issue.
Photo of Bob Ogden

Bob Ogden

  • 11 Posts
  • 0 Reply Likes
Thanks for the reply. Excellent explanation. Attached is a screenshot of my setup. I have enabled Client Classification under the two User Profiles for the two PPSK authentication groups. The iOS-FacStaff and iOS-Students user profiles have an attribute number of 2011 and 2013 respectively. I have tested this configuration and I receive the right IP Address when connecting my iPhone to the FacStaff or Student psk group.

 
Photo of Andrew Garcia

Andrew Garcia, Official Rep

  • 368 Posts
  • 120 Reply Likes
OK, just so I am clear:
PPSKgroup FacStaff returns 2001
PPSKgroup Student returns 2002
No PPSK groups return the value 2011.

User profile FacStaff-2001 has attribute 2001
User attribute iOS_FacStaff (client classified) has attribute 2011.

I will try to replicate your scenario and see what happens.

Are you on 6.1r6 on both AP and HiveManager?  WHat AP model are you using?
Photo of Bob Ogden

Bob Ogden

  • 11 Posts
  • 0 Reply Likes
Yes, you are clear on the configuration. I am currently on 6.1r6 on both the AP and HiveManager. The AP that has shown the error is a 121 and a 330. Although we have 121s, 330s, 350s, 370s, and 390s in our environment. 
Photo of Andrew Garcia

Andrew Garcia, Official Rep

  • 368 Posts
  • 120 Reply Likes
I replicated the heart of what your configuration looks like and did not receive that error.  Without being able to see your entire network policy config and all the related objects, I can't pinpoint where the problem is.

 
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
I had a similar issue when I included a vlan on the AP trunk for a different user profile for an ap that did not have that vlan in it's user profile. Only noticed the error when a user moved from location A to location B.
Photo of Larry

Larry

  • 55 Posts
  • 1 Reply Like
Are you saying on the switch port that the AP is hooked into? I have four radios showing same error.
Photo of Larry

Larry

  • 55 Posts
  • 1 Reply Like
The "minor" alarm is bringing some serious problems and flakiness. And the ONLY clients in our 105 AP (mostly 230s) deployment are those clients attaching to THOSE four APs that are showing this minor alarm.

I checked the switch side and they are all tagged/untagged appropriately and consistently with all the other APs that aren't having this issue.
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
In the case where these alarms appeared for me.

I had AP330s and cabling that was not labelled properly and no documentation where the cables actually terminated.

I had multi-story structure with different vlans assigned via topology and locations.
In order to allow time to trace each port to a specific location I enabled each trunk port to with all possible vlans that had been configured.

The error seemed to occur when a user connected in one location on vlan X moved to another location where the trunk had vlan X but the AP was not configured for the vlan X.

this may not be related to your issue, but it was the only time I had ever seen the minor alarm.
Photo of Bob Ogden

Bob Ogden

  • 11 Posts
  • 0 Reply Likes
Hi All,

I actually recreated the usergroups and started from scratch. I pushed out the new configuration and have not received any errors. PPSK has worked beautifully and has made our lives a lot easier with our school BYOD rollout. 
Photo of Amanda

Amanda

  • 396 Posts
  • 25 Reply Likes
Thank you for the update!
Photo of LB3

LB3

  • 12 Posts
  • 0 Reply Likes
@Andrew, I'm receiving the same error, and my thoughts were the same as yours.  Clients roaming from one building to the next, the vlan is allowed on the trunk port, but the attribute/vlan (I use the same number) is not specifically in the config for the AP in the second building.  How did you fix this for your installation?
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
On Cisco and Aerohive switches i define the allowed vlans on the AP trunk ports that are specific for that AP.
Photo of LB3

LB3

  • 12 Posts
  • 0 Reply Likes
Were clients still able to roam?  For example if the config is like this:

Building 1: 
Vlan 10 Building1OpenNetwork
Vlan 11 SecureNetwork (WPA2- 802.1x)

Building 2:
Vlan 20 Building2OpenNetwork
Vlan 21 SecureNetwork (WPA2- 802.1x)

Currently my trunk interface would look like this

Building 1: switchport trunk allowed vlan 10,11,21
Building 2: switchport trunk allowed vlan 11,20,21

If I switch it to this config

Building 1: switchport trunk allowed vlan 10,11
Building 2: switchport trunk allowed vlan 20,21

Will clients still be able to seamless roam on the secure network on building 1 and 2?
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
It would most likely be a nomadic roam, client would obtain new ip after re-authenticating to next buildings AP.

supplicant would still need to go through the normal association process to the new AP

for a layer 3 roam
assuming:
the AP coverage from building 1 to building 2 allows the client to make the roaming decision - no dead space in between

when roaming you need a place to roam from and a place to roam to. If you hit dead space in a stair case or else where, it is not a roam.

if FT is enabled, it should speed up dot1x re-auth process

you have the roaming profile configured for the hive

the client actually is transmitting data as they walk from building 1 to building 2

a gre tunnel would be built back until the transmission ends, then the client would get a new IP for the new subnet.

most people will do a nomadic roam

In my situation in a multi-story structure each floor had a vlan and so when user clam shelled a mac book and walked down a floor or two, they would be doing a nomadic roam. So walking building to building should be no different.