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

  • 2
  • Question
  • Updated 5 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 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.