KDC built in or out of smbd

[Krishna Ganugapati]

Andrew,

I'm  speculating here (my understanding of  named pipes is rusty and 
understanding of Samba slight, so please bear with me. I may study this a 
bit more and reply later where I have better understanding ...with this 
disclaimer please see below :-))

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

Am I right in understanding this to mean that because a single user-mode 
process grabs a hold of the TCP connection for 445 or 139, you cannot hand 
traffic off to separate processes? ie is the "named pipe" system implemented 
in the context of the user mode smbd process. Is it because of this, that we 
are unable to demux named pipe traffic across multiple processes.

(Does this mean that all rpc servers implemented with Samba4 "MS-RPC" must 
reside in the smbd process ? (massive swag on my part, here? Could you 
kindly confirm one way or the other)

Then if the above be the case: (if, not, pls ignore):

The solution would be to implement the named pipe file system  as a kernel 
mode driver. User mode processes can open file handles to the named pipe 
file system driver which now demuxes traffic to separate processes. The rpc 
runtime would open an handle to the kernel mode named pipe file system and 
submit requests. (Now RPC servers can be decoupled from the smbd process)

One may ask, wouldn't that entail the smb transport bits also being 
implemented as a kernel mode driver. I wouldn't suggest that... (it would be 
unrealistic and basically bad - kernel code having the potential to damage 
the entire system), but  the named pipe system could be moved into the 
kernel and have it proxy calls back up to the user-space smbd. Multiple 
processes on the same machine can now open pipes

The kernel mode named pipe file system would be a tiny shim and an up call 
mechanism could be implemented by have the smbd process pend an io-request 
down into the driver. When the driver has work to do, it would complete the 
request. The completed user-mode request (response from the driver) would 
actually be request from the kernel mode proxy for the user-mode server to 
complete work..

I'd like to understand this better, so I would want to go off and study this 
a bit more carefully. I hope it would be okay to discuss this latter down 
the line.

Krishna






n 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

----- Original Message ----- 
From: "Andrew Bartlett" <abartlet at samba.org>
To: "Jeremy Allison" <jra at samba.org>
Cc: "Krishna Ganugapati" <krishnag at marakicorp.com>; 
<samba-technical at lists.samba.org>; "Lukasz Stelmach" 
<lukasz.stelmach at telmark.waw.pl>
Sent: Tuesday, November 29, 2005 3:06 PM
Subject: Re: KDC built in or out of smbd