EAP-TLS and EAP-PEAP with different authentication/authorization settings
Hello, I have what I think is a very common use case. I'd like to support "dual stack" EAP-TLS and EAP-PEAP, the concept being that if a corporate device has a valid certificate and authenticates EPA-TLS it gets validated against one set of rules ultimately culminating with assignment in one or more VLANs, vs a BYOD device authenticated with EAP-PEAP that will go through a different authentication/authorization stack ending up in a different set of possible VLANs. We have the EAP-PEAP case working flawlessly on freeradius-3.0.4-6.el7. The problem is that when I enable the 'virtual_server' option for EAP-TLS, it still hits the default authentication/authorization stack resulting in searching the wrong LDAP (machines and people are separate) before it runs for the virtual server defined. By the time it hits the virtual server, the request has already been denied as the LDAP object does not exist in the area it is looking for. I would also like, if EAP-TLS is used, to ignore whatever username the client passes and instead use the client's CN from its certificate with regard to ldap authorization. If anyone has any advise on how to configure a completely divergent configuration that depends on whether or not the client is use TLS or PEAP, I would appreciate it. John
Just use some unlang in the post-auth section to separate your EAP-TLS policy from your PEAP decisions alan On 11 Jul 2017 10:48 pm, "John Meyers" <john+freeradius@themeyers.us> wrote:
Hello,
I have what I think is a very common use case. I'd like to support "dual stack" EAP-TLS and EAP-PEAP, the concept being that if a corporate device has a valid certificate and authenticates EPA-TLS it gets validated against one set of rules ultimately culminating with assignment in one or more VLANs, vs a BYOD device authenticated with EAP-PEAP that will go through a different authentication/authorization stack ending up in a different set of possible VLANs.
We have the EAP-PEAP case working flawlessly on freeradius-3.0.4-6.el7. The problem is that when I enable the 'virtual_server' option for EAP-TLS, it still hits the default authentication/authorization stack resulting in searching the wrong LDAP (machines and people are separate) before it runs for the virtual server defined. By the time it hits the virtual server, the request has already been denied as the LDAP object does not exist in the area it is looking for. I would also like, if EAP-TLS is used, to ignore whatever username the client passes and instead use the client's CN from its certificate with regard to ldap authorization.
If anyone has any advise on how to configure a completely divergent configuration that depends on whether or not the client is use TLS or PEAP, I would appreciate it.
John
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
Would you mind giving a hint on what this might look like? I'm not familiar with what variable would carry the authentication type, and debug mode does not seem to reveal it. Many thanks for the help! John On 7/11/17 6:12 PM, Alan Buxey wrote: > Just use some unlang in the post-auth section to separate your EAP-TLS > policy from your PEAP decisions > > alan > > On 11 Jul 2017 10:48 pm, "John Meyers" <john+freeradius@themeyers.us> wrote: > >> Hello, >> >> I have what I think is a very common use case. I'd like to support >> "dual stack" EAP-TLS and EAP-PEAP, the concept being that if a corporate >> device has a valid certificate and authenticates EPA-TLS it gets >> validated against one set of rules ultimately culminating with >> assignment in one or more VLANs, vs a BYOD device authenticated with >> EAP-PEAP that will go through a different authentication/authorization >> stack ending up in a different set of possible VLANs. >> >> We have the EAP-PEAP case working flawlessly on freeradius-3.0.4-6.el7. >> The problem is that when I enable the 'virtual_server' option for >> EAP-TLS, it still hits the default authentication/authorization stack >> resulting in searching the wrong LDAP (machines and people are separate) >> before it runs for the virtual server defined. By the time it hits the >> virtual server, the request has already been denied as the LDAP object >> does not exist in the area it is looking for. I would also like, if >> EAP-TLS is used, to ignore whatever username the client passes and >> instead use the client's CN from its certificate with regard to ldap >> authorization. >> >> If anyone has any advise on how to configure a completely divergent >> configuration that depends on whether or not the client is use TLS or >> PEAP, I would appreciate it. >> >> John >> >> >> >> - >> List info/subscribe/unsubscribe? See http://www.freeradius.org/ >> list/users.html > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jul 11, 2017, at 5:48 PM, John Meyers <john+freeradius@themeyers.us> wrote:
I have what I think is a very common use case. I'd like to support "dual stack" EAP-TLS and EAP-PEAP, the concept being that if a corporate device has a valid certificate and authenticates EPA-TLS it gets validated against one set of rules ultimately culminating with assignment in one or more VLANs, vs a BYOD device authenticated with EAP-PEAP that will go through a different authentication/authorization stack ending up in a different set of possible VLANs.
You may need to be more specific than that. The point is that EAP is a protocol with certain pre-defined behaviours, which are out of your control. So you have to fit your rules into the way that EAP behaves, not the other way around.
We have the EAP-PEAP case working flawlessly on freeradius-3.0.4-6.el7. The problem is that when I enable the 'virtual_server' option for EAP-TLS, it still hits the default authentication/authorization stack resulting in searching the wrong LDAP (machines and people are separate) before it runs for the virtual server defined.
And where are those rules? How do they work?
By the time it hits the virtual server,
Which virtual server?
the request has already been denied as the LDAP object does not exist in the area it is looking for. I would also like, if EAP-TLS is used, to ignore whatever username the client passes and instead use the client's CN from its certificate with regard to ldap authorization.
Read the debug output to see when the server knows that EAP-TLS is being used.
If anyone has any advise on how to configure a completely divergent configuration that depends on whether or not the client is use TLS or PEAP, I would appreciate it.
Odds are that you're putting all of the rules into the "authorize" section. This is wrong. That runs before the server knows what EAP type is being used. You should put the PEAP rules into the "inner-tunnel" virtual server. That way they'll (usually) only run when PEAP is being used. Then, put the VLAN assignment rules into the "post-auth" section: if (control:EAP-Type == PEAP) { ... PEAP rules ... } elsif (control:EAP-Type == TLS) { .. TLS rules ... } Alan DeKok.
Alan K and Alan B, Grateful for your help. You are indeed correct, I was using the 'authorize' section for the rules, since that is where the 'files' directive (that refers to mods-config/files/authorize) is placed in the out-of-the-box sample configuration. I am still confused though, since I want to look in different LDAP locations depending on if the client is a human (PEAP) or a machine (TLS). Doesn't ldap need to run in the 'authorize' section? Here is the pseudo-code of what I am trying to accomplish: if (EAP-Type == TLS) { # Client is a machine, override username given with what is on the cert and get attributes from LDAP Username = ClientCert-CN get-ldap-machine-attributes case LDAP-Group { Group-1: VLAN=100, Group-2: VLAN=200, Default: Reject } if (EAP-Type == PEAP) # Client is a human, authenticate against LDAP with provided username/password ldap-authenticate-person get-ldap-person-attributes case LDAP-Group { Group-1: VLAN=500, Group-2: VLAN=600, Default: Reject } Again, very grateful for your insight and assistance. On 7/12/17 7:58 AM, Alan DeKok wrote:
On Jul 11, 2017, at 5:48 PM, John Meyers <john+freeradius@themeyers.us> wrote:
I have what I think is a very common use case. I'd like to support "dual stack" EAP-TLS and EAP-PEAP, the concept being that if a corporate device has a valid certificate and authenticates EPA-TLS it gets validated against one set of rules ultimately culminating with assignment in one or more VLANs, vs a BYOD device authenticated with EAP-PEAP that will go through a different authentication/authorization stack ending up in a different set of possible VLANs. You may need to be more specific than that. The point is that EAP is a protocol with certain pre-defined behaviours, which are out of your control. So you have to fit your rules into the way that EAP behaves, not the other way around.
We have the EAP-PEAP case working flawlessly on freeradius-3.0.4-6.el7. The problem is that when I enable the 'virtual_server' option for EAP-TLS, it still hits the default authentication/authorization stack resulting in searching the wrong LDAP (machines and people are separate) before it runs for the virtual server defined. And where are those rules? How do they work?
By the time it hits the virtual server, Which virtual server?
the request has already been denied as the LDAP object does not exist in the area it is looking for. I would also like, if EAP-TLS is used, to ignore whatever username the client passes and instead use the client's CN from its certificate with regard to ldap authorization. Read the debug output to see when the server knows that EAP-TLS is being used.
If anyone has any advise on how to configure a completely divergent configuration that depends on whether or not the client is use TLS or PEAP, I would appreciate it. Odds are that you're putting all of the rules into the "authorize" section. This is wrong. That runs before the server knows what EAP type is being used.
You should put the PEAP rules into the "inner-tunnel" virtual server. That way they'll (usually) only run when PEAP is being used.
Then, put the VLAN assignment rules into the "post-auth" section:
if (control:EAP-Type == PEAP) { ... PEAP rules ... } elsif (control:EAP-Type == TLS) { .. TLS rules ... }
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jul 12, 2017, at 10:20 AM, John Meyers <john+freeradius@themeyers.us> wrote:
Grateful for your help. You are indeed correct, I was using the 'authorize' section for the rules, since that is where the 'files' directive (that refers to mods-config/files/authorize) is placed in the out-of-the-box sample configuration. I am still confused though, since I want to look in different LDAP locations depending on if the client is a human (PEAP) or a machine (TLS). Doesn't ldap need to run in the 'authorize' section? Here is the pseudo-code of what I am trying to accomplish:
LDAP can run in the authorize section, but it can also run elsewhere.
if (EAP-Type == TLS) { # Client is a machine, override username given with what is on the cert and get attributes from LDAP Username = ClientCert-CN
Don't change the User-Name. It's a bad idea. It will break EAP. Instead, create a *new* attribute which can then be used in the LDAP queries. In this case, Stripped-User-Name will probably Just work.
get-ldap-machine-attributes
Is that a different LDAP module than for PEAP? i.e. are the queries / baseDN different? This probably goes into the "post-auth" section, too.
case LDAP-Group { Group-1: VLAN=100, Group-2: VLAN=200, Default: Reject
This can go into the "post-auth" section of the "default" virtual server: if (LDAP-Group == "group1") { update reply { .. VLAN stuff... } } elsif (LDAP-Group == "group2" { update reply { .. VLAN stuff... } } else { reject }
} if (EAP-Type == PEAP) # Client is a human, authenticate against LDAP with provided username/password ldap-authenticate-person get-ldap-person-attributes
Again, what LDAP module / queries / basedn is used here? And if it's PEAP.. the LDAP checks go into the "inner-tunnel" visual server. Because that's where the real name / password is located. These checks *cannot* go into the "default" virtual server.
case LDAP-Group { Group-1: VLAN=500, Group-2: VLAN=600, Default: Reject }
Same comments as above. And upgrade to 3.0.14. You will likely run into issues with 3.0.4 that are best fixed by an upgrade. Alan DeKok.
OK. I believe I have it roughly working. Thank you! Yes, there are two different LDAP locations: ldap ldap-people { base_dn = "ou=people,dc=example,dc=com" ... } ldap ldap-machines { base_dn = "ou=computers,dc=example,dc=com" ... } What I would like to do for the machine query is: filter = "(cn=%{TLS-Client-Cert-Common-Name})" Following the documentation, I enabled "virtual_server check-eap-tls" in the eap configuration and then added "ldap-machines" to the post-auth section of the "check-eap-tls" server. It does not appear that TLS-Client-Cert-Common-Name is available to the default server. Does this seem to be the correct and reasonable way to do this? John On 7/12/17 10:29 AM, Alan DeKok wrote:
On Jul 12, 2017, at 10:20 AM, John Meyers <john+freeradius@themeyers.us> wrote:
Grateful for your help. You are indeed correct, I was using the 'authorize' section for the rules, since that is where the 'files' directive (that refers to mods-config/files/authorize) is placed in the out-of-the-box sample configuration. I am still confused though, since I want to look in different LDAP locations depending on if the client is a human (PEAP) or a machine (TLS). Doesn't ldap need to run in the 'authorize' section? Here is the pseudo-code of what I am trying to accomplish: LDAP can run in the authorize section, but it can also run elsewhere.
if (EAP-Type == TLS) { # Client is a machine, override username given with what is on the cert and get attributes from LDAP Username = ClientCert-CN Don't change the User-Name. It's a bad idea. It will break EAP.
Instead, create a *new* attribute which can then be used in the LDAP queries. In this case, Stripped-User-Name will probably Just work.
get-ldap-machine-attributes Is that a different LDAP module than for PEAP? i.e. are the queries / baseDN different?
This probably goes into the "post-auth" section, too.
case LDAP-Group { Group-1: VLAN=100, Group-2: VLAN=200, Default: Reject This can go into the "post-auth" section of the "default" virtual server:
if (LDAP-Group == "group1") { update reply { .. VLAN stuff... } } elsif (LDAP-Group == "group2" { update reply { .. VLAN stuff... } } else { reject }
} if (EAP-Type == PEAP) # Client is a human, authenticate against LDAP with provided username/password ldap-authenticate-person get-ldap-person-attributes Again, what LDAP module / queries / basedn is used here?
And if it's PEAP.. the LDAP checks go into the "inner-tunnel" visual server. Because that's where the real name / password is located. These checks *cannot* go into the "default" virtual server.
case LDAP-Group { Group-1: VLAN=500, Group-2: VLAN=600, Default: Reject } Same comments as above.
And upgrade to 3.0.14. You will likely run into issues with 3.0.4 that are best fixed by an upgrade.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan Buxey -
Alan DeKok -
John Meyers