On Tue, Feb 15, 2011 at 11:37:59AM -0200, Leonardo Carneiro wrote:
fileserver:/var/log# ldapsearch -h 127.0.0.1 -x -b dc=dominio,dc=com,dc=br '(objectclass=*)' # extended LDIF # # LDAPv3 # base <dc=dominio,dc=com,dc=br> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# search result search: 2 result: 32 No such object
But binding it to a root cn did work:
fileserver:/var/log# ldapsearch -h 127.0.0.1 -x -b dc=dominio,dc=com,dc=br '(objectclass=*)' -D "cn=root,dc=dominio,dc=com,dc=br" -w [passwd]
I am a bit worried about the order of parameters there. The filter '(objectclass=*)' should be at the end.
# extended LDIF # # LDAPv3 # base <dc=dominio,dc=com,dc=br> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# dominio.com.br dn: dc=dominio,dc=com,dc=br dc: dominio ...
Aha! How many entries did that search return? Was is about the same number that you would expect given your users and groups?
If you see lots of data then there is probably nothing wrong with the LDAP server at all.
Maybe it is just access-control that is not doing what you expect.
I have a backup from the very last moment before the upgrade, i'll use it and post the results here.
Wait a bit. The data may well be OK.
If the root-dn search returned the right number of entries then your problem is access-control, not database.
Did you previously have the LDAP server set up to refuse data to anonymous users?
Andrew