A DRAFT statement on our build systems for Samba 4.0

[Andrew Bartlett]

On Fri, 2012-05-18 at 10:57 +1000, Dewayne Geraghty wrote:
> Andrew, Thank-you for the excellent draft, though I have some minor points
> following from Simo's suggestions.
> 
> 1. We secure systems and distribute on Compact Flash, and other media.  Our
> clients typically run samba3 DC's with Windows Server 2003, 2008 servers
> joined to them.  Having a "Standard Samba 4" build with everything needed
> is certainly the Holy Grail, however the need for builds that only require
> file services or print services remains, for two reasons: minimisation of
> threat profile, and keeping systems small (and usually simple, or at least,
> consistent).  
> 
> To achieve this, we currently virtualise services to reduce the opportunity
> of a failed/hacked (sub)system, so ldap lives on one, samba3 another, dns &
> dhcp on another, and so on.  Similarly the disks are stratified by service.
> Point being, installing a full AD kit on both the HQ/"Head Office" system
> as well as remote Branches will unnecessarily expose elements, as well as
> "bulk-up" the deployment.  So having options to build only whats needed
> would be beneficial; for roll-out planning, maintenance ease, &  risk
> reduction.

There are a few things that will help you here.  The AD services only
listen when they are configured to.  A file server deployment will not
start a KDC or LDAP server, and will continue to use the 'samba3' RPC
services for LSA etc.  

Additionally, because the current modal has the AD services all loaded
as libraries in the 'samba' binary, you could simply not install that
binary on your target system, if that helped your threat profile. 

I will note that all Samba3 installations can be an NT4 domain
controller, and we have been under a trend to use more of our own RPC
services internally.  With that, and the use of shared libraries in the
waf build, there isn't a massive amount of complexity to save, and there
is complexity to add in terms of testing these partial builds. 

That is why, despite the demand, I'm hesitant to create a 'not AD DC'
build, because there is challenge in defining where to define the line.
For example, the 'samba4' client libraries are used by OpenChange and
the python libraries are used by FreeIPA, both of which are not 'AD DC'
users.  Once these are included, the components left are surprisingly
small!  (And without the AD DC, we can't do a full internal test of
them)

For your deployments, I would suggest that given our smaller
installation size, you would gain more by having the systems be
consistent, and then enable/run the services that you need on any given
isolated system.  

> 2. Another point of clarification for your draft; because there has been an
> evolution of samba4 to include previously third party items: a significant
> portion of heimdal, a "samba ldap" (for want of a better expression), and
> I've lost track of whether there's a "samba dns/dhcp/ntp" instance. Would
> your draft benefit from identifying what the new elements are, so community
> members can start planning their migration from the services that they may
> already have in place?  Or am I stretching the purpose too thinly?

We should improve our communication here - the WHATSNEW is the current
place were we document the major changes.  In short, with DNS we have a
module for bind9, or a internal DNS server (which isn't complete yet).
For NTP, the ntp.org NTP server can be configured to use us for
authentication.

> My current thinking is to have two Samba4 servers, 1 at HQ, the other at
> the Contingency site(s), and Samba3 file/print servers at the Branch sites.
> I haven't been able to determine how DNS DHCP will interact, as the
> branch's need resilience so they can function when their inter-office
> network becomes unavailable. Folks can continue to print, email, web
> browse. 

If your branches are on unreliable links, then Samba4's RODC
functionality would be a great thing to use for those branch offices.  I
would have that RODC also be a DNS server.  

> I see a LOT of challenges ahead, though I look forward to fulfilling the
> aspiration of secure AD services.

I look forward to working with you!

Andrew Bartlett

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