OpenLDAP fails to start because of tls-files

Hi,

I want to configure a ldap server for user authentification, nfs and so on.

I am following the handbook and here is the issue:

I generated the tls files:
Code:
freebsd openldap # openssl genrsa -out cert.key 1024
Generating RSA private key, 1024 bit long modulus
.....................++++++
......................................................++++++
e is 65537 (0x10001)
freebsd openldap # openssl req -new -key cert.key -out cert.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Berlin
Locality Name (eg, city) []:Berlin
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Home
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:server.fritz.box
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
freebsd openldap # openssl x509 -req -in cert.csr -days 365 -signkey cert.key -out cert.crt
Signature ok
subject=/C=DE/ST=Berlin/L=Berlin/O=Home/CN=server.fritz.box
Getting Private key
Common Name is the dnsname which I have added to the server ip in my fritzbox.

Now when I add them in my config like this:
Code:
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include         /usr/local/etc/openldap/schema/core.schema
include         /usr/local/etc/openldap/schema/cosine.schema
include         /usr/local/etc/openldap/schema/inetorgperson.schema
include         /usr/local/etc/openldap/schema/misc.schema
include         /usr/local/etc/openldap/schema/nis.schema
include         /usr/local/etc/openldap/schema/openldap.schema
include         /usr/local/etc/openldap/schema/samba.schema

loglevel 256

pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args

# Load dynamic backend modules:
modulepath      /usr/local/libexec/openldap
moduleload      back_bdb
# moduleload    back_hdb
# moduleload    back_ldap

# Sample security restrictions
#       Require integrity protection (prevent hijacking)
#       Require 112-bit (3DES or better) encryption for updates
#       Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
security ssf=128

TLSCertificateFile /path/to/your/cert.crt
TLSCertificateKeyFile /path/to/your/cert.key
TLSCACertificateFile /path/to/your/cacert.crt

# Sample access control policy:
#       Root DSE: allow anyone to read it
#       Subschema (sub)entry DSE: allow anyone to read it
#       Other DSEs:
#               Allow self write access
#               Allow authenticated users read access
#               Allow anonymous users to authenticate
#       Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
#       by self write
#       by users read
#       by anonymous auth
#
# 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!

#######################################################################
# BDB database definitions
#######################################################################

database        bdb
suffix          "dc=fritz,dc=box"
rootdn          "cn=Manager,dc=fritz,dc=box"
rootpw          {SSHA}pg37R0Xs+RoNipPyDswem1NOrd2+HYbB

# 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/db/openldap-data
# Indices to maintain
index   objectClass     eq
Where is the cacert.crt?

When I comment the tls section out slapd starts properly.

Regards
 
bsus said:
Where is the cacert.crt?
From the same page in the handbook you mentioned:
This will create a self-signed certificate that can be used for the directives in slapd.conf, where cert.crt and cacert.crt are the same file.
 
I mentioned this sentence, but I didn't understand it.

Does it mean that cacert.crt is linked to cert.crt or that slapd.conf automaticly uses the cert.crt?

What is with the main issue? Would is going wrong with TLS so slapd won't start.

Regards.
 
bsus said:
I mentioned this sentence, but I didn't understood it.

Does it mean that cacert.crt is linked to cert.crt or that slapd.conf automaticly uses the cert.crt?
No, it means you have to point to the same certificate for both entries.

Code:
TLSCertificateFile /path/to/your/cert.crt
TLSCACertificateFile /path/to/your/cacert.crt
 
Ahh I am so stupid.. didn't read the "path to your" I thought this was already /usr/local/etc/openldap.

Code:
security ssf=128

TLSCertificateFile /usr/local/etc/openldap/cert.crt
TLSCertificateKeyFile /usr/local/etc/openldap/cert.key
TLSCACertificateFile /usr/local/etc/openldap/cert.crt
This is working.
I am only getting an error that the hostnames don't match, but when I specify with the -h option I am getting a valid connection.

Now I am having some issues adding an account over ldapadd:
Code:
server ldif # ldapadd -x -Z -D "cn=Manager,dc=fritz,dc=box" -W -f people.ldif
ldap_start_tls: Connect error (-11)
	additional info: TLS: hostname does not match CN in peer certificate
Enter LDAP Password: 
adding new entry "ou=people,dc=fritz,dc=box"
ldap_add: No such object (32)

server ldif # ldapadd -x -Z -h server.fritz.box -D "cn=Manager,dc=fritz,dc=box" -W -f people.ldif
Enter LDAP Password: 
adding new entry "ou=people,dc=fritz,dc=box"
ldap_add: No such object (32)

