Security

Hi

I have seen this behavior in some customer environments and it could be several reasons. One customer had implemented that any unknown wired devices should be placed on the guest network, but implemented it as a reject from ClearPass and configured the switches with the guest network as the reject VLAN. This caused the switches to send a RADIUS request for MAC auth every minute with a lot of rejects as a result. Another customer had a lot of Cisco IP phones and had issues to deploy correct 802.1x profiles and certificates resulting in the phones trying 802.1x about every minute and falling back to MAC auth to get them to work.

In the first case I changed the behavior from a reject in ClearPass to an accept for unknown MAC address and sending a guest role to the switches. As a result almost all rejects was removed and I could see "real" rejects, such as user with wrong passwords or devices with wrong authentication methods etc.

In the second case I had to work with the IP telephony team and help them to get valid certificates and configure 802.1x settings on the phones.

I have also seen environments where computers are using docking stations, and when the computer the docking station is still powered on and the MAC address can't MAC authenticate as it's the computer who has the 802.1x profile. This leads to high loads of rejects during times when the computers sleep or are disconnected like outside office hours. Clients connected behind dump switches may also be an issue if your Aruba switches tries to initiate MAC authentications for MAC addresses that was previously connected to a dumb switch but is no longer connected.

I would say the you should start to drill down the different reasons for all rejects as they bring quite a load on both your ClearPass servers and the network and work with different teams responsible for the device types that cause most of the rejects. Maybe just start look at the top 10 MAC address list in Insight.

------------------------------
Best Regards
Jonas Hammarbäck
MVP Guru, ACEX, ACDX #1600, ACCX #1335, ACX-Network Security
Aranya AB
If you find my answer useful, consider giving kudos and/or mark as solution
------------------------------

Thank you for your answer, @jonas.hammarback

Upon investigation, I observed one address with over 60K authentication attempts over the period of 20hrs [snap attached].

Tracing through it, that MAC address (belongs to a system) is blocked by policy & is listed under blacklist group. As of now, I am struggling to find the answer as to why the endpoint is still within the network and attempting to authenticate though being blocked.

Is there any limit to MAC authentication attempts per second?

"I have also seen environments where computers are using docking stations, and when the computer the docking station is still powered on and the MAC address can't MAC authenticate as it's the computer who has the 802.1x profile. This leads to high loads of rejects during times when the computers sleep or are disconnected like outside office hours. Clients connected behind dump switches may also be an issue if your Aruba switches tries to initiate MAC authentications for MAC addresses that was previously connected to a dumb switch but is no longer connected."

This might be the case in our environment since all the computers (approx. 2L) are using docking stations.

Original Message:
Sent: May 27, 2025 05:05 AM
From: jonas.hammarback
Subject: ClearPass Insight - Success vs Failed Authentication Trend

Hi

I have seen this behavior in some customer environments and it could be several reasons. One customer had implemented that any unknown wired devices should be placed on the guest network, but implemented it as a reject from ClearPass and configured the switches with the guest network as the reject VLAN. This caused the switches to send a RADIUS request for MAC auth every minute with a lot of rejects as a result. Another customer had a lot of Cisco IP phones and had issues to deploy correct 802.1x profiles and certificates resulting in the phones trying 802.1x about every minute and falling back to MAC auth to get them to work.

In the first case I changed the behavior from a reject in ClearPass to an accept for unknown MAC address and sending a guest role to the switches. As a result almost all rejects was removed and I could see "real" rejects, such as user with wrong passwords or devices with wrong authentication methods etc.

In the second case I had to work with the IP telephony team and help them to get valid certificates and configure 802.1x settings on the phones.

I have also seen environments where computers are using docking stations, and when the computer the docking station is still powered on and the MAC address can't MAC authenticate as it's the computer who has the 802.1x profile. This leads to high loads of rejects during times when the computers sleep or are disconnected like outside office hours. Clients connected behind dump switches may also be an issue if your Aruba switches tries to initiate MAC authentications for MAC addresses that was previously connected to a dumb switch but is no longer connected.

I would say the you should start to drill down the different reasons for all rejects as they bring quite a load on both your ClearPass servers and the network and work with different teams responsible for the device types that cause most of the rejects. Maybe just start look at the top 10 MAC address list in Insight.

------------------------------
Best Regards
Jonas Hammarbäck
MVP Guru, ACEX, ACDX #1600, ACCX #1335, ACX-Network Security
Aranya AB
If you find my answer useful, consider giving kudos and/or mark as solution

Hi.

You would need to dig deeper into Insight and Access Tracker data to see, what is causing REJECTS.

It can be as trivial as for example radius tracker enabled on switches (by default these requests will fail and this is OK) or MAC authentications failing due to registration problems or client or infrastructure misconfiguration. As Jonas wrote there are many possible reasons. In some cases this can be normal and you would likely want to mitigate those cases hence real failings will be shown.

