[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Cannot create a database with more than one level of subordination
Hi all,
Did not anybody encounter the following problem? Or can explain me where
I am wrong (if I really am)?
I try to create an OpenLDAP database with more than one level of
subordination. It should look like this (the picture is somewhat
simplified by not showing some unrelated details like other branches):
dc=kt-privat,dc=donetsk,dc=ua - the topmost level
dc=druzh,dc=kt-privat,dc=donetsk,dc=ua - the next level, stored in
its own database
dc=micro7,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua - one more level,
also with its own database
I want to have an OpenLDAP server on each level. Or, to be more precise,
I want to have 3 servers, each holding databases for all three levels,
but the first server should be responsible for the topmost level master
replica, the second one - for the master replica of the second level and
so on. Each server should replicate the changes in its corresponding
master replica to all other ones. I hope I've managed to explain what I
mean despite of the quality of my English :-)
All this worked as long as there where only two levels. Two-level
configuration now without any problems in my "real-life" environment.
Moreover, everything seemed to be good when I've tried to add the third
level (dc=micro7,...) to OpenLDAP 2.1.xxx server (I don't remember the
minor release number). But when I've tried the same thing on the
OpenLDAP 2.2.13 server, I've got an error.
When I tried to populate the newly created level with the initial record
(containing information about this "dc" itself) I got the following
message from the "ldapadd":
-------------8><--------------------------------
adding new entry "dc=micro7,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua"
ldap_add: Internal (implementation specific) error (80)
additional info: 8∙╣
и├╖
-------------8><--------------------------------
When I copied the database generated on the 2.1 server to the 2.2
server, the server started normally, but I observed errors when I tried
to access even the second level of the tree with various LDAP clients.
Unfortunately, I cannot run OpenLDAP 2.1 on all of my servers. The older
servers run Fedora Core 1, which comes with OpenLDAP 2.1.x. The newer
ones run Fedora Core 3 with OpenLDAP 2.2.13 and I don't want to install
other versions OpenLDAP (at least the versions, for which I have not
RPMs). I've built OpenLDAP 2.2.26 RPM for FC3, but this version exposes
exactly the same behaviour as 2.2.13. To build a 2.3.6 RPM was not so
easy. Probably I could try harder and build it, if I was sure it would help.
So, does anybody knows, what is wrong? Isn't my configuration illegal by
its nature (I don't feel myself a big specialist in LDAP)? Or perhaps
this is a known bug in OpenLDAP 2.2.x?
My "slapd.conf" follows. If some additional details could be helpful, I
will supply them.
-------------8><-- slapd.conf ------------------------------
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
#######################################################################
# Global settings
#######################################################################
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/krb5-kdc.schema
#include /etc/openldap/schema/redhat/rfc822-MailMember.schema
include /etc/openldap/schema/redhat/autofs.schema
#include /etc/openldap/schema/redhat/kerberosobject.schema
include /etc/openldap/schema/samba.schema
loglevel 0
# Allow access from old clients, particulary from Directory Administrator
allow bind_v2
# 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/slapd.pid
argsfile /var/run/slapd.args
# Load dynamic backend modules:
# modulepath /usr/sbin/openldap
# moduleload back_bdb.la
# moduleload back_ldap.la
# moduleload back_ldbm.la
# moduleload back_passwd.la
# moduleload back_shell.la
# 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
# 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 is:
# Allow read by all
#
# rootdn can always write!
#access to *
# by dn="cn=Manager,dc=kt-privat,dc=donetsk,dc=ua" write
# by dn="cn=Replicator,dc=kt-privat,dc=donetsk,dc=ua" write
# by self write
# by users read
# by anonymous auth
access to attrs=userPassword
by dn="cn=Replicator,dc=kt-privat,dc=donetsk,dc=ua" write
by dn="cn=nssldap,ou=DSA,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua" write
by dn="cn=smbldap,ou=DSA,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua" write
by dn="cn=samba,ou=DSA,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua" write
by self write
by anonymous auth
by * none
access to attrs=sambaLMPassword
by dn="cn=Replicator,dc=kt-privat,dc=donetsk,dc=ua" write
by dn="cn=nssldap,ou=DSA,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua" write
by dn="cn=smbldap,ou=DSA,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua" write
by dn="cn=samba,ou=DSA,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua" write
by self write
by anonymous auth
by * none
access to attrs=sambaNTPassword
by dn="cn=Replicator,dc=kt-privat,dc=donetsk,dc=ua" write
by dn="cn=nssldap,ou=DSA,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua" write
by dn="cn=smbldap,ou=DSA,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua" write
by dn="cn=samba,ou=DSA,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua" write
by self write
by anonymous auth
by * none
access to *
by dn="cn=Replicator,dc=kt-privat,dc=donetsk,dc=ua" write
by dn="cn=nssldap,ou=DSA,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua" write
by dn="cn=smbldap,ou=DSA,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua" write
by dn="cn=samba,ou=DSA,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua" write
by * read
#######################################################################
# Individual databases
#######################################################################
############################
# 7-micro database
############################
database ldbm
suffix "dc=micro7,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua"
subordinate
rootdn "cn=Manager,dc=micro7,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw **********************************
# 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/ldap/druzh/7micro
# Indices to maintain
index objectClass,uidNumber,gidNumber eq
index cn,sn,uid,displayName pres,sub,eq
index memberUid,mail,givenname eq,subinitial
index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq
# Replicas to which we should propagate changes
#replica host=redmug.kt-privat.donetsk.ua:389
# binddn="cn=Replicator,dc=kt-privat,dc=donetsk,dc=ua"
# bindmethod=simple credentials=gjklybr
#replogfile /var/lib/ldap/slurpd/druzh.rep
############################
# Druzh branch database
############################
database ldbm
suffix "dc=druzh,dc=kt-privat,dc=donetsk,dc=ua"
subordinate
rootdn "cn=Manager,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw **************************************
# 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/ldap/druzh
# Indices to maintain
index objectClass,uidNumber,gidNumber eq
index cn,sn,uid,displayName pres,sub,eq
index memberUid,mail,givenname eq,subinitial
index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq
# Replicas to which we should propagate changes
#replica host=redmug.kt-privat.donetsk.ua:389
# binddn="cn=Replicator,dc=kt-privat,dc=donetsk,dc=ua"
# bindmethod=simple credentials=gjklybr
#replogfile /var/lib/ldap/slurpd/druzh.rep
#####################
# Root database
#####################
database ldbm
suffix "dc=kt-privat,dc=donetsk,dc=ua"
rootdn "cn=Manager,dc=kt-privat,dc=donetsk,dc=ua"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw ******************************************
# 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/ldap
# Indices to maintain
#index objectClass,uid,uidNumber,gidNumber,memberUid eq
#index cn,mail,surname,givenname eq,subinitial
index objectClass,uidNumber,gidNumber eq
index cn,sn,uid,displayName pres,sub,eq
index memberUid,mail,givenname eq,subinitial
index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq
# Replicas to which we should propagate changes
#replica host=ldap-1.example.com:389 tls=yes
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com@EXAMPLE.COM
updatedn "cn=Replicator,dc=kt-privat,dc=donetsk,dc=ua"
updateref "ldap://redmug.kt-privat.donetsk.ua";
-------------8><--------------------------------------------
--
Sayonara
_______________________________________
Dmitriy Stepanenko aka Mudropolk
e-mail: mpolk@kt-privat.donetsk.ua
ICQ: 112689047 phone: (38)(0626)41-93-06