Bug 7281 - DNS update broken when adding Samba 3.x to AD
Summary: DNS update broken when adding Samba 3.x to AD
Status: RESOLVED WORKSFORME
Alias: None
Product: Samba 3.4
Classification: Unclassified
Component: Client Tools (show other bugs)
Version: 3.4.7
Hardware: x86 Linux
: P3 normal
Target Milestone: ---
Assignee: Volker Lendecke
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-22 21:28 UTC by Brian May
Modified: 2015-12-06 21:03 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brian May 2010-03-22 21:28:36 UTC
As discussed on IRC.

When trying to join a Samba 3.2.5 box (pad) to a Samba 4 AD (bad), bind complains that it can't do the DNS update:

...
23-Mar-2010 12:42:01.115 client: client 172.31.4.13#41028: TCP request
23-Mar-2010 12:42:01.115 client: client 172.31.4.13#41028: using view '_default'
23-Mar-2010 12:42:01.115 security: client 172.31.4.13#41028: request is not signed
23-Mar-2010 12:42:01.115 security: client 172.31.4.13#41028: recursion available
23-Mar-2010 12:42:01.115 client: client 172.31.4.13#41028: update
23-Mar-2010 12:42:01.115 client: client 172.31.4.13#41028: ns_client_attach: ref = 1
23-Mar-2010 12:42:01.115 client: client @0xb507f008: accept
23-Mar-2010 12:42:01.115 general: sockmgr 0xb6c19008: watcher got message -3 for socket 22
23-Mar-2010 12:42:01.115 general: sockmgr 0xb6c19008: watcher got message -2 for socket -1
23-Mar-2010 12:42:01.115 update: client 172.31.4.13#41028: updating zone 'ad.vpac.org/IN': update unsuccessful: pad.ad.vpac.org/A: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
23-Mar-2010 12:42:01.115 update: client 172.31.4.13#41028: updating zone 'ad.vpac.org/IN': rolling back
23-Mar-2010 12:42:01.115 client: client 172.31.4.13#41028: send
23-Mar-2010 12:42:01.116 client: client 172.31.4.13#41028: sendto
23-Mar-2010 12:42:01.116 client: client 172.31.4.13#41028: senddone
23-Mar-2010 12:42:01.116 client: client 172.31.4.13#41028: next
23-Mar-2010 12:42:01.116 client: client 172.31.4.13#41028: ns_client_detach: ref = 0
23-Mar-2010 12:42:01.116 client: client 172.31.4.13#41028: endrequest
23-Mar-2010 12:42:01.116 client: client 172.31.4.13#41028: read
23-Mar-2010 12:42:01.116 general: socket 0xb521e178 172.31.4.13#41028: packet received correctly
23-Mar-2010 12:42:01.116 general: sockmgr 0xb6c19008: watcher got message -3 for socket 25
23-Mar-2010 12:42:01.116 general: sockmgr 0xb6c19008: watcher got message -2 for socket -1
23-Mar-2010 12:42:01.116 general: socket 0xb521e178: socket_recv: event 0xb52122d8 -> task 0xb6c2c858
23-Mar-2010 12:42:01.155 general: socket 0xb521e178: dispatch_recv:  event 0xb52122d8 -> task 0xb6c2c858
23-Mar-2010 12:42:01.155 general: socket 0xb521e178: internal_recv: task 0xb6c2c858 got event 0xb521e1ec
23-Mar-2010 12:42:01.155 general: socket 0xb521e178 172.31.4.13#41028: packet received correctly
23-Mar-2010 12:42:01.155 client: client 172.31.4.13#41028: TCP request
23-Mar-2010 12:42:01.155 client: client 172.31.4.13#41028: using view '_default'
23-Mar-2010 12:42:01.155 security: client 172.31.4.13#41028: request is not signed
23-Mar-2010 12:42:01.155 security: client 172.31.4.13#41028: recursion available
23-Mar-2010 12:42:01.155 client: client 172.31.4.13#41028: update
23-Mar-2010 12:42:01.155 client: client 172.31.4.13#41028: ns_client_attach: ref = 1
23-Mar-2010 12:42:01.155 update: client 172.31.4.13#41028: updating zone 'ad.vpac.org/IN': prerequisites are OK
23-Mar-2010 12:42:01.155 update: client 172.31.4.13#41028: updating zone 'ad.vpac.org/IN': update failed: rejected by secure update (REFUSED)
23-Mar-2010 12:42:01.155 update: client 172.31.4.13#41028: updating zone 'ad.vpac.org/IN': rolling back
23-Mar-2010 12:42:01.155 client: client 172.31.4.13#41028: send
23-Mar-2010 12:42:01.155 client: client 172.31.4.13#41028: sendto
...

