Query about tkey-gssapi-keytab and secure updates

isc at sunnyday.sk isc at sunnyday.sk
Wed Nov 4 23:14:23 UTC 2020 

Hello Bind users,

Trying to extend my understanding about tkey-gssapi-keytab statement
and possibility to use multiple principal names in single keytab file

The use case is simple:
Merging to MS AD environments to single ISC BIND DNS server with secure 
updates using update-policy

For testing, I create two AD domains

  	* test.local
  	* test1.local

During multiple testing, it looks like that using 'tkey-gssapi-keytab' 
is not enough to verify properly secure updates
Let me details result of my example:

named.conf

> _options {_
> _directory "/usr/local/etc/namedb/working";_
> _listen-on {_
> _"any";_
> _};_
> _pid-file "/var/run/named/pid";_
> _tkey-gssapi-keytab "/usr/local/etc/namedb/working/keytab.krb5";_
> _};_
> 
> _zone "test.local" {_
> _type master;_
> _file "/usr/local/etc/namedb/master/test.local";_
> _update-policy {_
> _grant "TEST.LOCAL" ms-self "." "ANY";_
> _};_
> _auto-dnssec maintain;_
> _};_
> _zone "test1.local" {_
> _type master;_
> _file "/usr/local/etc/namedb/master/test1.local";_
> _update-policy {_
> _grant "TEST1.LOCAL" ms-self "." "ANY";_
> _};_
> _auto-dnssec maintain;_
> _};_

keytab file is loaded and I can get TGT from AD for TEST.LOCAL

> _root at dns2:~ # ktutil -k /usr/local/etc/namedb/working/keytab.krb5 
> list_
> _/usr/local/etc/namedb/working/keytab.krb5:_
> 
> _Vno Type Principal Aliases_
> _9 arcfour-hmac-md5 DNS/dns2.test.local at TEST.LOCAL_
> _root at dns2:~ # kinit -k -t /usr/local/etc/namedb/working/keytab.krb5 
> DNS/dns2.test.local at TEST.LOCAL_
> _root at dns2:~ # klist_
> _Credentials cache: FILE:/tmp/krb5cc_0_
> _Principal: DNS/dns2.test.local at TEST.LOCAL_
> 
> _Issued Expires Principal_
> _Nov 4 23:28:05 2020 Nov 5 09:28:03 2020 krbtgt/TEST.LOCAL at TEST.LOCAL_
> _root at dns2:~ #_

Possible challenge I see is that BIND does not use keytab file to 
compare GSS request with keytab;
I can see on debug 8 gss messages with failure 'No No kerberos 
credential available'

