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: common_user@DOMAIN.LOCAL 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: common_user@domain.local krbPrincipalName: common_user@DOMAIN.LOCAL 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
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.
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.
On Aug 2, 2020, at 10:47 AM, Victor via Freeradius-Users <freeradius-users@lists.freeradius.org> 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.
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 <aland@deployingradius.com> wrote: On Aug 2, 2020, at 10:47 AM, Victor via Freeradius-Users <freeradius-users@lists.freeradius.org> 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
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
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
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@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@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
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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, <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
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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 <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 ********************************************************************** 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.
participants (4)
-
Alan DeKok -
Renters Cancellation Requests -
uj2.hahn＠posteo.de -
Victor