Retrieve operational attributes from OpenLDAP

I've been having trouble trying to find some good documentation on how to retrieve operational attributes from OpenLDAP.

I would like to retrieve the base distinguished name of an LDAP server by doing an LDAP search.

How come my search doesn't work when I explicitly ask for namingContexts attribute? I've been told that I need to add a plus ('+') sign to the attribute list.

If this is the case, should I get rid of the "namingContexts" attribute or have both?

ldapsearch -H ldap://ldap.mydomain.com -x -s base -b "" +
# note the + returns operational attributes

Edit: Note how it looks like the attributes requested are empty. Shouldn't the plus sign be in the attribute list? http://www.zytrax.com/books/ldap/ch3/#operational

reference: plus sign operator with OpenLDAP

From serverfault Jared

• How come my search doesn't work when I explicitly ask for namingContexts attribute?

  What is not working? Do you recieve an error?

  When there is a plus sign it returns all the attributes, regardless if namingContexts is added.

  Using:

  ldapsearch -x -H ldap://ldap.example.com -s base -b "" namingContexts
  

  Returns:

  # extended LDIF
  #
  # LDAPv3
  # base <> with scope baseObject
  # filter: (objectclass=*)
  # requesting: namingContexts 
  #
  
  #
  dn:
  namingContexts: o=example.com
  
  # search result
  search: 2
  result: 0 Success
  
  # numResponses: 2
  # numEntries: 1
  

  It is also listed using:

  ldapsearch -x -H ldap://ldap.example.com -s base -b "" +
  

  Returning:

  # extended LDIF
  #
  # LDAPv3
  # base <> with scope baseObject
  # filter: (objectclass=*)
  # requesting: + 
  #
  
  #
  dn:
  structuralObjectClass: OpenLDAProotDSE
  namingContexts: o=example.com
  supportedControl: 2.16.840.1.113730.3.4.18
  supportedControl: 2.16.840.1.113730.3.4.2
  supportedControl: 1.3.6.1.4.1.4203.1.10.1
  supportedControl: 1.2.840.113556.1.4.1413
  supportedControl: 1.2.840.113556.1.4.1339
  supportedControl: 1.2.840.113556.1.4.319
  supportedControl: 1.2.826.0.1.334810.2.3
  supportedExtension: 1.3.6.1.4.1.1466.20037
  supportedExtension: 1.3.6.1.4.1.4203.1.11.1
  supportedExtension: 1.3.6.1.4.1.4203.1.11.3
  supportedFeatures: 1.3.6.1.4.1.4203.1.5.1
  supportedFeatures: 1.3.6.1.4.1.4203.1.5.2
  supportedFeatures: 1.3.6.1.4.1.4203.1.5.3
  supportedFeatures: 1.3.6.1.4.1.4203.1.5.4
  supportedFeatures: 1.3.6.1.4.1.4203.1.5.5
  supportedLDAPVersion: 2
  supportedLDAPVersion: 3
  supportedSASLMechanisms: DIGEST-MD5
  supportedSASLMechanisms: CRAM-MD5
  subschemaSubentry: cn=Subschema
  
  # search result
  search: 2
  result: 0 Success
  
  # numResponses: 2
  # numEntries: 1
  

  From

• What version of OpenLDAP are you using? What does "doesn't work" mean precisely? What is the output when you run that command?

  I ran it on my OpenLDAP instance and it produced output similar to carrell's.

  I'm wondering if it may be a permissions issue. Perhaps anonymous users don't have read access on dn="" or access to the operational attributes in question?

  From Walter Mundt

• First access rule in my slapd.conf is explicitly to make sure that this is permitted; make sure you have something similar:

  # Let all clients figure out what auth mechanisms are available, determine
  # that TLS is okay, etc
  access to dn.base=""
          by *            read
  

  From Phil P