> _04-Nov-2020 23:29:04.945 client @0x803875000 10.0.110.207#61795 
> (612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): query: 
> 612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592 IN TKEY -T 
> (10.0.50.33)_
> _04-Nov-2020 23:29:04.947 failed gss_inquire_cred: GSSAPI error: Major 
> = Unspecified GSS failure. Minor code may provide more information, 
> Minor = No Kerberos credentials available (default cache: 
> FILE:/tmp/krb5cc_0)._
> _04-Nov-2020 23:29:04.950 gss-api source name (accept) is 
> AD207$@TEST.LOCAL_
> _04-Nov-2020 23:29:04.951 process_gsstkey(): dns_tsigerror_noerror_
> _04-Nov-2020 23:29:04.951 client @0x803875000 10.0.110.207#61795 
> (612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): send_
> _04-Nov-2020 23:29:04.951 client @0x803875000 10.0.110.207#61795 
> (612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): sendto_
> _04-Nov-2020 23:29:04.952 client @0x803875000 10.0.110.207#61795 
> (612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): senddone_
> _04-Nov-2020 23:29:04.952 client @0x803875000 10.0.110.207#61795 
> (612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): next_
> _04-Nov-2020 23:29:04.952 client @0x803875000 10.0.110.207#61795 
> (612-ms-7.11-94d12b.7a3e8427-1ed6-11eb-438f-005056bd8592): endrequest_
> _04-Nov-2020 23:29:04.952 client @0x803875000 10.0.110.207#61795: 
> closetcp_
> _04-Nov-2020 23:29:04.953 client @0x804c11000 10.0.110.207#61795: next_
> _04-Nov-2020 23:29:04.953 client @0x804c11000 10.0.110.207#61795: 
> request failed: end of file_
> _04-Nov-2020 23:29:04.953 client @0x804c11000 10.0.110.207#61795: 
> endrequest_
> _04-Nov-2020 23:29:04.953 client @0x804c11000 10.0.110.207#61795: 
> closetcp_
> _04-Nov-2020 23:29:04.953 client @0x803bfa400 10.0.110.207#51833: UDP 
> request_
> _04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833: using 
> view '_default'_
> _04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833: 
> request has valid signature: AD207\$\@TEST.LOCAL_
> _04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key 
> AD207\$\@TEST.LOCAL: recursion available_
> _04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key 
> AD207\$\@TEST.LOCAL: update_
> _04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key 
> AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': prerequisites are 
> OK_
> _04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key 
> AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': update section 
> prescan OK_
> _04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key 
> AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': deleting rrset at 
> 'ad207.test.local' AAAA_
> _04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key 
> AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': deleting rrset at 
> 'ad207.test.local' A_
> _04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key 
> AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': adding an RR at 
> 'ad207.test.local' A 10.0.110.207_
> _04-Nov-2020 23:29:04.954 client @0x803bfa400 10.0.110.207#51833/key 
> AD207\$\@TEST.LOCAL: updating zone 'test.local/IN': redundant request_

but still update get in and is approved.

The same is accepted also for client from second domain - TEST1.LOCAL
Even I do not have keytab loaded with Principal Name from TEST1.LOCAL, 
update will get in

> _04-Nov-2020 23:31:39.879 client @0x803875000 10.0.110.216#59439 
> (932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): query: 
> 932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2 IN TKEY -T 
> (10.0.50.33)_
> _04-Nov-2020 23:31:39.880 failed gss_inquire_cred: GSSAPI error: Major 
> = Unspecified GSS failure. Minor code may provide more information, 
> Minor = No Kerberos credentials available (default cache: 
> FILE:/tmp/krb5cc_0)._
> _04-Nov-2020 23:31:39.884 gss-api source name (accept) is 
> AD206$@TEST1.LOCAL_
> _04-Nov-2020 23:31:39.884 process_gsstkey(): dns_tsigerror_noerror_
> _04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439 
> (932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): send_
> _04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439 
> (932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): sendto_
> _04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439 
> (932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): senddone_
> _04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439 
> (932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): next_
> _04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439 
> (932-ms-7.51-18e34bc.2db42801-1eb9-11eb-d293-005056bddce2): endrequest_
> _04-Nov-2020 23:31:39.884 client @0x803875000 10.0.110.216#59439: 
> closetcp_
> _04-Nov-2020 23:31:39.885 client @0x804811a00 10.0.110.216#59439: next_
> _04-Nov-2020 23:31:39.885 client @0x804811a00 10.0.110.216#59439: 
> request failed: end of file_
> _04-Nov-2020 23:31:39.885 client @0x804811a00 10.0.110.216#59439: 
> endrequest_
> _04-Nov-2020 23:31:39.885 client @0x804811a00 10.0.110.216#59439: 
> closetcp_
> _04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407: UDP 
> request_
> _04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407: using 
> view '_default'_
> _04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407: 
> request has valid signature: AD206\$\@TEST1.LOCAL_
> _04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key 
> AD206\$\@TEST1.LOCAL: recursion available_
> _04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key 
> AD206\$\@TEST1.LOCAL: update_
> _04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key 
> AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': prerequisites are 
> OK_
> _04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key 
> AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': update section 
> prescan OK_
> _04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key 
> AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': deleting rrset at 
> 'ad206.test1.local' AAAA_
> _04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key 
> AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': deleting rrset at 
> 'ad206.test1.local' A_
> _04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key 
> AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': adding an RR at 
> 'ad206.test1.local' A 10.0.110.206_
> _04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key 
> AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': adding an RR at 
> 'ad206.test1.local' A 10.0.110.216_
> _04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key 
> AD206\$\@TEST1.LOCAL: updating zone 'test1.local/IN': redundant 
> request_
> _04-Nov-2020 23:31:39.886 client @0x803874600 10.0.110.216#53407/key 
> AD206\$\@TEST1.LOCAL: send_

