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
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@sys-net.it -----------------------------------
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@us.ibm.com
"Hey! Lama! Hey! How about a little something, you know, for the effort, you know?"
Pierangelo Masarati ando@sys-net.it To Brad T 10/04/2008 03:54 Waldorf/Poughkeepsie/IBM@IBMUS AM cc openldap-technical@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@sys-net.it -----------------------------------
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@sys-net.it -----------------------------------
openldap-technical@openldap.org
-
Brad T Waldorf -
Pierangelo Masarati