dns.keytab file

[Alexander Bokovoy]

On ma, 19 loka 2020, Rowland penny via samba-technical wrote:
> On 19/10/2020 14:37, Alexander Bokovoy wrote:
> > On ma, 19 loka 2020, Rowland penny via samba-technical wrote:
> > > On 19/10/2020 13:46, Alexander Bokovoy wrote:
> > > > On ma, 19 loka 2020, Rowland penny via samba-technical wrote:
> > > > > On 19/10/2020 13:07, Stefan Kania via samba-technical wrote:
> > > > > > Am 19.10.20 um 03:38 schrieb Andrew Bartlett:
> > > > > > > On Sat, 2020-10-17 at 09:47 +0200, Stefan Kania wrote:
> > > > > > > > Hi Andrew,
> > > > > > > > 
> > > > > > > > Am 16.10.20 um 22:37 schrieb Andrew Bartlett:
> > > > > > > > > I just saw this with a customer yesterday.
> > > > > > > > I see this every time I setup a new domain, I also wrote it into my
> > > > > > > > Samba4 book. If it's a bug should I write bugreport?
> > > > > > > Yes.
> > > > > > Done
> > > > > > https://bugzilla.samba.org/show_bug.cgi?id=14535
> > > > > > I hope I did it right :-)
> > > > > OK, I 'think' I have tracked this down. During the join, 'setup_bind9_dns'
> > > > > from sambadns.py is called, this in turn calls 'secretsdb_setup_dns'. This
> > > > > actually removes any existing 'dns.keytab' from the private and bind-dns
> > > > > dirs, it then goes on to create the keytab via the commit, but only in the
> > > > > private dir.
> > > > > 
> > > > > Now to consider how to create the keytab in the bind-dns dir, is it that the
> > > > > incorrect path is being passed ? Or just move it to the correct destination
> > > > > (does anything rely on the dns.keytab being in the private dir ?), or do
> > > > > something else ?
> > > > Looking into source4/dns_server/dlz_bind9.c, it accepts dns.keytba in
> > > > either path, first checking BIND's path, then Samba's private directory.
> > > > Since the process runs under BIND user (named:named in Fedora, for
> > > > example), it wouldn't have access to Samba's private directory.
> > > > 
> > > > Our source4/setup/named.txt talks about BIND's path (DNS_KEYTAB_ABS is
> > > > expanded to use BIND's path):
> > > > 
> > > > $ git grep DNS_KEYTAB_ABS
> > > > python/samba/provision/sambadns.py:            "DNS_KEYTAB_ABS": os.path.join(binddns_dir, keytab_name),
> > > > source4/setup/named.txt:tkey-gssapi-keytab "${DNS_KEYTAB_ABS}";
> > > > source4/setup/named.txt:chcon -t named_conf_t ${DNS_KEYTAB_ABS}
> > > > 
> > > > The logic was that if you ran Samba set up before 4.8.0,
> > > > samba_upgradedns script helps to upgrade to a newer setup as explained
> > > > in 8f2dee256e281c438105689b073f09685f161b16:
> > > > 
> > > > commit 8f2dee256e281c438105689b073f09685f161b16
> > > > Author: Andreas Schneider <asn at samba.org>
> > > > Date:   Thu Aug 10 15:37:54 2017 +0200
> > > > 
> > > >       python:samba: Use 'binddns dir' in samba-tool and samba_upgradedns
> > > > 
> > > >       This provisions the bind_dlz files in the 'binddns dir'. If you want to
> > > >       migrate to the new files strcuture you can run samba_upgradedns!
> > > > 
> > > >       BUG: https://bugzilla.samba.org/show_bug.cgi?id=12957
> > > > 
> > > > So I think the right path is BIND's path.
> > > > 
> > > > 
> > > On a new DC joined using BIND9_DLZ, the dns.keytab does not get created in
> > > the bind-dns dir, it is created in the private dir, so I think what you are
> > > saying is that the wrong path is being passed to 'secretsdb_setup_dns' ?
> > When we run 'provision()', it creates secrets.ldb and committing that to
> > disk will create dns.keytab, with the help of LDB's update_keytab
> > module. The provision code actually has the logic to create links from
> > Samba's private directory's dns.keytab to BIND's directory:
> > 
> >      # Now commit the secrets.ldb to disk
> >      secrets_ldb.transaction_commit()
> > 
> >      # the commit creates the dns.keytab in the private directory
> >      private_dns_keytab_path = os.path.join(paths.private_dir, paths.dns_keytab)
> >      bind_dns_keytab_path = os.path.join(paths.binddns_dir, paths.dns_keytab)
> > 
> >      if os.path.isfile(private_dns_keytab_path):
> >          if os.path.isfile(bind_dns_keytab_path):
> >              try:
> >                  os.unlink(bind_dns_keytab_path)
> >              except OSError as e:
> >                  logger.error("Failed to remove %s: %s" %
> >                               (bind_dns_keytab_path, e.strerror))
> > 
> >          # link the dns.keytab to the bind-dns directory
> >          try:
> >              os.link(private_dns_keytab_path, bind_dns_keytab_path)
> >          except OSError as e:
> >              logger.error("Failed to create link %s -> %s: %s" %
> >                           (private_dns_keytab_path, bind_dns_keytab_path, e.strerror))
> > 
> > 
> > So I think there are two areas to look:
> > 
> >   - something removes this link, leaving BIND's path without dns.keytab
> > 
> >   - the link is not enough to access the dns.keytab in Samba's private
> >     directory
> > 
> > I think we probably should instead move private version of the keytab to
> > BIND's location which means we could probably achieve that by forcing
> > secretsdb_setup_dns() to use that path as 'DNS_KEYTAB' value when
> > importing secrets_dns.ldif. However, this also means that samba
> > provisioning code should run under privileges that would allow it to
> > write into BIND's directory. This is probably fine as we run it as root
> > already.
> > 
> Yes, all that code above is very nice, it just doesn't seem to work during a
> DC join :-)
> 
> I can now create the keytab in /var/lib/samba/bind-dns/ during a join, I
> just need to either pass bind's gid down the stack or obtain it in
> secretsdb_setup_dns

One way would be to extract this logic from provision() into a helper
method that accepts a paths object and then does all the needed linkage.
In all cases where secretsdb_setup_dns() is called we pass unchanged
paths.private_dir, paths.binddns_dir, and paths.dns_keytab. So instead
of three of those, we could simply pass paths object and access those
directly or pass through to this new helper.

-- 
/ Alexander Bokovoy