KDC built in or out of smbd

[Andrew Bartlett]

On Tue, 2005-11-29 at 14:46 -0800, Jeremy Allison wrote:
> On Wed, Nov 30, 2005 at 09:37:24AM +1100, Andrew Bartlett wrote:
> > 
> > > Thus since Samba 4 is moving towards supporting AD semantics, would someone 
> > > comment if there is this move to decouple authentication services from the 
> > > file server architecture and is that already in place?
> > > Note I have not yet been able to successfully build all the Samba4 bits (for 
> > > some reason, my machine is choking, so my thoughts are speculative, but if 
> > > the Samba folks could shed some light, I'd be most obliged...
> > 
> > I'm not entirely sure what you mean by decoupling in this context.
> 
> What everyone means by this - running a kdc as a separate process (preferably on
> a separate machine :-).

The KDC is the easy bit, but doing so doesn't gain you anything.  

In the traditional MIT environment, the KDC typically ran on a machine
running only the KDC, kadmind and kpasswdd (and possibly not even a
remote login program).

In AD, the list of things which require read or write access to
passwords includes:
 - kdc
 - kpasswdd
 - netlogon service
 - samr servcie
 - lsa service (hosts domain trust passwords)
 - SWAT

It is the SAMR services line that opens the can of worms:  An
administrator can do a remote password set over ncacn_np (that is, over
an SMB connection), with only SMB authentication.  

Now, it is quite practical to forward the SAMR pipe across to a
different process or service, but we must convince the remote service
that we are trusted.  This is what kerberos delegation is for, but for
NTLMSSP authentication, we can't do that.  So, the SMB server must have
the right to impersonate any user, which then brings it into the
'trusted' net.

So, the list of trusted services includes:
 - kdc
 - kpasswdd
 - netlogon service
 - samr service
 - lsa service
 - SWAT
 - smb service

We could split out incoming CIFS traffic into fileshare and IPC$ access,
and proxy the file-share access to a separate process (at a performance
cost).

Anyway, I hope this gives an idea why I view splitting out the KDC for
security reasons as being 'difficult'.  More practical is splitting out
a KDC where an alternate implementation (matching our specifications for
PAC and the rest) is desired, as it is 'just' a matter of database
access.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
-------------- 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/archive/samba-technical/attachments/20051130/175a5841/attachment.bin