LDAP-UserDN is not unique per ldap module instance (auth problem when multiple ldap module instances used)
Hello all, in my current authentication policy, I use 2 instances of the LDAP module. The first instance queries the directory in a specific branch and gets information used in later checks. The other instance is used to authorize the user (and also authenticate him in some rare situations) and queries another branch. The problem is that when the second LDAP module is used for the authentication, it tries to bind with an LDAP-UserDN attribute obtained from the first module. I need to rewrite control:LDAP-UserDN for this to work. Tracing a bit the source, I saw that LDAP-UserDN is set with the '=' operator: https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/src/modules/rlm_... Is this by design? I would expect each module instance to have its own LDAP-UserDN and use that when used in authentication. Am I missing something, or is this something worth of raising a github issue? Regards, Kostas -- Kostas Zorbadelos http://gr.linkedin.com/in/kzorba
On Sep 14, 2018, at 8:04 AM, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
in my current authentication policy, I use 2 instances of the LDAP module. The first instance queries the directory in a specific branch and gets information used in later checks. The other instance is used to authorize the user (and also authenticate him in some rare situations) and queries another branch.
The problem is that when the second LDAP module is used for the authentication, it tries to bind with an LDAP-UserDN attribute obtained from the first module. I need to rewrite control:LDAP-UserDN for this to work. Tracing a bit the source, I saw that LDAP-UserDN is set with the '=' operator:
https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/src/modules/rlm_...
Is this by design? I would expect each module instance to have its own LDAP-UserDN and use that when used in authentication. Am I missing something, or is this something worth of raising a github issue?
No, each module should have it's own LDAP-UserDN, just like each module has it's own LDAP-Group operator. I'll see if I can push a fix. Alan DeKok.
On Sep 14, 2018, at 8:04 AM, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
Is this by design? I would expect each module instance to have its own LDAP-UserDN and use that when used in authentication. Am I missing something, or is this something worth of raising a github issue?
I've pushed a fix: https://github.com/FreeRADIUS/freeradius-server/commit/803cbea51b17620f467dd... Please verify it and get back to me. We should be releasing 3.0.18 soon. Alan DeKok.
On Παρ, Σεπ 14 2018 at 08:32:21 πμ, Alan DeKok <aland@deployingradius.com> wrote: Hello Alan and all, unfortunately I bumped into a side issue when trying to test this. My dev system is old, CentOS 6.10 [root@devradius ~]# gcc --version gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Building branch 3.0.x fails with the following error: CC src/lib/atomic_queue.c src/lib/atomic_queue.c:29:22: error: stdalign.h: No such file or directory src/lib/atomic_queue.c:42: error: expected specifier-qualifier-list before ‘alignas’ src/lib/atomic_queue.c:47: error: expected specifier-qualifier-list before ‘alignas’ src/lib/atomic_queue.c: In function ‘fr_atomic_queue_create’: src/lib/atomic_queue.c:78: error: ‘fr_atomic_queue_t’ has no member named ‘entry’ src/lib/atomic_queue.c:90: error: ‘fr_atomic_queue_t’ has no member named ‘entry’ src/lib/atomic_queue.c:91: error: ‘fr_atomic_queue_t’ has no member named ‘entry’ src/lib/atomic_queue.c:94: error: ‘fr_atomic_queue_t’ has no member named ‘size’ src/lib/atomic_queue.c:100: error: ‘fr_atomic_queue_t’ has no member named ‘head’ src/lib/atomic_queue.c:101: error: ‘fr_atomic_queue_t’ has no member named ‘tail’ src/lib/atomic_queue.c: In function ‘fr_atomic_queue_push’: ... Is there a way to overcome this (without upgrading gcc)? I think this will be an issue affecting 3.0.18 release. Would you like me to report it in a github issue? Tomorrow I will test in a newer CentOS 7 system to test the actual ldap module fix. Regards, Kostas
On Sep 14, 2018, at 8:04 AM, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
Is this by design? I would expect each module instance to have its own LDAP-UserDN and use that when used in authentication. Am I missing something, or is this something worth of raising a github issue?
I've pushed a fix: https://github.com/FreeRADIUS/freeradius-server/commit/803cbea51b17620f467dd...
Please verify it and get back to me. We should be releasing 3.0.18 soon.
Alan DeKok.
-- Kostas Zorbadelos http://gr.linkedin.com/in/kzorba
On Παρ, Σεπ 14 2018 at 08:32:21 πμ, Alan DeKok <aland@deployingradius.com> wrote: Hello, tested with the latest 3.0.x branch, authentication does not work. I think some more work has to be done in the patch. From what I understand, mod_authenticate() in rlm_ldap.c calls rlm_ldap_find_user() that I see gets directly LDAP-UserDN and not the module specific instance https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/src/modules/rlm_... Regards, Kostas
On Sep 14, 2018, at 8:04 AM, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
Is this by design? I would expect each module instance to have its own LDAP-UserDN and use that when used in authentication. Am I missing something, or is this something worth of raising a github issue?
I've pushed a fix: https://github.com/FreeRADIUS/freeradius-server/commit/803cbea51b17620f467dd...
Please verify it and get back to me. We should be releasing 3.0.18 soon.
Alan DeKok.
-- Kostas Zorbadelos http://gr.linkedin.com/in/kzorba
On Sep 16, 2018, at 4:05 PM, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
tested with the latest 3.0.x branch, authentication does not work. I think some more work has to be done in the patch. From what I understand, mod_authenticate() in rlm_ldap.c calls rlm_ldap_find_user() that I see gets directly LDAP-UserDN and not the module specific instance
https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/src/modules/rlm_...
I've pushed a fix, thanks. Alan DeKok.
Hi Alan, I confirm your fixes work now. Authentication succeeds when you use multiple instances of the ldap module, provided you use per-instance LDAP-UserDn. I think this should be made explicit in mods-available/ldap in commented documentation. I see you put # Name of the attribute that contains the user DN. # The default name is LDAP-UserDn. # # If you have multiple LDAP instances, you should # change this configuration item to: # # ${.:instance}-LDAP-UserDn # # That change allows the modules to set their own # User DN, and to not conflict with each other. # user_dn = "LDAP-UserDn" in the group {} section. I think this should be moved in the top level of the ldap module (or can you have user_dn in the group as well)? In my case I added user_dn = ${.:instance}-LDAP-UserDn in the top-level section of my ldap module instance (figured it out from the code). Best regards, Kostas On Δευ, Σεπ 17 2018 at 01:53:26 πμ, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 16, 2018, at 4:05 PM, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
tested with the latest 3.0.x branch, authentication does not work. I think some more work has to be done in the patch. From what I understand, mod_authenticate() in rlm_ldap.c calls rlm_ldap_find_user() that I see gets directly LDAP-UserDN and not the module specific instance
https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/src/modules/rlm_...
I've pushed a fix, thanks.
Alan DeKok.
-- Kostas Zorbadelos http://gr.linkedin.com/in/kzorba
On Sep 17, 2018, at 6:57 AM, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
in the group {} section. I think this should be moved in the top level of the ldap module (or can you have user_dn in the group as well)?
No, it should be in the top-level config. I've pushed a fix. Alan DeKok.
participants (2)
-
Alan DeKok -
Kostas Zorbadelos