Questions about ldap authentication, huntgroup and authorize file
Hi, I'm moving a setup from freeradius 2 (CentOS 6) to freeradius 3 (CentOS 7). The server is hosting : - a backend to authenticate users on Wifi 802.1X TTLS-PAP (openldap) and PEAP-MSCHAPv2 (Active Directory) - a backend to authenticate users on network equipment for admin purpose We use several ldap instances described in the ldap module. Our openldap server does not permit to read password. We use anonymous binding to run the authentication process. So, auth-type := <ldap_instance> is setted by ldap module file in each ldap instance : set_auth_type = yes Network equipements are grouped in the file huntgroup to apply a specific policy by using filters on huntgroup and ldap group in the file users. The filter replies differents vendor specific attributes for each ldap group and finally, we reject the authentication if there is no match. 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 I took care of the file README.rst. I had also a look to the documentation page about ldap module : http://wiki.freeradius.org/modules/Rlm_ldap 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 ? 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 ? 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) ? Thanks you for your help Regards, -- Jérôme BERTHIER
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.
Hello Alan, Le 09/10/2017 à 23:38, Alan DeKok a écrit :
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.
Something like that ? if (Ldap-Group == "ldap_group_1" && Huntgroup-Name == "JuniperNet") { update { reply:Service-Type = Login reply:Juniper-Local-User-Name := "radius-admin" } } elsif (Ldap-Group == "ldap_group_1" && Huntgroup-Name == "JuniperNet") { update { reply:Service-Type = Login reply:Juniper-Local-User-Name := "radius-operator" } } elsif (Huntgroup-Name == "JuniperNet") { reject }
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"
Do you mean that I need to setup one module file for each ldap server ? In the file authorize, I tried to use this attribute associated to each ldap server listed in the module file ldap. For example : DEFAULT myldap1-Ldap-Group=="ldap_group_1" , Huntgroup-Name == JuniperNet Service-Type = Login, Juniper-Local-User-Name := "radius-admin" then radiusd does not start because the attribute is unknown : /etc/raddb/mods-config/files/authorize[229]: Parse error (check) for entry DEFAULT: Unknown attribute "myldap1-Ldap-Group" Failed reading /etc/raddb/mods-config/files/authorize /etc/raddb/mods-enabled/files[9]: Instantiation failed for module "files" Regards, -- Jérôme BERTHIER
On Oct 10, 2017, at 12:00 PM, Jérôme BERTHIER <Jerome.Berthier@inria.fr> wrote:
Something like that ?
if (Ldap-Group == "ldap_group_1" && Huntgroup-Name == "JuniperNet") { update { reply:Service-Type = Login reply:Juniper-Local-User-Name := "radius-admin" } } elsif (Ldap-Group == "ldap_group_1" && Huntgroup-Name == "JuniperNet") { update { reply:Service-Type = Login reply:Juniper-Local-User-Name := "radius-operator" } } elsif (Huntgroup-Name == "JuniperNet") { reject }
Yes, that should work. Tho there's no need to check the Huntgroup-Name over and over again. You could just do: if (Huntgroup-Name == "JuniperNet") { if (Ldap-Group == "ldap_group_1") { update reply { Service-Type = Login Juniper-Local-User-Name := "radius-admin" } } elsif (Ldap-Group == "ldap_group_1") { update reply { Service-Type = Login Juniper-Local-User-Name := "radius-operator" } } else { reject } } That seems a lot clearer.
Do you mean that I need to setup one module file for each ldap server ?
If the LDAP servers are different, yes. Your previous message mentioned multiple LDAP instances. So... do you have multiple instances or not?
In the file authorize, I tried to use this attribute associated to each ldap server listed in the module file ldap. For example : DEFAULT myldap1-Ldap-Group=="ldap_group_1" , Huntgroup-Name == JuniperNet Service-Type = Login, Juniper-Local-User-Name := "radius-admin"
then radiusd does not start because the attribute is unknown :
/etc/raddb/mods-config/files/authorize[229]: Parse error (check) for entry DEFAULT: Unknown attribute "myldap1-Ldap-Group" Failed reading /etc/raddb/mods-config/files/authorize /etc/raddb/mods-enabled/files[9]: Instantiation failed for module "files"
Do you have an LDAP module which has: ldap myldap1 { ... } ? Again, see the comments in raddbs/mods-available/ldap. Or the Wiki. This is all documented. Alan DeKok.
Hello Alan, Le 10/10/2017 à 21:37, Alan DeKok a écrit :
On Oct 10, 2017, at 12:00 PM, Jérôme BERTHIER <Jerome.Berthier@inria.fr> wrote:
[...] Yes, that should work. Tho there's no need to check the Huntgroup-Name over and over again. You could just do:
if (Huntgroup-Name == "JuniperNet") { if (Ldap-Group == "ldap_group_1") { update reply { Service-Type = Login Juniper-Local-User-Name := "radius-admin" } } elsif (Ldap-Group == "ldap_group_1") { update reply { Service-Type = Login Juniper-Local-User-Name := "radius-operator" } } else { reject } }
That seems a lot clearer.
Yes thanks you but as far as I see, this syntax does not work inside the file authorize. I took a look to the man page rlm_files. I notive that the variable for cistron compatibility is not set to no. I tried to fix it. It does not change anything. Did you point th unlang syntax in order to use it in other file like the default site file ?
Do you mean that I need to setup one module file for each ldap server ? If the LDAP servers are different, yes.
Your previous message mentioned multiple LDAP instances. So... do you have multiple instances or not?
Yes I used to list all ldap servers in the same file ldap in the directory of mods (a single file for all ldap servers).
In the file authorize, I tried to use this attribute associated to each ldap server listed in the module file ldap. For example : DEFAULT myldap1-Ldap-Group=="ldap_group_1" , Huntgroup-Name == JuniperNet Service-Type = Login, Juniper-Local-User-Name := "radius-admin"
then radiusd does not start because the attribute is unknown :
/etc/raddb/mods-config/files/authorize[229]: Parse error (check) for entry DEFAULT: Unknown attribute "myldap1-Ldap-Group" Failed reading /etc/raddb/mods-config/files/authorize /etc/raddb/mods-enabled/files[9]: Instantiation failed for module "files" Do you have an LDAP module which has:
ldap myldap1 { ... }
?
Yes I tried to create a specific module file for a specific ldap instance myldap1 then I called it in the file authorize. In both cases, the module authorize is not validated for starting radiusd : /etc/raddb/mods-config/files/authorize[228]: Parse error (check) for entry DEFAULT: Unknown attribute "myldap1-Ldap-Group" Failed reading /etc/raddb/mods-config/files/authorize /etc/raddb/mods-enabled/files[9]: Instantiation failed for module "files"
Again, see the comments in raddbs/mods-available/ldap. Or the Wiki. This is all documented.
I read it again. I understand that it is possible to use specific ldap instance and to call it to parse group using <myldap>-Ldap-Group but it seems that it is not supported in the file authorize. I guess it should be used in the post auth section. Thanks you very much Regards, -- Jérôme BERTHIER DSI - SESI - Equipe Conception Inria Bordeaux - Sud-Ouest + 33 5 24 57 40 50
On Oct 12, 2017, at 10:52 AM, Jérôme BERTHIER <Jerome.Berthier@inria.fr> wrote:
Yes thanks you but as far as I see, this syntax does not work inside the file authorize.
It's not supposed to work there. You need to put it into the "default" virtual server.
I tried to create a specific module file for a specific ldap instance myldap1 then I called it in the file authorize.
In both cases, the module authorize is not validated for starting radiusd : /etc/raddb/mods-config/files/authorize[228]: Parse error (check) for entry DEFAULT: Unknown attribute "myldap1-Ldap-Group" Failed reading /etc/raddb/mods-config/files/authorize /etc/raddb/mods-enabled/files[9]: Instantiation failed for module "files"
That should work if the server is configured correctly. Again... post the debug output. ALL of it.
I understand that it is possible to use specific ldap instance and to call it to parse group using <myldap>-Ldap-Group but it seems that it is not supported in the file authorize.
It is supported. You may need to fix your configuration. Alan DeKok.
Le 12/10/2017 à 17:31, Alan DeKok a écrit :
On Oct 12, 2017, at 10:52 AM, Jérôme BERTHIER <Jerome.Berthier@inria.fr> wrote:
Yes thanks you but as far as I see, this syntax does not work inside the file authorize. It's not supposed to work there. You need to put it into the "default" virtual server.
OK I was confused of your previous message.
I tried to create a specific module file for a specific ldap instance myldap1 then I called it in the file authorize.
In both cases, the module authorize is not validated for starting radiusd : /etc/raddb/mods-config/files/authorize[228]: Parse error (check) for entry DEFAULT: Unknown attribute "myldap1-Ldap-Group" Failed reading /etc/raddb/mods-config/files/authorize /etc/raddb/mods-enabled/files[9]: Instantiation failed for module "files" That should work if the server is configured correctly.
Again... post the debug output. ALL of it.
I understand that it is possible to use specific ldap instance and to call it to parse group using <myldap>-Ldap-Group but it seems that it is not supported in the file authorize. It is supported. You may need to fix your configuration.
I found the issue. The attribute myldap1-Ldap-Group is unknown from the module "authorize" because its own module is not yet loaded. I tried both solutution : - define the instance "ldap myldap1 {}" in the ldap module file (linked as an enabled module) - define the instance "ldap myldap1 {}" in a new module file amyldap1 ( linked as an enabled module). If the module files are loaded following alphabet order then this new module should be loaded before the authorize module. By default, It does not work. So, I tried to call the instance myldap1 in the section instanciate of radiusd.conf. It fixed the problem. Now, I can use these attribute in the file authorize. Moreover, I will use the section instanciate to define a unique redundant pool of ldap servers. I 'm interested in this since a while. Thanks you very much for your help Have a nice day -- Jérôme BERTHIER
On Oct 13, 2017, at 7:56 AM, Jérôme BERTHIER <Jerome.Berthier@inria.fr> wrote:
I found the issue. The attribute myldap1-Ldap-Group is unknown from the module "authorize" because its own module is not yet loaded.
That's what the "instantiate" section is for.
I tried both solutution : - define the instance "ldap myldap1 {}" in the ldap module file (linked as an enabled module) - define the instance "ldap myldap1 {}" in a new module file amyldap1 ( linked as an enabled module). If the module files are loaded following alphabet order then this new module should be loaded before the authorize module.
The modules are loaded in the order that they appear in the directory. i.e. essentially randomly.
By default, It does not work.
So, I tried to call the instance myldap1 in the section instanciate of radiusd.conf. It fixed the problem. Now, I can use these attribute in the file authorize.
Moreover, I will use the section instanciate to define a unique redundant pool of ldap servers. I 'm interested in this since a while.
That's good. Alan DeKok.
participants (2)
-
Alan DeKok -
Jérôme BERTHIER