Security

Hello,

My organization is in the process of deploying Aruba Clearpass for Wireless and Wired Policy 802.1x. We tested this solution in a controlled environment with a single test switch for the wired side, but now that we are rolling it out to production we are noticing an alarming issue with RADIUS accounting.

While we are a multi-vendor environment, we heavily utilize Cisco switches for our campus access layer. When we made the switch to use CPPM as the RADIUS server, authentication worked as expected, however when reviewing the accounting data in access tracker, we noticed that we were seeing accounting data in the wrong places. For example, when viewing the access tracker record for a VoIP phone, the Framed-IP-Address data under the accounting tab showed that the voip phone had an IP address on another subnet entirely. Further investigation showed this is not actually the case.

The problem stems from RADIUS attribute 44, Acct-Session-ID. This session ID is NOT unique, in fact, Cisco switches begin with session ID 1 and count up for each accounting session that it starts. What we were seeing on the example mentioned above was accounting data for another device on another switch entirely for a session with the same acct-session-id. When you start talking thousands of switches, this accouting data in access tracker becomes very wrong, and I have concerns about how this may affect the postgres database with all of these duplicate IDs (certain fields are showing up with extremely long values as the erroneous relations are added between the auth and accounting records).

I opened a TAC case and they gave me a couple commands to implement on the switches to hopefully make the Acct-Session-IDs unique across devices by prepending the NAS-IP-Address in this session ID field, but the commands did not work. Cisco is saying that this is expected, as the commands that were given are "not intended to affect dot1x sessions". The commend in question is "radius-server attribute 44 extend-with-addr". This command is documented nowhere in the IOS-XE admin guides. This would have solved my issue entirely, if it worked...

Now, a potential solution to this problem is having the option to use Cisco avpair "audit-session-id" as the primary key in clearpass for RADIUS accounting purposes, but I cant find a way to do this from a user's perspective.

Another solution might be having clearpass take the NAS-IP-Address into account when receiving RADIUS accounting packets and matching them to authentication records.

I have scoured the internet in search of someone else having this same problem and cant turn up anything. We can't be the only place using Clearpass with Cisco switches, right? Having accurate accounting data is crucial for us, and right now our accounting data in CPPM is very, very broken.

I found this on the freeradius site, which is helpful in further explaining the problem. FreeRADIUS 

Cisco has sort of implemented the recommendation made here, but they implemented it with a Cisco AVPair instead of modifying the behavior of Acct-Session-ID directly. 

Appreciate any thoughts or solutions from the community.

The full recommendation, and workaround that has worked for other customers is to add two configuration lines to the Cisco device.

radius-server unique-ident <xx>
radius-server attribute 44 extend-with-addr

Doing this has been shown in the past to result in workable data being sent to ClearPass.  I do see other mentions of fixes that look to be related to this issue that were enabled in ClearPass 6.8.

What's the case number?  What version of ClearPass are you running?

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: May 19, 2024 07:22 PM
From: kaelanh
Subject: Wired RADIUS Accounting Issues

Hello,

My organization is in the process of deploying Aruba Clearpass for Wireless and Wired Policy 802.1x. We tested this solution in a controlled environment with a single test switch for the wired side, but now that we are rolling it out to production we are noticing an alarming issue with RADIUS accounting.

While we are a multi-vendor environment, we heavily utilize Cisco switches for our campus access layer. When we made the switch to use CPPM as the RADIUS server, authentication worked as expected, however when reviewing the accounting data in access tracker, we noticed that we were seeing accounting data in the wrong places. For example, when viewing the access tracker record for a VoIP phone, the Framed-IP-Address data under the accounting tab showed that the voip phone had an IP address on another subnet entirely. Further investigation showed this is not actually the case.

The problem stems from RADIUS attribute 44, Acct-Session-ID. This session ID is NOT unique, in fact, Cisco switches begin with session ID 1 and count up for each accounting session that it starts. What we were seeing on the example mentioned above was accounting data for another device on another switch entirely for a session with the same acct-session-id. When you start talking thousands of switches, this accouting data in access tracker becomes very wrong, and I have concerns about how this may affect the postgres database with all of these duplicate IDs (certain fields are showing up with extremely long values as the erroneous relations are added between the auth and accounting records).