This update was not expected to get accepted.

=======================================

I did modification of test to include tkey-gssapi-credential
where I got more expected result

> tkey-gssapi-credential "DNS/dns2.test.local at TEST.LOCAL";

Update into main domain TEST.LOCAL shows sucessfull GSS

> 04-Nov-2020 23:35:12.167 client @0x803875000 10.0.110.207#60534: query
> 04-Nov-2020 23:35:12.167 client @0x803875000 10.0.110.207#60534 
> (612-ms-7.12-9a6b9d.7a3e8427-1ed6-11eb-438f-005056bd8592): query: 
> 612-ms-7.12-9a6b9d.7a3e8427-1ed6-11eb-438f-005056bd8592 IN TKEY -T 
> (10.0.50.33)
> 04-Nov-2020 23:35:12.168 gss cred: "DNS/dns2.test.local at TEST.LOCAL", 
> GSS_C_ACCEPT, 4294967295
> 04-Nov-2020 23:35:12.170 gss-api source name (accept) is 
> AD207$@TEST.LOCAL
> 04-Nov-2020 23:35:12.170 process_gsstkey(): dns_tsigerror_noerror

with 2nd domain TEST1.LOCAL, ending in error

> 04-Nov-2020 23:36:07.223 client @0x804c11000 10.0.110.216#62340 
> (932-ms-7.53-192491b.2db42801-1eb9-11eb-d293-005056bddce2): query: 
> 932-ms-7.53-192491b.2db42801-1eb9-11eb-d293-005056bddce2 IN TKEY -T 
> (10.0.50.33)
> 04-Nov-2020 23:36:07.224 gss cred: "DNS/dns2.test.local at TEST.LOCAL", 
> GSS_C_ACCEPT, 4294967295
> 04-Nov-2020 23:36:07.224 failed gss_accept_sec_context: GSSAPI error: 
> Major = Unspecified GSS failure. Minor code may provide more 
> information, Minor = Cannot find key for DNS/dns2.test.local at TEST.LOCAL 
> kvno 3 in keytab (request ticket server 
> DNS/dns2.test.local at TEST1.LOCAL).
> 04-Nov-2020 23:36:07.224 process_gsstkey(): dns_tsigerror_badkey

where I understood that I apply explicitly 1 'security credential' to 
verify GSS;
Of course, update for TEST1.LOCAL is not valid for TEST.LOCAL Principal 
name

Other observation:

On my FreeBSD, I think BIND is caching Kerberos into

> root at dns2:~ # ls -la /var/tmp/krb5_53.rcache2
> -rw------- 1 bind wheel 13584 Nov 4 23:56 /var/tmp/krb5_0.rcache2

but log entry points to: _/tmp/krb5cc_0_

Making sum, my concern goes to:

	* is it expected to use single keytab file with multiple Principal Name 
authenticate clients from multiple domains?
In case yes - did my I miss any configuration to be done or I hit area 
which is not covered

In case no, we should be clear on documentation to point to single 
principal name to be used

Appreciate any feedback on this topic.

Best Regards,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20201105/b14b7b78/attachment.htm>

More information about the bind-users mailing list