Hi folks, I think I know the answer to this but I want to confirm it. We (the network infrastructure sysadmins) have been put in a situation where there are EAP-TLS clients on the network with certs issued by two different CAs. From talking to management, this is unavoidable and we must accommodate this with our RADIUS servers. (It's something to do with the way Azure AD does provisioning). My understanding is that a decision about which EAP module to use must be made in the outer server based on attributes in the RADIUS packet and then the correct EAP module can be used for that CA. Am I correct in thinking it is not possible to do something like: authorize { eap_module_1 eap_module_2 } and expect that FreeRADIUS tries each EAP module in turn until it finds one with the right CA? Also that it is not possible to check SSL cert attributes in the outer server to determine the correct CA? Thanks, Jonathan
have you tied with both CAs in chain or by defining/using the cert directory with all certs in there? alan
On Oct 4, 2017, at 6:16 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
We (the network infrastructure sysadmins) have been put in a situation where there are EAP-TLS clients on the network with certs issued by two different CAs. From talking to management, this is unavoidable and we must accommodate this with our RADIUS servers. (It's something to do with the way Azure AD does provisioning).
i.e. they screwed up and don't want to admit it. There's just no reason for one AD server to have two different CAs.
My understanding is that a decision about which EAP module to use must be made in the outer server based on attributes in the RADIUS packet and then the correct EAP module can be used for that CA.
Yes.
Am I correct in thinking it is not possible to do something like:
authorize { eap_module_1 eap_module_2 }
and expect that FreeRADIUS tries each EAP module in turn until it finds one with the right CA?
That's not how those protocols work.
Also that it is not possible to check SSL cert attributes in the outer server to determine the correct CA?
By the time the server gets that data, it's already chosen one CA, and can't swap mid-stream. If the outer identity is anonymous with no realm, you have no data with which to select an EAP module. if there outer realm has a real name or realm, you can use that to select the EAP module. *Or* if all of the end user systems have *both* CAs provisioned and enabled, then the situation is simple: just use one EAP module, and put both CAs into "ca_file". Alan DeKok.
On 04/10/17 13:15, Alan DeKok wrote:
On Oct 4, 2017, at 6:16 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
We (the network infrastructure sysadmins) have been put in a situation where there are EAP-TLS clients on the network with certs issued by two different CAs. From talking to management, this is unavoidable and we must accommodate this with our RADIUS servers. (It's something to do with the way Azure AD does provisioning). i.e. they screwed up and don't want to admit it. Agree.
There's just no reason for one AD server to have two different CAs. It's two different AD solutions - the traditional on-premises AD and a new cloud-hosted Azure AD. I don't see why they can't have the same CA, but the people responsible for this new hybrid solution disagree. User systems are split between the two ADs.
My understanding is that a decision about which EAP module to use must be made in the outer server based on attributes in the RADIUS packet and then the correct EAP module can be used for that CA. Yes.
Am I correct in thinking it is not possible to do something like:
authorize { eap_module_1 eap_module_2 }
and expect that FreeRADIUS tries each EAP module in turn until it finds one with the right CA? That's not how those protocols work.
Also that it is not possible to check SSL cert attributes in the outer server to determine the correct CA? By the time the server gets that data, it's already chosen one CA, and can't swap mid-stream.
If the outer identity is anonymous with no realm, you have no data with which to select an EAP module. Alas, all these systems have the same anonymous outer realm in the outer identity and from what I can see, no other distinguishing attributes that I could use to filter on. I will ask about getting the clients on Azure AD set to use a different realm.
if there outer realm has a real name or realm, you can use that to select the EAP module.
*Or* if all of the end user systems have *both* CAs provisioned and enabled, then the situation is simple: just use one EAP module, and put both CAs into "ca_file".
Sadly not. There are two types of end user system out in the wild and they have either one CA or the other. They are managed differently but they all use the same realm. Thanks for confirming my beliefs. I'll go back to management and tell them the author of the RFCs says their design won't work. Thanks, Jonathan
On Oct 4, 2017, at 9:23 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
It's two different AD solutions - the traditional on-premises AD and a new cloud-hosted Azure AD. I don't see why they can't have the same CA, but the people responsible for this new hybrid solution disagree. User systems are split between the two ADs.
The CA is just a blob of data. There's no reason they can't use the same CA in two places. Many other people do it.
Alas, all these systems have the same anonymous outer realm in the outer identity and from what I can see, no other distinguishing attributes that I could use to filter on.
That's just dumb...
Sadly not. There are two types of end user system out in the wild and they have either one CA or the other. They are managed differently but they all use the same realm.
Thanks for confirming my beliefs. I'll go back to management and tell them the author of the RFCs says their design won't work.
Yup. They can't work around the limitations of EAP and TLS. No matter what kind of ideas they have, reality is more important. Alan DeKok.
participants (3)
-
Alan Buxey -
Alan DeKok -
Jonathan Gazeley