rlm_ldap fails but ldapsearch works

[Victor]

I don't understand the need of it at the moment, but enableing it, didn't change the behaviour.

Best regards,
Victor








 On Sunday, August 2, 2020, 04:33:51 PM UTC, <uj2.hahn at posteo.de> wrote:





 And you should enable cacheable_name or cacheable_dn (=yes)  if not done
already!
Regards
Uwe

On 02.08.2020 18:01, uj2.hahn at 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 at deployingradius.com> wrote:
>>
>>
>>
>>
>>
>>   On Jul 29, 2020, at 12:24 PM, Victor via Freeradius-Users
>> <freeradius-users at 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
>

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html