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

[John Meyers]

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