I opened a TAC case and they gave me a couple commands to implement on the switches to hopefully make the Acct-Session-IDs unique across devices by prepending the NAS-IP-Address in this session ID field, but the commands did not work. Cisco is saying that this is expected, as the commands that were given are "not intended to affect dot1x sessions". The commend in question is "radius-server attribute 44 extend-with-addr". This command is documented nowhere in the IOS-XE admin guides. This would have solved my issue entirely, if it worked...

Now, a potential solution to this problem is having the option to use Cisco avpair "audit-session-id" as the primary key in clearpass for RADIUS accounting purposes, but I cant find a way to do this from a user's perspective.

Another solution might be having clearpass take the NAS-IP-Address into account when receiving RADIUS accounting packets and matching them to authentication records.

I have scoured the internet in search of someone else having this same problem and cant turn up anything. We can't be the only place using Clearpass with Cisco switches, right? Having accurate accounting data is crucial for us, and right now our accounting data in CPPM is very, very broken.

I found this on the freeradius site, which is helpful in further explaining the problem. FreeRADIUS 

Cisco has sort of implemented the recommendation made here, but they implemented it with a Cisco AVPair instead of modifying the behavior of Acct-Session-ID directly. 

Appreciate any thoughts or solutions from the community.

Carson,

That is exactly what TAC advised (the two commands you sent), and I was very excited to see these options existed. After applying the commands, I bounced a few ports to cause clients to re-authenticate. However, the Acct-Session-ID's continued to not be unique. Thinking this potentially required a reboot to take effect, I went ahead and rebooted. Still, same behavior on IOS-XE 16.12 train and 17.6 train. I wonder if the behavior is different on IOS classic and IOS-XE? I don't have an IOS classic device to test with.

I opened a Cisco TAC case and their reply was "There were open CDENTS ( defects) for this issue which were closed as working as expected. The reason, those commands do not apply to dot1x.". Doesnt sound like they plan to fix the issue on IOS-XE anytime soon, so I was hoping there was an alternative solution.

Case# 5382004902 // CPPM Ver 6.11.8

Thanks in advance!

Original Message:
Sent: May 20, 2024 10:54 PM
From: chulcher
Subject: Wired RADIUS Accounting Issues

The full recommendation, and workaround that has worked for other customers is to add two configuration lines to the Cisco device.

radius-server unique-ident <xx>
radius-server attribute 44 extend-with-addr

Doing this has been shown in the past to result in workable data being sent to ClearPass.  I do see other mentions of fixes that look to be related to this issue that were enabled in ClearPass 6.8.

What's the case number?  What version of ClearPass are you running?

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: May 19, 2024 07:22 PM
From: kaelanh
Subject: Wired RADIUS Accounting Issues

Hello,

My organization is in the process of deploying Aruba Clearpass for Wireless and Wired Policy 802.1x. We tested this solution in a controlled environment with a single test switch for the wired side, but now that we are rolling it out to production we are noticing an alarming issue with RADIUS accounting.

While we are a multi-vendor environment, we heavily utilize Cisco switches for our campus access layer. When we made the switch to use CPPM as the RADIUS server, authentication worked as expected, however when reviewing the accounting data in access tracker, we noticed that we were seeing accounting data in the wrong places. For example, when viewing the access tracker record for a VoIP phone, the Framed-IP-Address data under the accounting tab showed that the voip phone had an IP address on another subnet entirely. Further investigation showed this is not actually the case.

The problem stems from RADIUS attribute 44, Acct-Session-ID. This session ID is NOT unique, in fact, Cisco switches begin with session ID 1 and count up for each accounting session that it starts. What we were seeing on the example mentioned above was accounting data for another device on another switch entirely for a session with the same acct-session-id. When you start talking thousands of switches, this accouting data in access tracker becomes very wrong, and I have concerns about how this may affect the postgres database with all of these duplicate IDs (certain fields are showing up with extremely long values as the erroneous relations are added between the auth and accounting records).

I opened a TAC case and they gave me a couple commands to implement on the switches to hopefully make the Acct-Session-IDs unique across devices by prepending the NAS-IP-Address in this session ID field, but the commands did not work. Cisco is saying that this is expected, as the commands that were given are "not intended to affect dot1x sessions". The commend in question is "radius-server attribute 44 extend-with-addr". This command is documented nowhere in the IOS-XE admin guides. This would have solved my issue entirely, if it worked...

Now, a potential solution to this problem is having the option to use Cisco avpair "audit-session-id" as the primary key in clearpass for RADIUS accounting purposes, but I cant find a way to do this from a user's perspective.

