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

[SOLVED] Re: replication security (i)

ah yes i've done it now. thought i'd post my results in case any other ldap newbies have a similar problem. :-)

the problems with my setup stemmed from not setting up a dedicated replication account with access to the slave database. i had to create a replicator account and give that full access to the slave, removing the existing acls, ie.

access to *
  by dn="uid=replicator,ou=users,dc=my,dc=local" write
  by * read

my master server also had a 'syncrepl' entry (which i probably added in a moment of desperate frustration) and it wasn't needed in this case.

thank you everyone who helped me out!


 --- On Fri 11/11, John Halfpenny < jhalfpenny@excite.com > wrote:
From: John Halfpenny [mailto: jhalfpenny@excite.com]
To: bgmilne@staff.telkomsa.net
     Cc: openldap-software@OpenLDAP.org
Date: Fri, 11 Nov 2005 04:10:51 -0500 (EST)
Subject: Re: replication security (i)

<br>thanks for replying.<br><br>that makes sense. let me see if i have the logic right.<br><br>the reason my updates are being processed on the slave is because i'm not using a specific replication account as my updatedn. i am in fact using the manager dn, which explains why updates to it are being accepted when i connect directly to the slave with the manager's credentials.<br><br>presumably then i need to change my slave acls to allow only the replication account write access, which will force any update requests to be handed up to the master.<br><br>if that is right then the reason i confused the issue was to simply copy the config file from the master to the slave without setting separate acls on it.<br><br>john<br><br> --- On Thu 11/10, Buchan Milne < bgmilne@staff.telkomsa.net > wrote:<br>From: Buchan Milne [mailto: bgmilne@staff.telkomsa.net]<br>To: jhalfpenny@excite.com<br>     Cc: openldap-software@OpenLDAP.org<br>Date: Thu, 10 Nov 2005 19:03:45 +0200<br>Subject: Re: 
replication security (i)<br><br>On Thursday 10 November 2005 17:48, John Halfpenny wrote:<br>> hi quanah.<br>><br>> i've been using the oreilly book on ldap admin for a bit of guidance on<br>> this, but from what i can make out any changes i make to the slave stay<br>> there and aren't redirected to the master... (with readonly turned off that<br>> is)<br><br>If you have an 'updateref' directive for the database on the slave, a <br>non-replicadn client should get a referral to the value following the <br>directive. Usually, this should point to your master.<br><br>Whether the client will chase the referral or not is up to the client.<br><br>But, your slave should not be accepting any changes not made by the replicadn.<br><br>If you are using the rootdn for the replicadn, and making changes to the slave <br>from the rootdn, it will accept them.<br><br>The replicadn should not be used for *anything* but replication, which is why <br>you should not use the rootdn (which you may 
use for something <br>else).<br><br>> is it password related? does it make a difference which hashed password i<br>> use for the rootdn (ie. can i use the same SSHA coded password at both ends<br>> or do i have to generate them separately?)<br><br>Password hash is irrelevant.<br><br>Regards,<br>Buchan<br><br>-- <br>Buchan Milne<br>ISP Systems Specialist<br>B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)<br>Attachment: Attachment  (0.19KB)<br><br><br>_______________________________________________<br>Join Excite! - http://www.excite.com<br>The most personalized portal on the Web!<br>

Join Excite! - http://www.excite.com
The most personalized portal on the Web!