backend provision samba4-ol-multimaster

Oliver Liebel oliver at
Sat Sep 6 16:40:07 GMT 2008

Andrew Bartlett schrieb:
> On Fri, 2008-09-05 at 10:37 +0200, Oliver Liebel wrote:
>> e.g.  rid=serverid*100  instead of ...*10
> Sure, but then we have a maximum of 9 replicating servers, which seemed
> like rather a low limit.   
sorry, youre right - i missed that point, was just looking at the 

but there is another point to mention: we should add the "sizelimit 
unlimited"  ( or just  a value greater 552  [cn=schema] )
to slapd.conf-template again, otherwise we are running into trouble 
during initial content cload on the secondary dcs.

> Yep, we need a separate account, but I can't see a good way to move away
> from cleartext passwords.  
> ...
> No, we cannot use GSSAPI.  We must use something like DIGEST-MD5 because
> we are creating the backend for the KDC, so we can't use kerberos to do
> it :-)
okay, if we would use digest-md5, what do you think about the following 

we create the cn=replicator account in the same way, cn=samba-admin is
created (under cn=samba, so we can use the same authz-regexp mappings). 
we can use the --adminpass
given during provisioning (or use another pass, maybe 
"--replicator-pass=..." ) .
i have tested the following setup (using --adminpass), and its working:

...setup/cn=replicator.ldif:  (except dn/cn/entryCSN  identical to 
dn: cn=replicator
objectClass: top
objectClass: person
cn: replicator
userPassword:: ${LDAPADMINPASS_B64}
structuralObjectClass: person
entryUUID: ${UUID}
createTimestamp: ${LDAPTIME}
entryCSN: 20080714010529.241039Z#000000#000#000000
modifyTimestamp: ${LDAPTIME}

syncrepl section:
syncrepl rid=<rid>

acl section:
access to dn.subtree="DC=ldap,DC=local,DC=site"
     by dn=cn=samba-admin,cn=samba manage
     by dn=cn=replicator,cn=samba read
     by dn=cn=manager manage
     by * none
                           os.path.join(paths.ldapdir, "db", "samba",  
"cn=samba", "cn=samba-admin.ldif"),
                            os.path.join(paths.ldapdir, "db", "samba",  
"cn=samba", "cn=replicator.ldif"),
                            {"LDAPADMINPASS_B64": b64encode(adminpass),
                             "UUID": str(uuid.uuid4()),
                             "LDAPTIME": timestring(int(time.time()))} )

slapd-logs shows me that everythings working fine during sasl-bind:

 >>> SASL Authorize [conn=2]:  proxy authorization allowed authzDN=""
 >>> send_ldap_sasl: err=0 len=40
 >>> do_bind: SASL/DIGEST-MD5 bind: dn="cn=replicator,cn=samba" 

and replication itself is working fine.

as there is no need for rootpws for the subcontexts now
(which surely also can be kept there  - maybe for debugging issues,
using pre-crypted slappasswd-ssha-values),
the only thing remaining in cleartext are the authcid and credentials in 
syncrepl-config, but as
the replicator-account has only ro-privileges on the dit,
its not that bad, even if someone could catch a look on the config...

another option could be (with the advantage of having no passwords at 
all in slapd.conf / slapd.d/ )
to use mech external, but in that case we would have to setup
the ca and all host-certs during provisioning, maybe using a fixed 
cert-dn, e.g. cn=<hostname>,cn=samba4dc,dc=<names.domaindn>
or something like that.
but as we have to setup tls for replication anyway, maybe its worth a 

so what do you think about the mech we should use?

> I'm certainly quite OK with having a switch to inhibit the creation of
> the actual cn=samba data.
> If we do actually get as far as replicating cn=config, then perhaps this
> same switch might be used to create a 'stub' slapd.conf with only enough
> to replicate in cn=config?
hm... do you mean (after we have converted the complete slapd to olc on 
the first dc) a switch (for the other dcs) that will activate
a very small olc-replication config "from the scratch", which will fetch 
everything needed from the first dc?
yes, i think we can get that done.

have a nice weekend,

> Andrew Bartlett

Virus checked by G DATA AntiVirusKit
Version: AVK 19.344 from 06.09.2008
Virus news:

More information about the samba-technical mailing list