Yet another GSS-TSIG thread for BIND9 with AD

Vinícius Ferrão ferrao at versatushpc.com.br
Sat May 23 19:18:03 UTC 2020


Hello,

Hope everyone is fine on this quarantine timeframe.

So here is the issue: I’ve an Active Directory domain on Windows Server 2019 (upgraded since 2012 R2 days) that uses BIND9 as DNS service. This domain never had Windows DNS Server.

Everything works as expected, except for the GSS-TSIG updates, I’m scratching my head trying to solve this but nothing works and the debug messages does not says anything, which is extremely frustrating.

The scenario is the following:

192.168.1.2: BIND9 Master (RHEL8)
192.168.1.3: BIND9 Slave #1 (RHEL8)
192.168.1.4: BIND9 Slave #2 (RHEL8)
192.168.1.5: DC #1 (Server 2019)
192.168.1.6: DC #2 (Server 2019)

BIND 9 version:
bind-9.11.13-3.el8.x86_64
bind-license-9.11.13-3.el8.noarch
bind-libs-9.11.13-3.el8.x86_64
bind-export-libs-9.11.13-3.el8.x86_64
bind-utils-9.11.13-3.el8.x86_64
bind-libs-lite-9.11.13-3.el8.x86_64

All machines are configured pointing to 192.168.1.2 and 192.168.1.3 for DNS service. Those slaves are pretty simple, they run just a catalog zone to fetch everything from master:

// Catalog Zone
zone “catalog.local.example.com<http://catalog.local.example.com>" {
type slave;
file "slaves/catalog.local.example.com.db";
masters { 192.168.1.2; };
};

On the master, is where anything else is configured:

// Options
options {
…
// Recursion and caching disable
        recursion no;
        additional-from-auth no;
        additional-from-cache no;

// Keys
        managed-keys-directory "/var/named/dynamic”;

// Signed kerberos updates
        tkey-gssapi-keytab “/etc/krb5.keytab";
        tkey-gssapi-credential “DNS/ns.local.example.com at LOCAL.EXAMPLE.COM<mailto:DNS/ns.local.example.com at LOCAL.EXAMPLE.COM>";
        tkey-domain "LOCAL.EXAMPLE.COM<http://LOCAL.EXAMPLE.COM>”;

// Catalog zones support
        server-id "authoritative";
        allow-new-zones yes;
};

// Catalog Zone
zone "catalog.local.example.com<http://catalog.local.example.com>" {
        type master;
        file "/var/named/static/catalog.local.example.com.db";
        also-notify { 192.168.1.3; 192.168.1.4; };
        notify explicit;
};

// Start of AD authoritative dynamic zones

zone "local.example.com" {
        type master;
        file "/var/named/dynamic/local.example.com.db";
        notify yes;
        check-names ignore;
        allow-transfer { intnameservers; };
#       allow-update {
#               domaincontrollers;
#       };
        update-policy {
#               grant * krb5-subdomain local.example.com. ANY;
#               grant * ms-subdomain local.example.com. ANY;
                grant * subdomain local.example.com. ANY;
        };
};

I’ve tried a lot of combination in update policy, nothing really works: krb5-self, ms-selfsub and etc.

The other files and settings on the system appears to be right:

[root at ns named]# file /etc/krb5.keytab
/etc/krb5.keytab: Kerberos Keytab file, realm=LOCAL.EXAMPLE.COM<http://LOCAL.EXAMPLE.COM>, principal=DNS/ns.local.example.com<http://ns.local.example.com>, type=1, date=Sat May 23 07:40:19 2020, kvno=17

[root at ns named]# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
  17 DNS/ns.local.example.com at LOCAL.EXAMPLE.COM<mailto:DNS/ns.local.example.com at LOCAL.EXAMPLE.COM> (aes256-cts-hmac-sha1-96)

[root at pallet named]# cat /etc/krb5.conf
# To opt out of the system crypto-policies configuration of krb5, remove the
# symlink at /etc/krb5.conf.d/crypto-policies which will not be recreated.
includedir /etc/krb5.conf.d/

[logging]
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log

[libdefaults]
    dns_lookup_realm = false
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true
    rdns = false
    pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
    spake_preauth_groups = edwards25519
#    default_realm = EXAMPLE.COM<http://EXAMPLE.COM>
    default_realm = LOCAL.EXAMPLE.COM<http://LOCAL.EXAMPLE.COM>
    default_ccache_name = KEYRING:persistent:%{uid}

[realms]
# EXAMPLE.COM<http://EXAMPLE.COM> = {
#     kdc = kerberos.example.com<http://kerberos.example.com>
#     admin_server = kerberos.example.com<http://kerberos.example.com>
# }

[domain_realm]
# .example.com<http://example.com> = EXAMPLE.COM<http://EXAMPLE.COM>
# example.com<http://example.com> = EXAMPLE.COM<http://EXAMPLE.COM>

[root at ns named]# hostname
ns.example.com<http://ns.example.com>

So that’s is it, on the logs I only get the following, when I try to issue ipconfig /registerdns on a Windows domain-joined machine:

23-May-2020 01:57:03.693 update: debug 8: client @0x7fa1100a1ca0 192.168.1.12#62276: updating zone 'local.example.com/IN':<http://local.example.com/IN':> prerequisites are OK
23-May-2020 01:57:03.693 update-security: error: client @0x7fa1100a1ca0 192.168.1.12#62276: update 'local.example.com/IN<http://local.example.com/IN>' denied
23-May-2020 01:57:03.693 update: debug 8: client @0x7fa1100a1ca0 192.168.1.12#62276: updating zone 'local.example.com/IN':<http://local.example.com/IN':> rolling back
23-May-2020 01:57:03.700 update: debug 8: client @0x7fa1100a1ca0 192.168.1.12#65242: updating zone 'local.example.com/IN':<http://local.example.com/IN':> prerequisites are OK
23-May-2020 01:57:03.700 update-security: error: client @0x7fa1100a1ca0 192.168.1.12#65242: update 'local.example.com/IN<http://local.example.com/IN>' denied
23-May-2020 01:57:03.700 update: debug 8: client @0x7fa1100a1ca0 192.168.1.12#65242: updating zone 'local.example.com/IN':<http://local.example.com/IN':> rolling back
23-May-2020 01:57:05.740 update: debug 8: client @0x7fa1100a1ca0 192.168.1.15#49688: updating zone 'local.example.com/IN':<http://local.example.com/IN':> prerequisites are OK
23-May-2020 01:57:05.740 update-security: error: client @0x7fa1100a1ca0 192.168.1.15#49688: update 'local.example.com/IN<http://local.example.com/IN>' denied
23-May-2020 01:57:05.740 update: debug 8: client @0x7fa1100a1ca0 192.168.1.15#49688: updating zone 'local.example.com/IN':<http://local.example.com/IN':> rolling back

Any help on how to start debugging it is greatly appreciated.

Thanks,

PS: My implementation was based on this article: http://ddiguru.com/blog/configuring-gss-tsig-on-bind; except for the +DesOnly option, because it’s deprecated right now. I’ve enabled the AES256 passwords on the BIND9 user account on AD side and set the password after it so the hashes could be generated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200523/75b76452/attachment-0001.htm>


More information about the bind-users mailing list