$ 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.

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 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 with scope subtree

filter: passwordStorageScheme=*

requesting: passwordStorageScheme

config

dn: cn=config
passwordStorageScheme: SSHA

search result

numResponses: 2

numEntries: 1

}}}

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.

Per triage, push the target milestone to 1.3.6.

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-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1024

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.