Re: LDAP groups and how to filter

12 Feb 2020

      Thanks – for the record it’s FreeIPA.

So your first query works, but returns A LOT:

ldapsearch -D 'uid=admin,cn=users,cn=accounts,dc=server,dc=domain,dc=net' -w<password>' -h localhost -s sub '(objectclass=posixAccount)' -b 'uid=doakes,cn=users,cn=accounts,dc=server,dc=domain,dc=net'

# extended LDIF
#
# LDAPv3
# base <uid=doakes,cn=users,cn=accounts,dc=server,dc=domain,dc=net> with scope subtree
# filter: (objectclass=posixAccount)
# requesting: ALL
#

# doakes, users, accounts, shield.zswitch.net
dn: uid=doakes,cn=users,cn=accounts,dc=server,dc=domain,dc=net
krbLoginFailedCount: 0
krbLastFailedAuth: 20200210075459Z
memberOf: cn=ipausers,cn=groups,cn=accounts,dc=server,dc=domain,dc=net
memberOf: cn=employees,cn=groups,cn=accounts,dc=server,dc=domain,dc=net
memberOf: cn=ops_training_wheels,cn=groups,cn=accounts,dc=server,dc=domain,dc
=net
…

Much output later.

So that works – I’m struggling with how that translates to the group filter.

My mods-enabled/ldap has an identity and password configured in the ldap section.

My base_dn is ‘cn=accounts,dc=server,dc=domain,dc=net’

In the group section I change the filter to '(objectClass=posixAccount)' and uncommented scope = ‘sub’

Currently the membership filter is the default of :

membership_filter = "(|(member=%{control:Ldap-UserDn})(memberUid=%{%{Stripped-User-Name
}:-%{User-Name}}))"

How is that modified to handle that above query so I get the groups?

Sorry, bit of a noob on ldap.

Cheers,
Daniel

From: Freeradius-Users <freeradius-users-bounces+daniel=2600hz.com@lists.freeradius.org>
Date: Thursday, 13 February 2020 at 12:33 AM
To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org>
Subject: Re: LDAP groups and how to filter
I was going to explain something similar but Matthew was much faster.
In addition: You should definitely use ldapsearch on Linux command line
first to find the right
ldap module configuration. Because this has to match your ldap server
structure (did you mention what that
is? AD or OpenLDAP or what?).
ldapsearch is much easier for debugging.
In case you are not so familiar I give you an example:

Matthew described the two ways of getting group ownership.
The memberOf method would (in my case, you have to check for yours!)
translate into the following
ldap query on Ubuntu commandline:
...
ldapsearch -D "cn=<queryUser>,dc=kms,dc=de" -w <queryUserPasswd> -h
LDAPserver -s sub "(objectclass=posixAccount)" -b
"uid=uhahn,ou=people,dc=kms,dc=de" memberOf
Result is:

# extended LDIF
#
# LDAPv3
# base <uid=uhahn,ou=people,dc=kms,dc=de> with scope subtree
# filter: (objectclass=posixAccount)
# requesting: memberOf
#

# uhahn, people, kms.de
dn: uid=uhahn,ou=people,dc=kms,dc=de
memberOf: cn=lehrer,ou=groups,dc=kms,dc=de
memberOf: cn=gast,ou=groups,dc=kms,dc=de

# search result
search: 2
result: 0 Success

Note: Result are two memberOf: lines, i.e. user uhahn belongs to two
groups: lehrer and gast.
This is the most efficient way because you have to check this one user
only for his memberOf attribute.
---------------------------------
The other method without memberOf is to check ALL groups to see if the
user is part of it, i.e. if this name is part
of the member attribute of the group.

The ldapsearch command is:
...
ldapsearch -D "cn=<queryUser>,dc=kms,dc=de" -w <queryUserPasswd> -h
LDAPserver -s sub
"(&(member="uid=uhahn,ou=people,dc=kms,dc=de")(objectClass=groupOfNames))"
-b "ou=groups,dc=kms,dc=de" cn
Result is:

  extended LDIF
#
# LDAPv3
# base <ou=groups,dc=kms,dc=de> with scope subtree
# filter:
(&(member=uid=uhahn,ou=people,dc=kms,dc=de)(objectClass=groupOfNames))
# requesting: cn
#

# lehrer, groups, kms.de
dn: cn=lehrer,ou=groups,dc=kms,dc=de
cn: lehrer

# gast, groups, kms.de
dn: cn=gast,ou=groups,dc=kms,dc=de
cn: gast

# search result
search: 2
result: 0 Success

You get the same result: User uhahn belongs to two groups: lehrer and
gast.
So:
- understand the structure of your underlaying LDAP structure
- test the queries by ldapsearch
- once ldapsearch is working and shows the expected results: configure
the ldap module accordingly

Regards
Uwe
Am 12.02.2020 11:29 schrieb Matthew Newton:
...
On Tue, 2020-02-11 at 23:53 +0000, Daniel Oakes wrote:
...
Thanks that definitely got me a lot closer – but for some reason I’m
not getting an expansion of the groups, so suspect that it’s probably
something to do with the bind user:
Don't try and enumerate all the groups in FreeRADIUS. Configure the
LDAP module correctly and then use unlang to check groups, similar to
how you posted earlier.
if (LDAP-Group == "LDAP Group One") {
        update reply {
               Fortinet-Group-Name := 'group1'
       }
}
elsif (LDAP-Group == "LDAP Group Two") {
        update reply {
               Fortinet-Group-Name := 'group2'
       }
}
elsif
(....) {
}
There are two ways you can check LDAP group membership. Most efficient
is normally to use the "memberOf" attribute, see "membership_attribute"
in mods-available/ldap. This is a virtual attribute maintained by the
LDAP server for each entry with a list of all the groups that entry is
a member of. Not all LDAP servers provide it, or it might not be
enabled.
The alternative is to use a filter and look for all groups that contain
"member={search DN}". This may be slower, but should be supported on
all LDAP servers. See "membership_filter" in the ldap config.
In both cases, you need server permission to be able to either read all
relevant groups (membership_filter), or the memberOf attribute
(membership_attribute).
So, like Alan said, use `ldapsearch` to do the search to check that
FreeRADIUS can get the result, then configure the group member options
in LDAP as required and use the special LDAP-Group attribute above to
do the checking. Don't try and enumerate group memberships in unlang,
the module does the checking for you. Using &LDAP-Group[*] is likely
the wrong approach.
There's a lot more at https://wiki.freeradius.org/modules/Rlm_ldap
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html