Another solution might be having clearpass take the NAS-IP-Address into account when receiving RADIUS accounting packets and matching them to authentication records.

I have scoured the internet in search of someone else having this same problem and cant turn up anything. We can't be the only place using Clearpass with Cisco switches, right? Having accurate accounting data is crucial for us, and right now our accounting data in CPPM is very, very broken.

I found this on the freeradius site, which is helpful in further explaining the problem. FreeRADIUS 

Cisco has sort of implemented the recommendation made here, but they implemented it with a Cisco AVPair instead of modifying the behavior of Acct-Session-ID directly. 

Appreciate any thoughts or solutions from the community.

How is the switch defined in ClearPass?  Did you create a network device entry with a single IP address for the switch or with a subnet?

Carson,

That is exactly what TAC advised (the two commands you sent), and I was very excited to see these options existed. After applying the commands, I bounced a few ports to cause clients to re-authenticate. However, the Acct-Session-ID's continued to not be unique. Thinking this potentially required a reboot to take effect, I went ahead and rebooted. Still, same behavior on IOS-XE 16.12 train and 17.6 train. I wonder if the behavior is different on IOS classic and IOS-XE? I don't have an IOS classic device to test with.

I opened a Cisco TAC case and their reply was "There were open CDENTS ( defects) for this issue which were closed as working as expected. The reason, those commands do not apply to dot1x.". Doesnt sound like they plan to fix the issue on IOS-XE anytime soon, so I was hoping there was an alternative solution.

Case# 5382004902 // CPPM Ver 6.11.8

Thanks in advance!

Original Message:
Sent: May 20, 2024 10:54 PM
From: chulcher
Subject: Wired RADIUS Accounting Issues

The full recommendation, and workaround that has worked for other customers is to add two configuration lines to the Cisco device.

radius-server unique-ident <xx>
radius-server attribute 44 extend-with-addr

Doing this has been shown in the past to result in workable data being sent to ClearPass.  I do see other mentions of fixes that look to be related to this issue that were enabled in ClearPass 6.8.

What's the case number?  What version of ClearPass are you running?

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: May 19, 2024 07:22 PM
From: kaelanh
Subject: Wired RADIUS Accounting Issues

Hello,

My organization is in the process of deploying Aruba Clearpass for Wireless and Wired Policy 802.1x. We tested this solution in a controlled environment with a single test switch for the wired side, but now that we are rolling it out to production we are noticing an alarming issue with RADIUS accounting.

While we are a multi-vendor environment, we heavily utilize Cisco switches for our campus access layer. When we made the switch to use CPPM as the RADIUS server, authentication worked as expected, however when reviewing the accounting data in access tracker, we noticed that we were seeing accounting data in the wrong places. For example, when viewing the access tracker record for a VoIP phone, the Framed-IP-Address data under the accounting tab showed that the voip phone had an IP address on another subnet entirely. Further investigation showed this is not actually the case.

The problem stems from RADIUS attribute 44, Acct-Session-ID. This session ID is NOT unique, in fact, Cisco switches begin with session ID 1 and count up for each accounting session that it starts. What we were seeing on the example mentioned above was accounting data for another device on another switch entirely for a session with the same acct-session-id. When you start talking thousands of switches, this accouting data in access tracker becomes very wrong, and I have concerns about how this may affect the postgres database with all of these duplicate IDs (certain fields are showing up with extremely long values as the erroneous relations are added between the auth and accounting records).

I opened a TAC case and they gave me a couple commands to implement on the switches to hopefully make the Acct-Session-IDs unique across devices by prepending the NAS-IP-Address in this session ID field, but the commands did not work. Cisco is saying that this is expected, as the commands that were given are "not intended to affect dot1x sessions". The commend in question is "radius-server attribute 44 extend-with-addr". This command is documented nowhere in the IOS-XE admin guides. This would have solved my issue entirely, if it worked...

Now, a potential solution to this problem is having the option to use Cisco avpair "audit-session-id" as the primary key in clearpass for RADIUS accounting purposes, but I cant find a way to do this from a user's perspective.

Another solution might be having clearpass take the NAS-IP-Address into account when receiving RADIUS accounting packets and matching them to authentication records.

I have scoured the internet in search of someone else having this same problem and cant turn up anything. We can't be the only place using Clearpass with Cisco switches, right? Having accurate accounting data is crucial for us, and right now our accounting data in CPPM is very, very broken.

