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

Re: Disabling SASL auth at server side

On 01/11/12 13:37 +0100, Angel L. Mateo wrote:

I have an application I need to authenticate in my LDAP server. The problem I have is that this application is trying to authenticate its user (to search for user DNs) with SASL although I haven't configured SASL in my LDAP server. More detailed, the application does:

* First, it checks for supported mechanisms with a search like:

Jan 11 12:13:28 canis13 slapd[22380]: conn=41690 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Jan 11 12:13:28 canis13 slapd[22380]: conn=41690 op=0 SRCH attr=supportedSASLMechanisms Jan 11 12:13:28 canis13 slapd[22380]: conn=41690 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=

* This search gets

supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: NTLM

* Then it tries to bind using a SASL mechanism that I haven't configured.

With older version of openldap (2.3.30, debian etch version) I didn't have any problem because this search returns no result. Now I'm using openldap 2.4.21 (ubuntu lucid version) and I get this behaviour.

Is there any way to configure the openldap server to disable this mechanisms?, because I don't want any sasl authentication.

You could fiddle with the ACL on dn.base:

# Ensure read access to the base for things like
# supportedSASLMechanisms.  Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work # happily.
access to dn.base="" by * read

Be aware that if you choose to restrict access to supportedSaslMechnisms,
that there are other operation attributes available under the root DSE that
you may still wish to provide permissive access for. See RFC 2252, section

Dan White