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

Logged in as guest

Viewing Incoming/7434
Full headers

From: blance3459@hotmail.com
Subject: idassert-bind fails after restarting slapd
Compose comment
Download message
State:
0 replies:
7 followups: 1 2 3 4 5 6 7

Major security issue: yes  no

Notes:

Notification:


Date: Fri, 09 Nov 2012 01:55:31 +0000
From: blance3459@hotmail.com
To: openldap-its@OpenLDAP.org
Subject: idassert-bind fails after restarting slapd
Full_Name: Barry Lance
Version: 2.4.28
OS: Ubuntu 12.04
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (70.226.37.226)


Two servers: Master (192.168.1.1) and Replica (192.168.1.2) both running slap
2.4.28 and ubuntu 12.04.  Replica is a replication partner of Master using
syncrepl.  Replication is working fine.  When I attempt to add a chain overlay
to Replica to send all writes over to the master, it works exactly as expected
allowing both normal users and the rootdn to make appropriate changes.  However,
once I either reboot the replica server or restart slapd, the chain overlay
fails to allow any changes on the master.  Looking at syslog shows that before
the reboot/restart the requesting users' dn is proxied over as expected.  After
the restarting slapd or rebooting Replica, all changes are proxied anonymously
(dn="").

I am using simple binds at this point in the project, but it doesn't seems to
matter if I proxy in the clear, ldaps, or TLS the result is the same.  All three
methods can successfully negotiate a connection.  I've even tried switching
between using the rootdn and a different user as the binddn in my overlay, but
the result is still the same no matter what I use for the binddn.  When I look
at my config, I notice that "chain-idassert-bind"  appears to be hashed or
encrypted in thew config.  Is that normal?  Just seems really odd that my config
would work immediately when added, but fail after the the daemon has been
restarted.  Am I missing something really silly?  Hopefully, someone can assist
me on this.  I've been driving myself crazy trying to figure out why this
behavior is occurring.  

Disclaimer: I am using openldap as part of my capstone project for graduation. 
I'm not asking for anyone to do my "homework" for me, I'm just stuck on this one
issue that I would love to resolve so I can move on to the Kerberos phase of my
project (and maybe even study for an exam coming up in my algorithms class next
week).  

Here is my overlay config using the rootDN and TLS (on Replica):

dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend, cn=config
changetype: add
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {0}ldap
olcDbURI: "ldap://master.example.net/"
olcDbRebindAsUser: TRUE
olcDbIDAssertBind: bindmethod=simple 
 binddn="cn=admin,dc=example,dc=net" 
 credentials=(secret) 
 mode=self 
 starttls=critical 
 tls_cacert=/etc/ssl/certs/cacert.pem 
 tls_reqcert=demand 

And without TLS (also on Replica):

dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend, cn=config
changetype: add
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {0}ldap
olcDbURI: "ldap://master.example.net/"
olcDbRebindAsUser: TRUE
olcDbIDAssertBind: bindmethod=simple 
 binddn="cn=admin,dc=example,dc=net" 
 credentials=(secret)
 mode=self 

Followup 1

