KDC built in or out of smbd

[Stefan (metze) Metzmacher]

Krishna Ganugapati schrieb:
> 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)

It's like this:

we have only one server binary 'smbd' which can load shared modules
at runtime.

shared modules can register plugins for the following interfaces:
- events: this abstracts filediscriptor and timed events
           the default is to use the 'epoll'-module that fallback back to select if epoll
           isn't available, but we also have a module for hooking into the GTK event system
           so that our async client libraries can be used in GTK apps.
- process models: the process models handles stuff like what happens, when we
                   start a new 'task' and what happens when we got an incomming
                   stream socket connection.
                   e.g. 'single' (runs everything in one unix process),
                        'standard' (the 'fork' process model, forks for each task
                        and on every incoming connection)
- server service: the main server tasks, at smbd startup we start all server services
                   which are configured, and use the configured process model for that.
                   each service then sets up the listen sockets, and for stream sockets
                   it can decide what process model will be used for incoming connections.
                   e.g. 'smb_server', 'dcerpc_server', 'ldap_server', 'cldap_server', 'kdc',
                        'nbt_server', 'wrepl_server', 'winbind', 'web_server'(for swat2)
- auth: backends for the NTLM-Server side authentification:
         e.g. 'sam' (this looks into our sam.ldb), 'anonymous',
              'winbind' (this is for trusted domains, and uses winbind as proxy)
- gensec: this abstracts like GSSAPI, but is more generic, so that we can support
           GSSAPI, SASL and DCERPC-Auth with the same modules
	  e.g. 'ntlmssp', 'krb5', 'spnego'
- ntvfs: this interface abstracts the file access that the 'smb_server' overs.
          you can have a list of backend per file share. the interface handles
          async module chaning fine.
          e.g. 'cifs' a proxy backend the passes all SMB calls to another server,
               mostly used for testing
               'posix' this does basicly the fileserving the samba3 does.
               'unixid' this is typicaly configured before the 'posix' backend, and calls
                        setuid()..., so the the following module interacts as the correct unix user
               'ipc' this handles the 'IPC$'-share and passes the requests to the DCERPC server,
               but via function calls not via sockets
               'print' for SMB printing
- dcerpc endpoint server: this interface is for supporting the different pipes.
                           e.g. 'samr', 'netlogon', 'spoolss', 'lsa', 'drsuapi',.....
                           'remote' (a proxy backend that forwards the requests to another
                           RPC-server)


I think this are the important interfaces we have, there're some others like ldb modules,
socket modules (unix,ipv4,ipv6), ...

So you can see if you want you can run everything in one unix process, which is very useful
for development, and to garanty that the only blocking system call is the events-modules
event_wait_once() function (typically epoll() or select()), while processing an unlimited number
of client requests + internal IPC messaging.

But you can also use the 'standard' (fork) process-model that creates new unix processes
for each 'task' and each incoming connection.

So if *you* want you can do everything, create your own ntvfs_ipc module that passes
the requests to another unix process,(via our IRPC code or via unix sockets or ...)

Or you can create you own dcerpc endpoint module and let this pass the requests to another
unix process.

Or you can create your an auth module and replace the auth_sam with something like the
auth_winbind code...

Or you can write your own process model module....

But at least when you want to be act as a AD Domain Controller, you need the LDAP-Server, the
KDC-Server, the SAMR-DCERPC module, the auth_sam module to access the sam.ldb,
witch is the LDAP-like database that stores the AD tree.

If you have any questions please ask:-)

-- 
metze

Stefan Metzmacher <metze at samba.org> www.samba.org