Plans for pdb_ads and auth_netlogond?

[Andrew Bartlett]

On Thu, 2012-06-21 at 08:57 +1000, Andrew Bartlett wrote:
> On Wed, 2012-06-20 at 13:00 -0400, simo wrote:
> > On Tue, 2012-06-19 at 23:08 +1000, Andrew Bartlett wrote: 
> > > On Sun, 2012-06-17 at 01:52 +0200, Michael Adam wrote:
> > > > simo wrote:
> > > > > On Sat, 2012-06-16 at 07:33 +0200, Volker Lendecke wrote: 
> > > > > > On Sat, Jun 16, 2012 at 02:56:43PM +1000, Andrew Bartlett wrote:
> > > > > > > On Mon, 2012-06-11 at 12:08 +0200, Volker Lendecke wrote:
> > > > > > > > Hi!
> > > > > > > > 
> > > > > > > > I don't think that I can give input that is deemed worth any
> > > > > > > > consideration on this matter.
> > > > > > > 
> > > > > > > Sorry,
> > > > > > > 
> > > > > > > I'm not really sure what you mean by that.
> > > > > > > 
> > > > > > > Are you OK with the patch, or do you have plans to develop these into
> > > > > > > something that we use?
> > > > > > 
> > > > > > They are still my preferred way to let smbd3 access the
> > > > > > directory. You have decided that linking instead of ipc is
> > > > > > the better way to integrate components. Your approach has
> > > > > > more support in the community than mine,
> > > > > 
> > > > > I am not sure that is true. I made it clear earlier that I think the
> > > > > linking approach is wrong, and I do prefer the forking and executing of
> > > > > smbd.
> > > 
> > > Simo,
> > > 
> > > I'm rather confused:  Is this comment related to my patches, or just a general
> > > concern following up the comments you made last week?  We currently fork() and 
> > > exec() smbd, and after your clear feedback on the question, there are no current
> > > proposals to change that.  
> > 
> > That was a general comment, but forking and executing also naturally
> > means ion the long term we should have separate daemons handling the
> > separate aspects of samba.
> > 
> > I am *really* uncomfortable about the fact we link everything everywhere
> > because it makes it impossible to do proper security enforcement by
> > confining the single daemon.
> > 
> > For example it should be possible to confine the file server so it
> > doesn't have full access to the password database. Failure to do so
> > means a bug in the file server will compromise your entire domain
> > easily. That is not really a good idea. We need to stop letting every
> > single last remote part of samba require direct access to all that
> > information.
> > That's why I think Volker approach is superior.
> 
> Simo,
> 
> Sadly the code you so defend does not achieve either of these aims.  It
> only changes the full, unfettered access to the password db from being
> direct access to tdb files to SYSTEM access over ldapi://.  The
> auth_samba4 and pdb_samba4 code could be configured to do the same, but
> there is simply no advantage in doing so (and you loose transactions). 
> 
> Certainly it may be possible to build an alternate solution that does
> not have these properties, but you certainly would not start with
> auth_netlogond, because it fundamentally requires access the the machine
> account password (or the ability to reset it), and in AD the DC machine
> account password IS access to the full password database (just start a
> new replication). 
> 
> In a similar way, it may well be possible to build passdb modules that
> operate on reduced privileges only for whatever residual uses smbd needs
> beyond authentication (there may not be many), but rather than maintain
> a duplicate module, a configuration of pdb_samba4 could suffice here.
> 
> However, smbd has never to my knowledge even been demonstrated in such a
> mode, even in the much simpler classic domain controller case, so this
> would be totally new development. 
> 
> I have actually spent a great deal of time thinking about the security
> boundaries here, starting with the discussion you will recall many years
> back on why our KDC cannot be separated from the rest of Samba.  The AD
> design - such as the same machine account being used for accepting file
> server kerberos connections as sensitive DRS replication forces a number
> of compromises.  There may be ways around this, and I'm happy to work
> with you on them, but it really needs to be designed from scratch
> strictly and totally with this purpose and the full complexity of AD
> authentication in mind.  

Just a quick note to clarify this:  I mean that an AD KDC cannot operate
in an isolated security domain, separated in particular from the DCE/RPC
servers.  It can of course be in a distinct process (which we do
regularly), or even started independently (using a hdb or MIT plugin
module), but it remains in the same security domain as the DCE/RPC
servers at least.  As I said, I'm happy to work with you to try and
design a new solution for the difficult task of separating it form the
file server.

Thanks,

Andrew Bartlett


-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org