unable to filter on attributes with default values under cn=config

389-ds-bot commented 4 years ago

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/47688

Created at 2014-02-04 01:50:49 by jhoblitt
Assigned to nobody

I've discovered that I seem to be able to use a query filter to select out the passwordStorageScheme attribute. Per discussion on freenode with richm, it sounds like this may be a bug.

An example of ldapsearch queries that I would expect to return a result (with and without -s base):

$ ldapsearch -x -D "cn=directory manager" -w password -b cn=config "passwordStorageScheme=*" passwordStorageScheme -L
version: 1

#
# LDAPv3
# base <cn=config> with scope subtree
# filter: passwordStorageScheme=*
# requesting: passwordStorageScheme 
#

# search result

# numResponses: 1

$ ldapsearch -x -D "cn=directory manager" -w password -s base -b cn=config "passwordStorageScheme=*" passwordStorageScheme -L
version: 1

#
# LDAPv3
# base <cn=config> with scope baseObject
# filter: passwordStorageScheme=*
# requesting: passwordStorageScheme 
#

# search result

# numResponses: 1

Demonstration that the attribute does exist:

$ ldapsearch -x -D "cn=directory manager" -w password -b "cn=config" 'objectclass=*'|grep -i passwordStorageScheme
passwordStorageScheme: SSHA

Example of filtering on a different attribute under the same base that succeeds:

$ ldapsearch -x -D "cn=directory manager" -w password -b cn=config "nsslapd-secureport=*" nsslapd-secureport -L
version: 1

#
# LDAPv3
# base <cn=config> with scope subtree
# filter: nsslapd-secureport=*
# requesting: nsslapd-secureport 
#

# config
dn: cn=config
nsslapd-secureport: 636

# search result

# numResponses: 2
# numEntries: 1

389-ds-bot commented 4 years ago

Comment from jhoblitt at 2014-02-04 01:52:16

$ rpm -q 389-ds-base 389-ds-base-1.2.11.15-30.el6_5.x86_64 $ yum info 389-ds-base Loaded plugins: security Installed Packages Name : 389-ds-base Arch : x86_64 Version : 1.2.11.15 Release : 30.el6_5 Size : 4.9 M Repo : installed From repo : sl6x-security Summary : 389 Directory Server (base) URL : http://port389.org/ License : GPLv2 with exceptions Description : 389 Directory Server is an LDAPv3 compliant server. The base : package includes the LDAP server and command line utilities for : server administration.

389-ds-bot commented 4 years ago

Comment from jhoblitt at 2014-02-04 02:12:26

After further discussion on freenode with richm, it appears that this is a general issue in querying for attributes that have not had a value explicitly defined (they are at the default value).

$ cat passwordstorage.ldif                    
dn: cn=config
changetype: modify
add: passwordStorageScheme
passwordStorageScheme: SSHA512
$ ldapmodify -x -D "cn=directory manager" -w password -f passwordstorage.ldif
modifying entry "cn=config"

$ ldapsearch -x -D "cn=directory manager" -w password -b cn=config "passwordStorageScheme=*" passwordStorageScheme -L
version: 1

#
# LDAPv3
# base <cn=config> with scope subtree
# filter: passwordStorageScheme=*
# requesting: passwordStorageScheme 
#

# config
dn: cn=config
passwordStorageScheme: SSHA512

# search result

# numResponses: 2
# numEntries: 1

Interestingly, if I set the attribute's value back to the default I can still query on it. My assumption is that this is related to a value having never been explicitly set rather than special behaviour around the default value.

$ cat passwordstorage.ldif                    
dn: cn=config
changetype: modify
replace: passwordStorageScheme
passwordStorageScheme: SSHA
$ ldapmodify -x -D "cn=directory manager" -w password -f passwordstorage.ldif 
modifying entry "cn=config"

$ ldapsearch -x -D "cn=directory manager" -w password -b cn=config "passwordStorageScheme=*" passwordStorageScheme -L
version: 1

#
# LDAPv3
# base <cn=config> with scope subtree
# filter: passwordStorageScheme=*
# requesting: passwordStorageScheme 
#

# config
dn: cn=config
passwordStorageScheme: SSHA

# search result

# numResponses: 2
# numEntries: 1

389-ds-bot commented 4 years ago

Comment from jhoblitt at 2014-02-04 02:22:12

My use case for querying on [cn=config] attributes with default values is allow idempotent management of the value of these attributes via a Puppet module that I'm currently developing.

Example of trying to manage an attribute:

https://github.com/jhoblitt/puppet-port389/blob/b5f5e992715a6ff904b8b53f3d61240f90e0aac6/manifests/instance/ssl.pp#L72-L78

This does appear to be working now with the caveat that attributes will be set at least once, even if the desired value is the default. Until working through this behaviour for the passwordStorageScheme attribute I hadn't realized that that was also seeing this behaviour as the nsslapd-secureport attributed always being set by puppet on the first run.

389-ds-bot commented 4 years ago

Comment from nhosoi (@nhosoi) at 2016-05-13 00:14:23

Per triage, push the target milestone to 1.3.6.

389-ds-bot commented 4 years ago

Comment from jhoblitt at 2017-02-11 22:51:06

Metadata Update from @jhoblitt:

Issue set to the milestone: 1.3.6.0

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2017-02-13 04:24:03

The issue is the filter:

{william@ldapkdc 13:22} ~/development/389ds I0> ldapsearch -h localhost -x -D "cn=directory manager" -w password -s base -b cn=config "objectClass=*" passwordStorageScheme
# extended LDIF
#
# LDAPv3
# base <cn=config> with scope baseObject
# filter: objectClass=*
# requesting: passwordStorageScheme 
#

# config
dn: cn=config
passwordStorageScheme: SSHA512

# search result
search: 2
result: 0 Success

{william@ldapkdc 13:22} ~/development/389ds I0> ldapsearch -h localhost -x -D "cn=directory manager" -w password -s base -b cn=config "passwordStorageScheme=*" passwordStorageScheme
# extended LDIF
#
# LDAPv3
# base <cn=config> with scope baseObject
# filter: passwordStorageScheme=*
# requesting: passwordStorageScheme 
#

# search result
search: 2
result: 0 Success

# numResponses: 1

It looks like we don't handle presence correctly in fedse.c.

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2017-02-13 04:24:11

Metadata Update from @Firstyear:

Custom field reviewstatus adjusted to review
Issue close_status updated to: None

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2017-02-15 00:41:55

Metadata Update from @Firstyear:

Custom field reviewstatus reset

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2017-05-08 22:26:19

Metadata Update from @mreynolds389:

Issue set to the milestone: 1.3.7 backlog (was: 1.3.6.0)

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2019-08-23 21:22:21

Metadata Update from @mreynolds389:

Custom field reviewstatus adjusted to None
Issue set to the milestone: 1.4 backlog (was: 1.3.7 backlog)

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2020-05-20 16:42:09

Metadata Update from @mreynolds389:

Issue set to the milestone: 1.4.4 (was: 1.4 backlog)

jchapma commented 2 years ago

Not sure what to do with this one. Setting label to triage.

droideck commented 1 year ago

It works as intended. Closing as `Works for me!".

$ ldapsearch -H ldap://localhost:389 -D "cn=Directory manager" -w password -b "cn=config" passwordStorageScheme -s base
# extended LDIF
#
# LDAPv3
# base <cn=config> with scope baseObject
# filter: (objectclass=*)
# requesting: passwordStorageScheme 
#

# config
dn: cn=config
passwordStorageScheme: PBKDF2-SHA512

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

389ds / 389-ds-base

unable to filter on attributes with default values under cn=config #1024