Fedora DS Support

[Endi Sukma Dewata]

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 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? 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?

> 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?

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?

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

What do you think about this? Thanks.

--
Endi S. Dewata