OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/8799
Full headers

From: quanah@openldap.org
Subject: slaptest fails to properly convert chain configuration
Compose comment
Download message
State:
0 replies:
1 followups: 1

Major security issue: yes  no

Notes:

Notification:


Date: Mon, 22 Jan 2018 21:59:20 +0000
From: quanah@openldap.org
To: openldap-its@OpenLDAP.org
Subject: slaptest fails to properly convert chain configuration
Full_Name: Quanah Gibson-Mount
Version: 2.4.45
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)


The process for converting a slapd configuration to cn=config making use of
slapo-chain at a global level is seriously broken.

This can be trivially illustrated by using the slapd.conf generated by test032.

After doing conversion, the resulting cn=config database has *two* ldap backends
defined:

dn: olcDatabase={-1}frontend,cn=config
dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf
dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf


The first instance ({0}ldap,...) isn't even valid.  If you remove the entire
chain configuration from this database, and then attempt to import it, you get
the following:

ldapadd -H ldap:/// -D cn=config -w secret -f ./olcOverlay\=\{0\}chain.ldif
adding new entry "olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config"

ldapadd -H ldap:/// -D cn=config -w secret -f ./olcDatabase\=\{0\}ldap.ldif
adding new entry "olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config"
ldap_add: Object class violation (65)


This is because the first instance ({0}) is *missing* the required olcDbURI
attribute.  In addition, it generates completely bogus attribute values (See
ITS#8693)

The *second* generated LDAP backend database is what is correct.

Here's the LDIF for the incorrect database:

dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {0}ldap
olcDbStartTLS: none  starttls=no
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0


Here's the LDIF for the *correct* database:

dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {1}ldap
olcDbURI: "ldap://localhost:9012"
olcDbStartTLS: none  starttls=no
olcDbIDAssertBind: mode=self flags=non-prescriptive,proxy-authz-non-critical
  bindmethod=simple timeout=0 network-timeout=0 binddn="cn=manager,dc=exampl
 e,dc=com" credentials="secret" keepalive=0:0:0
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0

However, even in the case of the *correct* LDIF, the bogus olcDbStartTLS
attribute is defined (Again, ITS#8693)

This is the slapd.conf used to convert:

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/openldap.schema
include         /usr/local/etc/openldap/schema/nis.schema
pidfile         /tmp/slapd.1.pid
argsfile        /tmp/slapd.1.args

modulepath      /usr/local/libexec/openldap
moduleload      back_mdb.la
moduleload back_ldap.la
moduleload back_monitor.la

overlay         chain
chain-uri       ldap://localhost:9012/
chain-idassert-bind     bindmethod=simple
                        binddn="cn=Manager,dc=example,dc=com"
                        credentials=secret
                        mode=self
                        flags=non-prescriptive

database        mdb
suffix          "dc=example,dc=com"
rootdn          "cn=Manager,dc=example,dc=com"
rootpw          secret
directory       /tmp/db.1.a
index           objectClass     eq
index           cn,sn,uid       pres,eq,sub

database        monitor

Followup 1

Download message
Date: Tue, 23 Jan 2018 00:57:00 +0100
From: =?utf-8?B?T25kxZllaiBLdXpuw61r?= <ondra@mistotebe.net>
To: quanah@openldap.org
Cc: openldap-its@OpenLDAP.org
Subject: Re: (ITS#8799) slaptest fails to properly convert chain configuration
On Mon, Jan 22, 2018 at 09:59:21PM +0000, quanah@openldap.org wrote:
> The process for converting a slapd configuration to cn=config making use of
> slapo-chain at a global level is seriously broken.

It's not as bad, just a little bit broken:

> This can be trivially illustrated by using the slapd.conf generated by
test032.
> 
> After doing conversion, the resulting cn=config database has *two* ldap
backends
> defined:
> 
> dn: olcDatabase={-1}frontend,cn=config
> dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
> dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf

This is the catchall database used to handle referrals that are not
handled by any other database you configure by hand. It collects all the
chain-* settings that appear before the first chain-uri.

> dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf
> 
> The first instance ({0}ldap,...) isn't even valid.  If you remove the
entire
> chain configuration from this database, and then attempt to import it, you
get
> the following:

Yeah that is a problem.

> ldap_add: Object class violation (65)
> 
> This is because the first instance ({0}) is *missing* the required olcDbURI
> attribute.  In addition, it generates completely bogus attribute values
(See
> ITS#8693)

Maybe we just need to inherit objectclass: olcLdapDatabase somehow in
olcChainOverlay and keep these settings in the overlay entry, or specify
a bogus URI to be configured there. Whatever is most useable and still
allows for seamless expansion.

> The *second* generated LDAP backend database is what is correct.
> 
> Here's the LDIF for the incorrect database:
> 
> [...]
> 
> Here's the LDIF for the *correct* database:
> 
> [...]

-- 
Ond..ej Kuzn..k
Senior Software Engineer
Symas Corporation                       http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org