Security

Hi

During tests performed by one of my customers we discovered that ClearPass sends a retry to Entra ID in case the service isn't available. Is this an expected behavior?

In the Source configuration there are no options to configure the number of retries.

In this specific environment the the RADIUS server configuration was configured with a 5 second timeout. So if Entra ID wasn't accessible ClearPass needed 2x5 seconds to respond with the correct enforcement profile. But at that time the WLAN infrastructure had already considered it as a RADIUS server timeout.

By default this Entra ID timeout is 60 seconds, and with a retry it will reach 120 seconds. No RADIUS authentication in the world will be that patient... 😅 

We have now changed the Entra ID timeout to just 1 second and tests show that normal Entra ID response time is about 200 ms.

2026-08-27 13:16:38,091	[Th 7802 Req 26753221 SessId R000cba62-04-6a901c95] INFO RadiusServer.Radius - rlm_eap_tls: Session established.
2026-08-27 13:16:38,091	[Th 7802 Req 26753221 SessId R000cba62-04-6a901c95] INFO RadiusServer.Radius - rlm_eap_tls: Initiating policy evaluation
2026-08-27 13:16:38,091	[Th 7802 Req 26753221 SessId R000cba62-04-6a901c95] INFO RadiusServer.Radius - rlm_policy: Starting Policy Evaluation.
2026-08-27 13:16:39,100	[HttpModule-ThreadPool-3-0x7fbc08544700 r=R000cba62-04-6a901c95 h=129] ERROR Http.HttpAutzSession - execute: get::<easy_perform>, (error=28) Timeout was reached
2026-08-27 13:16:39,100	[HttpModule-ThreadPool-3-0x7fbc08544700 r=R000cba62-04-6a901c95 h=129] ERROR BaseExtSvr.ExtSvrSession - Unable to get next handle from manager with name=Customer-Entra
2026-08-27 13:16:39,100	[RequestHandler-1-0x7fbbb85e2700 h=21321533 c=R000cba62-04-6a901c95] INFO Core.PETaskRoleMapping - Roles: Customer-IT, Customer-Staff, Customer-Staff_all, Customer-site_Campus, Machine Authenticated]
2026-08-27 13:16:39,100	[RequestHandler-1-0x7fbbb85e2700 r=R000cba62-04-6a901c95 h=21321531 c=R000cba62-04-6a901c95] INFO Core.PETaskScheduler - ** Completed PETaskRoleMapping **
2026-08-27 13:16:39,100	[RequestHandler-1-0x7fbbb85e2700 r=R000cba62-04-6a901c95 h=21321531 c=R000cba62-04-6a901c95] INFO Core.PETaskScheduler - ** Starting PETaskPolicyResult **
2026-08-27 13:16:39,100	[RequestHandler-1-0x7fbbb85e2700 r=R000cba62-04-6a901c95 h=21321531 c=R000cba62-04-6a901c95] INFO Core.PETaskScheduler - ** Completed PETaskPolicyResult **
2026-08-27 13:16:39,100	[RequestHandler-1-0x7fbbb85e2700 r=R000cba62-04-6a901c95 h=21321531 c=R000cba62-04-6a901c95] INFO Core.PETaskScheduler - ** Starting PETaskEnforcement **
2026-08-27 13:16:40,000	[HttpModule-ThreadPool-14-0x7fbbcedf6700 r=R000cba62-04-6a901c95 h=140] ERROR Http.HttpAutzSession - execute: get::<easy_perform>, (error=28) Timeout was reached
2026-08-27 13:16:40,000	[HttpModule-ThreadPool-14-0x7fbbcedf6700 r=R000cba62-04-6a901c95 h=140] ERROR BaseExtSvr.ExtSvrSession - Unable to get next handle from manager with name=Customer-Entra
2026-08-27 13:16:40,000	[RequestHandler-1-0x7fbbb85e2700 h=21321558 c=R000cba62-04-6a901c95] INFO Core.PETaskEnforcement - EnfProfiles: Customer-IT, Customer-Staff-vlan-Campus
2026-08-27 13:16:40,000	[RequestHandler-1-0x7fbbb85e2700 r=R000cba62-04-6a901c95 h=21321531 c=R000cba62-04-6a901c95] INFO Core.PETaskScheduler - ** Completed PETaskEnforcement **
2026-08-27 13:16:40,000	[RequestHandler-1-0x7fbbb85e2700 r=R000cba62-04-6a901c95 h=21321531 c=R000cba62-04-6a901c95] INFO Core.PETaskScheduler - ** Starting PETaskRadiusEnfProfileBuilder **

------------------------------
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
------------------------------

You've read it right, and pretty sure your mitigation is the correct one. The retry is baked in. The authorization source config exposes a timeout but no retry count, so what you can control is exactly what you controlled, keeping timeout times two comfortably inside the NAD's RADIUS timeout. With Entra normally answering in a couple hundred milliseconds, a 1 second timeout costs you nothing really.

One thing to add on top. Look at enabling cached roles and posture attributes for the service, so a short Entra outage rides on the last known authorization instead of stalling every auth. Whether that's acceptable is a policy call, but it turns a hard dependency into a soft one.

------------------------------
Dustin Burns

@Worldcom Exchange, Inc.


If my post was useful accept solution and/or give kudos
------------------------------

We will discuss the idea to enable cached roles in the service. Sounds like a good way to handle short disruptions.

------------------------------
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
------------------------------

Original Message:
Sent: Aug 27, 2026 11:50 AM
From: DB86
Subject: Entra ID authorization retry

You've read it right, and pretty sure your mitigation is the correct one. The retry is baked in. The authorization source config exposes a timeout but no retry count, so what you can control is exactly what you controlled, keeping timeout times two comfortably inside the NAD's RADIUS timeout. With Entra normally answering in a couple hundred milliseconds, a 1 second timeout costs you nothing really.

One thing to add on top. Look at enabling cached roles and posture attributes for the service, so a short Entra outage rides on the last known authorization instead of stalling every auth. Whether that's acceptable is a policy call, but it turns a hard dependency into a soft one.

------------------------------
Dustin Burns

@Worldcom Exchange, Inc.


If my post was useful accept solution and/or give kudos
------------------------------

You didn't mention what type of authentication source you were using. Was the Authentication Type: Azure? 

I had looked at this type only briefly as our current autz with the intune extension adds quite a bit of overhead. Caching through the extension is not the same as caching from the authentication source. I took a non traditional approach to solve this. My deployment with the Azure source is currently only for SSO at this time.  The filter did not work for us as we use machine auth and there was no UPN email format that could be looked up as %{Authenticaiton:Username}. When I changed the filters the autz would fail and I have not had time to question or debug outside quick log review. Currently we fetch the Entra Groups via Intune Extension. 

You can monitor the autz latency via snmp mibs. I have seen quite a negative experience when hundreds of devices are all trying to perform real time autz to a cloud source. I think this is a good conversation and real life challenge of modern day cloud integrations. It sounds nice on paper and appears to function nice on first deployment. 

I agree with what you said, most of the times clients are performing new auth requests in 1-3 seconds vs keeping a radius session open and waiting. There is a new setting on a patch of 6.11 which allows you adjust the radius timeout to as low as 30 seconds "Request Expire Time".  This can help purge client timeouts a bit faster on the back end. 

I think the concept of overhead latency is a good one with cloud integration and radius. Its been a couple years but I recall reading somewhere in freeradius guides or maybe it was the book. External autz like this has warnings on it.