My error is "No such object(32)". I googled around and found out, that "No such object" means that a hierarchial object is missing in the database. Is this true? How can I add the missing point?
Code:
cat people.ldif
dn: ou=people,dc=fritz,dc=box
objectClass: top
objectClass: organizationalUnit
ou: people

dn: uid=guest,ou=people,dc=fritz,dc=box
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
objectClass: top
uidNumber: 10000
gidNumber: 10000
homeDirectory: /home/temp
loginShell: /bin/bash
uid: guest
cn: guest

dn: ou=groups,dc=fritz,dc=box
objectClass: top
objectClass: organizationalUnit
ou: groups

dn: cn=guest,ou=groups,dc=fritz,dc=box
objectClass: posixGroup
objectClass: top
gidNumber: 10000
cn: guest
 
I find OpenLDAP error messages quite meager and sometimes misleading. Thus, 32 usually is something very basic.
Does your server respond to LDAP queries at all? What is the outcome of:
Code:
ldapsearch -x -Z -h server.fritz.box -D "cn=Manager,dc=fritz,dc=box" -W -b 'dc=fritz,dc=box' '(objectclass=*)'
Even if the directory is empty, the records for the domain and the Manager should be printed.
 
Hi,
the results of ldapsearch are also very strange:

Code:
server ~ # ldapsearch -x -Z -h server.fritz.box -D "cn=Manager,dc=fritz,dc=box" -W -b 'dc=fritz,dc=box' '(objectclass=*)'
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <dc=fritz,dc=box> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 3
result: 32 No such object

# numResponses: 1
 
At least it's clear that the server responds but refuses to show its contents. I would try to comment out the
Code:
security ssf=128
line from slapd.conf and issue ldapsearch without "-Z". Whatever the reason, you need to get your domain printed (so you're sure it works) before trying to add any ldifs.
 
Hi,
I deactivated the ssf=128 line in slapd.conf and ran ldapsearch without the -Z option - result is still the same:
Code:
 ldapsearch -x -h server.fritz.box -D "cn=Manager,dc=fritz,dc=box" -W -b 'dc=fritz,dc=box' '(objectclass=*)'
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <dc=fritz,dc=box> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1

Whatever the reason, you need to get your domain printed (so you're sure it works) before trying to add any ldifs.
I could think the domain is the problem. I only have a crippled fritz.box which doesn't run a "real" DNS-dameon like BIND. Also nameserver doesn't work in my intranet on unix (only with shared /etc/hosts).
 
I could think the domain is the problem. I only have a crippled fritz.box which doesn't run a "real" DNS-dameon like BIND. Also nameserver doens't work in my intranet on unix (only with shared /etc/hosts).
An LDAP "domain" as such is just a root record in your LDAP directory tree, stored in your BDB database, and has nothing to do with any DNS domain unless you have a special configuration (not your case by now). Did you restart slapd when you made changes to slapd.conf? (just in case...)
 
What you need are the entries for the root record, they are not added automatically by the slapd server. Something like this (this is what I used for dc=example,dc=org, adapt to your domain):
Code:
# Organization for Example Corporation
dn: dc=example,dc=org
objectClass: dcObject
objectClass: organization
dc: example
o: Example Corporation
description: The Example Corporation

# Organizational Role for Directory Manager
dn: cn=Manager,dc=example,dc=org
objectClass: organizationalRole
cn: Manager
description: Directory Manager
 
@rockhardridefire
Surely have I restarted the slap-daemon ;)


@kpa
I ain't sure if I already added at the beginning a (currupted?) root record.
But I tried it again and became following values:
Code:
server ldif # ldapadd -x -h server.fritz.box -D "cn=Manager,dc=fritz,dc=box" -W -f base.ldif
Enter LDAP Password: 
adding new entry "dc=fritz, dc=box"
ldap_add: Naming violation (64)
	additional info: value of single-valued naming attribute 'dc' conflicts with value present in entry

server ldif # cat base.ldif
# Organization for Example Corporation
dn: dc=fritz, dc=box
objectClass: dcObject
objectClass: organization
dc: example
o: Home
description: Home LDAP Server

# Organizational Role for Directory Manager
dn: cn=Manager,dc=fritz, dc=box
objectClass: organizationalRole
cn: Manager
description: Directory Manager
server ldif #
 
Ok, kpa was right, and I made a mistake when telling you that the base record for your domain is already there when you configure your slapd.conf. But what actually is there, is the "naming context" into which you add your domain records beginning with the base. So, to check if your server responds to queries, the correct command would have been:

Code:
ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts

In response you should get something like:

Code:
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts 
#

#
dn:
namingContexts: dc=fritz,dc=box

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
Concerning your base.ldif:

1. In both records, you have a space between "dc=fritz," and "dc=box" which must not be there.

2. If the dc=fritz, as you are telling in your DN line, it cannot be "example" at the same time, so change "dc: example" to "dc: fritz".

Also make sure that your ldif file has no trailing spaces in any line.
 
Concerning your base.ldif:

1. In both records, you have a space between "dc=fritz," and "dc=box" which must not be there.

2. If the dc=fritz, as you are telling in your DN line, it cannot be "example" at the same time, so change "dc: example" to "dc: fritz".

Also make sure that your ldif file has no trailing spaces in any line.
I inserted the space to make it more readable. Normaly it should be valid(?), because the parsing overskips whitespaces. Usually at least..

Added the newer base.ldif and see there it works:

Now it works and gives me an usable output:
Code:
server ~ # ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts 
#

#
dn:
namingContexts: dc=fritz,dc=box

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Now I tried adding a guest user account:
Code:
server ldif # ldapadd -x -h server.fritz.box -D "cn=Manager,dc=fritz,dc=box" -W -f people.ldif
Enter LDAP Password: 
adding new entry "dc=fritz,dc=box"
ldap_add: Object class violation (65)
	additional info: attribute 'dc' not allowed

Somewhere there's a dc=fritz,dc=box to much.. but where?

Code:
dn: dc=fritz,dc=box
objectclass: organization
objectclass: top
o: Professional Network Solutions
l: Berlin

dn: ou=users,dc=fritz,dc=box
objectclass: organizationalunit
ou: people
discription: User accounts

dn: uid=guest,ou=users,dc=fritz,dc=box
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
objectClass: top
uidNumber: 10000
gidNumber: 10000
homeDirectory: /home/guest
loginShell: /bin/bash
uid: guest
cn: guest

dn: ou=groups,dc=fritz,dc=box
objectClass: top
objectClass: organizationalUnit
ou: groups

dn: cn=guest,ou=groups,dc=fritz,dc=box
objectClass: posixGroup
objectClass: top
gidNumber: 10000
cn: guest

Thank you for youre help,
Regards
 
Try adding only the root node first, to help narrow down the problem.

Change:
Code:
dn: dc=fritz,dc=box
objectclass: organization
objectclass: top
o: Professional Network Solutions
l: Berlin

To:
Code:
dn: dc=fritz,dc=box
dc: fritz
ou: fritz dot box
objectClass: dcObject
objectClass: organizationalUnit

and try again.
 
Hi anomie,

thank you, this solved my issue ;)


