#78 Strange byte sequence for attribute with no values (nsslapd-referral)
Closed: wontfix None Opened 11 years ago by mkosek.


Description of problem:
I've been using OpenLDAP to talk to Fedora DS, and my bindings
weren't working!  This was quite vexing, so I did some investigation.
I finally pinpointed the error to ldap_get_values_len() returning
a NULL pointer for nsslapd-referral, with no error code.

Sounds sort of like a bug in OpenLDAP, no?  Yes it does, but it's a bug
that's only tickled in very strange circumstances.  If you use ldapvi,
well, that links to OpenLDAP, but it ignores NULLs so that's why you
never see a nsslapd-referral in your cn=config entry.

I made a dump of the buffer that OpenLDAP was parsing values out
of (I think this was what was transmitted over the network.)

Exhibit A (byte sequence containing nsslapd-referral):


Exhibit B (byte sequence containing nsslapd-localhost):


As you can see, the byte sequence for nsslapd-referral appears to have
no textual data associated with it.

Howard responded to the OpenLDAP list with this:

> But it's certainly stupid for the server to attach the attribute to the
> response with no values, since this is obviously NOT an attrsOnly search
> response. Sounds like you ought to file a bug report against the Fedora
> Directory Server. [1]

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Attempt to retrieve the cn=config object with the OpenLDAP library and
observe the ldap_get_values_len output for nsslapd-referral. If requested, I
could probably create a C test script.

Actual results:
nsslapd-referral is sent with weird byte sequence.

Expected results:
nsslapd-referral is omitted from results.

I'm not familiar with openLDAP. Does it have its own ldapsearch? It is unlcear what you are doing to reproduce this behavior.

Can you please provide the exact testcase?


Is the testcase described in the bz 643979 comment 7 detailed enough?
I am testing this bug fix, and got :
[root@amitesthost scripts]# ldapsearch -x -h localhost -p 389 -D "cn=Directory
Manager" -w xyz -b "cn=config" | grep nsslapd-referral

Which I guess violating this rule "The cn=config is not supposed to store empty
This bug has a history. The original bug was supposed to be fixed, but it failed in the verification phase. So, the "Description of problem" may not be a help...

Side note, from a LDAP standard point of view, there is nothing wrong with attributes without values.

Question, is the problem with "nsslapd-referral" or "nsslapd-referralmode"? There is a conflict between bugzilla and trac. I saw an empty nsslapd-referralmode in my cn=config entry, but I did not see nsslapd-referral. Also, there were many attributes in the returned cn=config that did not have values, not just nsslapd-referralmode.


I wrote a ldap client, and I do not see nsslapd-referral being returned when searching on cn=config. I think this was fixed by 643979, and that QE got confused when they saw nsslapd-referralmode.

In regards to some of the attributes being returned with "" values, that would need to be handled in a new bug, but we know where the issue is happening, and it is by design. Changing the behaviour could cause issues with existing ldap clients.

Closing bug...


Added initial screened field value.

At Rich's suggestion I am reopening this bug.


To recap: when logged in as the directory administrator (cn=root in my case) and selecting the "Configuration" tab for a server in the 389-console, I receive a message stating I do have the necessary permissions and am prompted to login as a different user.

When running in 389-console in debug mode, I see these messages which I think are relevant:

DSEntrySet.getAttributes(): failed to get attribute nsslapd-referral in cn=config
DSEntrySet.show(): some of the attributes of cn=config could not be read. Either they are not present in the entry or there is an ACI which prevents that attribute from being read. Try authenticating as a user with more access


cat /etc/redhat-release

CentOS release 5.7 (Final)

I can not reproduce the issue on RHEL 6 (DS master source code).

here is my comparable output from the console:

DSEntrySet.getAttributes(): nsslapd-lastmod was found, setting value from entry
DSEntrySet.getAttributes(): nsslapd-readonly was found, setting value from entry
DSEntrySet.getAttributes(): nsslapd-schemacheck was found, setting value from entry
DSEntrySet.getAttributes(): failed to get attribute nsslapd-referral in cn=config
DSEntrySet.getAttributes(): created attribute nsslapd-referral in cn=config
DSEntrySet.getAttributes(): nsslapd-referral was found, setting value from entry
ServerSettingsPanel.ReferralText.show: <>

Getting the DS logs would be very useful, as well as a copy of the "cn=config" entry from the dse.ldif.

Any update? If there is no response this will be closed at the end of next week. It can always be reopened.

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.1

6 years ago

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/78

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.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Invalid)

2 years ago

Login to comment on this ticket.