EAP-TLS and EAP-PEAP with different authentication/authorization settings

John Meyers john+freeradius at themeyers.us
Wed Jul 12 16:20:52 CEST 2017


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






More information about the Freeradius-Users mailing list