XAD Hooks for Samba3 (was [PATCH] : Support for External RPC in Samba3)

[Andrew Bartlett]

On Wed, 2012-01-25 at 06:24 -0700, Har Gagan Sahai wrote:
> Hi, 
> 
> 
> We are proposing the patch to introduce the external RPC server support with Samba 3, where the external RPC server 
> is capable of handling the MSRPC requests. 

G'day,

I wanted to first thank you for your mail, and for proposing these
patches publicly.  It is useful to see how companies are using Samba,
and XAD (as most of the Samba Team would know DSfW as) is certainly one
of the more interesting uses of Samba.  I first met Luke Howard though
his XAD efforts almost a decade ago, and have followed it with intrigue
and interest as I worked on Samba4.  I've retitled the thread for
clarity to my fellow team members as to what we are dealing with here,
as most of us know of XAD and have met Luke at some point. 

That said, there are a number of technical issues that should be
addressed, which I'll detail below.  Many of these issues come up
because the patch series/concepts are actually quite old - for many
parts I recognise the concepts date back to Luke's first glue with
Samba. 

As you know we have our own AD implementation, which also uses plugins
and inter-process communication to talk between smbd and the rest of the
server, but so far those interfaces have been considered private and
flexible.

There are more than just the technical issues however - we as the Samba
Team also need to consider if we wish to bear the costs of defining a
fixed interface to support XAD/DSfW in the long term.  Addressing the
the technical points I raise would however reduce the size of the patch,
and make that easier to consider. 

> These patches are based on samba 3.6.1 version. 

The very first issue I have with this patch series that it should target
master.  We have made a big effort to continue the merge of Samba3 and
Samba4 in master, and the patch series should use the facilities we have
developed for that.  My view is that new features such as this should
not be introduced into 3.6.  Also, if you wish the patch to be present
in any version other than 3.6, it would have to be ported to master
anyway, so it is better to do that first. 

> The objective of this patch is to use samba  : 
> 
> 
> 1. Forward the RPCs (SAMR, LSA and NETLOGON) from samba to external RPC server 

This patch introduces a duplicate and special-case pipe forwarding
mechanism to that used between smbd and the various named pipe servers
we already have.  While we have not declared this a public interface,
adding another duplicate mechanism and operating protocol seems a poor
design choice, and a legacy that we should not have to maintain.

> 2. Winbind using MSRPC as backend methods and forwarding the RPC requests to external RPC server 

As regards the winbindd changes, the correct course of action here may
be more clear if/when we rework winbindd for interaction with Samba4's
AD.  However, I can say this:  I'm not a fan of the:

if (*lp_dce_funnel_directory() == '\0')

statements everywhere.

To put it another way, if we did follow this approach in general, we
could really end up in a mess.  We have three projects using part of the
Samba codebase for AD-like things: FreeIPA, Samba4 and XAD/DSfW.  If we
ended up with 

if (freeIPA) {
} else if (Samba4) {
} else if (DSfW) {
}

Then I think we would all agree it isn't sustainable, and just isn't the
Samba style.  Done right, developers need not even notice that smbd now
hosts a full AD server.  As an example, we introduced major behaviour
changes for the s3 session setup code (using gensec modules from s4),
but created a common abstraction layer, so the only S4-specific change
was to call a generic-purpose hook on an auth module.

I am surprised the patches do not implement even a minimal passdb
module, as many of the areas you hook are interfaced via passdb, and
others could be extended in the same way. 

For example, it may benefit both your project and a Samba4 AD DC if
passdb provided the machine account password.  This would avoid the need
to duplicate the 'kinit' code. 

> 3. Samba as file server for SYSVOL share access 

These patches are an example of why working with master would be
advantageous.  The patches for domain DFS could then be rewritten as VFS
modules in the same way that vfs_samba4 is already handled.

> 4. Winbindd IDMAP support with LDAP (in our case eDirectory) as back end with secure bind 
> 
> 
> These and few more changes are done to achieve Windows 2003 domain functionality using samba 3. This is used as part of 
> the product Novell Domain Services for Windows product. 

Some of the other changes include a duplicate of the cldap proxy
mechanism currently present in nmbd.  Given that the proposed patch does
not use the source IP address (the main deficiency in the cldap proxy is
that this info is lost), it should use that mechanism, rather than
introducing the additional complexity. 

An even better solution would be to hook via a plugin for either the S4
or DSfW netlogon response.

> I am attaching the patches with the mail. Also attached is the write up document describing the changes done in the patches. 
> 
> 
> Please review the patch and let us know your feedback. 

My main comment is that given that we have already demonstrated using
smbd to host the file servers for Samba4's AD server, it seems to me
that hosting XAD/DSfW should not need to be this intrusive.  Or at
least, where intrusion cannot be avoided, the intrusion should be
generic and improve Samba overall, rather than specific to one
particular mode of operation.

Please do not take these comments personally, but understand that this
is a proposal that we need to deal with very carefully.  

Thanks,

Andrew Bartlett

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