Re: SyncRepl - no write access

[Turbo Fredriksson <turbo@bayour.com>]

Quoting Quanah Gibson-Mount <quanah@stanford.edu>:

> updatedn="cn=Manager,dc=stanford,dc=edu"

What's this? Is this specified with 'root{dn,pw}' on
the provider? It exists (with 'userPassword: {xxx}')
in the DB? Can it be 'kerberized'?

I ask because no matter what I do, the consumer can't
update it's database (it tries to write as anonymous).


On the provider I kinit as 'ldap/provider' and then I start
the provider slapd, modify (as myself) an attribute in the
'o=Bortheiry,c=SE' object.

On the consumer I kinit as 'ldap/consumer-1'. After starting
the consumer slapd, I get the  following output (slapd w/ '-d 384'):

----- s n i p -----
=> access_allowed: write access to "o=Bortheiry,c=SE" "o" requested
=> dn: [2]
=> dn: [3]
=> dn: [4] cn=monitor
=> dn: [5] cn=subschema
=> acl_get: [6] attr o
=> acl_mask: access to entry "o=Bortheiry,c=SE", attr "o" requested
=> acl_mask: to all values by "", (=n)
<= check a_dn_pat: cn=ldap/provider,ou=ldap,ou=system,o=bayour.com,c=se
<= aci_mask grant =rsc deny =n
<= acl_mask: [3] applying +rsc (stop)
<= acl_mask: [3] mask: =rsc
=> access_allowed: write access denied by =rsc
syncrepl_entry : be_modify failed (50)
acl: no-user-mod syncreplCookie: modify access granted
acl: no-user-mod structuralObjectClass: modify access granted
acl: no-user-mod entryUUID: modify access granted
acl: no-user-mod creatorsName: modify access granted
acl: no-user-mod createTimestamp: modify access granted
acl: no-user-mod entryCSN: modify access granted
acl: no-user-mod modifiersName: modify access granted
acl: no-user-mod modifyTimestamp: modify access granted
----- s n i p -----

But just a few lines below this (and a few lines above), a _search_ access
works just as expected:

----- s n i p -----
=> access_allowed: search access to "o=Sundqvist,c=SE" "objectClass" requested
=> dn: [2]
=> dn: [3]
=> dn: [4] cn=monitor
=> dn: [5] cn=subschema
=> acl_get: [6] attr objectClass
=> acl_mask: access to entry "o=Sundqvist,c=SE", attr "objectClass" requested
=> acl_mask: to all values by "cn=ldap/provider,ou=ldap,ou=system,o=bayour.com,c=se", (=n)
<= check a_dn_pat: cn=ldap/provider,ou=ldap,ou=system,o=bayour.com,c=se
<= check a_authz.sai_sasl_ssf: ACL 56 > OP 0
<= aci_mask grant =rsc deny =n
<= acl_mask: [3] applying +rsc (stop)
<= acl_mask: [3] mask: =rsc
=> access_allowed: search access granted by =rsc
----- s n i p -----


I've been playing all day with ACL's, but that's "just for show".
It isn't authenticated when it tries to do the update, but authenticated
when it _doesn't_ try to update. Here's my ACL's etc (selected parts) if
I've done something 'obvious' fault:

PROVIDER
----- s n i p -----
sasl-regexp uid=(.*),cn=bayour.com,cn=gssapi,cn=auth
            ldap:///c=SE??sub?(krb5PrincipalName=$1@BAYOUR.COM)
include     <a href="http://www.bayour.com/slapd.access.txt";>/etc/ldap/slapd.access</a>
access to * by group.base="cn=Replicators,ou=LDAP,ou=System,o=Bayour.COM,c=SE" sasl_ssf=56 read
            by aci write
sessionlog  1 40
----- s n i p -----

CONSUMER
----- s n i p -----
sasl-regexp uid=(.*),cn=bayour.com,cn=gssapi,cn=auth
            ldap:///c=SE??sub?krb5PrincipalName=$1@BAYOUR.COM
include     <a href="http://www.bayour.com/slapd.access.txt";>/etc/ldap/slapd.access</a>
access to * by group.base="cn=Replicators,ou=LDAP,ou=System,o=Bayour.COM,c=SE" sasl_ssf=56 write
            by dn.exact="cn=ldap/provider,ou=LDAP,ou=System,o=Bayour.COM,c=SE" sasl_ssf=56 write
            by aci write
syncrepl    rid=1
            provider=ldaps://pumba.bayour.com
            type=refreshAndPersist
            searchbase="c=SE"
            filter="(objectClass=*)"
            scope=sub
            attrs="*"
            schemachecking=off
            updatedn="cn=ldap/provider,ou=LDAP,ou=System,o=Bayour.COM,c=SE"
            binddn="cn=ldap/consumer-1,ou=LDAP,ou=System,o=Bayour.COM,c=SE"
            bindmethod=sasl
            saslmech=GSSAPI
            realm=BAYOUR.COM
            authcId=ldap/consumer-1
updateref   ldaps://pumba.bayour.com
----- s n i p -----

I've verified that the sasl-regexp works as expected.

Before trying to start any of the slapd's, I regenerate
the database from scratch to make sure I have a known
state to work with.

I'm loading the LDIF with 'slapadd -p -w -i 1' on the
provider and 'slapadd -r -w -i 1' on the consumer.