In worst case it can show deliberate attack in progress inside your network.

So from distance we can't say if this is ok or not.

Best, Gorazd

Totally agree with using Insight database here.

Hi.

You would need to dig deeper into Insight and Access Tracker data to see, what is causing REJECTS.

It can be as trivial as for example radius tracker enabled on switches (by default these requests will fail and this is OK) or MAC authentications failing due to registration problems or client or infrastructure misconfiguration. As Jonas wrote there are many possible reasons. In some cases this can be normal and you would likely want to mitigate those cases hence real failings will be shown.

In worst case it can show deliberate attack in progress inside your network.

So from distance we can't say if this is ok or not.

Best, Gorazd

4 years ago I wrote a program that analysed the Insight database. This would extract details of the top 10 devices that failed authentication. Invariably these would be devices that were continually authenticating  - typically every couple of seconds. Likewise, I observed devices that were continually successfully authenticating and then a couple of seconds later would try again… The code (python) is available on GitHub: https://github.com/derinmellor/ClearPass-Operational-Report, it was based on the 6.7-6.9 release. I believe the Insight database schema has subsequently change but I don't have the details.

At the time there didn't seem to be any interest in ClearPass Operational Reports so I moved on. 

Regards Derin

Totally agree with using Insight database here.

Hi.

You would need to dig deeper into Insight and Access Tracker data to see, what is causing REJECTS.

It can be as trivial as for example radius tracker enabled on switches (by default these requests will fail and this is OK) or MAC authentications failing due to registration problems or client or infrastructure misconfiguration. As Jonas wrote there are many possible reasons. In some cases this can be normal and you would likely want to mitigate those cases hence real failings will be shown.

In worst case it can show deliberate attack in progress inside your network.

So from distance we can't say if this is ok or not.

Best, Gorazd

Hi Derin.

Looks like github link has additional "." in url.

But anyhow great job. I use pgadmin to query Clearpass databases to do the same. But having script it is much more convenient.

Best, Gorazd

4 years ago I wrote a program that analysed the Insight database. This would extract details of the top 10 devices that failed authentication. Invariably these would be devices that were continually authenticating  - typically every couple of seconds. Likewise, I observed devices that were continually successfully authenticating and then a couple of seconds later would try again… The code (python) is available on GitHub: https://github.com/derinmellor/ClearPass-Operational-Report, it was based on the 6.7-6.9 release. I believe the Insight database schema has subsequently change but I don't have the details.

At the time there didn't seem to be any interest in ClearPass Operational Reports so I moved on. 

Regards Derin

Totally agree with using Insight database here.

Hi.

You would need to dig deeper into Insight and Access Tracker data to see, what is causing REJECTS.

It can be as trivial as for example radius tracker enabled on switches (by default these requests will fail and this is OK) or MAC authentications failing due to registration problems or client or infrastructure misconfiguration. As Jonas wrote there are many possible reasons. In some cases this can be normal and you would likely want to mitigate those cases hence real failings will be shown.

In worst case it can show deliberate attack in progress inside your network.

So from distance we can't say if this is ok or not.

Best, Gorazd

Gorazd,

AccessTracker is a fabulous tool to investigate individual issues. However, on a large operational site it becomes almost useless. By processing the InsightDB you can see all these trends and offenders - then AccessTracker can be used to understand what is going on a specific offender. What surprises me is so few sites actually look at what their sites are doing. This isn't helped by the default ClearPass Insight Reports being rather restricted. Using the SQL interface allows you to mine this information. What would be really useful would be to build in some AI to dynamically identify concerns. 
Maybe I should toluene my attention to that?

Regards Derin

Hi Derin.

Looks like github link has additional "." in url.

But anyhow great job. I use pgadmin to query Clearpass databases to do the same. But having script it is much more convenient.

Best, Gorazd

4 years ago I wrote a program that analysed the Insight database. This would extract details of the top 10 devices that failed authentication. Invariably these would be devices that were continually authenticating  - typically every couple of seconds. Likewise, I observed devices that were continually successfully authenticating and then a couple of seconds later would try again… The code (python) is available on GitHub: https://github.com/derinmellor/ClearPass-Operational-Report, it was based on the 6.7-6.9 release. I believe the Insight database schema has subsequently change but I don't have the details.

At the time there didn't seem to be any interest in ClearPass Operational Reports so I moved on. 

Regards Derin

Totally agree with using Insight database here.

Hi.

You would need to dig deeper into Insight and Access Tracker data to see, what is causing REJECTS.

It can be as trivial as for example radius tracker enabled on switches (by default these requests will fail and this is OK) or MAC authentications failing due to registration problems or client or infrastructure misconfiguration. As Jonas wrote there are many possible reasons. In some cases this can be normal and you would likely want to mitigate those cases hence real failings will be shown.

In worst case it can show deliberate attack in progress inside your network.

So from distance we can't say if this is ok or not.

Best, Gorazd