What is Franky exactly?

[simo]

On Tue, 2011-11-29 at 08:16 +1100, Andrew Bartlett wrote: 
> On Sat, 2011-11-26 at 16:31 -0500, simo wrote:
> 
> > > Much the same argument is true of the LSA serice daemon. We have years
> > > of experience running the LSA module inside bin/samba for an AD DC. As
> > > far as I know, you have not attempted to test the LSA service code you
> > > are proposing when Samba is an AD DC. It certainly has not been tested
> > > by any of our users.
> > 
> > Exactly and that's because *nobody* has proposed running the smbd's LSA
> > daemon in the AD-DC scenario. The idea is to proxy all connections to
> > the bin/samba LSA daemon for AD-DC services. It's the Franky approach.
> > 
> > I wonder if you ever bothered to understand how the Franky architecture
> > was supposed to work, your comments here seem to indicate you didn't, a
> > pity.
> 
> Simo,
> 
> I did not read Andreas' comments to have the same meaning as Tridge did,
> but I have the additional background of your personal assurance that you
> are not trying to build an AD clone with FreeIPA or Samba3's lsad.  
> 
> Part of the confusion here comes from that the wiki page about Franky.
> The only public reference for what Franky is (wrongly, as far as I can
> tell) suggests exactly what Tridge was worried about:
> 
> https://wiki.samba.org/index.php/Franky#The_Plumbing_Design.2C_revised

This is the relevant part from that page:

        To delegate the RPC services relevant for domain authentication
        to Samba4, put 
        rpc_server:lsarpc = external
        rpc_server:netlogon = external
        rpc_server:samr = external

This means that all the logon RPC services are delegated to bin/samba
via proxy named pipes. It is quite clear to me.

Also in 'The Plunbing Design' section it says:

        samba4 offers the named pipes samr, lsa, netlogon, epm, and
        drsuapi

I know there is a 'revised' part, but that can be discussed. In my mind
pdb_ads or pdb_samba4 are not ideal, but can be used for smbd's internal
purposes.
There has never been in my mind any doubt that the rpc need to be
forwarded. In fact we made sure with our work (funded by Red Hat) that
even smbd pipes through proxy pipes as many calls as it can so that
internal and external use of these pipes is going through the same paths
and uses the same daemons. 


> (from the wiki page)
> > The Plumbing Design, revised 
> > During another Göttingen meeting another idea was born: pdb_ads.
> > 
> > In the last 12 months, in particular Günther Deschner has done a
> > tremendous amount of work in the Samba 3 RPC server area, making it
> > likely that the RPC services in Samba 3 are sufficient to provide
> > enough infrastructure to provide AD-like services to Windows clients.
> > The things that Samba 3 does not have and probably will not have for
> > the foreseeable future are LDAP and Kerberos services.
> > 
> > The missing piece to provide interoperability between Samba 3 and
> > Samba 4's LDAP/Kerberos services is a way to access the AD-style LDAP
> > database Samba 4 provides from Samba 3. The new pdb_ads module uses
> > the existing passdb infrastructure in Samba 3 to do exactly that.
> 
> Perhaps someone involved in the Franky proposal could clarify that page
> with the current integration status and current proposals?  

I think we should discuss pros and cons and find middle ground. I do not
agree with using pdb_ads to provide lsa/samr services for example, but
it is ok to use to provide ldapsam:trusted for example so that smbd
doesn't need to go great lengths to actually resolve users.

> Alternately, if we wish to move on from that name (and remove that
> page), I'm happy to write up a new page with my thoughts and proposals,
> built on the technology we have so far and what we demonstrate in
> plugin_s4_dc.

I prefer you talk to the people that made this proposal and come to
common ground rather than trying to delete and override.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>