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@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@TEST.LOCAL_
_root@dns2:~ # kinit -k -t /usr/local/etc/namedb/working/keytab.krb5
DNS/dns2.test.local@TEST.LOCAL_
_root@dns2:~ # klist_
_Credentials cache: FILE:/tmp/krb5cc_0_
_Principal: DNS/dns2.test.local@TEST.LOCAL_
_Issued Expires Principal_
_Nov 4 23:28:05 2020 Nov 5 09:28:03 2020 krbtgt/TEST.LOCAL@TEST.LOCAL_
_root@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@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@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@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@TEST.LOCAL
kvno 3 in keytab (request ticket server
DNS/dns2.test.local@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@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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
