Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question
    
I just tried doing ldapsearch -H ldap://ldap.mydomain.com -x -s base -b "" namingContexts on a sun directory server and it worked, so you're probably doing the right thing. The '+' didn't change anything. Is it possible you need to authenticate first? –  Mark Jul 14 '09 at 14:18
    
The plus sign should be specific for OpenLDAP. –  Jared Jul 14 '09 at 14:33
add comment

3 Answers

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
share|improve this answer
add comment

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?

share|improve this answer
add comment

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
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.