Fedora DS Support

[Andrew Bartlett]

On Thu, 2009-09-03 at 16:36 -0400, Endi Sukma Dewata wrote:
> Andrew,
> 
> ----- "Andrew Bartlett" <abartlet at samba.org> wrote:
> 
> > > Another thing, I changed the provisioning script so that it creates 2
> > > credential objects: one for the directory manager (simple) and another
> > > for samba-admin (SASL). The script will use the directory manager
> > > credential for importing Samba objects. The samba-admin credential object
> > > will only be used for creating the secrets database. For OpenLDAP, these
> > > 2 credential objects will be identical (SASL), so everything should work
> > > the same as before.
> > 
> > I would really prefer we just had one user.  Is there a particular
> > reason to introduce this point of difference?
> 
> The main reason is there are some things that can only be done by the directory
> manager (DM), e.g. configuring SASL mappings, adding the root entry of each
> partition and configuring ACL on it. On the other hand, currently it's not
> possible to do a SASL bind and get mapped to DM because it's not an object in
> the DIT.
> 
> In my opinion during provisioning Samba should just continue to use the DM with
> simple bind because it's the most appropriate user for managing FDS. Then
> during server runtime Samba can use samba-admin with SASL bind to access the
> backend.

I can live with that.  

> I have a question though, what is the advantage of using SASL bind over simple
> bind of if both are done over ldapi (no network traffic) and the interface has
> been made private to Samba process? 

Not much.  It's cleaner in the Samba process (for silly reasons), and
against OpenLDAP it avoided keeping the password in the slapd.conf (but
that has gone away in favour of cn=config anyway).  

I suppose I just felt funny about keeping the directory manager password
around, not having any access control on Samba whatsoever, and the risk
that an administrator would configure the system to use ldap over TCP
(now disabled as an option, but no doubt someone will patch it back in
at some point). 

> The DM password is stored in clear text in
> secrets.ldb (if using simple) and fedorads.inf. The samba-admin password is
> stored in clear text in secrets.ldb (if using SASL) and cn=samba-admin object.
> Does Samba use the cn=samba-admin object for any purpose other than SASL auth?

No.  

> > I'm not very happy about introducing the _fds.ldif files, nor the
> > contents of the ACI being proposed.  The fundamental task remains to
> > remove the anonymous access - the only user that should have access to
> > the DB is samba-admin - not the general case of any user.  Indeed, no
> > other users should even be permitted to bind (so you should remove, not
> > complement, the existing SASL mapping). 
> 
> There are 2 ways to remove the other SASL mappings:
> 
> 1. Before starting the server by editing the dse.ldif generated by setup-ds.pl.
>    Does Samba have an LDIF parser & writer that can be used by provision.py?

Yes.  LDB has conversion functions to and from LDIF.

> 2. After starting the server by removing the SASL mappings from cn=config.
>    We will need to bind as DM over ldapi.
> 
> Which one do you prefer?

Bind as DM over ldapi might be better. 

> > Also, I was quite deliberate in choosing to remove the aci from the
> > schema.  If we place it in the Samba schema, then we show it to clients,
> > and must place it in an objectClass that we can validate etc.  
> 
> > If we must create the access control 'in directory', and we can't do
> > that until we create the partition objects, then I would prefer (despite
> > my protest above) that we create the provision using the directory
> > manager, and use a direct ldapi-based edit of the database to add the
> > ACL). 
> 
> If I understood correctly disabling anonymous access is not available in the
> current FDS. But without the proper ACI, anonymous users will not be able to
> access the tree anyway. Having an ACI in the root entries is essential to
> give access to samba-admin (unless Samba server uses DM) and prevent anonymous
> access. Also, the ACI needs to be stored somewhere, either in _fds.ldif or
> hardcoded in provision.py.
> 
> Instead of loading the entries via LDB (i.e. ldapi), we probably could import
> the entries including the ACL during instance creation (setup-ds.pl) or using
> ldif2db before the FDS is started. Either way it doesn't require binding as DM
> and there is no need to include aci in Samba schema because it's a direct
> operation against FDS.
> 
> However, the current code that imports the entries (setup_samdb()) is doing it
> after the FDS is started. Changing the code like that might require some
> significant restructuring. Do you think this is possible?
> 
> So I think the options are:
> 
> 1. Use the DM over ldapi to load the entries and configure FDS, then configure
>    Samba server to use samba-admin.
> 
> 2. Use setup-ds.pl/ldif2db to load the entries, use LDIF parser to configure DS,
>    then configure Samba server to use samba-admin.
> 
> 3. Use setup-ds.pl/ldif2db to load only the root entries that contains ACI, use
>    LDIF parser to configure DS, load the remaining entries as samba-admin over
>    ldapi, then configure Samba server to use samba-admin too.

The code is currently structured to permit this (hence why all the root
entries are split into an add/modify case), but I'm not really happy
with it. 

> What do you think about this? Thanks.

The best way might be to provision as directory manager, and bound over
LDAPI directly remove the SASL mappings before we start, also fix ACI
once we are done.  We should still have pretty good control over the DS
(and not be exposed on TCP) at this point - I hope!

The other option might be to work with the Fedora DS team to add an
option to the fedorads.inf fed to setup-ds.pl to specify the default
ACL, so that it is possible to start a Fedora DS instance locked-down.

Thankyou for your persistence with this!

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20090904/b7aee21e/attachment.pgp>