[Date Prev][Date Next]
Re: ou=people hidden from ldapsearch
> ldapsearch -x -h ldap.example.com -b example.com
> objectclass=organizationalUnit 1 -LLL
If that command gave the results you show, it's not OpenLDAP ldapsearch.
example.com is not a valid DN, it should be -b dc=example,dc=com.
Also the command asks for attributes "1" and "-LLL" to be returned.
Put options before the filter. Also the standard way to ask for no
attrs to be returned is "1.1", not "1". It's a guaranteed unused OID
(object identifier), and OIDs always have at least 2 components.
> When I perform the same search against OpenLDAP, I get the following:
> Notice the destinct lack of ou=people,dc=example,dc=com and
> I know they're there, because I can create objects etc in them, but
> I'm at a complete loss as to why they don't show up in the ldapsearch.
Maybe your config has access controls which hides them.
Or maybe these actually do not have objectClass: organizationalUnit.
Try the True filter "(&)" instead:
ldapsearch -x -LL -h ldap.example.com -s base
-b cn=people,dc=example,dc=com "(&)" objectClass
Or maybe you edited the slapd.conf to add an objectClass index after
loading a few entries? Then the already-added objects would not get
indexed. If so, stop slapd, run slapindex and restart slapd. (OTOH
if you use slapd.d/cn=config and modify the cn=config over the LDAP
protocol, such reindexing happens automatically.)
Or if the tree is really large and you have not indexed objectclass,
maybe the search hit a time limit and didn't return everything. Then
there should be an error message at the end of the ldapsearch output.
> I know I'm obviously doing something stupid here, and again, I
> apologize, but any assistance would be appreciated.
Hey, relax. And show us your config, after deleting any passwords, if
this doesn't help. It's hard to diagnose without guessing otherwise.
Also show the exact command you used, and whether it said success or