Samba AD and Bind

Dewayne Geraghty dewaynegeraghty at gmail.com
Tue Aug 8 04:15:48 UTC 2017


On 8 August 2017 at 12:50, Amitay Isaacs via samba-technical <
samba-technical at lists.samba.org> wrote:

> Hi Andreas,
>
> On Fri, Aug 4, 2017 at 7:42 PM, Andreas Schneider via samba-technical <
> samba-technical at lists.samba.org> wrote:
>
> > Hi Andrew,
> >
> > we have a bind_dlz module so that Bind can be used as a nameserver. The
> > files
> > needed by bind (beside the module) are the tsig and config file.
> >
> > Those are located in the Samba private directory!
> >
> > Distributions limit the access to the private directory to root and give
> it
> > 0700 as the permissions.
> >
>
> > As the 'named' of bind needs to access to those files it wants access to
> > the
> > private directory but it is not allowed.
> >
> > I think if an external daemon wants to have access to some samba
> resources,
> > the private directory is the wrong place.
> >
> > So instead of
> >
> > ${LOCALSTATEDIR}/lib/samba/private
> >
> > there should be probably
> >
> > ${LOCALSTATEDIR}/lib/samba/bind_dns
> >
> >
> > and all the files required by bind should go there. Then we could give
> > 'named'
> > access to that directory!
> >
> > named:root with 0770 for the permissions ...
> >
>
> It's a good idea to separate the files required for bind.  However, it has
> to be done carefully.
>
> For dlz_bind module, provisioning creates a partial copy of samdb with base
> and domain
> partitions.  But the dns partitions are linked to the dns partitions from
> the main samdb.
>
> For named, to be able to access the dns partitions in private directory
> (via a link in
> the separate bind_dns directory), the private directory needs to have at
> least execute
> permission for others.  That will indicate that you can change the
> permissions for
> the private directory to 0751 (or 0701 if you must).
>
> The other option could be to move sam.ldb* out of private/ directory into
> it's own
> directory.  That way private/ can be 0700.  We still need to manage the
> permissions
> for sam.ldb* files and the directory they are moved in, so named as the
> required access.
>
> Amitay.
>

Sadly, I too have travelled this path (trying to separate bind off the
SAMBA server).  Recall that sam.ldb contains little gems like the
unicodePwd, userPassword (and clearTextPassword) of user accounts which
would be sought by any (all?) hacking efforts.
This is the one file that needs strong protection...

I'm happy to be corrected but I understand that SAMBA as AD-DC needs to
talk to bind/named, over tss, to maintain DNS entries for other DC's as
well as a plethora of SRV records for client devices to map.  Is there any
other purpose?  (eg PC registrations? or is it enough that forward and
reverse resolution is successful from say, a recursive request?)


More information about the samba-technical mailing list