[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: cn=config chaining

To: Quanah Gibson-Mount <quanah@zimbra.com>, "openldap-technical@openldap.org" <openldap-technical@openldap.org>
Subject: Re: cn=config chaining
From: "Jancewicz, Russell" <russell.jancewicz@uconn.edu>
Date: Thu, 26 Sep 2013 17:23:42 +0000
Accept-language: en-US
Content-id: <262344CF2C95D74A8E0348D699D020C2@ad.uconn.edu>
Content-language: en-US
In-reply-to: <C20412007E72F921EAF069AF@[192.168.1.93]>
Thread-index: AQHOutHDrqCGvsOs90qxuVa1UpxMcpnYgaaA///C/YA=
Thread-topic: cn=config chaining
User-agent: Microsoft-MacOutlook/14.3.6.130613

It was modified from the generation of slapd-chain2.conf which also didn't
work (I was working off the assumption that the overlay needed to be on
olcDatabase={1}frontend)

This is the slapd-chain2.conf file I am using (modified slightly)
The only differences between this and the unmodified slapd-chain2.conf is
the directory and the addition of chain-tls and chain-idassert-authzFrom
to the "overlay chain" section.

I'm generating my config with it with
$ slaptest -f slapd-chain2.conf -F ./slapd.d-test/

"""
include		/etc/openldap/schema/core.schema
include		/etc/openldap/schema/cosine.schema
include		/etc/openldap/schema/inetorgperson.schema
include		/etc/openldap/schema/openldap.schema
include		/etc/openldap/schema/nis.schema

database	hdb
directory   	/srv/ldap/example.com/
suffix		"dc=example,dc=com"
rootdn		"cn=admin,dc=example,dc=com"
rootpw		secret

overlay		chain
chain-uri	ldap://master.example.com
chain-idassert-bind bindmethod=simple binddn="dc=example,dc=com"
credentials=secret mode=self
chain-tls start
chain-idassert-authzFrom "*"
"""

The resulting cn=config doesn't generate objects on the
olcDatabase={1}frontend database but rather the two following objects are
generated within olcOverlay={0}chain,olcDatabase={1}hdb,cn=config

olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config

"""
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 f3da9a85
dn: olcDatabase={0}ldap
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
structuralObjectClass: olcLDAPConfig
entryUUID: df7b759c-bb09-1032-82c9-adb6d4ef9266
creatorsName: cn=config
createTimestamp: 20130926151258Z
entryCSN: 20130926151258.900907Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20130926151258Z
"""	

olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config

"""
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 b7a21479
dn: olcDatabase={1}ldap
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {1}ldap
olcDbURI: "ldap://master.example.com";
olcDbStartTLS: start  starttls=no
olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical
bindm
 ethod=simple timeout=0 network-timeout=0 binddn="dc=example,dc=com"
credentials
 ="secret" keepalive
 =0:0:0
olcDbIDAssertAuthzFrom: *
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
structuralObjectClass: olcLDAPConfig
entryUUID: df7b7c90-bb09-1032-82ca-adb6d4ef9266
creatorsName: cn=config
createTimestamp: 20130926151258Z
entryCSN: 20130926151258.900907Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20130926151258Z
"""

The changes to relocate these objects to the olcDatabase{-1}fontend was in
response to the things I had read online.

-Russell J. Jancewicz
University of Connecticut

On 2013-09-26 13:02, "Quanah Gibson-Mount" <quanah@zimbra.com> wrote:

>--On Thursday, September 26, 2013 4:02 PM +0000 "Jancewicz, Russell"
><russell.jancewicz@uconn.edu> wrote:
>
>
>> dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
>> objectClass: olcOverlayConfig
>> objectClass: olcChainConfig
>> olcOverlay: {0}chain
>> olcChainCacheURI: FALSE
>> olcChainMaxReferralDepth: 1
>> olcChainReturnError: FALSE
>>
>>
>> dn:
>> olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
>> objectClass: olcLDAPConfig
>> objectClass: olcChainDatabase
>> olcDatabase: ldap
>> olcDbURI: "ldap://master.example.com";
>> olcDbStartTLS: start  starttls=no
>> olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical
>> bindmethod=simple timeout=0 network-timeout=0
>> binddn="cn=admin,dc=example,dc=com" credentials="<SECRET>"
>> keepalive=0:0:0
>> olcDbIDAssertAuthzFrom: *
>> 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
>
>This is not a valid conversion of slapd-chain2.conf from the test suite.
>How did you arrive at this config?
>
>--Quanah
>
>--
>
>Quanah Gibson-Mount
>Lead Engineer
>Zimbra Software, LLC
>--------------------
>Zimbra ::  the leader in open source messaging and collaboration

Follow-Ups:
- Re: cn=config chaining
  - From: Dieter KlÃnter <dieter@dkluenter.de>

References:
- Re: cn=config chaining
  - From: Quanah Gibson-Mount <quanah@zimbra.com>

Prev by Date: Re: cn=config chaining
Next by Date: Re: Other system use port 636 connect LDAP Server Error
Index(es):
- Chronological
- Thread