backend provision samba4-ol-multimaster

[Oliver Liebel]

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 
"readability".

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 
idea:

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 
cn=samba-admin)
dn: cn=replicator
objectClass: top
objectClass: person
cn: replicator
userPassword:: ${LDAPADMINPASS_B64}
structuralObjectClass: person
entryUUID: ${UUID}
creatorsName:
createTimestamp: ${LDAPTIME}
entryCSN: 20080714010529.241039Z#000000#000#000000
modifiersName:
modifyTimestamp: ${LDAPTIME}



slapd.conf:
syncrepl section:
syncrepl rid=<rid>
      provider=<host>
      ...
      bindmethod=sasl
      saslmech=DIGEST-MD5
      authcid="replicator"
      credentials="linux"

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


provison.py:
setup_file(setup_path("cn=samba-admin.ldif"),
                           os.path.join(paths.ldapdir, "db", "samba",  
"cn=samba", "cn=samba-admin.ldif"),
                          ...
setup_file(setup_path("cn=replicator.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" 
sasl_ssf=128

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 
thougt.

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,
oliver

> Andrew Bartlett
>
>   

____________
Virus checked by G DATA AntiVirusKit
Version: AVK 19.344 from 06.09.2008
Virus news: www.antiviruslab.com