Concurrent Onboarding (port-access onboarding-method concurrent enable) is what triggers both a MAC and 802.1X authentication at the same time.
Sending both at the same time has the benefit that you don't need any timeouts and both MAC and 802.1X work immediate; and with the default settings 802.1X will take precedence (higher security/confidence) over MAC authentication. Most customers just ignore the MAC authentication. If you are not willing to ignore the MAC authentication, you will need to accept that the 802.1X needs to timeout first, and any timeout/retry will cause MAC auths to be delayed, with some (most legacy) devices even failing if they see a delay for DHCP.
My recommendation: keep concurrent onboarding and just ignore the failed MAC auth.
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check
https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.
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: Jun 16, 2023 10:02 AM
From: Mflowers@beta.team
Subject: 802.1x and MAC service getting hit while only 802.1x service needs to hit
Here is my config for this from my 6300 templates. Not sure if this helps you or not.
This will try 802.1x first and if that fails, then fall over to MAC-Auth. I adjusted the eapol-requests/max-retries to limit the time before the MAC-Auth.
interface 1/1/1
no shutdown
%if _interface.1.LAG=1%
description %_interface.1.LAG.Description%
lag 1
%else%
no routing
description ACCESS_PORT
vlan access 3
spanning-tree bpdu-guard
spanning-tree root-guard
spanning-tree tcn-guard
spanning-tree port-type admin-edge
port-access onboarding-method concurrent enable
aaa authentication port-access auth-precedence dot1x mac-auth
aaa authentication port-access client-limit 5
aaa authentication port-access critical-role CRITICAL
aaa authentication port-access reject-role REJECT
aaa authentication port-access dot1x authenticator
eapol-timeout 15
max-eapol-requests 1
max-retries 1
enable
aaa authentication port-access mac-auth
enable
loop-protect
%endif%
Original Message:
Sent: Jun 14, 2023 04:35 AM
From: JeffreyMik
Subject: 802.1x and MAC service getting hit while only 802.1x service needs to hit
I have tried this, but then the fallover to MAC-auth is taking more then a minute. Is there a way to shorten this time?
Jeffrey Mik
Original Message:
Sent: Jun 14, 2023 04:27 AM
From: NHN
Subject: 802.1x and MAC service getting hit while only 802.1x service needs to hit
the recommended way is to configure Auth-Priority & Auth-Order
- 802.1X
- MAC
the switch will not initiate 802.1X authentication request for a device that does not support 802.1X.
------------------------------
NHN
Original Message:
Sent: Jun 14, 2023 03:24 AM
From: JeffreyMik
Subject: 802.1x and MAC service getting hit while only 802.1x service needs to hit
"But I have already found a solution for this problem. I added a configuration in the switch where it first tries using 802.1x and then falls over to MAC-auth. It seems to work because the MAC-auth service doesn't get hit anymore when a 802.1x request is send to Clearpass."
I have tried this a couple of times and found out that when a MAC-auth device gets connected to the network, it takes a long time to fall back to MAC-auth. When a 802.1x supplicant tries to connect it is fast, but the MAC-auth can take up to two minutes to complete.
When I remove the Auth-Priority & Auth-Order commands from the switch config, the MAC-auth services gets hit when a 802.1x supplicant tries to connect. This is not a real big problem because the 802.1x service gets hit aswel and sends back the correct DUR. But it is a bit annoying to see a [deny access profile] response in the access tracker every time a 802.1x supplicant tries to connect.
Does anyone have a solution for this?
Original Message:
Sent: Jun 08, 2023 07:50 AM
From: JeffreyMik
Subject: 802.1x and MAC service getting hit while only 802.1x service needs to hit
Yes ofcourse
This is the one for 802.1x

And this is the one for MAC-auth

But I have already found a solution for this problem. I added a configuration in the switch where it first tries using 802.1x and then falls over to MAC-auth. It seems to work because the MAC-auth service doesn't get hit anymore when a 802.1x request is send to Clearpass.
Original Message:
Sent: Jun 08, 2023 07:25 AM
From: cordless
Subject: 802.1x and MAC service getting hit while only 802.1x service needs to hit
Can you show the MAC and 802.1X Service definition please - Screen shot of the Service Summary. I have to understand how those are defined.
Original Message:
Sent: Jun 08, 2023 04:06 AM
From: JeffreyMik
Subject: 802.1x and MAC service getting hit while only 802.1x service needs to hit
Hello everyone,
I have a question about two services I have in Clearpass. I made two services to handle 802.1x and MAC authentication from an ArubaOS switch (2930F) with firmware version (WC.16.11.0006). I configured the switch to use Clearpass as a radius server to handle authentication and that is working fine. But when I connect a device that does 802.1x, the 802.1x and MAC-auth services are hitting instead of only the 802.1x. Can someone explain how to fix this 'problem'.
And one other thing is that profiling sometimes takes a really long time. I enabled profiling in the service and made a rolemapping that checks if the device category exists in the endpoint database. If that is not the case, then a profiler downloadable user role is send back to the switch that contains an ACL to give access to DHCP/DNS/Clearpass. The downloadable user role also contains a vlan. The vlan on the switch is configured with a ip-helper to Clearpass. SNTP is also configured on the switch and NTP is enabled on Clearpass (Both with the same ntp server).
In the screenshot below you can see what I mean with the profiling taking so long and both of the services getting hit.

So my questions are;
- How can I fix the issue of the two services that are getting hit?
- Why does the profiling of a device is taking so long?
Thanks in advance,
Jeffrey