[Date Prev][Date Next]
Re: Question on updatedn
- To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Subject: Re: Question on updatedn
- From: Krishna Sivaramapuram <firstname.lastname@example.org>
- Date: Thu, 02 Feb 2006 13:17:06 -0800
- Cc: openldap-software@OpenLDAP.org
- In-reply-to: <184.108.40.206.0.20060130144100.0222d3c8@OpenLDAP.org>
- References: <01LYDPB0BXFU8WWS4B@psulias.psu.edu> <43DE80EF.email@example.com> <43DE89A1.firstname.lastname@example.org> <220.127.116.11.0.20060130144100.0222d3c8@OpenLDAP.org>
- User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
The rootdn's of the master and the slave are given the same name in my
config. I was using a different dn other than the rootdn as the updatedn
in the slave and I have setup the following access control on the slave
to allow only the master's ip bind in to the node.
access to dn.base="organizationalStatus=repNode,dc=com"
by peername.ip=192.168.0.5 auth
access to dn.subtree="organizationalStatus=users,dc=com"
by peername.ip=192.168.0.5 write
by * read
And in the master I have the following...
When I tried to write any node below
"organizationalStatus=users,dc=com", it did work for a while even though
repNode is not the rootdn in the slave. Suddenly it doesn't work anymore
and slurpd is saying it has invalid credentials. What slurpd is saying
sounds correct since repNode is not the rootdn on the slave.
Now, how do I say that the dn "organizationalStatus=repNode,dc=com"
should also allow simple authentication with passwd as secret? Or how do
I get this to work?
Kurt D. Zeilenga wrote:
At 01:48 PM 1/30/2006, Krishna Sivaramapuram wrote:
I read that giving the updatedn the same permissions as the rootdn is not a good idea. I understand this is for ACL reasons.
Not sure exactly what text you are referring here, but what OpenLDAP
documentation commonly says is that the updatedn of a slave should
not be set to the rootdn of the master. The reason has nothing to
do with access controls/permissions, but to ensure proper return
of update referrals when accessed by the directory manager who
has the DN of the master's rootdn.
You can certainly set the rootdn of the slave to the updatedn
of the slave as long as it differs from the rootdn of the master.
But it generally recommended that you use ACLs instead to
grant necessary access to the updatedn.
Personally, I prefer to avoid setting a rootdn on all servers,
instead opting to grant necessary access via ACLs.