I found this on the freeradius site, which is helpful in further explaining the problem. FreeRADIUS 

Cisco has sort of implemented the recommendation made here, but they implemented it with a Cisco AVPair instead of modifying the behavior of Acct-Session-ID directly. 

Appreciate any thoughts or solutions from the community.

It is defined with a subnet entry. 

How is the switch defined in ClearPass?  Did you create a network device entry with a single IP address for the switch or with a subnet?

Carson,

That is exactly what TAC advised (the two commands you sent), and I was very excited to see these options existed. After applying the commands, I bounced a few ports to cause clients to re-authenticate. However, the Acct-Session-ID's continued to not be unique. Thinking this potentially required a reboot to take effect, I went ahead and rebooted. Still, same behavior on IOS-XE 16.12 train and 17.6 train. I wonder if the behavior is different on IOS classic and IOS-XE? I don't have an IOS classic device to test with.

I opened a Cisco TAC case and their reply was "There were open CDENTS ( defects) for this issue which were closed as working as expected. The reason, those commands do not apply to dot1x.". Doesnt sound like they plan to fix the issue on IOS-XE anytime soon, so I was hoping there was an alternative solution.

Case# 5382004902 // CPPM Ver 6.11.8

Thanks in advance!

Original Message:
Sent: May 20, 2024 10:54 PM
From: chulcher
Subject: Wired RADIUS Accounting Issues

The full recommendation, and workaround that has worked for other customers is to add two configuration lines to the Cisco device.

radius-server unique-ident <xx>
radius-server attribute 44 extend-with-addr

Doing this has been shown in the past to result in workable data being sent to ClearPass.  I do see other mentions of fixes that look to be related to this issue that were enabled in ClearPass 6.8.

What's the case number?  What version of ClearPass are you running?

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: May 19, 2024 07:22 PM
From: kaelanh
Subject: Wired RADIUS Accounting Issues

Hello,

My organization is in the process of deploying Aruba Clearpass for Wireless and Wired Policy 802.1x. We tested this solution in a controlled environment with a single test switch for the wired side, but now that we are rolling it out to production we are noticing an alarming issue with RADIUS accounting.

While we are a multi-vendor environment, we heavily utilize Cisco switches for our campus access layer. When we made the switch to use CPPM as the RADIUS server, authentication worked as expected, however when reviewing the accounting data in access tracker, we noticed that we were seeing accounting data in the wrong places. For example, when viewing the access tracker record for a VoIP phone, the Framed-IP-Address data under the accounting tab showed that the voip phone had an IP address on another subnet entirely. Further investigation showed this is not actually the case.

The problem stems from RADIUS attribute 44, Acct-Session-ID. This session ID is NOT unique, in fact, Cisco switches begin with session ID 1 and count up for each accounting session that it starts. What we were seeing on the example mentioned above was accounting data for another device on another switch entirely for a session with the same acct-session-id. When you start talking thousands of switches, this accouting data in access tracker becomes very wrong, and I have concerns about how this may affect the postgres database with all of these duplicate IDs (certain fields are showing up with extremely long values as the erroneous relations are added between the auth and accounting records).

I opened a TAC case and they gave me a couple commands to implement on the switches to hopefully make the Acct-Session-IDs unique across devices by prepending the NAS-IP-Address in this session ID field, but the commands did not work. Cisco is saying that this is expected, as the commands that were given are "not intended to affect dot1x sessions". The commend in question is "radius-server attribute 44 extend-with-addr". This command is documented nowhere in the IOS-XE admin guides. This would have solved my issue entirely, if it worked...

Now, a potential solution to this problem is having the option to use Cisco avpair "audit-session-id" as the primary key in clearpass for RADIUS accounting purposes, but I cant find a way to do this from a user's perspective.

Another solution might be having clearpass take the NAS-IP-Address into account when receiving RADIUS accounting packets and matching them to authentication records.

I have scoured the internet in search of someone else having this same problem and cant turn up anything. We can't be the only place using Clearpass with Cisco switches, right? Having accurate accounting data is crucial for us, and right now our accounting data in CPPM is very, very broken.

I found this on the freeradius site, which is helpful in further explaining the problem. FreeRADIUS 

Cisco has sort of implemented the recommendation made here, but they implemented it with a Cisco AVPair instead of modifying the behavior of Acct-Session-ID directly. 

