FreeRADIUS › Users

rlm_ldap fails but ldapsearch works

Classic

List

Threaded

10 messages Options

Users mailing list

rlm_ldap fails but ldapsearch works

Hello,

I'm trying to check whether a user belongs to a group or not:

(0) if (LDAP-Group == "someusers") {
(0) Searching for user in group "someusers"
rlm_ldap (ldap): Reserved connection (6)
(0) Using user DN from request "uid=common_user,cn=users,cn=accounts,dc=domain,dc=local"
(0) Checking for user in group objects
(0) EXPAND (&(cn=someusers)(|(&(uid=%{%{Stripped-User-Name}:-%{User-Name}})(memberOf=cn=someusers,cn=groups,cn=accounts,dc=domain,dc=local))))
(0) --> (&(cn=someusers)(|(&(uid=common_user)(memberOf=cn=someusers,cn=groups,cn=accounts,dc=domain,dc=local))))
(0) Performing search in "uid=common_user,cn=users,cn=accounts,dc=domain,dc=local" with filter "(&(cn=someusers)(|(&(uid=common_user)(memberOf=cn=someusers,cn=groups,cn=accounts,dc=domain,dc=local))))", scope "sub"
(0) Waiting for search result...
(0) Search returned no results
(0) Checking user object's memberOf attributes
(0) Performing unfiltered search in "uid=common_user,cn=users,cn=accounts,dc=domain,dc=local", scope "base"
(0) Waiting for search result...
(0) No group membership attribute(s) found in user object
rlm_ldap (ldap): Released connection (6)

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
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=domain,dc=local> with scope subtree
# filter: (&(cn=someusers)(member=uid\3dcommon_user\2ccn\3dusers\2ccn\3daccounts\2cdc\3ddomain\2cdc\3dlocal))
# requesting: ALL
#

# someusers, groups, accounts, domain.local
dn: cn=someusers,cn=groups,cn=accounts,dc=domain,dc=local
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
description: Default group for all users
cn: someusers
ipaUniqueID: ebca3046-a5a0-11ea-8166-9a6e275fb41f
member: uid=common_user,cn=users,cn=accounts,dc=domain,dc=local
member: uid=very_special_user,cn=users,cn=accounts,dc=domain,dc=local

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

and

ldapsearch -b "uid=common_user,cn=users,cn=accounts,dc=domain,dc=local" -D uid=common_user,cn=users,cn=accounts,dc=domain,dc=local -W
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <uid=common_user,cn=users,cn=accounts,dc=domain,dc=local> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# common_user, users, accounts, domain.local
dn: uid=common_user,cn=users,cn=accounts,dc=domain,dc=local
displayName: utilisateur banal
uid: common_user
krbCanonicalName: [hidden email]
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: ipasshuser
objectClass: ipaSshGroupOfPubKeys
objectClass: mepOriginEntry
objectClass: ipauserauthtypeclass
loginShell: /bin/bash
initials: ub
gecos: utilisateur banal
sn: banal
homeDirectory: /home/common_user
mail: [hidden email]
krbPrincipalName: [hidden email]
givenName: utilisateur
cn: utilisateur banal
ipaUniqueID: some_unique_ID
uidNumber: theSameNumber
gidNumber: theSameNumber
krbPasswordExpiration: the_pass_exp
krbLastPwdChange: the_pass_exp
memberOf: cn=someusers,cn=groups,cn=accounts,dc=domain,dc=local
memberOf: cn=manyemoreusers,cn=groups,cn=accounts,dc=domain,dc=local
ipaUserAuthType: o_type
ipaSshPubKey: some_pubkey

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Some of the configuration:

/etc/raddb/sites-enabled/default
...
user {
base_dn = "${..base_dn}"
filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
sasl {
}
}
group {
base_dn = 'uid=common_user,cn=users,cn=accounts,dc=domain,dc=local'
scope = 'sub'
membership_filter = "(|(&(uid=%{%{Stripped-User-Name}:-%{User-Name}})(memberOf=${..ldapgroup})))"
membership_attribute = 'memberOf'
}

/etc/raddb/mods-enabled/ldap
...
post-auth {
update {
&reply: += &session-state:
}
-sql
exec
remove_reply_message_if_eap
Post-Auth-Type REJECT {
-sql
attr_filter.access_reject

eap

remove_reply_message_if_eap
}
Post-Auth-Type Challenge {
}
if (LDAP-Group == "someusers") {
update {
reply:Class := "OKOKOKOKOK"
}
}
else {
update {
reply:Class := "NONONONONO"
}
}
}

Where to go from here?

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

Alan DeKok-2

Re: rlm_ldap fails but ldapsearch works

On Jul 29, 2020, at 12:24 PM, Victor via Freeradius-Users <[hidden email]> 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

Users mailing list

Re: rlm_ldap fails but ldapsearch works

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 <[hidden email]> wrote:

On Jul 29, 2020, at 12:24 PM, Victor via Freeradius-Users <[hidden email]> 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

Alan DeKok-2

Re: rlm_ldap fails but ldapsearch works

On Aug 2, 2020, at 10:47 AM, Victor via Freeradius-Users <[hidden email]> wrote:
>
> Well, from the wireshark LDAP protocol decode:

Which doesn't really help.

> -the answer to rlm_ldap:
...
> -the answer to ldapsearch:

Yes, you already said that in your first message. Repeating it doesn't help.

> rlm_ldap clearly doesn't get the same answer, almost to the same request (timeLimit differs):

Then blame the LDAP server. If the same query gives two different answers, then it's broken. Or, there's something happening behind the scenes. e.g. it's applying additional filters based on something else such as source IP.

Are you doing the ldapsearch from the same machine which is running FreeRADIUS?

But... in the end the issue is simple. The query used by FreeRADIUS is correct, but the answer returned by the LDAP server is wrong. You have to figure out what's wrong with the LDAP server, and why.

Alan DeKok.

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

uj2.hahn

Re: rlm_ldap fails but ldapsearch works

In reply to this post by Users mailing list

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 <[hidden email]> wrote:
>
>
>
>
>
> On Jul 29, 2020, at 12:24 PM, Victor via Freeradius-Users <[hidden email]> 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

uj2.hahn

Re: rlm_ldap fails but ldapsearch works

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

On 02.08.2020 18:01, [hidden email] 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
>> <[hidden email]> wrote:
>>
>>
>>
>>
>>
>> On Jul 29, 2020, at 12:24 PM, Victor via Freeradius-Users
>> <[hidden email]> 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

Users mailing list

Re: rlm_ldap fails but ldapsearch works

In reply to this post by uj2.hahn

Hello Uwe,

The attribute is not set, but it's the default. Anyway tried with name_attribute = cn, the result is the same.

cn is the identifier of the group and its members are listed with "member: uid=":
# ipausers, groups, accounts, xxxx.local
dn: cn=ipausers,cn=groups,cn=accounts,dc=xxxx,dc=local
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
description: Default group for all users
cn: ipausers
ipaUniqueID: ebca3046-a5a0-11ea-8166-9a6e275fb53e
member: uid=baseuser,cn=users,cn=accounts,dc=xxxx,dc=local
...

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

The filter is: (&(cn=ipausers)(member=uid\3dbaseuser\2ccn\3dusers\2ccn\3daccounts\2cdc\3dxxxx\2cdc\3dlocal))

Victor

On Sunday, August 2, 2020, 04:01:59 PM UTC, <[hidden email]> 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 <[hidden email]> wrote:
>
>
>
>
>
> On Jul 29, 2020, at 12:24 PM, Victor via Freeradius-Users <[hidden email]> 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

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

Users mailing list

Re: rlm_ldap fails but ldapsearch works

In reply to this post by uj2.hahn

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, <[hidden email]> wrote:

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

On 02.08.2020 18:01, [hidden email] wrote:

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

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

Users mailing list

Re: rlm_ldap fails but ldapsearch works

In reply to this post by Alan DeKok-2

Hello Alan,

It turns out the problem was the undefined ldap admin bind credentials:

# identity = 'cn=admin,dc=example,dc=org'
# password = mypass

rlm_ldap uses the current user credentials for the user search bind, which works, but not for the group search, i.e. it binds anonymously per connection and therefore the requests fail.

Victor

On Sunday, August 2, 2020, 03:10:10 PM UTC, Alan DeKok <[hidden email]> wrote:

On Aug 2, 2020, at 10:47 AM, Victor via Freeradius-Users <[hidden email]> wrote:
>
> Well, from the wireshark LDAP protocol decode:

Which doesn't really help.

> -the answer to rlm_ldap:
...
> -the answer to ldapsearch:

Yes, you already said that in your first message. Repeating it doesn't help.

> rlm_ldap clearly doesn't get the same answer, almost to the same request (timeLimit differs):

Then blame the LDAP server. If the same query gives two different answers, then it's broken. Or, there's something happening behind the scenes. e.g. it's applying additional filters based on something else such as source IP.

Are you doing the ldapsearch from the same machine which is running FreeRADIUS?

But... in the end the issue is simple. The query used by FreeRADIUS is correct, but the answer returned by the LDAP server is wrong. You have to figure out what's wrong with the LDAP server, and why.

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

Renters Cancellation Requests

FW: Re: rlm_ldap fails but ldapsearch works

In reply to this post by Alan DeKok-2

PR - How May We Assist?
KBA-01143-R4Z7T7
Specialty Services

Dear Valued Customer,

Thank you for your inquiry. Please let us know how we may assist you.

If you have a Renter’s policy, you can manage your policy online 24/7 at: https://www.myassurantpolicy.com/

You have access to a range of service options including:

*
View/update policy information
*
Manage your payments
*
Obtain proof of insurance
*
And much more

Thank you for allowing us the opportunity to serve you.

Sincerely,

Insurance Services

Assurant - Global Specialty Operations

------------------- Original Message -------------------
From: Alan DeKok
Received: Sat Aug 01 2020 10:02:08 GMT-0400 (Eastern Daylight Time)
To: Cornelius Kölbel via Freeradius-Users
Subject: Re: rlm_ldap fails but ldapsearch works

On Jul 29, 2020, at 12:24 PM, Victor via Freeradius-Users <[hidden email]> 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

**********************************************************************
This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html