# Problems getting LDAP working

## Adamal

I am trying to follow the ldap documentation: http://www.gentoo.org/doc/en/ldap-howto.xml

When I get to the ldapserch part here is what I get

```

root@pegasus log # ldapsearch -D "cn=Manager,dc=dname,dc=com" -W

Enter LDAP Password:

ldap_sasl_interactive_bind_s: Can't contact LDAP server (81)
```

I have not idea how to even start figuring out what is wrong here.  What can the problem be?

I am also running the following services in case that helps:

apache2

courier-imapd-ssl

courier-imapd

mysql

postfix

saslauthd

samba

----------

## Adamal

Ok well I've made a little progress but I'm still running into Errors

If I use the -x option it works but without it, it doesn't.  It seems to be a problem with SASL.

```
root@auth ssl # ldapsearch -D "cn=Manager,dc=dname,dc=com" -W

Enter LDAP Password:

SASL/DIGEST-MD5 authentication started

ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80)

        additional info: SASL(-13): user not found: no secret in database

root@auth ssl # ldapsearch -D "cn=Manager,dc=dname,dc=com" -W -x

Enter LDAP Password:

# extended LDIF

#

# LDAPv3

# base <> with scope sub

# filter: (objectclass=*)

# requesting: ALL

#

# search result

search: 2

result: 32 No such object

# numResponses: 1

root@auth ssl #

```

/etc/openldap/ldap.conf

```
BASE            dc=dname, dc=com

URI             ldaps://auth.dname.com:636/

TLS_REQCERT     allow

```

/etc/openldap/slapd.conf

```

include         /etc/openldap/schema/core.schema

# Include the needed data schemes

include         /etc/openldap/schema/cosine.schema

include         /etc/openldap/schema/inetorgperson.schema

include         /etc/openldap/schema/nis.schema

include         /etc/openldap/schema/samba.schema

# Use crypt to hash the passwords

password-hash {crypt}

# Define SSL and TLS properties (optional)

TLSCertificateFile /etc/ssl/ldap.pem

TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem

TLSCACertificateFile /etc/ssl/ldap.pem

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory

# service AND an understanding of referrals.

#referral       ldap://root.openldap.org

pidfile         /var/run/openldap/slapd.pid

argsfile        /var/run/openldap/slapd.args

database        ldbm

suffix          "dc=dname,dc=com"

rootdn          "cn=Manager,dc=dname,dc=com"

# Cleartext passwords, especially for the rootdn, should

# be avoid.  See slappasswd(8) and slapd.conf(5) for details.

# Use of strong authentication encouraged.

rootpw          {MD5}qMKu9pNJWW6S8eJNsh5KsA==

# The database directory MUST exist prior to running slapd AND

# should only be accessible by the slapd and slap tools.

# Mode 700 recommended.

directory       /var/lib/openldap-ldbm

# Indices to maintain

index   objectClass     eq

```

----------

## Adamal

Some one has to have found a solution to this problem

 *Quote:*   

> ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80)
> 
>         additional info: SASL(-13): user not found: no secret in database 

 

It only seems to be a problem using SASL, I can't find any solutions on the net and none of the gentoo docs even mention the problem.

----------

## Chrisje

This is not going to help you, but I'm facing this very same problem for a few days now. Going to watch this thread.

----------

## Adamal

I've read a ton of simular threads on the web none with answers.  I'm going to guess that its broken.

----------

## onlawn

The answer is that it is trying to check a password in the SASL database that you don't have there. You have it in your slapd.conf file, if I see it correctly.

Please try using a lowercase 'w' instead of an uppercase 'W' and tell me how it works? That should tell slapd you are trying to do a simple bind (which requires simple binds to be allowed).

If you want to bind against a SASL db password with the slapd.conf specified adminstrator you add the following (for the newer openldap) substitution command in your slapd.conf...

```
rootdn         "uid=ldapadm, cn=SASL.DOMAIN, cn=GSSAPI, cn=AUTH"
```

Personally I use MIT-Kerberos5 as my sasldb, but that is another story.

----------

## Adamal

The lower case w should cause it to use non SASL authentication right?

how do you add the password to the SASL database?  with the code you provided?

----------

## onlawn

According to the man page, the `-w` [lower case] causes it to do a simple bind. It is my understanding that 'simple' means without any external help (like from SASL or Kerberos).

When you put a password in your sasl.conf file, which is not a good idea generally but not detrimental either, you do it specifically because it won't need saslauthd, MYSQL, or Kerberos running. It means you expect to do simple binds.

Normally, (and this is where the confusion comes in) binary packagers don't include SASL support. So -W or -w would have the same effect in my estimation. Therefore the Debian list (for instance) won't be of any help.

Now this isn't to be confused with how the binding is made, i.e. LOGIN, GSSAPI, MD5, SSHA, etc... That is specified with the `-Y` option [upper case] and would be my next area to play with if the `-w` doesn't work.