Appreciate any thoughts or solutions from the community.

Try with a single IP address for each switch instead.

It is defined with a subnet entry. 

How is the switch defined in ClearPass?  Did you create a network device entry with a single IP address for the switch or with a subnet?

Carson,

That is exactly what TAC advised (the two commands you sent), and I was very excited to see these options existed. After applying the commands, I bounced a few ports to cause clients to re-authenticate. However, the Acct-Session-ID's continued to not be unique. Thinking this potentially required a reboot to take effect, I went ahead and rebooted. Still, same behavior on IOS-XE 16.12 train and 17.6 train. I wonder if the behavior is different on IOS classic and IOS-XE? I don't have an IOS classic device to test with.

I opened a Cisco TAC case and their reply was "There were open CDENTS ( defects) for this issue which were closed as working as expected. The reason, those commands do not apply to dot1x.". Doesnt sound like they plan to fix the issue on IOS-XE anytime soon, so I was hoping there was an alternative solution.

Case# 5382004902 // CPPM Ver 6.11.8

Thanks in advance!

Original Message:
Sent: May 20, 2024 10:54 PM
From: chulcher
Subject: Wired RADIUS Accounting Issues

The full recommendation, and workaround that has worked for other customers is to add two configuration lines to the Cisco device.

radius-server unique-ident <xx>
radius-server attribute 44 extend-with-addr

Doing this has been shown in the past to result in workable data being sent to ClearPass.  I do see other mentions of fixes that look to be related to this issue that were enabled in ClearPass 6.8.

What's the case number?  What version of ClearPass are you running?

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: May 19, 2024 07:22 PM
From: kaelanh
Subject: Wired RADIUS Accounting Issues

Hello,

My organization is in the process of deploying Aruba Clearpass for Wireless and Wired Policy 802.1x. We tested this solution in a controlled environment with a single test switch for the wired side, but now that we are rolling it out to production we are noticing an alarming issue with RADIUS accounting.

While we are a multi-vendor environment, we heavily utilize Cisco switches for our campus access layer. When we made the switch to use CPPM as the RADIUS server, authentication worked as expected, however when reviewing the accounting data in access tracker, we noticed that we were seeing accounting data in the wrong places. For example, when viewing the access tracker record for a VoIP phone, the Framed-IP-Address data under the accounting tab showed that the voip phone had an IP address on another subnet entirely. Further investigation showed this is not actually the case.

The problem stems from RADIUS attribute 44, Acct-Session-ID. This session ID is NOT unique, in fact, Cisco switches begin with session ID 1 and count up for each accounting session that it starts. What we were seeing on the example mentioned above was accounting data for another device on another switch entirely for a session with the same acct-session-id. When you start talking thousands of switches, this accouting data in access tracker becomes very wrong, and I have concerns about how this may affect the postgres database with all of these duplicate IDs (certain fields are showing up with extremely long values as the erroneous relations are added between the auth and accounting records).

I opened a TAC case and they gave me a couple commands to implement on the switches to hopefully make the Acct-Session-IDs unique across devices by prepending the NAS-IP-Address in this session ID field, but the commands did not work. Cisco is saying that this is expected, as the commands that were given are "not intended to affect dot1x sessions". The commend in question is "radius-server attribute 44 extend-with-addr". This command is documented nowhere in the IOS-XE admin guides. This would have solved my issue entirely, if it worked...

Now, a potential solution to this problem is having the option to use Cisco avpair "audit-session-id" as the primary key in clearpass for RADIUS accounting purposes, but I cant find a way to do this from a user's perspective.

Another solution might be having clearpass take the NAS-IP-Address into account when receiving RADIUS accounting packets and matching them to authentication records.

I have scoured the internet in search of someone else having this same problem and cant turn up anything. We can't be the only place using Clearpass with Cisco switches, right? Having accurate accounting data is crucial for us, and right now our accounting data in CPPM is very, very broken.

I found this on the freeradius site, which is helpful in further explaining the problem. FreeRADIUS 

Cisco has sort of implemented the recommendation made here, but they implemented it with a Cisco AVPair instead of modifying the behavior of Acct-Session-ID directly. 

Appreciate any thoughts or solutions from the community.

