[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldapsearch & ldapadd SASL problems

Howard Chu wrote:
The logs you provided indicate that SASL authentication is fine, most likely there's something wrong with the ACLs.

Thanks for that - some experimentation later, it transpired that my ACLs weren't being processed properly as I had commented out a line between the 'access' line & the 'by' line.


access to *
#	comment line here
	by dn=[stuff] write
	by * read

doesn't work, where

access to *
	by dn=[stuff] write
	by * read
#	comment here if you have to, or above the access line


Thanks!  Now onto the next stages...


Juliet Kemp wrote:
[apologies; sent from unsubscribed mail address first time round!]

I'm trying to set up OpenLDAP + SASL + Kerberos V, on a Debian server.

There seems to be an authentication problem when I try ldapsearch or ldapadd. If I kinit as ldapadm (my admin user) & then do ldapsearch (no filter) I get output with no error messages, but no results back; if I put the 'rootdn' & 'rootpw' options back in slapd.access & execute 'ldapsearch -D [rootdn user]' I get the expected 3 entries back. Looking at the slapd logs (log level 65) the only dubious-looking lines are:

localhost slapd[1484]: ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable)


localhost slapd[1486]: bdb_search: 1 does not match filter

(that entry should match the filter!  Similar lines for other entries)

Similarly, ldapadd fails - error message is given in this instance:

ldap_add: Insufficient access (50)
        additional info: no write access to parent

The logs give the same 'Resource temporarily unavailable' line as above. I also get

=> bdb_dn2id( "uid=test,dc=ph,dc=ic,dc=ac,dc=uk" )
<= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30990)

but I read this (hopefully correctly!) as a check that the 'test' user I'm trying to add doesn't already exist (i.e. the failure is correct).

ldapwhoami gives:

SASL/GSSAPI authentication started
SASL username: ldapadm@PH.IC.AC.UK
SASL installing layers

(which is what I expect)


access to dn.base="" by * read

# The admin dn has full write access
access to dn.subtree="dc=ph,dc=ic,dc=ac,dc=uk"
        by dn="uid=ldapadm,ou=people,dc=ph,dc=ic,dc=ac,dc=uk" write
        by * read

Any suggestions? I reproduce the full logs of the ldapsearch underneath.

+ Ms Juliet Kemp                                                +
+ Computer Manager		    star@imperial.ac.uk         +
+ Astrophysics Group                                            +
+ Imperial College                  Tel: +44 (0)20759 47543     +
+ London. SW7 2AZ                   Fax: +44 (0)20759 47541     +