And you should enable cacheable_name or cacheable_dn (=yes) if not done already! Regards Uwe On 02.08.2020 18:01, uj2.hahn@posteo.de wrote:
Victor, did you set the name_attribute = cn (or ou) in ldap module correctly?
Regards Uwe
On 02.08.2020 16:47, Victor via Freeradius-Users wrote:
Hello Alan,
Well, from the wireshark LDAP protocol decode:
-the answer to rlm_ldap:
Lightweight Directory Access Protocol LDAPMessage searchResDone(6) success [2 results] messageID: 6 protocolOp: searchResDone (5) searchResDone resultCode: success (0) matchedDN: errorMessage: [Response To: 16] [Time: 0.000694000 seconds]
-the answer to ldapsearch:
Lightweight Directory Access Protocol LDAPMessage searchResEntry(2) "cn=ipausers,cn=groups,cn=accounts,dc=xxxx,dc=local" [1 result] messageID: 2 protocolOp: searchResEntry (4) searchResEntry objectName: cn=ipausers,cn=groups,cn=accounts,dc=xxxx,dc=local attributes: 5 items PartialAttributeList item objectClass type: objectClass vals: 5 items AttributeValue: top AttributeValue: groupofnames AttributeValue: nestedgroup AttributeValue: ipausergroup AttributeValue: ipaobject PartialAttributeList item description type: description vals: 1 item AttributeValue: Default group for all users PartialAttributeList item cn type: cn vals: 1 item AttributeValue: ipausers PartialAttributeList item ipaUniqueID type: ipaUniqueID vals: 1 item AttributeValue: c862bf44-d36b-11ea-84a9-3ed34312a8ce PartialAttributeList item member type: member vals: 1 item AttributeValue: uid=baseuser,cn=users,cn=accounts,dc=xxxx,dc=local [Response To: 8] [Time: 0.001658000 seconds] Lightweight Directory Access Protocol LDAPMessage searchResDone(2) success [1 result] messageID: 2 protocolOp: searchResDone (5) searchResDone resultCode: success (0) matchedDN: errorMessage: [Response To: 8] [Time: 0.001658000 seconds]
rlm_ldap clearly doesn't get the same answer, almost to the same request (timeLimit differs):
-from rlm_ldap: Lightweight Directory Access Protocol LDAPMessage searchRequest(6) "dc=xxxx,dc=local" wholeSubtree messageID: 6 protocolOp: searchRequest (3) searchRequest baseObject: dc=xxxx,dc=local scope: wholeSubtree (2) derefAliases: neverDerefAliases (0) sizeLimit: 0 timeLimit: 10 typesOnly: False Filter: (&(cn=ipausers)(member=uid=baseuser,cn=users,cn=accounts,dc=xxxx,dc=local)) attributes: 0 items [Response In: 17]
-from ldapsearch:
Lightweight Directory Access Protocol LDAPMessage searchRequest(2) "dc=xxxx,dc=local" wholeSubtree messageID: 2 protocolOp: searchRequest (3) searchRequest baseObject: dc=xxxx,dc=local scope: wholeSubtree (2) derefAliases: neverDerefAliases (0) sizeLimit: 0 timeLimit: 0 typesOnly: False Filter: (&(cn=ipausers)(member=uid=baseuser,cn=users,cn=accounts,dc=xxxx,dc=local)) attributes: 0 items [Response In: 9]
The bind user is the same:
Lightweight Directory Access Protocol LDAPMessage bindRequest(4) "uid=baseuser,cn=users,cn=accounts,dc=xxxx,dc=local" simple messageID: 4 protocolOp: bindRequest (0) bindRequest [Response In: 14]
Thanks again
On Saturday, August 1, 2020, 01:57:40 PM UTC, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 29, 2020, at 12:24 PM, Victor via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Hello,
I'm trying to check whether a user belongs to a group or not: ... but
ldapsearch -b "dc=domain,dc=local" "(&(cn=someusers)(member=uid\3dcommon_user\2ccn\3dusers\2ccn\3daccounts\2cdc\3ddomain\2cdc\3dlocal))" -D uid=common_user,cn=users,cn=accounts,dc=domain,dc=local -W See mods-available/ldap in recent releases. It has detailed instructions for how to turn the FreeRADIUS configuration items into ldapsearch arguments.
There's no real magic here. If FR returns different data than ldapsearch, then the only cause is that the searches are different. i.e. search string, name/password used to search, etc.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html