However there is no evidence of any existing DNS entry pad.ad.vpac.org/A.

bind is version  1:9.7.0.dfsg.P1-1 from Debian/unstable with the patches applied from the samba-master tree.

Later on in the logs I see this suspicious line, but as it happens afterwards I suspect this is a symptom of the above problem:

23-Mar-2010 12:42:01.186 general: gss cred: "DNS/ad.vpac.org@AD.VPAC.ORG", GSS_C_ACCEPT, 4294967285
23-Mar-2010 12:42:01.187 general: failed gss_accept_sec_context: GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more information, Minor = Wrong principal in request.
23-Mar-2010 12:42:01.187 general: process_gsstkey(): dns_tsigerror_badkey


Brian May
Comment 1 Brian May 2010-03-23 18:55:25 UTC
Samba makes two DNS update requests. As expected, both fail, from wireshark:

Domain Name System (query)
    Length: 149
    Transaction ID: 0x4567
    Flags: 0x2800 (Dynamic update)
        0... .... .... .... = Response: Message is a query
        .010 1... .... .... = Opcode: Dynamic update (5)
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... .0.. .... = Z: reserved (0)
        .... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable
    Zones: 1
    Prerequisites: 4
    Updates: 0
    Additional RRs: 0
    Zone
        ad.vpac.org: type SOA, class IN
            Name: ad.vpac.org
            Type: SOA (Start of zone of authority)
            Class: IN (0x0001)
    Prerequisites
        pad.ad.vpac.org: type CNAME, class NONE
            Name: pad.ad.vpac.org
            Type: CNAME (Canonical name for an alias)
            Class: NONE (0x00fe)
            Time to live: 0 time
            Data length: 0
        pad.ad.vpac.org: type A, class IN, addr 172.31.4.13
            Name: pad.ad.vpac.org
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 0 time
            Data length: 4
            Addr: 172.31.4.13
        pad.ad.vpac.org: type A, class IN, addr 172.31.4.13
            Name: pad.ad.vpac.org
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 0 time
            Data length: 4
            Addr: 172.31.4.13
        pad.ad.vpac.org: type A, class IN, addr 172.31.4.13
            Name: pad.ad.vpac.org
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 0 time
            Data length: 4
            Addr: 172.31.4.13

pad.ad.vpac.org doesn't exist yet, so of course the Prerequisites are going to fail. Not sure if all Prerequisites must succeed or only one, it seems strange it is asking for both CNAME and A records.


    Prerequisites
        pad.ad.vpac.org: type CNAME, class NONE
            Name: pad.ad.vpac.org
            Type: CNAME (Canonical name for an alias)
            Class: NONE (0x00fe)
            Time to live: 0 time
            Data length: 0
    Updates
        pad.ad.vpac.org: type A, class ANY
            Name: pad.ad.vpac.org
            Type: A (Host address)
            Class: ANY (0x00ff)
            Time to live: 0 time
            Data length: 0
        pad.ad.vpac.org: type A, class IN, addr 172.31.4.13
            Name: pad.ad.vpac.org
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 1 hour
            Data length: 4
            Addr: 172.31.4.13
        pad.ad.vpac.org: type A, class IN, addr 172.31.4.13
            Name: pad.ad.vpac.org
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 1 hour
            Data length: 4
            Addr: 172.31.4.13
        pad.ad.vpac.org: type A, class IN, addr 172.31.4.13
            Name: pad.ad.vpac.org
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 1 hour
            Data length: 4
            Addr: 172.31.4.13

Again, pad.ad.vpac.org CNAME record doesn't exist - and in fact we don't want it to exist. Why are we updating the A record three (if not four) times?
Comment 2 Brian May 2010-03-23 19:02:28 UTC
Disregard previous response, looks like I am getting mislead by errors. I think the error I was debugging was expected, I think Samba was just checking to make sure the DNS entries didn't exist before doing an update. Now looking at the *real* error ("Refused").

Brian May
Comment 3 Brian May 2010-03-23 19:06:48 UTC
This is the response to the last packet I quoted before, the one that does the actual update:

