glad I could help.
There is no specific conditions that needs to be matched in order for multiple enforcement profiles to be applied. Every enforcement profile you apply for a rule in your policy should be applied. There are many use cases for applying multiple profiles.
Such as those shown by Herman. I also like to add a post-authentication profile to wired enforcements, which updates the location of the end device in the attributes.
Original Message:
Sent: May 22, 2025 12:21 PM
From: djwilliams-dmu
Subject: AOSCX with EAP-TEAP Auth (CPPM) - No client username resolution on the switch
Hey Herman!
Thank you for sharing your configuration. Right now I apply a role to absolutely everything. I match TEAP and all kinds of criteria in the role mapping. My enforcement policy basically just becomes "if role = x, than run this enforcement profile."
I have not had much luck applying multiple enforcement profiles on a single match condition in an enforcement policy. It seems to just execute the first profile. What conditions need to exist for Clearpass to execute more than one enforcement profile?
Original Message:
Sent: May 22, 2025 11:50 AM
From: Herman Robers
Subject: AOSCX with EAP-TEAP Auth (CPPM) - No client username resolution on the switch
Can't see what your full configuration looks like, but this Enforcement Policy is how it works for me:
The Role-employee is applied for Aruba role capable devices, the VLANs for non-role capable devices; but most important is the TEAP-Method-1-Username in line 2 that returns the computer (Method-1) username if Method-2 fails, and the Method-2 (User) is returned if both methods are successful.
From your diagram, one difference is that you should always return a role. What I can't see, is the Rules Evaluation Algorithm. What works best for me is to have 'apply-all' in the Role Mapping policy, but a 'first-applicable' in the Enforcement. That is because in that case you are certain which enforcement profiles are returned. If there can be profiles from different rules, it becomes blurry as if there multiple enforcement profiles selected for the same attribute, there can be conflicts and for many attributes only a single value can be returned.
Hope this helps, and doesn't confuse you even more....
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your HPE Aruba Networking partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact HPE Aruba Networking TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or HPE Aruba Networking.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
Original Message:
Sent: May 21, 2025 11:44 AM
From: djwilliams-dmu
Subject: AOSCX with EAP-TEAP Auth (CPPM) - No client username resolution on the switch
Thank you Levi! This led me right to what I needed. I learned something else in this process I wanted to post.
In the enforcement policy we can apply multiple enforcement profiles to a match condition. This did not work for me. I'll be honest, I don't fully understand why you would apply multiple enforcement profiles to a match statement in an enforcement policy or why you would or could move them up and down in priority if they don't all execute. The use case is a bit lost on me.
What did work was simply adding another attribute to return in the existing enforcement profile that was being matched by the enforcement policy condition already. I added a little diagram that might explain what didn't work for me and what did work.
Original Message:
Sent: May 20, 2025 02:07 AM
From: levi_m
Subject: AOSCX with EAP-TEAP Auth (CPPM) - No client username resolution on the switch
Hi,
to see the clients username you have to send the right teap-username to the nad via an enforcement profile. If you want to see the user you would have to send the teap-method-2-username.
You have to create an enforcement profile for that. Inside the profile you send the clients TEAP Method 2 username as the value for the standard RADIUS attribute "User-Name". The value should be an dynamic variable, so it has to be in curly brackets (%{XXX}). Inside the brackets you define the TEAP Method of which you want to see the username.
You can see tthe correct name for that inside an access tracker record.
Then you can add this profile to your enforcement policy.
The "anonymous" comes from an standard windows security setting inside the nic profile.
Best,
Levi
Original Message:
Sent: May 19, 2025 04:27 PM
From: djwilliams-dmu
Subject: AOSCX with EAP-TEAP Auth (CPPM) - No client username resolution on the switch
I have a question about where the AOS CX switch gets the information that it shows for "Client-Name" in the output of the "show port-access client" command when doing 802.1x authentication.
I'm migrating from EAP-PEAP to EAP-TEAP and the EAP-PEAP usernames show up in the output but the EAP-TEAP users show up with "anonymous" Is there an attribute I can return from Clearpass that will allow the switch to reflect what user is authenticated on a switchport?
e4207stk01# sho port-access client
Port Access Clients
RADIUS overridden user roles are suffixed with '*'
Flags: Onboarding-Method|Mode|Device-Type|Status
Onboarding-Method: 1x 802.1X, ma MAC-Auth, ps Port-Security, dp Device-Profile
Mode: c Client-Mode, d Device-Mode, m Multi-Domain
Device-Type: d Data, v Voice
Status: s Success, f Failed, p In-Progress, d Role-Download-Failed
--------------------------------------------------------------------------------------------------------------
Port Client-Name IPv4-Address User-Role VLAN Flags
--------------------------------------------------------------------------------------------------------------
3/1/47 anonymous 10.10.32.15 USER-Employee (u)1001 1x|c|-|s