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 -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
