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