8:07 p.m.
Hi.
I used the Delta-syncrepl configuration example from the admin guide
(http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl) to
create configuration files for a basic 1 Master, 1 Slave configuration.
With a populated & functional master, i started the slave and hit this
error...
slap_client_connect: URI=ldap://9.57.13.249:389
DN="cn=user.replicator,ou=people
,dc=exampleb,dc=com" ldap_sasl_bind_s failed (49)+
(The replicator DN couldn't bind.) In fact, i couldn't execute a basic
ldapsearch while binding as the replicator DN... kept getting "ldap_bind:
Invalid credentials (49)".
Long story short, the fix was to comment out the following ACL statements
in the master config file ... i could then bind as the replicator DN and
delta-syncrepl worked...
# Give the replica DN unlimited read access.
access to *
by dn.base="cn=user.replicator,ou=People,dc=exampleb,dc=com" read
by * break
I might be missing something... but based on my results, it seems like
those ACL statements aren't needed and actually prevented me from
delta-syncrepl'ing successfully. Wanted to pass along this info incase i'm
actually on to something... so you can fix the documentation if need be.
Thanks!
Master slapd.conf
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
pidfile /usr/local/var/run/slapd.pid
argsfile /usr/local/var/run/slapd.args
# Give the replica DN unlimited read access.
#access to *
# by dn.base="cn=user.replicator,ou=People,dc=exampleb,dc=com" read
# by * break
# Accesslog database definitions
database hdb
suffix cn=accesslog
directory /usr/local/var/openldap-data/db/accesslog
rootdn cn=accesslog
index default eq
index entryCSN,objectClass,reqEnd,reqResult,reqStart
overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE
# Let the replica DN have limitless searches
limits dn.exact="cn=user.replicator,ou=People,dc=exampleb,dc=com"
time.soft=unlimited time.hard=unlimited size.soft=unlimited
size.hard=unlimited
database hdb
suffix "dc=exampleb,dc=com"
rootdn "cn=kingb,dc=exampleb,dc=com"
rootpw pappie
directory /usr/local/var/openldap-data
index objectclass,entryCSN,entryUUID eq
overlay syncprov
syncprov-checkpoint 1000 60
# accesslog overlay definitions for primary db
overlay accesslog
logdb cn=accesslog
logops writes
logsuccess TRUE
# scan the accesslog DB every day, and purge entries older than 7 days
logpurge 07+00:00 01+00:00
# Let the replica DN have limitless searches
limits dn.exact="cn=user.replicator,ou=People,dc=exampleb,dc=com"
time.soft=unlimited time.hard=unlimited size.soft=unlimited
size.hard=unlimited
Slave slapd.conf
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
pidfile /usr/local/var/run/slapd.pid
argsfile /usr/local/var/run/slapd.args
database hdb
suffix "dc=exampleb,dc=com"
rootdn "cn=kingb,dc=exampleb,dc=com"
rootpw pappie
directory /usr/local/var/openldap-data
index entryUUID eq
# syncrepl directives
syncrepl rid=0
provider=ldap://(my_ip_address):389
bindmethod=simple
binddn="cn=user.replicator,ou=People,dc=exampleb,dc=com"
credentials=metsrbad
searchbase="dc=exampleb,dc=com"
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=on
type=refreshAndPersist
retry="60 +"
syncdata=accesslog
# Refer updates to the master
updateref ldap://(my_ip_address):389
12:54 a.m.
Brad T Waldorf wrote:
Hi.
I used the Delta-syncrepl configuration example from the admin guide
(http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl) to
create configuration files for a basic 1 Master, 1 Slave configuration.
With a populated & functional master, i started the slave and hit this
error...
slap_client_connect: URI=ldap://9.57.13.249:389
DN="cn=user.replicator,ou=people
,dc=exampleb,dc=com" ldap_sasl_bind_s failed (49)+
(The replicator DN couldn't bind.) In fact, i couldn't execute a basic
ldapsearch while binding as the replicator DN... kept getting "ldap_bind:
Invalid credentials (49)".
Long story short, the fix was to comment out the following ACL statements
in the master config file ... i could then bind as the replicator DN and
delta-syncrepl worked...
# Give the replica DN unlimited read access.
access to *
by dn.base="cn=user.replicator,ou=People,dc=exampleb,dc=com" read
by * break
You ACLs are obviously wrong. The above piece of ACL is intended to
exist along with other rules, otherwise it's useless by itself. In
fact, in order to check an identity, anonymous must be able to bind, and
thus needs auth permission. Posting your hack like it were the solution
to a problem is only going to create further confusion in those who
didn't understand the ACL model yet.
A minimal ACL design that allows essential operations including
replication would need:
- let everyone try to auth
- let replication identity read everthing that needs to be replicated
- let others read/write what they are allowed to read
so:
access to attrs=userPassword
by <replication identity> read
by * auth
access to <something else>
by <replication identity> read
by <others> <as appropriate>
# catchall for what's left
access to *
by <replication identity> read
As you may see, you need to repeat the "by <replication identity> read"
snippet all times. So a shortcut is:
access to *
by <replication identity> read
by * break
access to attrs=userPassword
by * auth
access to <something else>
by <others> <as appropriate>
which means: replication identity can read everything, others don't gain
any privilege; but don't stop evaluating rules, step to the next one for
further permission.
If you don't understand this, please don't try to teach others how ACLs
need to be configured to have replication work as intended. You removed
from your example the comment "This ACL may need to be merged with other
ACL statements."
<http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl>
(that statement probably needs to be strenghtened, replacing "may" with
"must").
Probably this was not your intention, but the consequence is that
googling up "openldap delta-syncrepl access" will likely hit your
message and propagate false information.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
6 p.m.
wow. My intention certainly wasn't to insist that my "hack" was the
absolute solution. Just saying what seemed to work for me... trying to
give ldap admins some information that i thought might lead to a possible
documentation fix. Guess i was wrong. Sorry, just trying to help.
And i definitely wasn't trying to teach others how ACLs need to be
configured. In my email i said stuff like "I might be missing something",
"incase i'm actually on to something", and "fix the documentation if
need
be". These are not the phrases used by someone who's confident with their
"hack" or trying to teach others about ACLs... (to me anyway).
I understand your sentiment about misleading others with false fixes...
next time i'll add a specific question to the end, such as "what am i
missing?", or "what have i done wrong?"... so that the thread seems
unresolved and give more chance that googler's will read the follow-up
thread.
Anyway, thanks for your thorough ACL information... good stuff. I would
definitely recommend replacing "may need to" with "must" in the
following
statement, as you suggested. "This ACL may need to be merged with other
ACL statements."
~~~~~~~~~~~~~~~~~~~~~~~~~~
TPF Test and Information Development
(845) 433-8129
bwaldorf(a)us.ibm.com
"Hey! Lama! Hey! How about a little something, you know, for the effort,
you know?"
Pierangelo
Masarati
<ando(a)sys-net.it> To
Brad T
10/04/2008 03:54 Waldorf/Poughkeepsie/IBM@IBMUS
AM cc
openldap-technical(a)openldap.org
Subject
Re: Incorrect snippet in
delta-syncrepl example in admin
guide?
Brad T Waldorf wrote:
Hi.
I used the Delta-syncrepl configuration example from the admin guide
(http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl) to
create configuration files for a basic 1 Master, 1 Slave configuration.
With a populated & functional master, i started the slave and hit this
error...
slap_client_connect: URI=ldap://9.57.13.249:389
DN="cn=user.replicator,ou=people
,dc=exampleb,dc=com" ldap_sasl_bind_s failed (49)+
(The replicator DN couldn't bind.) In fact, i couldn't execute a basic
ldapsearch while binding as the replicator DN... kept getting "ldap_bind:
Invalid credentials (49)".
Long story short, the fix was to comment out the following ACL statements
in the master config file ... i could then bind as the replicator DN and
delta-syncrepl worked...
# Give the replica DN unlimited read access.
access to *
by dn.base="cn=user.replicator,ou=People,dc=exampleb,dc=com" read
by * break
You ACLs are obviously wrong. The above piece of ACL is intended to
exist along with other rules, otherwise it's useless by itself. In
fact, in order to check an identity, anonymous must be able to bind, and
thus needs auth permission. Posting your hack like it were the solution
to a problem is only going to create further confusion in those who
didn't understand the ACL model yet.
A minimal ACL design that allows essential operations including
replication would need:
- let everyone try to auth
- let replication identity read everthing that needs to be replicated
- let others read/write what they are allowed to read
so:
access to attrs=userPassword
by <replication identity> read
by * auth
access to <something else>
by <replication identity> read
by <others> <as appropriate>
# catchall for what's left
access to *
by <replication identity> read
As you may see, you need to repeat the "by <replication identity> read"
snippet all times. So a shortcut is:
access to *
by <replication identity> read
by * break
access to attrs=userPassword
by * auth
access to <something else>
by <others> <as appropriate>
which means: replication identity can read everything, others don't gain
any privilege; but don't stop evaluating rules, step to the next one for
further permission.
If you don't understand this, please don't try to teach others how ACLs
need to be configured to have replication work as intended. You removed
from your example the comment "This ACL may need to be merged with other
ACL statements."
<http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl>
(that statement probably needs to be strenghtened, replacing "may" with
"must").
Probably this was not your intention, but the consequence is that
googling up "openldap delta-syncrepl access" will likely hit your
message and propagate false information.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
10:59 a.m.
Brad T Waldorf wrote:
I would
definitely recommend replacing "may need to" with "must" in the
following
statement, as you suggested. "This ACL may need to be merged with other
ACL statements."
Probably, that whole example should be removed, as it belongs to access
control rather than to replication.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
5233
days inactive
5234
days old
openldap-technical@openldap.org
3 comments
2 participants
participants (2)
-
Brad T Waldorf -
Pierangelo Masarati