Download message
Date: Thu, 08 Nov 2012 18:09:49 -0800
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: blance3459@hotmail.com, openldap-its@openldap.org
Subject: Re: (ITS#7434) idassert-bind fails after restarting slapd
--On Friday, November 09, 2012 1:55 AM +0000 blance3459@hotmail.com wrote:

> Full_Name: Barry Lance
> Version: 2.4.28
> OS: Ubuntu 12.04
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (70.226.37.226)
>

Hi Barry,

Thanks for the report.  I would note that OpenLDAP 2.4.28 is 5 releases old 
at this point.  I don't see anything specific in the CHANGES file between 
2.4.28 and 2.4.33 for this issue, but it may be fixed and not logged in 
there.  Confirming that the behavior persists with 2.4.33 would be helpful.

Also, don't confuse encoding with encryption. ;)  It is standard in LDIF 
for data to be base64 encoded if the attribute value requires it based on 
the characters in the data.  You can use various tools to decode the 
attribute value back out.

Regards,
Quanah


--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration



Followup 2

Download message
Date: Thu, 08 Nov 2012 18:45:53 -0800
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: openldap-its@openldap.org, blance3459@hotmail.com
Subject: Re: (ITS#7434) idassert-bind fails after restarting slapd
--On Friday, November 09, 2012 2:10 AM +0000 quanah@zimbra.com wrote:

> --On Friday, November 09, 2012 1:55 AM +0000 blance3459@hotmail.com wrote:
>
>> Full_Name: Barry Lance
>> Version: 2.4.28
>> OS: Ubuntu 12.04
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (70.226.37.226)
>>
>
> Hi Barry,

Hi Barry,

Are you sure you aren't hitting:

	Fixed slapd-ldap idassert bind handling (ITS#7403)

Fixed in OpenLDAP 2.4.33?

--Quanah


--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration



Followup 3

Download message
From: Barry Lance <blance3459@hotmail.com>
To: "openldap-its@OpenLDAP.org" <openldap-its@openldap.org>
Subject: RE: (ITS#7434) idassert-bind fails after restarting slapd
Date: Tue, 4 Dec 2012 11:36:24 -0500
--_e0f270ad-e1a3-48b6-986f-f9f11dfd57c0_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Quanah=2C=20
=20
I finally got back around to working on this over the last couple of days. =
 Where I'm at with my project is: I have two servers (virtual machines)=2C =
named master and replica=2C  with slapd configured with my directory inform=
ation and single-master replication between them. =20
 I created a Kerberos realm and various principals in open ldap. =20
 Replication access is authenticated using sasl/gssapi with the slapd princ=
ipal=2C ldap/replica.example.net. =20
 k5start has been added to system startup to buid the credential cache for =
slapd.
 =20
 That brings me to configuring referrals and proxyAuth on replica.  What ap=
pears to be happening is that at the initial configuration (before restarti=
ng the daemon) is the client binds to the replica and authenticates with it=
s kerberos ticket.  The "magic" is performed on the sasl user
and the ldap directory entry is returned.  It then proceeds into the modifi=
cation and notices the update referral.  It then checks to determine if the=
 binddn used in  in the olcDbIDAssertBind
statems can authzTo the bound user.  It can and the proxy of the modificati=
on proceeds.  On the master=2C the proxy request is received=2C more "magic=
" is done on the user id to make sure it is in=20
the correct form=2C the authzTo attribute is again checked and allowed.  Th=
e update is performed as the user=2C and success is returned back through t=
he chain to the user.  This is how I would expect=20
the process to proceed.  However=2C if I restart the server (or slapd daemo=
n)=2C this behavior changes.  After restarting=2C the bind occurs at the re=
plica=2C does "magic"=2C and then sees the referral and attempts the proxy.=
  What's notable here is that the check of authzTo is NOT performed.
The refereal is then chased=2C but the authzTo check was never made.  Since=
 there is no user to "authzTo"=2C does the referral get chased with perhaps=
 a "null" or anonymous user?
Whatever the case=2C it appears the the original binding user is never sent=
 over the proxy.  Over at the master=2C I see the bind request come on from=
 the replica which is treated as an anonymous bind request.
No magic=2C no authzTo check=2C no nothing.  It then goes straight into the=
 modification and tries to perform=2C but is blocked due to the bound user =
being anonymous and the stronger authentication error (8) is returned. =20
Given that the bind occured anonymously=2C I feel that error is expected an=
d wanted.
=20
I had been trying to use sasl binding here=2C but was not having the same s=
ucess that I had with syncrepl.  In order to only fight one battle at a tim=
e=2C I changed by proxy config to use a simple bind instead of sasl/gssapi.=
 =20
=20
Referrals and proxy authentication are configured on replica with the follo=
wing ldif.  I tried setting the override flag because the man page makes it=
 sound like it forces the authzTo check at bind time.
By doing that I was hoping I could force the check and see the authzTo proc=
ess in my logs.  Is this what the ITS you mentions is referring to?=20
dn: olcDatabase=3D{1}hdb=2Ccn=3Dconfig
 changetype: modify
 add: olcUpdateref
 olcUpdateref: "ldap://master.example.net:389/"
 =20
 dn: cn=3Dmodule{0}=2Ccn=3Dconfig
 changetype: modify
 add: olcModuleLoad
 olcModuleLoad: {1}back_ldap
 =20
 dn: olcOverlay=3Dchain=2ColcDatabase=3D{-1}frontend=2Ccn=3Dconfig
 changetype: add
 objectClass: olcOverlayConfig
 objectClass: olcChainConfig
 olcOverlay: {0}chain
 olcChainReturnError: TRUE
 =20
 dn: olcDatabase=3Dldap=2ColcOverlay=3D{0}chain=2ColcDatabase=3D{-1}fronten=
d=2Ccn=3Dconfig
 changetype: add
 objectClass: olcLDAPConfig
 objectClass: olcChainDatabase
 olcDatabase: {0}ldap
 olcDbURI: "ldap://master.example.net:389/"
 olcDbRebindAsUser: TRUE
 olcDbIDAssertBind: bindmethod=3Dsimple
   binddn=3D"cn=3Dreplica=2Cou=3Dhosts=2Cdc=3Dexample=2Cdc=3Dnet"
   credentials=3Dshhh-secret
   mode=3Dself
   flags=3Doverride
   starttls=3Dcritical
   tls_reqcert=3Ddemand
   tls_cacert=3D/etc/ssl/certs/cacert.pem =20
 =20
After adding that information via ldapmodify=2C I attempt to perform an upd=
ate on the replica.  For testing=2C i simply change the description attribu=
te for uid=3Dadministrator=2Cou=3Dpeople=2Cdc=3Dexample=2Cdc=3Dnet.  I'm us=
ing this simple ldif to test with:
  dn: uid=3Dadministrator=2Cou=3Dpeople=2Cdc=3Dexample=2Cdc=3Dnet
 changetype: modify
 replace: description
 description: Network Administrator
Initially after configuring the proxy and obtainng a kerberos ticket for th=
e account (administrator=2C self write)=2C this update succeeds.  Looking a=
t syslog on replica=2C I see happiness.  The ldap modify binds using gssapi=
=2C I see SASL name being correctly converted to uid=3Dadministrator=2Cou=
=3Dpeople=2Cdc=3Dexample=2Cdc=3Dnet.
  Dec  3 22:17:01 replica slapd[994]: SASL Canonicalize [conn

Message of length 243872 truncated


Followup 4

Download message
Date: Wed, 09 Jan 2013 13:06:22 -0800
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: blance3459@hotmail.com, openldap-its@openldap.org
Subject: RE: (ITS#7434) idassert-bind fails after restarting slapd
--On Tuesday, December 04, 2012 4:37 PM +0000 blance3459@hotmail.com wrote:

> --_e0f270ad-e1a3-48b6-986f-f9f11dfd57c0_
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Quanah=2C=20
> =20
> I finally got back around to working on this over the last couple of
> days. =  Where I'm at with my project is: I have two servers (virtual
> machines)=2C = named master and replica=2C  with slapd configured with my
> directory inform= ation and single-master replication between them. =20
>  I created a Kerberos realm and various principals in open ldap. =20
>  Replication access is authenticated using sasl/gssapi with the slapd
> princ= ipal=2C ldap/replica.example.net. =20
>  k5start has been added to system startup to buid the credential cache
> for = slapd.

Hi Barry,

Two things: Please use an email client that can create emails that are 
readable, instead of whatever it is you're doing now. ;)

Second, you never answered about trying a current release of OpenLDAP.  I 
pointed out two bits that may have resulted in your situation being fixed.

Thanks,
Quanah


--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration



Followup 5

Download message
From: Barry Lance <blance3459@hotmail.com>
To: "openldap-its@openldap.org" <openldap-its@openldap.org>
Subject: ITS#7434
Date: Thu, 10 Jan 2013 16:35:38 -0500
--_2dfc1396-6cab-4ee1-b5cd-ec8dfb5286a7_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Quanah=2C  Trying to post a reply using my hotmail account.  Sorry for the =
unreadable output previously posted.  I'm almost embarassed to say I've bee=
n involved in IT for over 15 years and never used a mailing list before. An=
yhow=2C I did download the source packages and compiled them.  However=2C t=
he semester was winding down and I was under a lot of pressure to have some=
thing completed before the end of finals week so my professor could assgn m=
e a grade for the work I had done.  I revered back to my previous version t=
o to get some stuff written.  Not to mention=2C my algorithms professor was=
 kicking my butt too. Wil I ever "really" need an FFT in the real world?  l=
ol The more I looked at what I was trying to accomplish=2C I realized I was=
 attaking the problem all wrong.  What I was being asked to do was somethin=
g more like configuring my two slapd servers to act more like Active Direct=
ory global catalog servers. GC's utilitze MM instead of  single master repl=
ication so I scrapped the SM replication design in favor of MM.  Once this =
was done=2C I no longer needed the chaining overlay or proxy auth.  I now h=
ave MM replication of both cn=3Dconfig and my directory data (with delta) w=
orking and my Kerberos KDC's are happy. One thing I did find was that confi=
guring MM replication made me learn a little more about how to "properly" n=
ame/configure an overlay with the syncprov and accesslog modules by digging=
 into the test scripts.   I had some issues with sync state on the consumer=
s =2C but I found a post you made to someone else a few years back that sol=
ved my delta replication issue by configuring an syncprov overlay on the ac=
cesslog db.  Not sure I remember seeing that in the Admin Guide. Looking ba=
ck at the orignal post I noticed the chain overlay I had configured was dn:=
 olcDatabase=3Dldap=2ColcOverlay=3D{0}chain=2ColcDatabase=3D{-1}frontend=2C=
 cn=3Dconfig.  knowing what I know now=2C I'm not 100% sure that was correc=
t.  Shouldn't that overlay have been in either config database of my direct=
ory  or ldap backend database for the chain rather than a "frontend"?  Just=
 a thought I've been kicking around in my head. Either way=2C I have my lda=
p config working.  We can either close this issue if you'd like or leave it=
 open and I'll attempt to confirm my theory on the overlay not being proper=
ly located when I get a chance.   Completely your choice.
But I do have a couple questions on my MM replication of cn=3Dconfig if you=
 want to take them.  First=2C does it make sense or is it possible to do de=
lta replication on cn=3Dconfig?  The data "on the wire" seems like it would=
 be much smaller and less frequent than directory data so perhaps it's not =
as beneficial?   Secondly=2C I am using a simple bind with this replication=
 agreement (versus sasl/gssapi and tls for my directoiry data).  When confi=
guring limits and acl's for replication of my dit=2C I created a groupofnam=
es (cn=3Dreplicators=2C ou=3Dgroups=2C dc=3Dexample=2Cdc=3Dnet) that has ea=
ch ldap server as a member.  My thought process was that this made the solu=
tion a bit more scalable.  As ldap servers were added to the topology=2C th=
ey could be added to the group of names and automtically be given the corre=
ct permissions an limits.  Likewise=2C as server are decomisioned=2C they c=
ould easily be removed by deleteing them from the group and directory.   Ca=
n I use this same group of names in cn=3Dconfig replication by creating a s=
imilar limit and acl using this group of names?  Since I am handling the fo=
rmatting of the gssapi uid in cn=3Dconfig (maybe a mistake if I ever wanted=
 to be able to handle multiple directories/domains)=2C can I use the gssapi=
 authtication of hosts in dc=3Dexample=2Cdc=3Dnet?  Seems I sould be able t=
o since it appears that when the authorization occurs in the database=2C th=
e bind id is assumed to be already authenticated and accepted as presented =
with no further authentication taking place.  I'm thinking that so long as =
that uid is formatted into a dn listed in an acl=2C the matching access is =
applied?  Am I way off base in my thinking?  Now that I have a rough workab=
le solution I'm just trying to pretty it up a bit and make the design more =
efficient and scalable. Thanks Barry  		 	   		  =

--_2dfc1396-6cab-4ee1-b5cd-ec8dfb5286a7_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 12pt=3B
font-family:Calibri
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'>Quanah=2C
<BR>&nbsp=3B<BR>Trying=
 to post a reply using my hotmail account.&nbsp=3B Sorry for the unreadable=
 output previously pos

Message of length 10062 truncated


Followup 6

Download message
Date: Thu, 10 Jan 2013 20:28:53 -0500
From: Barry Lance <blance3459@hotmail.com>
To: openldap-its@openldap.org
Subject: RE: (ITS#7434) idassert-bind fails after restarting slapd

Okay, trying again with Thunderbird since Hotmail is determined only to send
in HTML format...

Quanah,

Trying to post a reply using my Hotmail account.  Sorry for the
unreadable output previously posted.  I'm almost embarrassed to say I've
been involved in IT for over 15 years and never used a mailing list before.

Anyhow, I did download the source packages and compiled them. However,
the semester was winding down and I was under a lot of pressure to have
something completed before the end of finals week so my professor could
assign me a grade for the work I had done.  I revered back to my
previous version to to get some stuff written. Not to mention, my
algorithms professor was kicking my butt too. Will I ever "really" need
an FFT in the real world?  lol

The more I looked at what I was trying to accomplish, I realized I was
attacking the problem all wrong.  What I was being asked to do was
something more like configuring my two slapd servers to act more like
Active Directory global catalog servers. GC's utilize MM instead of
single master replication so I scrapped the SM replication design in
favor of MM.  Once this was done, I no longer needed the chaining
overlay or proxy auth.  I now have MM replication of both cn=config and
my directory data (with delta) working and my Kerberos KDC's are happy.

One thing I did find was that configuring MM replication made me learn a
little more about how to "properly" name/configure an overlay with the
syncprov and accesslog modules by digging into the test scripts.   I had
some issues with sync state on the consumers , but I found a post you
made to someone else a few years back that solved my delta replication
issue by configuring an syncprov overlay on the accesslog db.  Not sure
I remember seeing that in the Admin Guide.

Looking back at the original post I noticed the chain overlay I had
configured was dn:
olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,
cn=config.  knowing what I know now, I'm not 100% sure that was
correct.  Shouldn't that overlay have been in either config database of
my directory  or ldap backend database for the chain rather than a
"frontend"?  Just a thought I've been kicking around in my head.

Either way, I have my ldap config working.  We can either close this
issue if you'd like or leave it open and I'll attempt to confirm my
theory on the overlay not being properly located when I get a chance.
Completely your choice.

But I do have a couple questions on my MM replication of cn=config if
you want to take them.  First, does it make sense or is it possible to
do delta replication on cn=config?  The data "on the wire" seems like it
would be much smaller and less frequent than directory data so perhaps
it's not as beneficial?   Secondly, I am using a simple bind with this
replication agreement (versus sasl/gssapi and tls for my directory
data).  When configuring limits and acl's for replication of my dit, I
created a groupofnames (cn=replicators, ou=groups, dc=example,dc=net)
that has each ldap server as a member.  My thought process was that this
made the solution a bit more scalable.  As ldap servers were added to
the topology, they could be added to the group of names and
automatically be given the correct permissions an limits.  Likewise, as
server are decommissioned, they could easily be removed by deleting them
from the group and directory.   Can I use this same group of names in
cn=config replication by creating a similar limit and acl using this
group of names?  Since I am handling the formatting of the gssapi uid in
cn=config (maybe a mistake if I ever wanted to be able to handle
multiple directories/domains), can I use the gssapi authentication of
hosts in dc=example,dc=net?  Seems I should be able to since it appears
that when the authorization occurs in the database, the bind id is
assumed to be already authenticated and accepted as presented with no
further authentication taking place.  I'm thinking that so long as that
uid is formatted into a db listed in an acl, the matching access is
applied?  Am I way off base in my thinking?  Now that I have a rough
workable solution I'm just trying to pretty it up a bit and make the
design more efficient and scalable.

Thanks

Barry





Followup 7

Download message
Date: Sat, 07 Sep 2013 09:53:41 -0700
From: Howard Chu <hyc@symas.com>
To: blance3459@hotmail.com, openldap-its@openldap.org
Subject: Re: (ITS#7434) idassert-bind fails after restarting slapd
blance3459@hotmail.com wrote:
> Full_Name: Barry Lance
> Version: 2.4.28
> OS: Ubuntu 12.04
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (70.226.37.226)

It appears the submitter found an alternate solution, but just for future 
reference this issue was the same as ITS#7381, now fixed in git master.
>
> Two servers: Master (192.168.1.1) and Replica (192.168.1.2) both running
slap
> 2.4.28 and ubuntu 12.04.  Replica is a replication partner of Master using
> syncrepl.  Replication is working fine.  When I attempt to add a chain
overlay
> to Replica to send all writes over to the master, it works exactly as
expected
> allowing both normal users and the rootdn to make appropriate changes. 
However,
> once I either reboot the replica server or restart slapd, the chain overlay
> fails to allow any changes on the master.  Looking at syslog shows that
before
> the reboot/restart the requesting users' dn is proxied over as expected. 
After
> the restarting slapd or rebooting Replica, all changes are proxied
anonymously
> (dn="").
>
> I am using simple binds at this point in the project, but it doesn't seems
to
> matter if I proxy in the clear, ldaps, or TLS the result is the same.  All
three
> methods can successfully negotiate a connection.  I've even tried switching
> between using the rootdn and a different user as the binddn in my overlay,
but
> the result is still the same no matter what I use for the binddn.  When I
look
> at my config, I notice that "chain-idassert-bind"  appears to be hashed or
> encrypted in thew config.  Is that normal?  Just seems really odd that my
config
> would work immediately when added, but fail after the the daemon has been
> restarted.  Am I missing something really silly?  Hopefully, someone can
assist
> me on this.  I've been driving myself crazy trying to figure out why this
> behavior is occurring.
>
> Disclaimer: I am using openldap as part of my capstone project for
graduation.
> I'm not asking for anyone to do my "homework" for me, I'm just stuck on
this one
> issue that I would love to resolve so I can move on to the Kerberos phase
of my
> project (and maybe even study for an exam coming up in my algorithms class
next
> week).
>
> Here is my overlay config using the rootDN and TLS (on Replica):
>
> dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,
cn=config
> changetype: add
> objectClass: olcLDAPConfig
> objectClass: olcChainDatabase
> olcDatabase: {0}ldap
> olcDbURI: "ldap://master.example.net/"
> olcDbRebindAsUser: TRUE
> olcDbIDAssertBind: bindmethod=simple
>   binddn="cn=admin,dc=example,dc=net"
>   credentials=(secret)
>   mode=self
>   starttls=critical
>   tls_cacert=/etc/ssl/certs/cacert.pem
>   tls_reqcert=demand
>
> And without TLS (also on Replica):
>
> dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,
cn=config
> changetype: add
> objectClass: olcLDAPConfig
> objectClass: olcChainDatabase
> olcDatabase: {0}ldap
> olcDbURI: "ldap://master.example.net/"
> olcDbRebindAsUser: TRUE
> olcDbIDAssertBind: bindmethod=simple
>   binddn="cn=admin,dc=example,dc=net"
>   credentials=(secret)
>   mode=self
>
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/


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