Plans for pdb_ads and auth_netlogond?

[Andrew Bartlett]

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.  

Thanks,

Andrew Bartlett

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