Domain Name System (response)
    [Request In: 122]
    [Time: 0.000478000 seconds]
    Length: 29
    Transaction ID: 0x23c6
    Flags: 0xa885 (Dynamic update response, Refused)
        1... .... .... .... = Response: Message is a response
        .010 1... .... .... = Opcode: Dynamic update (5)
        .... .0.. .... .... = Authoritative: Server is not an authority for domain
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... 1... .... = Recursion available: Server can do recursive queries
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
        .... .... .... 0101 = Reply code: Refused (5)
    Zones: 1
    Prerequisites: 0
    Updates: 0
    Additional RRs: 0
    Zone
        ad.vpac.org: type SOA, class IN
            Name: ad.vpac.org
            Type: SOA (Start of zone of authority)
            Class: IN (0x0001)

I also note the log message "prerequisites are OK" just prior to the REFUSED message in the log I quoted. This is starting to look like a bind permission issue.

Brian May
Comment 4 Brian May 2010-03-23 19:34:50 UTC
I think the entire issues falls down to one line in the logs:

23-Mar-2010 12:42:01.155 security: client 172.31.4.13#41028: request is not
signed

Looking at lib/dns/ssu.c, dns_ssutable_checkrules function, it appears for ms-self matches, bind9 requires the request be signed:

        case DNS_SSUMATCHTYPE_SELFKRB5:
        case DNS_SSUMATCHTYPE_SELFMS:
        case DNS_SSUMATCHTYPE_SUBDOMAINKRB5:
        case DNS_SSUMATCHTYPE_SUBDOMAINMS:
            if (signer == NULL)
                continue;       
            break;      

So why isn't the request signed? Is this expected?
Comment 5 Brian May 2010-03-23 19:38:21 UTC
This is samba version 3.4.7~dfsg-1, so it is recent.
Comment 6 Brian May 2010-03-23 23:57:23 UTC
Hello,

I was under the impression that Samba 3.x is meant to work fine as a member of an AD domain.

However Andrew Tridgell has indicated that Samba may never have had support for signing (TSIG?) because it is rather complicated.

This seems to contradict the idea that Samba 3.x will work find as a member of an AD domain however, because it appears this signing is a requirement to get the DNS entries correct.

Looking at the bind code, it appears that signing is required in order to authenticate who is making the change, otherwise anybody could submit changes. Older versions of bind have the same code.

Just a thought: Is it possible we are using the word "signing" to mean different things?

Brian May
Comment 7 Brian May 2010-03-24 21:10:07 UTC
My brain hurts. Made the following change to Samba and it fixed the problem.

--- samba-3.4.7~dfsg.orig/source3/utils/net_ads.c
+++ samba-3.4.7~dfsg/source3/utils/net_ads.c
@@ -201,7 +201,8 @@ static int net_ads_info(struct net_conte
 static void use_in_memory_ccache(void) {
        /* Use in-memory credentials cache so we do not interfere with
         * existing credentials */
-       setenv(KRB5_ENV_CCNAME, "MEMORY:net_ads", 1);
+//     setenv(KRB5_ENV_CCNAME, "MEMORY:net_ads", 1);
+       setenv(KRB5_ENV_CCNAME, "FILE:/tmp/net_ads", 1);
 }
 
 static ADS_STATUS ads_startup_int(struct net_context *c, bool only_own_domain,


This wasn't suppose to fix anything!

Anyway my theory is that this error is significant: "general: failed gss_accept_sec_context: GSSAPI error:
Major = Unspecified GSS failure.  Minor code may provide more information,
Minor = Wrong principal in request."

Really don't understand how the above change "fixed" anything though. Just to check I went to the old code and it broke again.

Brian May
Comment 8 Andrew Bartlett 2010-03-25 06:30:16 UTC
perhaps the Samba3 code was originally written and tested against Heimdal, but Brian uses a not very latest MIT Kerberos?  (MEMORY: keytabs were supported in Heimdal much earlier).

A simple fix with mkstemp() would seem to be the correct fix. 
Comment 9 Brian May 2010-03-25 17:03:45 UTC
Hmmm... Good theory.

Only problem is this is box is now Debian/unstable. It appears net is linked with MIT Kerberos version 1.8+dfsg~alpha1-7, which I assume should be recent.

Still, it is possible that MEMORY ccache support is broken in this version of MIT Kerberos...

Brian May
Comment 10 Björn Jacke 2015-12-06 21:03:16 UTC
i think this is not a problem anymore with recent distributions. i see mainly a wrong fqdn of the member server cause problems for dns updates. if you still see the error desceibed here, please reopen and add details on the setup here.