I have some last question:

1. How can I add additional attributes (streetaddress, city, phone..)?
2. I have now activated TLS again and searching with
Code:
ldapsearch -Z -h 'server.fritz.box' -b '' -s base '(objectclass=*)'
works properly without getting an warning/error. Is now everything configured properly to have a encrypted connection?
 
Stricktly speaking, your error message says that, in your ldif, there's an object that tries to add a dc attribute but doesn't have sufficient object classes defined for that. That's your 1st stanza: in order to add
Code:
dn: dc=fritz,dc=box
you also need
Code:
objectClass: dcObject
But didn't you already add base.ldif successfully? Then you don't need the 1st stanza at all. Delete it from people.ldif and try to add it again.

BTW, if you wanna check whether your base.ldif has added the domain root record, namingContexts is no longer enough. Now searching for a record should work:
Code:
ldapsearch -x -h server.fritz.box -D "cn=Manager,dc=fritz,dc=box" -W -b 'dc=fritz,dc=box' '(objectclass=*)'
 
Searching for a record doesn't work :(

Code:
server src # ldapsearch -x -h server.fritz.box -D "cn=Manager,dc=fritz,dc=box" -W -b 'dc=fritz,dc=box' '(objectclass=*)'
Enter LDAP Password: 
ldap_bind: Confidentiality required (13)
	additional info: confidentiality required

Password is correct, don't know what is missing....
 
The -Z was missing...
Code:
 ldapsearch -Z -h server.fritz.box -D "cn=Manager,dc=fritz,dc=box" -W -b 'dc=fritz,dc=box' '(objectclass=*)'
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <dc=fritz,dc=box> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# fritz.box
dn: dc=fritz,dc=box
dc: fritz
ou: fritz dot box
objectClass: dcObject
objectClass: organizationalUnit

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1
 
Congratulations! :beergrin Now you have an LDAP directory (with 1 record). Now you can add objects and groups to it. Here's an outline of how the tree works and how to populate it:

http://www.ibm.com/developerworks/linux/tutorials/l-ldap/section4.html
http://www.ibm.com/developerworks/linux/tutorials/l-ldap/section2.html

Actually, it's easier to use a GUI client for adding/editing the entries, and that will also give you a picture of the tree. There are some desktop (gq, luma, jxplorer...) and web (phpldapadmin...) clients.
 
Back
Top