On Oct 9, 2017, at 10:29 AM, Jérôme BERTHIER <Jerome.Berthier@inria.fr> wrote:
The filter replies differents vendor specific attributes for each ldap group and finally, we reject the authentication if there is no match.
OK.
For example, for devices from Juniper, we use this setup :
DEFAULT Ldap-Group==ldap_group_1,Huntgroup-Name == JuniperNet Service-Type = Login, Juniper-Local-User-Name := "radius-admin" DEFAULT Ldap-Group==ldap_group_2,Huntgroup-Name == JuniperNet Service-Type = Login, Juniper-Local-User-Name := "radius-operator" DEFAULT Auth-Type := Reject,Huntgroup-Name == JuniperNet
You can also do that all in "unlang", which might be clearer.
I still have few questions :
1) I notice that the variable Ldap-Group is no more set by the last ldap instance called. So, I corrected my config to describe the default instance ldap {}. It works but is it planned to be able to call another instance in the file authorize ?
The LDAP-Group attribute is created only for the "ldap" module. If you have multiple LDAP modules (e.g. ldap ldap1 { ...} ), then there will be an attribute created called "ldap1-LDAP-Group"
2) Since the module ldap does not set auth-type := ldap anymore, I add the lines to the configuration of the site where needed :
if ((ok || updated) && User-Password) { update { control:Auth-Type := ldap } }
Is it correct ?
Yes.
3) Is it correct to use the file authorize to apply filters like we do ? or, shall we do it in the post auth section (it could be innacurate if we need to reject the access) ?
It's fine. Alan DeKok.