As far as adding the password to the SASL database (which is a good idea to try) if you are running strict sasldb I believe the command is `saslpasswd2`. But like I said before, I've hooked in Kerberos before that point  by changing the runtime options in /etc/conf.d/saslauthd, so you'll probably want to research how to use it. I'm sure it will be straight forward though.

The only sticky part is the part of the code where I sluffed "SASL.DOMAIN". You'll need to determine that ahead of time and set it accordingly. My sasl domain (technically my Kerberos Realm since that is how I am doing it) is the same as my DNS domain.

Also "GSSAPI" means I'm hooking into Kerberos, you may want your 'auth' to be something else.

UPDATE:

Another key part in setting this up is this... You need an /etc/sasl2/slapd.conf file. Here is the contents of mine...

```
pwcheck_method: saslauthd
```

Last edited by onlawn on Wed Jan 26, 2005 6:48 pm; edited 1 time in total

----------

## Adamal

I've already used saslpasswd2 but I'll do a little more research in this arena.  From what I can tell -w does the samething as -x except you can specify the password on the commandline.  Either way I need to do a little more research into SASL.  Thanks for your help.

On a side note why are you using Kerberos? Just curious.

----------

## onlawn

 *Quote:*   

> From what I can tell -w does the samething as -x except you can specify the password on the commandline.

 

Let me know how it works.

 *Quote:*   

> On a side note why are you using Kerberos? Just curious.

 

Funny enough, the decision to use Kerberos involves our entire network here. We use it for a number of tasks. The reason I go though the hoops to use the SASL hooks in Kerberos through LDAP is to provide programs that provide LDAP authentication a way to hook into the main authentication scheme.

Oh and as a correction, the compile time option that makes us different than most binary packages is '--enable-spasswd'. We used to use '--enable-kpasswd' but that has been depricated. Were it our choice we wouldn't use it either, to their credit. But not every program and wervice we run can use GSSAPI (to connect via Kerberos5 tickets).

Here is looking forward to the day that everything is GSSAPI aware ;)

----------

## wimverheij

I am experiencing the same problem. I was wondering if it has anything to do with the(TCP-) port on which the LDAP server listens. As far as I can figure out, this port is not open.

The problem is that I don't know how to check this, or how to open the specific port

Sorry, I have to correct my comments. I receive a :" ldap_bind: Can't contact LDAP server (81)" message.

----------

## onlawn

Since your problem is happening in "ldapbind:" instead of the sasl_bind I believe you are having a different issue.

Best to start a new thread on that one, wimverheij, if you don't mind. I'll be happy to help out over there also. I have the response ready to go :)

What I will say though is that the debugging on ldap is pretty good. You can learn quite a bit by adding `-d 1` to your ldapsearch command. Then keep incrementing that number in subsiquent attempts with ldapsearch, all the way to `-d 3`.

The output if that should be enough to determine definitively if your issue is truely different than the rest (if they post their debug info also).

----------

## wimverheij

Thanks onlawn, I'll just do that, including a verbose output of the search command

----------

## roep

I have had the same issue.  Looking in /var/log/messages I saw an error:

 *Quote:*   

> 
> 
> Mar  8 21:52:16 hostname slapd[8772]: <= dn2id could not open dn2id.dbb
> 
> 

 

I touched this file (as root) and changed ownership to ldap and all seemed well.

```

touch /var/lib/openldap-ldbm/dn2id.dbb

chown ldap:ldap /var/lib/openldap-ldbm/dn2id.dbb

```

----------

## najt

Have you tried updating to openldap-2.2.23-r1 ?

----------

## drax_

Adamal, the anwser to your problem, is very simple. I encountered the same things a few days ago.

The reason the ldap client tries to bind with sasl by default, and that you HAVE to pass -x to do simple auth, is because openldap was compiled using the "sasl" flag.

I also have this flag in my make.conf since I use postfix and saslauth, but I dont use sasl for ldap, and in fact, it gets in the way  :Wink: 

Simply add "net-nds/openldap -sasl" to your /etc/portage/package.use and re-emerge openldap. You will then be able to just type ldapsearch (as long as you have a good ldap.conf).

----------

## Adamal

 *drax_ wrote:*   

> Adamal, the anwser to your problem, is very simple. I encountered the same things a few days ago.
> 
> The reason the ldap client tries to bind with sasl by default, and that you HAVE to pass -x to do simple auth, is because openldap was compiled using the "sasl" flag.
> 
> I also have this flag in my make.conf since I use postfix and saslauth, but I dont use sasl for ldap, and in fact, it gets in the way 
> ...

 

You are correct.  However I was trying to get ldap to work with sasl.  I finally gave up and re-emerged it without the sasl flag.  Its been running great on my server now for quite some time.  LDAP was definitly the way to go.

----------

