Re: GSS-TSIG updates from Windows clients

2014-05-06 Thread Nicholas F Miller 
You might try changing your update-policy from:

grant johnmill-dnst...@lab.brandeis.edu zonesub ANY;
grant * zonesub ANY;

to

grant johnmill-dnst...@lab.brandeis.edu zonesub ANY;
grant LAB.BRANDEIS.EDU zonesub ANY;

I’m not positive this is the proper syntax since we don’t use the zonesub 
option. We use the ms-subdomain and krb5-subdomain options:

grant LAB.BRANDEIS.EDU ms-subdomain LAB.BRANDEIS.EDU;
grant LAB.BRANDEIS.EDU krb5-subdomain LAB.BRANDEIS.EDU;

_
Nicholas Miller, OIT, University of Colorado at Boulder




On May 2, 2014, at 5:16 PM, John Miller johnm...@brandeis.edu wrote:

 Hi folks,
 
 I'm trying to get our AD domain controllers to update our BIND 9.8.2 
 servers--specifically for the zone
 
 _msdcs.lab.brandeis.edu.
 
 I've got updates working in general: I can run kinit username@REALM 
 (johnmill-dns-t...@lab.brandeis.edu in this case), then successfully run 
 nsupdate -g from my desktop:
 
 server dns-ext-dev1.lab.brandeis.edu
 zone _msdcs.lab.brandeis.edu.
 update add yourmom._msdcs.lab.brandeis.edu. 300 IN A 127.0.0.1
 send
 
 This works fine--I grab the necessary tickets from our domain controllers, 
 and BIND accepts my update.
 
 My update-policy {} directive for the zone looks like:
 
 update-policy {
   grant johnmill-dnst...@lab.brandeis.edu zonesub ANY;
   grant * zonesub ANY;
 }
 
 This is uber-lenient--I don't plan to leave things this way. but the wildcard 
 should allow anything with a pulse to update.
 
 When I try to use Windows (the domain controller itself) to send updates, the 
 update first gets sent insecurely (which fails), then Windows attempts secure 
 authentication (and succeeds), but doesn't actually send a secured update:
 
 named[13861]: client 129.64.102.112#64501: UDP request
 named[13861]: client 129.64.102.112#64501: using view '_default'
 named[13861]: client 129.64.102.112#64501: request is not signed
 named[13861]: client 129.64.102.112#64501: recursion not available
 named[13861]: client 129.64.102.112#64501: update
 named[13861]: client 129.64.102.112#64501: update 
 '_msdcs.lab.brandeis.edu/IN' denied
 named[13861]: client 129.64.102.112#64501: send
 named[13861]: client 129.64.102.112#64501: sendto
 named[13861]: client 129.64.102.112#64501: senddone
 named[13861]: client 129.64.102.112#64501: next
 named[13861]: client 129.64.102.112#64501: endrequest
 named[13861]: client @0x7f75640f6980: udprecv
 named[13861]: client 129.64.102.112#52448: new TCP connection
 named[13861]: client 129.64.102.112#52448: replace
 named[13861]: clientmgr @0x7f7564003f98: createclients
 named[13861]: clientmgr @0x7f7564003f98: recycle
 named[13861]: client 129.64.102.112#52448: read
 named[13861]: client 129.64.102.112#52448: TCP request
 named[13861]: client 129.64.102.112#52448: using view '_default'
 named[13861]: client 129.64.102.112#52448: request is not signed
 named[13861]: client 129.64.102.112#52448: recursion not available
 named[13861]: client 129.64.102.112#52448: query
 named[13861]: failed gss_inquire_cred: GSSAPI error: Major = Unspecified GSS 
 failure.  Minor code may provide more information, Minor = Success.
 named[13861]: gss-api source name (accept) is AD-2K8-DEV1$@LAB.BRANDEIS.EDU
 named[13861]: process_gsstkey(): dns_tsigerror_noerror
 named[13861]: client 129.64.102.112#52448: send
 named[13861]: client 129.64.102.112#52448: sendto
 named[13861]: client 129.64.102.112#52448: senddone
 named[13861]: client 129.64.102.112#52448: next
 named[13861]: client 129.64.102.112#52448: endrequest
 named[13861]: client 129.64.102.112#52448: read
 named[13861]: client @0x7f7564104b70: accept
 named[13861]: client 129.64.102.112#52448: next
 named[13861]: client 129.64.102.112#52448: request failed: end of file
 named[13861]: client 129.64.102.112#52448: endrequest
 named[13861]: client 129.64.102.112#52448: closetcp
 named[13861]: client 129.64.102.112#64230: UDP request
 named[13861]: client 129.64.102.112#64230: using view '_default'
 named[13861]: client 129.64.102.112#64230: request is not signed
 named[13861]: client 129.64.102.112#64230: recursion not available
 named[13861]: client 129.64.102.112#64230: query
 named[13861]: client 129.64.102.112#64230: query 
 '_msdcs.lab.brandeis.edu/SOA/IN' approved
 named[13861]: client 129.64.102.112#64230: send
 named[13861]: client 129.64.102.112#64230: sendto
 named[13861]: client 129.64.102.112#64230: senddone
 named[13861]: client 129.64.102.112#64230: next
 named[13861]: client 129.64.102.112#64230: endrequest
 named[13861]: client @0x7f75640f6980: udprecv
 named[13861]: client 129.64.102.112#63381: UDP request
 named[13861]: client 129.64.102.112#63381: using view '_default'
 named[13861]: client 129.64.102.112#63381: request is not signed
 named[13861]: client 129.64.102.112#63381: recursion not available
 named[13861]: client 129.64.102.112#63381: query
 named[13861]: client 129.64.102.112#63381: query (cache)

