(resending -- forgot to cc mailing list) Alan, You are of course correct - this works just fine in the post-auth area of the default virtual server. However, is there any reason that radiusprofile attributes (such as VLAN override) would not be honored if done in this manner? In my ldap-machine definition I have: update { ... reply:Tunnel-Private-Group-ID := 'radiusTunnelPrivategroupId' } profile { filter = "(objectclass=radiusprofile)" } The client's LDAP entry contains: objectClass: radiusprofile radiusTunnelPrivateGroupId: 104 And debug output shows: (10) ldap-machine : Performing search in 'ou=computers,dc=example,dc=com' with filter '(cn=TESTMACHINE)', scope 'sub' (10) ldap-machine : Waiting for search result... (10) ldap-machine : User object found at DN "cn=TESTMACHINE,ou=endpoints,dc=example,dc=com" rlm_ldap (ldap-machine): Released connection (4) ... and no reference at all the VLAN override in the access response. On 7/12/17 12:08 PM, Alan DeKok wrote:
On Jul 12, 2017, at 11:50 AM, John Meyers <john+freeradius@themeyers.us> wrote:
OK. I believe I have it roughly working. Thank you! Good to hear.
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" ... } Makes sense.
What I would like to do for the machine query is: filter = "(cn=%{TLS-Client-Cert-Common-Name})" That should work.
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. That attribute should be available in the control list in the post-auth section, tho.
Does this seem to be the correct and reasonable way to do this? Yes.
Alan DeKok.