I will give that a shot and see how it does. May take a bit longer as I want to reboot the switches so they start the acct-session-ids back at 1 just so it is easy to observe. If it works, this is likely a usable workaround for now, but it definitely complicates our config a bit when scaling to thousands of switches. I think we could make it manageable using the Clearpass API and external tools, but being able to define by subnet greatly simplifies config. Thanks for the direction!

Try with a single IP address for each switch instead.

It is defined with a subnet entry. 

How is the switch defined in ClearPass?  Did you create a network device entry with a single IP address for the switch or with a subnet?

Carson,

That is exactly what TAC advised (the two commands you sent), and I was very excited to see these options existed. After applying the commands, I bounced a few ports to cause clients to re-authenticate. However, the Acct-Session-ID's continued to not be unique. Thinking this potentially required a reboot to take effect, I went ahead and rebooted. Still, same behavior on IOS-XE 16.12 train and 17.6 train. I wonder if the behavior is different on IOS classic and IOS-XE? I don't have an IOS classic device to test with.

I opened a Cisco TAC case and their reply was "There were open CDENTS ( defects) for this issue which were closed as working as expected. The reason, those commands do not apply to dot1x.". Doesnt sound like they plan to fix the issue on IOS-XE anytime soon, so I was hoping there was an alternative solution.

Case# 5382004902 // CPPM Ver 6.11.8

Thanks in advance!

Original Message:
Sent: May 20, 2024 10:54 PM
From: chulcher
Subject: Wired RADIUS Accounting Issues

The full recommendation, and workaround that has worked for other customers is to add two configuration lines to the Cisco device.

radius-server unique-ident <xx>
radius-server attribute 44 extend-with-addr

Doing this has been shown in the past to result in workable data being sent to ClearPass.  I do see other mentions of fixes that look to be related to this issue that were enabled in ClearPass 6.8.

What's the case number?  What version of ClearPass are you running?

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: May 19, 2024 07:22 PM
From: kaelanh
Subject: Wired RADIUS Accounting Issues

Hello,

My organization is in the process of deploying Aruba Clearpass for Wireless and Wired Policy 802.1x. We tested this solution in a controlled environment with a single test switch for the wired side, but now that we are rolling it out to production we are noticing an alarming issue with RADIUS accounting.

While we are a multi-vendor environment, we heavily utilize Cisco switches for our campus access layer. When we made the switch to use CPPM as the RADIUS server, authentication worked as expected, however when reviewing the accounting data in access tracker, we noticed that we were seeing accounting data in the wrong places. For example, when viewing the access tracker record for a VoIP phone, the Framed-IP-Address data under the accounting tab showed that the voip phone had an IP address on another subnet entirely. Further investigation showed this is not actually the case.

The problem stems from RADIUS attribute 44, Acct-Session-ID. This session ID is NOT unique, in fact, Cisco switches begin with session ID 1 and count up for each accounting session that it starts. What we were seeing on the example mentioned above was accounting data for another device on another switch entirely for a session with the same acct-session-id. When you start talking thousands of switches, this accouting data in access tracker becomes very wrong, and I have concerns about how this may affect the postgres database with all of these duplicate IDs (certain fields are showing up with extremely long values as the erroneous relations are added between the auth and accounting records).

I opened a TAC case and they gave me a couple commands to implement on the switches to hopefully make the Acct-Session-IDs unique across devices by prepending the NAS-IP-Address in this session ID field, but the commands did not work. Cisco is saying that this is expected, as the commands that were given are "not intended to affect dot1x sessions". The commend in question is "radius-server attribute 44 extend-with-addr". This command is documented nowhere in the IOS-XE admin guides. This would have solved my issue entirely, if it worked...

Now, a potential solution to this problem is having the option to use Cisco avpair "audit-session-id" as the primary key in clearpass for RADIUS accounting purposes, but I cant find a way to do this from a user's perspective.

Another solution might be having clearpass take the NAS-IP-Address into account when receiving RADIUS accounting packets and matching them to authentication records.

I have scoured the internet in search of someone else having this same problem and cant turn up anything. We can't be the only place using Clearpass with Cisco switches, right? Having accurate accounting data is crucial for us, and right now our accounting data in CPPM is very, very broken.

I found this on the freeradius site, which is helpful in further explaining the problem. FreeRADIUS 

Cisco has sort of implemented the recommendation made here, but they implemented it with a Cisco AVPair instead of modifying the behavior of Acct-Session-ID directly. 

Appreciate any thoughts or solutions from the community.