Re: GSS-TSIG updates from Windows clients

2014-05-06 Thread John Miller 
Thanks to both Mark and Nicholas for the help.  Unfortunately, still not 
able to get this working (BIND 9.8.2 (RHEL 6)  AD 2008R2).  It's a case 
of AD negotiating a TKEY (successfully), then reverting back to unsigned 
updates.  If an update's not signed, doesn't matter what your 
update-policy statements look like.


We're just going to continue with unsigned updates (or manual-only 
updates).  I'd still like to solve the problem, but probably won't go 
into production with it.


Some possible insight in the comments of:

http://netlinxinc.com/netlinx-blog/45-dns/136-how-to-implement-gss-tsig-on-isc-bind.html

Windows 7 and Windows 2008 R2 have changed their behavior in regards to 
dynamic updates and how they send signed updates to BIND DNS servers. 
These new operating systems will first send an “unsigned” update to a 
DNS server and will only revert to a “signed” update if there is 
additional information provided in the response DNS message. Earlier 
operating systems would automatically revert to signed updates as the 
next sequence in the dynamic update process. Current versions of BIND 9 
do not place the additional header information in the response package, 
so the Windows 7 and 2008 servers will not revert. There is a patch that 
you can apply (manually) and re-compile that works.


Evidently AD expects additional records in the TKEY response, otherwise 
we see the behavior I'm seeing.  I've attached a pcap of a sample TKEY 
response and a sample unsigned update rejection; if any of you have this 
working, would you mind listing your BIND and AD versions, as well as 
posting some sample packet output?  I'd be curious to see how our 
environment differs from yours.


John



On 05/06/2014 10:15 AM, Nicholas F Miller wrote:

You might try changing your update-policy from:

grant johnmill-dnst...@lab.brandeis.edu zonesub ANY;
grant * zonesub ANY;

to

grant johnmill-dnst...@lab.brandeis.edu zonesub ANY;
grant LAB.BRANDEIS.EDU zonesub ANY;

I’m not positive this is the proper syntax since we don’t use the zonesub 
option. We use the ms-subdomain and krb5-subdomain options:

grant LAB.BRANDEIS.EDU ms-subdomain LAB.BRANDEIS.EDU;
grant LAB.BRANDEIS.EDU krb5-subdomain LAB.BRANDEIS.EDU;

_
Nicholas Miller, OIT, University of Colorado at Boulder



tkey_no_addl.pcap
Description: application/vnd.tcpdump.pcap


update_refused.pcap
Description: application/vnd.tcpdump.pcap
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: GSS-TSIG updates from Windows clients

2014-05-02 Thread Mark Andrews 

See
tkey-gssapi-credential quoted_string;
tkey-gssapi-keytab quoted_string;
grant  ms-subdomain ;


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users