dns.keytab file

Rowland penny rpenny at samba.org
Mon Oct 19 13:51:57 UTC 2020


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

Rowland





More information about the samba-technical mailing list