Different BaseDN for User/Group Objects in rlm_ldap
Hi List, we are currently using rlm_ldap to check against a LDAP backend, which works fine so far. rlm_ldap is configured to use a BaseDN of "ou=poeple,dc=example,dc=org". We have also specified a group membership filter and are trying to enforce group memberships via the combination of huntgroups-file and Ldap-Group-Settings in the users file. According to debug output, this seems to work (since freeradius is trying to find the groups specified in the users file). However, our groups are stored underneath "ou=groups,dc=example,dc=org" - so rlm_ldap is not able to find them with the basedn shown above. We are also not able to change the basedn to something else, since there is a different user-tree underneath dc=example,dc=org which should not be taken into account by freeradius. Is there is possibility to set a different basedn for group lookups OR another feasable solution (e.g. modify the filter...?). Filter and groupmembership_filter are currently set to: filter = "(uid=%{Stripped-User-Name:-%{mschap:User-Name}})" groupname_attribute = cn groupmembership_filter = "(objectClass=posixGroup)(memberUid=%{Stripped-User-Name:-%{mschap:User-Name}})" Debug output states this: rlm_ldap: performing search in ou=poeple,dc=example,dc=org, with filter (&(cn=GROUP-NAME-FROM-USERS-FILE)(objectClass=posixGroup)(memberUid=LOGIN-USER)) Thanks in advance for your help! -- Mit freundlichen Grüßen / with kind regards Rudolph Bott
Am Mittwoch, 9. Januar 2013, 09:29:48 schrieb Rudolph Bott:
Hi List,
we are currently using rlm_ldap to check against a LDAP backend, which works fine so far. rlm_ldap is configured to use a BaseDN of "ou=poeple,dc=example,dc=org". We have also specified a group membership filter and are trying to enforce group memberships via the combination of huntgroups-file and Ldap-Group-Settings in the users file.
According to debug output, this seems to work (since freeradius is trying to find the groups specified in the users file).
However, our groups are stored underneath "ou=groups,dc=example,dc=org" - so rlm_ldap is not able to find them with the basedn shown above. We are also not able to change the basedn to something else, since there is a different user-tree underneath dc=example,dc=org which should not be taken into account by freeradius.
Is there is possibility to set a different basedn for group lookups OR another feasable solution (e.g. modify the filter...?). Filter and groupmembership_filter are currently set to:
filter = "(uid=%{Stripped-User-Name:-%{mschap:User-Name}})" groupname_attribute = cn groupmembership_filter = "(objectClass=posixGroup)(memberUid=%{Stripped-User-Name:-%{mschap:User-Name }})"
Debug output states this:
rlm_ldap: performing search in ou=poeple,dc=example,dc=org, with filter (&(cn=GROUP-NAME-FROM-USERS-FILE)(objectClass=posixGroup)(memberUid=LOGIN-US ER))
Change the baseDN in the ldap module configuration of FR to "dc=example,dc=org". -- Dr. Michael Schwartzkopff Guardinistr. 63 81375 München Tel: (0163) 172 50 98 Fax: (089) 620 304 13
Hi, thanks for the fast reply. Am 2013-01-09 09:43, schrieb Michael Schwartzkopff:
Am Mittwoch, 9. Januar 2013, 09:29:48 schrieb Rudolph Bott:
Hi List,
we are currently using rlm_ldap to check against a LDAP backend, which works fine so far. rlm_ldap is configured to use a BaseDN of "ou=poeple,dc=example,dc=org". We have also specified a group membership filter and are trying to enforce group memberships via the combination of huntgroups-file and Ldap-Group-Settings in the users file.
According to debug output, this seems to work (since freeradius is trying to find the groups specified in the users file).
However, our groups are stored underneath "ou=groups,dc=example,dc=org" - so rlm_ldap is not able to find them with the basedn shown above. We are also not able to change the basedn to something else, since there is a different user-tree underneath dc=example,dc=org which should not be taken into account by freeradius.
Is there is possibility to set a different basedn for group lookups OR another feasable solution (e.g. modify the filter...?). Filter and groupmembership_filter are currently set to:
filter = "(uid=%{Stripped-User-Name:-%{mschap:User-Name}})" groupname_attribute = cn groupmembership_filter =
"(objectClass=posixGroup)(memberUid=%{Stripped-User-Name:-%{mschap:User-Name }})"
Debug output states this:
rlm_ldap: performing search in ou=poeple,dc=example,dc=org, with filter
(&(cn=GROUP-NAME-FROM-USERS-FILE)(objectClass=posixGroup)(memberUid=LOGIN-US ER))
Change the baseDN in the ldap module configuration of FR to "dc=example,dc=org".
As I said, that is not an option since there is another users tree underneath dc=example,dc=org (e.g. "ou=people2,dc=example,dc=org") which should not be considered/read by freeradius. The LDAP-structure is similar to this: org \- example |- people |- people2 \- groups
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Mit freundlichen Grüßen / with kind regards Rudolph Bott
On Wednesday 09 January 2013 09:29:48 Rudolph Bott wrote:
Is there is possibility to set a different basedn for group lookups OR another feasable solution (e.g. modify the filter...?). Filter and groupmembership_filter are currently set to:
Create a new ldap module called e.g. ldap2 (just copy the existing ldap module and rename it to ldap2, also rename it in the module itself, otherwise FR tries to instantiate the ldap module twice), adjust there the new basedn and call it where you want in authorize section. Regards, Tobias Hachmer
Am 2013-01-09 10:27, schrieb Tobias Hachmer:
On Wednesday 09 January 2013 09:29:48 Rudolph Bott wrote:
Is there is possibility to set a different basedn for group lookups OR another feasable solution (e.g. modify the filter...?). Filter and groupmembership_filter are currently set to:
Create a new ldap module called e.g. ldap2 (just copy the existing ldap module and rename it to ldap2, also rename it in the module itself, otherwise FR tries to instantiate the ldap module twice), adjust there the new basedn and call it where you want in authorize section.
I am not sure if that would work in this case (but maybe I just got the concept of the LDAP module wrong): * NAS XY connects to FR with an Access-Request * the huntgroup/users file tells FR to require the membership of an LDAP-Group named 'blah' * the LDAP module which does the authentication automatically checks if the current user (which it uses to bind to LDAP) is a member of that group How would I exactly fit in another copy of the LDAP module in this scenario? Wouldn't that mean that the second instance of that module would also have to bind to LDAP using the same settings? And how would I tell the second instance to check for the group required by the users file instead of the first module? For completeness, this is a sample line from the huntgroups file: HQ NAS-IP-Address == 1.2.3.4 And this the corresponding users file: DEFAULT Huntgroup-Name == HQ, Ldap-Group == SpecialUserGroup Reply-Message = "\n###### Access granted by SpecialUserGroup ########\n", Fall-Through = no If there is a request from the NAS specified by that IP adress, the LDAP module will automatically check if the user is in the group SpecialUserGroup.
Regards, Tobias Hachmer - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Mit freundlichen Grüßen / with kind regards Rudolph Bott
On Wednesday 09 January 2013 10:48:16 Rudolph Bott wrote:
Am 2013-01-09 10:27, schrieb Tobias Hachmer:
On Wednesday 09 January 2013 09:29:48 Rudolph Bott wrote:
Is there is possibility to set a different basedn for group lookups OR another feasable solution (e.g. modify the filter...?). Filter and
groupmembership_filter are currently set to: Create a new ldap module called e.g. ldap2 (just copy the existing ldap module and rename it to ldap2, also rename it in the module itself, otherwise FR tries to instantiate the ldap module twice), adjust there the new basedn and call it where you want in authorize section.
I am not sure if that would work in this case (but maybe I just got the concept of the LDAP module wrong):
* NAS XY connects to FR with an Access-Request * the huntgroup/users file tells FR to require the membership of an LDAP-Group named 'blah' * the LDAP module which does the authentication automatically checks if the current user (which it uses to bind to LDAP) is a member of that group
How would I exactly fit in another copy of the LDAP module in this scenario? Wouldn't that mean that the second instance of that module would also have to bind to LDAP using the same settings? And how would I tell the second instance to check for the group required by the users file instead of the first module?
You have to configure the second ldap module in the same way as the first. If you just want another basedn and querying against the same ldap directory, adjust only the basdn in second ldap module. Copy /etc/raddb|freeradius/modules/ldap to /etc/raddb|freeradius/modules/ldap2 Be sure that the second ldap module looks like ---snippet--- ldap ldap2 { ---snippet--- The easiest way is to just call it as next as the first ldap module in authorize and authenticate section, fit it to your scenario. If you doing so the ldap search will be done first with ldap module1 and after that with ldap module 2. I guess this is not really what you want. Maybe you can check with unlang on user/group specific things, NAS IP, or huntgroups, I don't know, to call the appropriate correct ldap module. Regards, Tobias Hachmer
On 01/09/2013 08:29 AM, Rudolph Bott wrote:
However, our groups are stored underneath "ou=groups,dc=example,dc=org" - so rlm_ldap is not able to find them with the basedn shown above. We
Unsolicited advice: that's not a great schema, and you should look to move away from it.
are also not able to change the basedn to something else, since there is a different user-tree underneath dc=example,dc=org which should not be taken into account by freeradius.
Define a 2nd copy of the LDAP module with the base DN of the group area. Run the 1st LDAP module before doing any group checks so that "Ldap-UserDN" is populated. Check the per-instance Ldap-Group attribute of the 2nd instance. Like so: ldap { # base DN for users } ldap ldap2 { # base DN for groups } ... authorize { ... ldap if (ldap2-Ldap-Group == FOO) { # will search 2nd base DN using user DN of 1st module } ... } Alternatively, if your users are all in a flat hierarchy, you can hard-code Ldap-UserDN and skip calling the 1st module (unless you need data from there, of course)
Hi Phil, we fixed the problem by using the radiusGroupName attribute in the user's object instead of posixGroup-Objects. Thanks for your help anyone! Am 2013-01-09 12:38, schrieb Phil Mayers:
On 01/09/2013 08:29 AM, Rudolph Bott wrote:
However, our groups are stored underneath "ou=groups,dc=example,dc=org" - so rlm_ldap is not able to find them with the basedn shown above. We
Unsolicited advice: that's not a great schema, and you should look to move away from it.
are also not able to change the basedn to something else, since there is a different user-tree underneath dc=example,dc=org which should not be taken into account by freeradius.
Define a 2nd copy of the LDAP module with the base DN of the group area.
Run the 1st LDAP module before doing any group checks so that "Ldap-UserDN" is populated.
Check the per-instance Ldap-Group attribute of the 2nd instance.
Like so:
ldap { # base DN for users } ldap ldap2 { # base DN for groups }
...
authorize { ... ldap if (ldap2-Ldap-Group == FOO) { # will search 2nd base DN using user DN of 1st module } ... }
Alternatively, if your users are all in a flat hierarchy, you can hard-code Ldap-UserDN and skip calling the 1st module (unless you need data from there, of course) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Mit freundlichen Grüßen / with kind regards Rudolph Bott
participants (4)
-
Michael Schwartzkopff -
Phil Mayers -
Rudolph Bott -
Tobias Hachmer