LinuxQuestions.org - [SOLVED] openldap setup Invalid credentials error (49)

- Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)

- - openldap setup Invalid credentials error (49) (https://www.linuxquestions.org/questions/linux-server-73/openldap-setup-invalid-credentials-error-49-a-798807/)

openldap setup Invalid credentials error (49)

I'm trying to set up openLDAP on fedora 12 and am have not luck authenticating the root user after starting the service. I'm hoping someone with more experience might be willing to help. I left all the settings as default and get the following when I do a simple search:

Code:

[root@claudius ~]# ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts



# extended LDIF

#

# LDAPv3

# base <> with scope baseObject

# filter: (objectclass=*)

# requesting: namingContexts 

#



#

dn:

namingContexts: dc=my-domain,dc=com



# search result

search: 2

result: 0 Success



# numResponses: 2

# numEntries: 1

So the slapd service seems to be running ok. However, when I attempt to run a basic ldif file I get the following

Code:

[root@claudius ~]# ldapadd  -x -D "cn=Manager,dc=my-domain,dc=com" -W -f base.ldif 

Enter LDAP Password: 

ldap_bind: Invalid credentials (49)

Here is the base.ldif:

Code:

[root@claudius ~]# cat base.ldif 

dn: dc=my-domain,dc=com

objectclass: dcObject

objectclass: organization

o: Example Company

dc: my-domain



dn: cn=Manager,dc=my-domain,dc=com

objectclass: organizationalRole

cn: Manager

I got the sample file from here.

I've tried substituting several different output strings from slappasswd, but all with the same result.
Finally, here is the slap.conf file:

Code:

[root@claudius ~]# grep -v ^# /etc/openldap/slapd.conf|cat -s



include        /etc/openldap/schema/corba.schema

include        /etc/openldap/schema/core.schema

include        /etc/openldap/schema/cosine.schema

include        /etc/openldap/schema/duaconf.schema

include        /etc/openldap/schema/dyngroup.schema

include        /etc/openldap/schema/inetorgperson.schema

include        /etc/openldap/schema/java.schema

include        /etc/openldap/schema/misc.schema

include        /etc/openldap/schema/nis.schema

include        /etc/openldap/schema/openldap.schema

include        /etc/openldap/schema/ppolicy.schema

include        /etc/openldap/schema/collective.schema



allow bind_v2



pidfile        /var/run/openldap/slapd.pid

argsfile        /var/run/openldap/slapd.args



database        bdb

suffix          "dc=my-domain,dc=com"

checkpoint      1024 15

rootdn          "cn=Manager,dc=my-domain,dc=com"



rootpw          {SSHA}7QH+zdRtuIpyJb9scodYkn1uUKIvQ8W6



directory      /var/lib/ldap



index objectClass                      eq,pres

index ou,cn,mail,surname,givenname      eq,pres,sub

index uidNumber,gidNumber,loginShell    eq,pres

index uid,memberUid                    eq,pres,sub

index nisMapName,nisMapEntry            eq,pres,sub



database monitor



access to *

        by dn.exact="cn=Manager,dc=my-domain,dc=com" read

        by * none

As you can see, all the setting are default except the password, of which I've tried several types.

I'd appreciate any advice anyone has.

Thanks

Hi,

You can stop slapd from running and use slapadd to add the ldif:

Code:

slapadd -l base.ldif

Then start slapd and try to search with authentication:

Code:

ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts -D "cn=Manager,dc=my-domain,dc=com" -W

bathory, thanks for the suggestion. I tried the commands with the following results:

Code:

[root@claudius ~]# slapadd -l base.ldif 

_#################### 100.00% eta  none elapsed            none fast!        

Closing DB...

and after restarting the slapd service:

Code:

[root@claudius ~]# ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts -D "cn=Manager,dc=my-domain,dc=com" -W

Enter LDAP Password: 

ldap_bind: Invalid credentials (49)

a search without credentials has the same results as before.

I just discovered slapcat, which produced the following:

Code:

[root@claudius ~]# slapcat

dn: dc=my-domain,dc=com

objectClass: dcObject

objectClass: organization

o: Example Company

dc: my-domain

structuralObjectClass: organization

entryUUID: 94a09be2-d016-102e-9b40-a962b0240786

creatorsName: cn=Manager,dc=my-domain,dc=com

createTimestamp: 20100330070700Z

entryCSN: 20100330070700.510148Z#000000#000#000000

modifiersName: cn=Manager,dc=my-domain,dc=com

modifyTimestamp: 20100330070700Z



dn: cn=Manager,dc=my-domain,dc=com

objectClass: organizationalRole

cn: Manager

structuralObjectClass: organizationalRole

entryUUID: 94add80c-d016-102e-9b41-a962b0240786

creatorsName: cn=Manager,dc=my-domain,dc=com

createTimestamp: 20100330070700Z

entryCSN: 20100330070700.596894Z#000000#000#000000

modifiersName: cn=Manager,dc=my-domain,dc=com

modifyTimestamp: 20100330070700Z

So I've verified that the ldif file was imported.

The ldif was imported because slapadd does not care about credentials. I suspected the problem was due to the ACL:

Quote:

access to *
by dn.exact="cn=Manager,dc=my-domain,dc=com" read
by * none

that does not allow "cn=Manager,dc=my-domain,dc=com" to write to the directory.
So are you sure that the rootpw you're using is correct?
You can stop slapd and then run it from CLI in debug mode to watch the output and see if you can find the reason why you get the "Invalid Credentials" error:

Code:

slapd -d -1

Just out of curiosity, why aren't you using the directory server that comes with Fedora?

I believe the ACL you mentioned is for the "monitor" database. The comments in the slap.conf file seem to indicate that I should be able to leave the general ACL undefined.

Code:

# if no access controls are present, the default policy

# allows anyone and everyone to read anything but restricts

# updates to rootdn.  (e.g., "access to * by * read")

#

# rootdn can always read and write EVERYTHING!

As for the the correct password, I've tried several passwords, typing them all very meticulously. I'm pretty sure I've ruled that out.

I may go and use Fedora's Directory server. To be honest, this is my first Linux directory server and I wasn't aware that Fedora had a separate directory project.

You can try to change the order of the included schema files and see if it makes any difference. At least core.schema should come first:

Code:

include          /etc/openldap/schema/core.schema

include          /etc/openldap/schema/cosine.schema

include          /etc/openldap/schema/inetorgperson.schema

include          /etc/openldap/schema/nis.schema

include        /etc/openldap/schema/misc.schema

include        /etc/openldap/schema/corba.schema

include        /etc/openldap/schema/duaconf.schema

include        /etc/openldap/schema/dyngroup.schema

include        /etc/openldap/schema/java.schema

include        /etc/openldap/schema/nis.schema

include        /etc/openldap/schema/openldap.schema

include        /etc/openldap/schema/ppolicy.schema

include        /etc/openldap/schema/collective.schema

Also you can comment out those you don't need.

Thanks for all your help bathory. I found the problem. I came across some info in the documentation about how the openldap server reads the settings files. Apparently the newest version of openldap reads the settings from the slapd.d directory. Any changes made to slapd.conf are ignored unless there is no slapd.d directory, in which case a new directory and setting file is created from the settings in slapd.conf. You can force the daemon to read the slapd.conf file and overwrite the slapd.d directory files, which is how I was able to resolve the problem.

thanks again.

What command did you use to forcibly read that file?
Want to know how you resolved that issue?

from the slapd man page:

Code:

      -f slapd-config-file

              Specifies  the  slapd  configuration  file.  The  default  is

              /usr/local/etc/openldap/slapd.conf.



      -F slapd-config-directory

              Specifies  the  slapd  configuration  directory.        The default is

              /usr/local/etc/openldap/slapd.d.        If both -f and -F  are        speci-

              fied,  the  config  file        will  be  read and converted to config

              directory format and written to  the  specified  directory.  If

              neither  option  is  specified,  slapd  will attempt to read the

              default config directory before trying to use the default config

              file. If a valid config directory exists then the default config

              file is ignored. All of the  slap  tools        that  use  the        config

              options observe this same behavior.

So to force the config file to be read, just use the -f option.