Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Samba] Join AD fails DNS update

3,284 views
Skip to first unread message

Lars Hanke

unread,
Jun 24, 2014, 9:40:02 AM6/24/14
to
This topic has been on the list two years ago, already, but apparently
to no conclusion.

I'm trying to join a Debian Wheezy machine (Samba 3.6.6) to my freshly
made backports AD (Samba 4.1.7). This is what I see:

root@samba4:/# net ads join -U Admini...@AD.MICROSULT.DE
Enter Admini...@AD.MICROSULT.DE's password:
Using short domain name -- AD
Joined 'SAMBA4' to realm 'ad.microsult.de'
DNS Update for samba4.ad.microsult.de failed: ERROR_DNS_INVALID_MESSAGE
DNS update failed!
root@samba4:/# host samba4.ad.microsult.de
Host samba4.ad.microsult.de not found: 3(NXDOMAIN)
root@samba4:/# net --version
Version 3.6.6

The old discussion (e.g.
http://www.spinics.net/lists/samba/msg102650.html) recommended to ignore
the message, but it stipulates that at least sometimes the client entry
was added. I didn't see any DNS update so far. I use DLZ like them.

Any idea how to troubleshoot this situation?

Kind regards,
- lars.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

steve

unread,
Jun 24, 2014, 10:10:02 AM6/24/14
to
On Tue, 2014-06-24 at 15:34 +0200, Lars Hanke wrote:
> This topic has been on the list two years ago, already, but apparently
> to no conclusion.
>
> I'm trying to join a Debian Wheezy machine (Samba 3.6.6) to my freshly
> made backports AD (Samba 4.1.7). This is what I see:
>
> root@samba4:/# net ads join -U Admini...@AD.MICROSULT.DE
> Enter Admini...@AD.MICROSULT.DE's password:
> Using short domain name -- AD
> Joined 'SAMBA4' to realm 'ad.microsult.de'
> DNS Update for samba4.ad.microsult.de failed: ERROR_DNS_INVALID_MESSAGE
> DNS update failed!
> root@samba4:/# host samba4.ad.microsult.de
> Host samba4.ad.microsult.de not found: 3(NXDOMAIN)
> root@samba4:/# net --version
> Version 3.6.6
>
> The old discussion (e.g.
> http://www.spinics.net/lists/samba/msg102650.html) recommended to ignore
> the message, but it stipulates that at least sometimes the client entry
> was added. I didn't see any DNS update so far. I use DLZ like them.
>
> Any idea how to troubleshoot this situation?

You do not need to register the machine in dns but you may as well get
it right:
The hostname that your client is sending is not the hostname of the
machine you are attempting to join. You need to edit /etc/hostname
and /etc/hosts and a few other things. This is for Ubuntu. I think
debian is the same for dns:
http://linuxcostablanca.blogspot.com.es/2014/05/dns-good-enough-for-kerberos.html

Unless you are running a service that clients need to discover,
(frighteningly) the machine you join does not need to be registered in
DNS. The only requirement for AD is a keytab.
HTH
Steve

L.P.H. van Belle

unread,
Jun 24, 2014, 10:10:02 AM6/24/14
to
What you can do is the following.

setup the resolv.conf
domain yourinternal.domain.tld
search yourinternal.domain.tld
nameserver IP_OF_YOUR_AD_SERVER

second.
check you hosts file
127.0.0.1 localhost localhost.localdomain.
IP_OF_THIS_SERVER hostname.yourinternal.domain.tld

( or put this in /etc/network/interfaces dns-domain dns-search dns-nameserver )
( or if you use resolvconf /etc/resolvconf/resolv.conf.d )

test ping hostname.domain.tld for your AD server.
If that does not work, add the ip / FQHN of you server to the hosts file.
but it should not be needed.

third.
krb5.conf
[libdefaults]
dns_lookup_realm = false
dns_lookup_kdc = true
default_realm = YOURINTERNAL.DOMAIN.TLD << IN CAPS !


setup your smb.conf ( from a 4.1.7 debian backports samba )
[global]
workgroup = INTERNAL
security = ADS
realm = YOURINTERNAL.DOMAIN.TLD << IN CAPS
encrypt passwords = yes

netbios name = HOSTNAME << IN CAPS
domain master = no
host msdfs = no

dedicated keytab file = /etc/krb5.keytab
kerberos method = secrets and keytab
client signing = if_required

## map id's outside to domain to tdb files.
idmap config *:backend = tdb
idmap config *:range = 50001-80000
## map ids from the domain the range may not overlap !
idmap config INTERNAL:backend = ad
idmap config INTERNAL:schema_mode = rfc2307
idmap config INTERNAL:range = 10000-40000

winbind nss info = rfc2307
winbind trusted domains only = no
winbind use default domain = yes
winbind enum users = yes
winbind enum groups = yes
winbind refresh tickets = yes
winbind offline logon = yes


net ads join -U Administrator

If you join and you get a dns error when adding.
Did you already added the hostname of the server in the AD DNS?
If So, thats why you get and error. Ignore it, and check if your member server joined the domain in the AD.

Should works, im having also a samba 3.6.6 in my wheezy sernet setup.
but if this still doesnt work, add wheezy-backport in your apt.sources
and upgrade 3.6.6 to the latest backports version, that one im using for my proxy setup.
for your sources.list if needed.
deb http://ftp.debian.org/debian/ wheezy-backports main contrib non-free

apt-get update and check with apt-cache policy samba before upgradeing.


Louis


>-----Oorspronkelijk bericht-----
>Van: deb...@lhanke.de [mailto:samba-...@lists.samba.org]
>Namens Lars Hanke
>Verzonden: dinsdag 24 juni 2014 15:35
>Aan: sa...@lists.samba.org
>Onderwerp: [Samba] Join AD fails DNS update

Rowland Penny

unread,
Jun 24, 2014, 10:40:02 AM6/24/14
to
Er Louis, I think that I have told you this before, but anyway, if you
read 'man resolv.conf' you will find this:

The domain and search keywords are mutually exclusive. If more than one
instance of these keywords is present, the last instance wins.

So in the resolv.conf that you suggested, the line 'domain
yourinternal.domain.tld' will be ignored, so why add it??

Rowland

Lars Hanke

unread,
Jun 24, 2014, 12:10:06 PM6/24/14
to
Hi,

> setup the resolv.conf
My resolv.conf looks okay and I can resolve other AD specific stuff.

> check you hosts file
> 127.0.0.1 localhost localhost.localdomain.
> IP_OF_THIS_SERVER hostname.yourinternal.domain.tld

It looks like that, but has hostname as second alternative. This is
strange, since /etc/nsswitch.conf has:

hosts: files dns

and is still unable to resolve hostname.yourinternal.domain.tld. This
doesn't change, if I remove the hostname alias.

> test ping hostname.domain.tld for your AD server.
works fine!

> krb5.conf
I added:
> [libdefaults]
> dns_lookup_realm = false
> dns_lookup_kdc = true
but no change. However, I can do 'kinit Administrator' successfully,
i.e. the Kerberos subsystem seems to work.

> setup your smb.conf ( from a 4.1.7 debian backports samba )
My smb.conf is a little leaner still, but I guess that some of the
options are for more advanced usage than a simple join. I hate to add
configuration options, which I do not understand. But I'll use it as a
guide when I advance further.

> net ads join -U Administrator
>
> If you join and you get a dns error when adding.
> Did you already added the hostname of the server in the AD DNS?
> If So, thats why you get and error. Ignore it, and check if your member server joined the domain in the AD.

Okay, here we probably come closer. The syslog of the AD DC has:

Jun 24 15:24:44 samba named[7248]: samba_dlz: starting transaction on
zone ad.microsult.de
Jun 24 15:24:44 samba named[7248]: client 172.16.6.242#38702: updating
zone 'ad.microsult.de/NONE': update unsuccessful:
samba4.ad.microsult.de/A: 'RRset exists (value dependent)' prerequisite
not satisfied (NXRRSET)
Jun 24 15:24:44 samba named[7248]: samba_dlz: cancelling transaction on
zone ad.microsult.de
Jun 24 15:24:44 samba named[7248]: samba_dlz: starting transaction on
zone ad.microsult.de
Jun 24 15:24:44 samba named[7248]: samba_dlz: spnego update failed
Jun 24 15:24:44 samba named[7248]: client 172.16.6.242#38702: updating
zone 'ad.microsult.de/NONE': update failed: rejected by secure update
(REFUSED)
Jun 24 15:24:44 samba named[7248]: samba_dlz: cancelling transaction on
zone ad.microsult.de

BUT:

root@samba:/# dig @samba samba4.ad.microsult.de

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @samba samba4.ad.microsult.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40150
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;samba4.ad.microsult.de. IN A

;; AUTHORITY SECTION:
ad.microsult.de. 0 IN SOA samba.ad.microsult.de.
hostmaster.ad.microsult.de. 1 900 600 86400 0

;; Query time: 27 msec
;; SERVER: 172.16.6.240#53(172.16.6.240)
;; WHEN: Tue Jun 24 18:02:18 2014
;; MSG SIZE rcvd: 93

So DLZ claims that the entry exists, but it cannot be accessed by Bind.
Any ideas?

steve

unread,
Jun 24, 2014, 1:10:02 PM6/24/14
to
On Tue, 2014-06-24 at 18:06 +0200, Lars Hanke wrote:

>
> So DLZ claims that the entry exists, but it cannot be accessed by Bind.
> Any ideas?

Tidy up the stale records:
http://linuxcostablanca.blogspot.com.es/2013/09/samba4-bind9dlz-stale-dns-records-with.html

steve

unread,
Jun 24, 2014, 1:10:02 PM6/24/14
to
On Tue, 2014-06-24 at 18:06 +0200, Lars Hanke wrote:
> Hi,
>
> > setup the resolv.conf
> My resolv.conf looks okay and I can resolve other AD specific stuff.
>
> > check you hosts file
> > 127.0.0.1 localhost localhost.localdomain.
> > IP_OF_THIS_SERVER hostname.yourinternal.domain.tld

The ONLY way we can get it to register upon domain join is:

/etc/hosts
127.0.0.1 fqdn hostname localhost

Lose the IP_OF_THIS_SERVER for the join.

And /etc/hostname
fqdn

1. net ads leave -UAdministrator
2. remove the A record on the DC
3. net ads join -UAdministrator

Nothing else works on Ubuntu. YMMV on deb.
Steve

Lars Hanke

unread,
Jun 24, 2014, 2:10:02 PM6/24/14
to
> The ONLY way we can get it to register upon domain join is:
>
> /etc/hosts
> 127.0.0.1 fqdn hostname localhost
>
> And /etc/hostname
> fqdn
>
> 1. net ads leave -UAdministrator
> 2. remove the A record on the DC
> 3. net ads join -UAdministrator

Left the domain, changed /etc/hosts and /etc/hostname, couldn't remove
any A record (see other post), joined again => same situation.

However, after leaving the dn:
CN=samba4,CN=Computers,DC=ad,DC=microsult,DC=de in sam.ldb was gone on
the AD DC. After joining a new one appeared. So the join seems to work.

Regards,
- lars.

Lars Hanke

unread,
Jun 24, 2014, 2:10:02 PM6/24/14
to

>> So DLZ claims that the entry exists, but it cannot be accessed by Bind.
>> Any ideas?
> Tidy up the stale records:
> http://linuxcostablanca.blogspot.com.es/2013/09/samba4-bind9dlz-stale-dns-records-with.html

Tried that, but I see a different LDAP structure than stipulated in the
post. I can do

ldbsearch --url=/srv/files/private/sam.ldb | grep MicrosoftDNS

which produces DN of root servers but none of the local DNS entries. On
the other hand these entries exist, e.g.:

root@samba:/# host -t SRV _ldap._tcp.ad.microsult.de
_ldap._tcp.ad.microsult.de has SRV record 0 100 389 samba.ad.microsult.de.
root@samba:/# ldbsearch --url=/srv/files/private/sam.ldb | grep _ldap
root@samba:/#

This stuff is definitely not listed in any hosts files. I can also
search for the new hostname, which occurs in a single DN

dn: CN=samba4,CN=Computers,DC=ad,DC=microsult,DC=de

i.e. nothing about DNS. On the other hand it seems like the join was
successful. Is sam.ldb probably the wrong database to look for DNS?

Regards,
- lars.

steve

unread,
Jun 24, 2014, 2:40:02 PM6/24/14
to
On Tue, 2014-06-24 at 20:07 +0200, Lars Hanke wrote:
> > The ONLY way we can get it to register upon domain join is:
> >
> > /etc/hosts
> > 127.0.0.1 fqdn hostname localhost
> >
> > And /etc/hostname
> > fqdn
> >
> > 1. net ads leave -UAdministrator
> > 2. remove the A record on the DC
> > 3. net ads join -UAdministrator
>
> Left the domain, changed /etc/hosts and /etc/hostname, couldn't remove
> any A record (see other post), joined again => same situation.
>
> However, after leaving the dn:
> CN=samba4,CN=Computers,DC=ad,DC=microsult,DC=de in sam.ldb was gone on
> the AD DC. After joining a new one appeared. So the join seems to work.
>
> Regards,
> - lars.

Hi lars
Is there a pressing reason to have the Samba box registered in DNS? It
is very difficult to do and is not necessary unless you are running any
kerberized service on it. For an AD client or a samba file server all
you need is a keytab.
Just a thought. . .
Steve

Lars Hanke

unread,
Jun 24, 2014, 3:10:02 PM6/24/14
to
Hi Steve,

currently there is no pressing reason. I can register the machines in
another DNS domain to make them accessible.

However, the notion that I do not understand the elementary basics, e.g.
where samba stores its DNS entries, gives an uneasy feeling for creating
a production solution. If something doesn't work and I know why, I can
decide whether I can cope with that. Life has taught me that if
something doesn't work and you don't know why, it will hit you even
harder later.

In case that this is an actual bug, I'd like to hunt it down to either
file it properly, or even provide a patch. It's been out there for at
least 2 years! But since I'm new to samba4 and AD (not to LDAP,
Kerberos, or samba), I acknowledge that I do not understand its full
complexity.

Regards,
-lars.

Rowland Penny

unread,
Jun 24, 2014, 3:30:03 PM6/24/14
to
On 24/06/14 20:08, Lars Hanke wrote:
> Hi Steve,
>
> currently there is no pressing reason. I can register the machines in
> another DNS domain to make them accessible.
>
> However, the notion that I do not understand the elementary basics,
> e.g. where samba stores its DNS entries, gives an uneasy feeling for
> creating a production solution. If something doesn't work and I know
> why, I can decide whether I can cope with that. Life has taught me
> that if something doesn't work and you don't know why, it will hit you
> even harder later.
The problem is probably that you are only searching on port 389, try
this search:

ldbsearch -LLL -x -h localhost -p 3268 -b "DC=example,DC=com" -s sub -D
"CN=Administrator,CN=Users,DC=example,DC=com" -w <ADpassword>

Rowland

L.P.H. van Belle

unread,
Jun 25, 2014, 3:40:01 AM6/25/14
to

And Again, there are 2 ways how resolving is done... read the last part, i've put in a example...

And, yes i know that....

>The domain and search keywords are mutually exclusive. If
>more than one instance of these keywords is present, the last instance wins.

And yes, above is correct

but you really need to understand that putting the domain there also make this much easier to understand for none experienced users.

>> the domain name is determined from the hostname and the domain search path is constructed from the domain name.
and
>> The search list is normally determined from the local domain name; by default, it contains only the local domain name.
This may be changed by listing the desired domain search path following
and
>> The domain and search keywords are mutually exclusive. If more than one instance of these keywords is present, the last instance wins.

And to make sure you set the correct domain/search you can put it like this, it wont hurt, it isnt wrong and it helps people put in the correct domain/search.
it just adds the primary domain in the search 2 times.

This is not wrong.
domain search1.domain
search search1.domain
nameserver 1.1.1.1

this is the same and also not wrong..
search search1.domain
nameserver 1.1.1.1

and this is also the same, and not wrong.
domain search1.domain
nameserver 1.1.1.1

but which one helps a newbe the most with what he/she is do-ing.

....

even...
this is the same and not wrong. ( if you installed the right way )
nameserver 1.1.1.1

and dont forget this one.

man gethostname
>> The GNU C library does not employ the gethostname() system call; instead, it implements gethostname() as a library function that calls uname(2)


To draw another parallel, you seem to want the output of the command hostname --fqdn (which depends on the resolver), while others want hostname .
getfqdn seems to return a different result than gethostname if the hostname of the machine is an alias.


For example if I have this in /etc/hosts and with some python testing.

127.0.0.1 localhost localhost.localdomain localhost2 localhost2.localdomain2 mypersonaldomainname.tld


python -c 'import socket; print socket.getfqdn()'
gives localhost.localdomain

python -c 'import socket; print socket.gethostname()'
gives mypersonaldomainname.tld


and same with cfengine.
P.S. cfengine has sys.fqhost, sys.domain, sys.uqhost (which seem to be DNS based) and sys.host (which seems to be extracted from uname)

I hope its now more clear.

Best regards,

Louis

L.P.H. van Belle

unread,
Jun 25, 2014, 3:50:01 AM6/25/14
to
...
for kerberos to work you need to have a A and PTR record aka good working dns setup.

but if you only need kerberos for auth on a server, and you dont want to do a domain join.
This is a good example to look in to, which i can tell works very good.
https://community.zarafa.com/pg/blog/read/18332/zarafa-outlook-amp-webaccess-sso-with-samba4


Louis

>-----Oorspronkelijk bericht-----
>Van: st...@steve-ss.com [mailto:samba-...@lists.samba.org]
>Namens steve
>Verzonden: dinsdag 24 juni 2014 20:34
>Aan: sa...@lists.samba.org
>Onderwerp: Re: [Samba] Join AD fails DNS update

L.P.H. van Belle

unread,
Jun 25, 2014, 3:50:01 AM6/25/14
to

and this is not needed... if the A record in the dns is correct.

>
>1. net ads leave -UAdministrator
>2. remove the A record on the DC
>3. net ads join -UAdministrator

If you have a correct A record in the dns, you still can join the domain.

I just gives a error of unable to create the dns record at join.
imo a bug of samba and can be ignored. the hostname wil be created in the AD anyway.

and i explain why.
1) pc gets dhcp ip, and this is added in the dns. ( in case of dynamic dns )
2) pc joins the ad.. and gets added in the ad.
and during this join a A record is also tried to create in the dns.
but is is already there... so it gives back an error...

Samba should check if the A record already exist, if so, dont create it.

I've tested this, multiple times, and if i have to rejoin a domain,
just clear the /var/lib/samba
and remove the hostname from the AD, and you can rejoin.


Best regards,

Louis


>-----Oorspronkelijk bericht-----
>Van: st...@steve-ss.com [mailto:samba-...@lists.samba.org]
>Namens steve
>Verzonden: dinsdag 24 juni 2014 19:00
>Aan: sa...@lists.samba.org
>Onderwerp: Re: [Samba] Join AD fails DNS update
>

Lars Hanke

unread,
Jun 25, 2014, 4:00:02 AM6/25/14
to
Hi Louis,

in the current case there is no A record in the DNS, but the update
fails claiming it was already there. This smells like a real bug.

Regards,
- lars.

Rowland Penny

unread,
Jun 25, 2014, 4:00:02 AM6/25/14
to
On 25/06/14 08:35, L.P.H. van Belle wrote:
> And Again, there are 2 ways how resolving is done... read the last part, i've put in a example...
>
> And, yes i know that....
>
>> The domain and search keywords are mutually exclusive. If
>> more than one instance of these keywords is present, the last instance wins.
> And yes, above is correct
>
> but you really need to understand that putting the domain there also make this much easier to understand for none experienced users.
No it doesn't, you cannot advise users to read manpages and then ignore
what is in them!

>>> the domain name is determined from the hostname and the domain search path is constructed from the domain name.
> and
>>> The search list is normally determined from the local domain name; by default, it contains only the local domain name.
> This may be changed by listing the desired domain search path following
> and
>>> The domain and search keywords are mutually exclusive. If more than one instance of these keywords is present, the last instance wins.
> And to make sure you set the correct domain/search you can put it like this, it wont hurt,

No, it wont hurt, it wont help but it wont hurt.

> it isnt wrong

Oh yes it is.

> and it helps people put in the correct domain/search.

But you only need one.

> it just adds the primary domain in the search 2 times.
>
> This is not wrong.
> domain search1.domain
> search search1.domain
> nameserver 1.1.1.1

Yes it is

> this is the same and also not wrong..
> search search1.domain
> nameserver 1.1.1.1

you could use that

> and this is also the same, and not wrong.
> domain search1.domain
> nameserver 1.1.1.1

Or that

> but which one helps a newbe the most with what he/she is do-ing.
>
> ....

Either of the last two, but not the first.

>
>
> even...
> this is the same and not wrong. ( if you installed the right way )
> nameserver 1.1.1.1
>
> and dont forget this one.
>
> man gethostname
>>> The GNU C library does not employ the gethostname() system call; instead, it implements gethostname() as a library function that calls uname(2)
>
> To draw another parallel, you seem to want the output of the command hostname --fqdn (which depends on the resolver), while others want hostname .

No, I don't, all I want is for correct info to be given, if the manpage
says 'it is pointless doing this' then it is pointless advising other
people to do it. You personally can do what you like, but you shouldn't
advise other people to do an incorrect thing, sorry if this upsets you,
but it is just my opinion.

Rowland

L.P.H. van Belle

unread,
Jun 25, 2014, 4:10:02 AM6/25/14
to

How did you look for the record?

I have seen this also yes.
When you look with the windows tools, try to refresh the screen first.
do you use the internal dns of bind for dns?
this happend for me with the bind dns.
i did fix it, but that was months ago, im try to remember, but ... :-((

this also happens when you have a setup like this.

sambadomain.domain.tld

AND
dns of samba also manages : domain.tld.

now when you add a A record for sambadomain.domain.tld in domain.tld
this also cases this problem.

when this happend, you can check it als following.

1) look in the dns with the windows tools, you wil see all you dns records.
2) setup a bind slave for both zones, and check whats in these zones,
you will see your missing lots of your dns records.

quick fix, reprovision you samba4 domain.
the other, ... still cant remember.. (sorry)


Greetz,

Louis



>-----Oorspronkelijk bericht-----
>Van: deb...@lhanke.de [mailto:samba-...@lists.samba.org]
>Namens Lars Hanke
>Verzonden: woensdag 25 juni 2014 9:53

L.P.H. van Belle

unread,
Jun 25, 2014, 4:50:04 AM6/25/14
to
Dear Rowland... ;-) good friend.. ;-)

It does not upset me and i just try to explain what happens here.
there are 2 different ways how resolving can be done...

try to understand this ....from the manual.. .
( and stop thinking for 1 second about the resolv.conf about whats right or wrong... )

domain Local domain name.
If no domain entry is present, the domain is determined from the local hostname returned by
gethostname(2); the domain part is taken to be everything after the first '.'.
Finally, if the hostname does not contain a domain part, the root domain is assumed.

The GNU C library does not employ the gethostname() system call; instead, it implements
gethostname() as a library function that calls uname(2) and copies up to len bytes from the returned nodename field into name.

so this is exaly what happens within ubuntu.

and when you also read..
The uname() function documentation includes the following information:
Note that there is no standard that says that the hostname set by sethostname(2)
is the same string as the nodename field of the struct returned by uname()

(indeed, some systems allow a 256-byte hostname and an 8-byte nodename), but this is true on Linux.
The same holds for setdomainname(2) and the domainname field.


This is why so many poeple have problems with this..

1 program uses the resolv.conf => man resolv.conf

The other uses the GNU C library which in the end in a library function that calls uname(2)
=> man 2 uname


The only thing i dont know is which program is doing what. :-/


Just google around and you wil see lots of people who have problems with this.


Louis






>-----Oorspronkelijk bericht-----
>Van: rowlan...@googlemail.com
>[mailto:samba-...@lists.samba.org] Namens Rowland Penny
>Verzonden: woensdag 25 juni 2014 9:58
>Aan: sa...@lists.samba.org
>Onderwerp: Re: [Samba] Join AD fails DNS update
>

Rowland Penny

unread,
Jun 25, 2014, 5:10:02 AM6/25/14
to
Hi Louis, yes I understand and agree with all that, but, I still cannot
agree with advising somebody to do something that is technically
incorrect. Adding both 'domain' and 'search' lines to resolv.conf is not
required and which ever of them is the last to be added wins.

I think that a better suggestion would to advise users this:
Whether using dhcp or a static address, check that /etc/resolv.conf
contains just a nameserver line pointing to the AD server and a search
line pointing to the AD domain (which should be the dns domain).

If you are interested I found a thread discussing just what /etc/hosts
should contain, which I think gives an insight on this problem:
https://lists.debian.org/debian-devel/2013/07/msg00809.html

Rowland

Harry Jede

unread,
Jun 26, 2014, 6:10:02 AM6/26/14
to
On 11:32:09 wrote Lars Hanke:
Yes,
you do not interpret the dig output in a correct manner!

1.
Your commandline tells dig to query the server "samba" for the record
"samba4.ad.microsult.de". But did you get an "Answer SECTION"?
No!

2.
The "AUTHORITY SECTION" returns a SOA record instead of a NS record.

Conclusion:
Your bind server @samba has no knowlege which nameserver he should
consult to retrieve or update a record in zone "ad.microsult.de".

So add a NS record to your zone declaration. In flat file format it
should look like this:

@ IN SOA ad.microsult.de. root.kronprinz.xx. (
505061645
10800
3600
604800
86400 )
NS samba.ad.microsult.de.
$ORIGIN ad.microsult.de.
samba A 172.16.6.240

>
> Kind regards,
>
> - lars.


--

Regards
Harry Jede

Lars Hanke

unread,
Jun 26, 2014, 6:20:02 AM6/26/14
to
I dug into the code of bind to check where the error occurs, and it
seems we misinterpreted its meaning. Not an issue of bad wording, but us
ignoring proper punctuation. :(

Jun 24 15:24:44 samba named[7248]: client 172.16.6.242#38702: updating
zone 'ad.microsult.de/NONE': update unsuccessful:
samba4.ad.microsult.de/A: 'RRset exists (value dependent)' prerequisite
not satisfied (NXRRSET)

It does mean that some RRset is required to exist, but it does not! (see
RFC2136). Unfortunately, the message doesn't state which set fails.
Since prerequisites are optional, I assume that SAMBA_DLZ explicitly
sets these fields. Any idea why or what it requires?

Furthermore, I sent the original reply to Rowland's message from the
wrong e-mail address, i.e. it was not accepted by the list. Since it has
some useful information, I append it here to share my research:

Thanks Rowland, this gives a more comprehensive view.

> The problem is probably that you are only searching on port 389, try
> this search:
> ldbsearch -LLL -x -h localhost -p 3268 -b "DC=example,DC=com" -s sub -D
> "CN=Administrator,CN=Users,DC=example,DC=com" -w <ADpassword>

The syntax looks like ldapsearch instead of ldbsearch, but yes this
search returns the DNS entries maintained by the AD DC. It does not
contain any entry for a machine called samba4, i.e. the error that it
cannot be added since it exists already is wrong, remember:

client 172.16.6.242#40938: updating zone 'ad.microsult.de/NONE': update
unsuccessful: samba4.ad.microsult.de/A: 'RRset exists (value dependent)'
prerequisite not satisfied (NXRRSET)

Still the only entity about the joined machine is:

ldapsearch -LLL -x -h localhost -p 3268 -b "DC=ad,DC=microsult,DC=de" -s
sub -D "CN=Administrator,CN=Users,DC=ad,DC=microsult,DC=de" -W | grep -i
samba4 | grep ^dn:
Enter LDAP Password:
dn: CN=samba4,CN=Computers,DC=ad,DC=microsult,DC=de

The process logging the error is named, but it claims to propagate an
error from within samba_dlz.

... and we learned that the DNS records except root servers are not
stored in sam.ldb. However, a construct like:

for f in `find / -type f -name '*.ldb'`; do echo File: $f; ldbsearch
--url="$f" | grep -i samba | grep ^dn: ; done

showed it's in

private/sam.ldb.d/DC=DOMAINDNSZONES,DC=AD,DC=MICROSULT,DC=DE.ldb

but no, there's no trace of any machine called samba4 in it.

Lars Hanke

unread,
Jun 26, 2014, 6:40:02 AM6/26/14
to
>> So DLZ claims that the entry exists, but it cannot be accessed by
>> Bind. Any ideas?
> Yes,
> you do not interpret the dig output in a correct manner!
>
> 1.
> Your commandline tells dig to query the server "samba" for the record
> "samba4.ad.microsult.de". But did you get an "Answer SECTION"?
> No!
>
> 2.
> The "AUTHORITY SECTION" returns a SOA record instead of a NS record.
>
> Conclusion:
> Your bind server @samba has no knowlege which nameserver he should
> consult to retrieve or update a record in zone "ad.microsult.de".

Actually, samba should be authorative for ad.microsult.de with its
entries retrieved from the samba LDAP by DLZ. In fact samba can resolve
all existing entries in ad.microsult.de.

root@samba:/# dig @samba samba.ad.microsult.de

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @samba samba.ad.microsult.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32949
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;samba.ad.microsult.de. IN A

;; ANSWER SECTION:
samba.ad.microsult.de. 900 IN A 172.16.6.240

;; AUTHORITY SECTION:
ad.microsult.de. 900 IN NS samba.ad.microsult.de.

;; Query time: 1 msec
;; SERVER: 172.16.6.240#53(172.16.6.240)
;; WHEN: Thu Jun 26 12:21:36 2014
;; MSG SIZE rcvd: 69

root@samba:/# dig @samba samba4.ad.microsult.de

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @samba samba4.ad.microsult.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55243
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;samba4.ad.microsult.de. IN A

;; AUTHORITY SECTION:
ad.microsult.de. 0 IN SOA samba.ad.microsult.de.
hostmaster.ad.microsult.de. 1 900 600 86400 0

;; Query time: 1 msec
;; SERVER: 172.16.6.240#53(172.16.6.240)
;; WHEN: Thu Jun 26 12:22:08 2014
;; MSG SIZE rcvd: 93

Regards,
- lars.

Rowland Penny

unread,
Jun 26, 2014, 6:40:02 AM6/26/14
to
On 26/06/14 11:18, Lars Hanke wrote:
> I dug into the code of bind to check where the error occurs, and it
> seems we misinterpreted its meaning. Not an issue of bad wording, but
> us ignoring proper punctuation. :(
>
> Jun 24 15:24:44 samba named[7248]: client 172.16.6.242#38702: updating
> zone 'ad.microsult.de/NONE': update unsuccessful:
> samba4.ad.microsult.de/A: 'RRset exists (value dependent)'
> prerequisite not satisfied (NXRRSET)
>
> It does mean that some RRset is required to exist, but it does not!
> (see RFC2136). Unfortunately, the message doesn't state which set
> fails. Since prerequisites are optional, I assume that SAMBA_DLZ
> explicitly sets these fields. Any idea why or what it requires?

What have you got in the systems main logfile (syslog on debian)

>
> Furthermore, I sent the original reply to Rowland's message from the
> wrong e-mail address, i.e. it was not accepted by the list. Since it
> has some useful information, I append it here to share my research:
>
> Thanks Rowland, this gives a more comprehensive view.
>
> > The problem is probably that you are only searching on port 389, try
> > this search:
> > ldbsearch -LLL -x -h localhost -p 3268 -b "DC=example,DC=com" -s sub -D
> > "CN=Administrator,CN=Users,DC=example,DC=com" -w <ADpassword>
>
> The syntax looks like ldapsearch instead of ldbsearch,

OOPS, yes you are right.

> but yes this search returns the DNS entries maintained by the AD DC.
> It does not contain any entry for a machine called samba4, i.e. the
> error that it cannot be added since it exists already is wrong, remember:
>
> client 172.16.6.242#40938: updating zone 'ad.microsult.de/NONE':
> update unsuccessful: samba4.ad.microsult.de/A: 'RRset exists (value
> dependent)' prerequisite not satisfied (NXRRSET)
>
> Still the only entity about the joined machine is:
>
> ldapsearch -LLL -x -h localhost -p 3268 -b "DC=ad,DC=microsult,DC=de"
> -s sub -D "CN=Administrator,CN=Users,DC=ad,DC=microsult,DC=de" -W |
> grep -i samba4 | grep ^dn:
> Enter LDAP Password:
> dn: CN=samba4,CN=Computers,DC=ad,DC=microsult,DC=de
>
> The process logging the error is named, but it claims to propagate an
> error from within samba_dlz.
>
> ... and we learned that the DNS records except root servers are not
> stored in sam.ldb.

Yes they are, you just cannot see them in a normal search.

> However, a construct like:
>
> for f in `find / -type f -name '*.ldb'`; do echo File: $f; ldbsearch
> --url="$f" | grep -i samba | grep ^dn: ; done
>
> showed it's in
>
> private/sam.ldb.d/DC=DOMAINDNSZONES,DC=AD,DC=MICROSULT,DC=DE.ldb
>
> but no, there's no trace of any machine called samba4 in it.

What ever you do, DO NOT EDIT

'DC=DOMAINDNSZONES,DC=AD,DC=MICROSULT,DC=DE.ldb'

If you do, you will probably destroy your domain, only edit sam.ldb.

Rowland

Lars Hanke

unread,
Jun 26, 2014, 6:50:02 AM6/26/14
to
>> It does mean that some RRset is required to exist, but it does not!
>> (see RFC2136). Unfortunately, the message doesn't state which set
>> fails. Since prerequisites are optional, I assume that SAMBA_DLZ
>> explicitly sets these fields. Any idea why or what it requires?
>
> What have you got in the systems main logfile (syslog on debian)

This is what named produces during the join.

Jun 24 15:24:44 samba named[7248]: samba_dlz: starting transaction on
zone ad.microsult.de
Jun 24 15:24:44 samba named[7248]: client 172.16.6.242#38702: updating
zone 'ad.microsult.de/NONE': update unsuccessful:
samba4.ad.microsult.de/A: 'RRset exists (value dependent)' prerequisite
not satisfied (NXRRSET)
Jun 24 15:24:44 samba named[7248]: samba_dlz: cancelling transaction on
zone ad.microsult.de
Jun 24 15:24:44 samba named[7248]: samba_dlz: starting transaction on
zone ad.microsult.de
Jun 24 15:24:44 samba named[7248]: samba_dlz: spnego update failed
Jun 24 15:24:44 samba named[7248]: client 172.16.6.242#38702: updating
zone 'ad.microsult.de/NONE': update failed: rejected by secure update
(REFUSED)
Jun 24 15:24:44 samba named[7248]: samba_dlz: cancelling transaction on
zone ad.microsult.de

However, temp_check(), which produces the error, only returns
DNS_R_NXRRSET without further context. So FAILNT in update_action()
cannot log any details, i.e. which RRset exactly was expected and found
missing is not conveyed in the error message.

So, if someone knows how or where the update message is built, we might
find what we actually require.

Regards,
- lars.

Rowland Penny

unread,
Jun 26, 2014, 7:00:02 AM6/26/14
to
Have you tried running the 'nsupdate' command direct, this is what named
is doing and it might get you more info.

Rowland

Lars Hanke

unread,
Jun 26, 2014, 7:30:02 AM6/26/14
to
> Have you tried running the 'nsupdate' command direct, this is what named
> is doing and it might get you more info.

Didn't even know that tool ...

The update is refused, but I don't see clearly why (see log at the end).
Maybe this is an issue to be solved beforehand ...

On the other hand, this will not help to hunt down the prerequisite
issue, since it would require me to manually define such, i.e. prereq
nxrrset.

Just for my understanding ... I thought that SAMBA_DLZ is an interface
for Bind9 to access samba's LDAP. So if samba updates its LDAP, why we
still go through the pain of sending update requests?

root@samba:/# nsupdate -D -l
setup_system()
Creating key...
namefromtext
keycreate
reset_system()
user_interaction()
get_next_command()
> update add samba4.ad.microsult.de 86400 A 172.16.6.242
evaluate_update()
update_addordelete()
get_next_command()
> send
start_update()
recvsoa()
About to create rcvmsg
show_message()
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59702
;; flags: qr aa ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;samba4.ad.microsult.de. IN SOA

;; AUTHORITY SECTION:
ad.microsult.de. 0 IN SOA samba.ad.microsult.de.
hostmaster.ad.microsult.de. 1 900 600 86400 0

;; TSIG PSEUDOSECTION:
local-ddns. 0 ANY TSIG hmac-sha256. 1403781225
300 32 vQ9kJvZKQKMBMuDfLhd4qN5fbZ0ekdJX9RJ/QwHWSPQ= 59702 NOERROR 0

Found zone name: ad.microsult.de
The master is: samba.ad.microsult.de
send_update()
Sending update to 127.0.0.1#53
show_message()
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 28777
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1
;; UPDATE SECTION:
samba4.ad.microsult.de. 86400 IN A 172.16.6.242

;; TSIG PSEUDOSECTION:
local-ddns. 0 ANY TSIG hmac-sha256. 1403781225
300 32 6C64ivAB6zDMqC2OV9EecmOAr8bWw4fBhXOq1WuWPyQ= 28777 NOERROR 0

Out of recvsoa
update_completed()
tsig verification successful
show_message()

Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: REFUSED, id: 28777
;; flags: qr ra; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;ad.microsult.de. IN SOA

;; TSIG PSEUDOSECTION:
local-ddns. 0 ANY TSIG hmac-sha256. 1403781225
300 32 EauhZfYkovrkF+hocj17kvUs61BLleTa71AJ9PAza5Q= 28777 NOERROR 0

done_update()
reset_system()
user_interaction()
get_next_command()
> cleanup()
detach tsigkey x0x7f35351885f8
Shutting down task manager
shutdown_program()
Shutting down request manager
Destroy DST lib
Destroying request manager
Freeing the dispatchers
Shutting down dispatch manager
Destroying event
Shutting down socket manager
Shutting down timer manager
Destroying hash context
Destroying name state
Removing log context
Destroying memory context
root@samba:/#

Kind regards,
- lars.

steve

unread,
Jun 26, 2014, 8:00:01 AM6/26/14
to
On Thu, 2014-06-26 at 13:26 +0200, Lars Hanke wrote:

>
> root@samba:/# nsupdate -D -l

You need:
nsupdate -g

Have you set the bind TSIG to point at the keytab? Can bind read it? Can
your version of bind do kerberised updates?

HTH,
Steve

Rowland Penny

unread,
Jun 26, 2014, 8:10:02 AM6/26/14
to
login as root, kinit as Administrator, now run nsupdate like this:

nsupdate -g -d
> update add samba4.ad.microsult.de 86400 A 172.16.6.242
> send

Rowland

Lars Hanke

unread,
Jun 26, 2014, 8:30:01 AM6/26/14
to
>> root@samba:/# nsupdate -D -l
> You need:
> nsupdate -g

oops, missed that option in the man page.

Yes, using nsupdate -g and a valid TGT I could add my samba4 record to
the DNS - which seems to answer all your following questions.

Thanks, this may prove valuable for all further investigation.

I'd love this -D verbosity on named syslogs. This would help to figure
out, what samba actually sends. I'll experiment with the '-d' option
tonight.

Thanks,
- lars.

steve

unread,
Jun 26, 2014, 10:50:02 AM6/26/14
to
On Thu, 2014-06-26 at 14:27 +0200, Lars Hanke wrote:
> >> root@samba:/# nsupdate -D -l
> > You need:
> > nsupdate -g
>
> oops, missed that option in the man page.
>
> Yes, using nsupdate -g and a valid TGT I could add my samba4 record to
> the DNS - which seems to answer all your following questions.
>
> Thanks, this may prove valuable for all further investigation.
>
> I'd love this -D verbosity on named syslogs. This would help to figure
> out, what samba actually sends. I'll experiment with the '-d' option
> tonight.
>
> Thanks,
> - lars.

Hi
I don't think the join does much apart from add an A record for the
machine:

catral:/home/steve # net ads join -UAdministrator
Enter Administrator's password:
Using short domain name -- HH3
Joined 'CATRAL' to dns domain 'hh3.site'
catral:/home/steve #

bind replies simply:

2014-06-26T16:29:50.485203+02:00 hh16 named[2103]: samba_dlz: starting
transaction on zone hh3.site
2014-06-26T16:29:50.485943+02:00 hh16 named[2103]: samba_dlz: committed
transaction on zone hh3.site

on an smb.conf of:
[global]
workgroup = HH3
realm = HH3.SITE
security = ADS
kerberos method = system keytab

and an A record appears:
nslookup catral
Server: 192.168.1.16
Address: 192.168.1.16#53

Name: catral.hh3.site
Address: 192.168.1.25

samba-tool dns query hh16 hh3.site catral A -UAdministrator
Password for [HH3\Administrator]:
Name=, Records=1, Children=0
A: 192.168.1.25 (flags=f0, serial=1301, ttl=3600)

The full ddns update including A, AAAA and PTR on the client via
nsupdate -g (under sssd) looks like this:

2014-06-26T16:24:46.918055+02:00 hh16 named[2103]: samba_dlz: starting
transaction on zone hh3.site
2014-06-26T16:24:46.923381+02:00 hh16 named[2103]: samba_dlz: allowing
update of signer=CATRAL\$\@HH3.SITE name=catral.hh3.site
tcpaddr=192.168.1.25 type=A key=3058272441.sig-hh16.hh3.site/160/0
2014-06-26T16:24:46.923974+02:00 hh16 named[2103]: client
192.168.1.25#45673/key CATRAL\$\@HH3.SITE: updating zone
'hh3.site/NONE': deleting rrset at 'catral.hh3.site' A
2014-06-26T16:24:46.931087+02:00 hh16 named[2103]: samba_dlz: subtracted
rdataset catral.hh3.site
'catral.hh3.site.#0113600#011IN#011A#011192.168.1.25'
2014-06-26T16:24:46.934733+02:00 hh16 named[2103]: samba_dlz: subtracted
rdataset hh3.site 'hh3.site.#0113600#011IN#011SOA#011hh16.hh3.site.
hostmaster.hh3.site. 1300 900 600 86400 0'
2014-06-26T16:24:46.936719+02:00 hh16 named[2103]: samba_dlz: added
rdataset hh3.site 'hh3.site.#0113600#011IN#011SOA#011hh16.hh3.site.
hostmaster.hh3.site. 1301 900 600 86400 0'
2014-06-26T16:24:48.149630+02:00 hh16 named[2103]: samba_dlz: committed
transaction on zone hh3.site
2014-06-26T16:24:48.289150+02:00 hh16 named[2103]: samba_dlz: starting
transaction on zone hh3.site
2014-06-26T16:24:48.291793+02:00 hh16 named[2103]: samba_dlz: allowing
update of signer=CATRAL\$\@HH3.SITE name=catral.hh3.site
tcpaddr=192.168.1.25 type=AAAA key=669082013.sig-hh16.hh3.site/160/0
2014-06-26T16:24:48.292445+02:00 hh16 named[2103]: client
192.168.1.25#51878/key CATRAL\$\@HH3.SITE: updating zone
'hh3.site/NONE': deleting rrset at 'catral.hh3.site' AAAA
2014-06-26T16:24:48.292893+02:00 hh16 named[2103]: samba_dlz: committed
transaction on zone hh3.site
2014-06-26T16:24:48.487283+02:00 hh16 named[2103]: samba_dlz: starting
transaction on zone hh3.site
2014-06-26T16:24:48.491456+02:00 hh16 named[2103]: samba_dlz: allowing
update of signer=CATRAL\$\@HH3.SITE name=catral.hh3.site
tcpaddr=192.168.1.25 type=A key=3406268820.sig-hh16.hh3.site/160/0
2014-06-26T16:24:48.492269+02:00 hh16 named[2103]: client
192.168.1.25#50716/key CATRAL\$\@HH3.SITE: updating zone
'hh3.site/NONE': adding an RR at 'catral.hh3.site' A
2014-06-26T16:24:48.495603+02:00 hh16 named[2103]: samba_dlz: added
rdataset catral.hh3.site
'catral.hh3.site.#0113600#011IN#011A#011192.168.1.25'
2014-06-26T16:24:48.499268+02:00 hh16 named[2103]: samba_dlz: subtracted
rdataset hh3.site 'hh3.site.#0113600#011IN#011SOA#011hh16.hh3.site.
hostmaster.hh3.site. 1301 900 600 86400 0'
2014-06-26T16:24:48.501137+02:00 hh16 named[2103]: samba_dlz: added
rdataset hh3.site 'hh3.site.#0113600#011IN#011SOA#011hh16.hh3.site.
hostmaster.hh3.site. 1302 900 600 86400 0'
2014-06-26T16:24:49.792656+02:00 hh16 named[2103]: samba_dlz: committed
transaction on zone hh3.site
2014-06-26T16:24:51.295817+02:00 hh16 named[2103]: samba_dlz: starting
transaction on zone 1.168.192.in-addr.arpa
2014-06-26T16:24:51.300085+02:00 hh16 named[2103]: samba_dlz: allowing
update of signer=CATRAL\$\@HH3.SITE name=25.1.168.192.in-addr.arpa
tcpaddr=192.168.1.25 type=PTR key=2770023077.sig-hh16.hh3.site/160/0
2014-06-26T16:24:51.300783+02:00 hh16 named[2103]: client
192.168.1.25#47761/key CATRAL\$\@HH3.SITE: updating zone
'1.168.192.in-addr.arpa/NONE': deleting rrset at
'25.1.168.192.in-addr.arpa' PTR
2014-06-26T16:24:51.304773+02:00 hh16 named[2103]: samba_dlz: subtracted
rdataset 25.1.168.192.in-addr.arpa
'25.1.168.192.in-addr.arpa.#0113600#011IN#011PTR#011catral.hh3.site.'
2014-06-26T16:24:51.308932+02:00 hh16 named[2103]: samba_dlz: subtracted
rdataset 1.168.192.in-addr.arpa
'1.168.192.in-addr.arpa.#0113600#011IN#011SOA#011hh16.hh3.site.
hostmaster.hh3.site. 48 900 600 86400 3600'
2014-06-26T16:24:51.311249+02:00 hh16 named[2103]: samba_dlz: added
rdataset 1.168.192.in-addr.arpa
'1.168.192.in-addr.arpa.#0113600#011IN#011SOA#011hh16.hh3.site.
hostmaster.hh3.site. 49 900 600 86400 3600'
2014-06-26T16:24:52.164513+02:00 hh16 named[2103]: samba_dlz: committed
transaction on zone 1.168.192.in-addr.arpa
2014-06-26T16:24:52.270345+02:00 hh16 named[2103]: samba_dlz: starting
transaction on zone 1.168.192.in-addr.arpa
2014-06-26T16:24:52.274466+02:00 hh16 named[2103]: samba_dlz: allowing
update of signer=CATRAL\$\@HH3.SITE name=25.1.168.192.in-addr.arpa
tcpaddr=192.168.1.25 type=PTR key=1117518000.sig-hh16.hh3.site/160/0
2014-06-26T16:24:52.276199+02:00 hh16 named[2103]: client
192.168.1.25#37720/key CATRAL\$\@HH3.SITE: updating zone
'1.168.192.in-addr.arpa/NONE': adding an RR at
'25.1.168.192.in-addr.arpa' PTR
2014-06-26T16:24:52.280119+02:00 hh16 named[2103]: samba_dlz: added
rdataset 25.1.168.192.in-addr.arpa
'25.1.168.192.in-addr.arpa.#0113600#011IN#011PTR#011catral.hh3.site.'
2014-06-26T16:24:52.284008+02:00 hh16 named[2103]: samba_dlz: subtracted
rdataset 1.168.192.in-addr.arpa
'1.168.192.in-addr.arpa.#0113600#011IN#011SOA#011hh16.hh3.site.
hostmaster.hh3.site. 49 900 600 86400 3600'
2014-06-26T16:24:52.286022+02:00 hh16 named[2103]: samba_dlz: added
rdataset 1.168.192.in-addr.arpa
'1.168.192.in-addr.arpa.#0113600#011IN#011SOA#011hh16.hh3.site.
hostmaster.hh3.site. 50 900 600 86400 3600'
2014-06-26T16:24:53.286665+02:00 hh16 named[2103]: samba_dlz: committed
transaction on zone 1.168.192.in-addr.arpa

Whatever the join sends to nsupdate (if it sends anything) is with
different options to the minimalistic ones sssd offers when it calls out
to nsupdate.

Maybe this will help you get resolved.
HTH
Steve

Lars Hanke

unread,
Jun 26, 2014, 12:30:02 PM6/26/14
to
Hi Steve,

>> I'd love this -D verbosity on named syslogs. This would help to figure
>> out, what samba actually sends. I'll experiment with the '-d' option
>> tonight.

Unfortunately -d 100 doesn't make named any more verbose. I'm already
imagining me hooking up a gdb. Didn't do that for at leat 5 years ...

> I don't think the join does much apart from add an A record for the
> machine:

Yes, but it obviously ties this to conditions, which fail to verify. And
no-one seems to have an idea, which conditions this would be.
Unfortunately your syslog does not disclose any details of successful
prerequisite processing.

steve

unread,
Jun 26, 2014, 12:50:02 PM6/26/14
to
On Thu, 2014-06-26 at 18:19 +0200, Lars Hanke wrote:
> Hi Steve,
>
> >> I'd love this -D verbosity on named syslogs. This would help to figure
> >> out, what samba actually sends. I'll experiment with the '-d' option
> >> tonight.
>
> Unfortunately -d 100 doesn't make named any more verbose. I'm already
> imagining me hooking up a gdb. Didn't do that for at leat 5 years ...
>
> > I don't think the join does much apart from add an A record for the
> > machine:
>
> Yes, but it obviously ties this to conditions, which fail to verify. And
> no-one seems to have an idea, which conditions this would be.
> Unfortunately your syslog does not disclose any details of successful
> prerequisite processing.
>
>
bind needs to be able to read the keytab on the DC and have write access
on the dns dbs. dns settings on the client have to be perfect. I don't
think yours is at the time of the join.

Can you post your named or bind conf?

The syslog proves that I have the correct dns settings in /etc/hosts
and /etc/reslov.conf, that named can read the dns keytab, write to the
required partitions and that I am able to verify both the machine and
get a tgt as a user who is allowed to perform the dns update. If any of
those are missing for you. . .

If you wish to verify whether nsupdate is used during the join process
then remove it before the join. I don't think it is as we cannot
reproduce that (lack of) verbosity at the command line. Sorry, no time
to do that over here at the moment. Alternatively you could ask the at
samba-technical.
HTH
Steve

Rowland Penny

unread,
Jun 26, 2014, 2:10:03 PM6/26/14
to
On 26/06/14 17:19, Lars Hanke wrote:
> Hi Steve,
>
> >> I'd love this -D verbosity on named syslogs. This would help to figure
>>> out, what samba actually sends. I'll experiment with the '-d' option
>>> tonight.
>
> Unfortunately -d 100 doesn't make named any more verbose. I'm already
> imagining me hooking up a gdb. Didn't do that for at leat 5 years ...
>
>> I don't think the join does much apart from add an A record for the
>> machine:
>
> Yes, but it obviously ties this to conditions, which fail to verify.
> And no-one seems to have an idea, which conditions this would be.
> Unfortunately your syslog does not disclose any details of successful
> prerequisite processing.
>
>
Hmm, you don't seem to be getting anywhere, could I suggest that you try
upgrading your wheezy client to samba from backports.
If the problem is still there and if it is proved to be a bug, then you
stand a chance of getting it fixed, you have little or no chance of
getting samba 3.6.6 fixed as the 3.6 series is in security fixes only
mode and will reach EOL when 4.2 comes out , this will probably happen
well before the end of this year.

Rowland

Lars Hanke

unread,
Jun 26, 2014, 2:40:01 PM6/26/14
to
I made some substantial progress in finding out what is happening.
tcpdump was my friend. I always thought the update was internal to the
the DC, but it is actually a matter of the client talking to the DNS.

The prerequisite, which is considered not satisfied, is:

samba4.ad.microsult.de CNAME NONE 0 0

which means (RFC 2136, 2.4.3) that the said CNAME must not exist.

This makes sense, and it should not exist. I'll try to reproduce this
using nsupdate. By now samba 3.6.6 seems to do everything right, but the
DLZ answers wrong, i.e. if there is a bug, it seems to be on the samba4
side.

Regards,
- lars.

Rowland Penny

unread,
Jun 26, 2014, 3:10:02 PM6/26/14
to
On 26/06/14 19:33, Lars Hanke wrote:
> I made some substantial progress in finding out what is happening.
> tcpdump was my friend. I always thought the update was internal to the
> the DC, but it is actually a matter of the client talking to the DNS.
>
> The prerequisite, which is considered not satisfied, is:
>
> samba4.ad.microsult.de CNAME NONE 0 0
>
> which means (RFC 2136, 2.4.3) that the said CNAME must not exist.
>
> This makes sense, and it should not exist. I'll try to reproduce this
> using nsupdate. By now samba 3.6.6 seems to do everything right, but
> the DLZ answers wrong, i.e. if there is a bug, it seems to be on the
> samba4 side.
>
> Regards,
> - lars.
There is another way round this problem, run a dhcp server on the samba4
machine and use this to update samba4 dns.

Rowland

Lars Hanke

unread,
Jun 27, 2014, 8:20:01 AM6/27/14
to
Hi Steve,

taking my time to analyze what is happening I found the following:

1) Any local updates on the AD DC using nsupdate -g run well.So the
configuration on the AD DC should be fine, and Bind9 is performing well
with DLZ. I traced the network packages to compare with what the does.

2) net ads join form the client contacts the DNS of the DC twice, which
causes the strange structure of syslog entries. The first one
stipulating an unsatisfied prerequisite seems to be merely informative.
It does not contain any update records.

3) The second request contains the update request. It is refused,
because it does not contain ANY authorization data.

This relaxes me a lot, since the server side is running nicely. As yet,
I don't know whether and how I'll need the functions of 'net' in any
unattended mode. This also motivates that updating the client may be
sensible in that case.

However, what I do not understand is why the client's 'net' contacts the
DNS directly?

In order to make this succeed the client must have credentials for the
central DNS. Nothing that I would want.

I'd expect that the client management tools speak to samba and samba in
turn locally updates DNS. Does anybody know how the protocol is intended?

> to do that over here at the moment. Alternatively you could ask the at
> samba-technical.

;)

Regards,
- lars.

PS: Just to share my findings:

>>> I don't think the join does much apart from add an A record for the
>>> machine:

The first update request checks that
- there is no corresponding CNAME (which probably succeeds)
- there is an IN for the correct IP (which should fail)
- there is an IN for 127.0.0.2 (which should also fail)
So the failure of the first request is to be expected, but I'm still not
clear why we see NXRRSET.

The second update wipes all entries for the new FQDN and registers the
name for the proper IP and 127.0.0.2! This at least sounds strange,
unless issued locally on the DC.

L.P.H. van Belle

unread,
Jun 27, 2014, 9:50:03 AM6/27/14
to
nsupdate -D -l ??

Are you using bind9_DLZ of bind9_FLATFILE

above is NOT for DLZ.

-g is used for kerberos auth.

and i see:
>tsig verification successful
TSIG ??

so you problem is probely in you Bind setup, not samba.
I think you mixing TSIG and GSSTSIG

start reading here.

http://wiki.samba.org/index.php/DNS_Backend_BIND



Louis



>-----Oorspronkelijk bericht-----
>Van: deb...@lhanke.de [mailto:samba-...@lists.samba.org]
>Namens Lars Hanke
>Verzonden: donderdag 26 juni 2014 13:27
>Aan: Rowland Penny; sa...@lists.samba.org
>Onderwerp: Re: [Samba] Join AD fails DNS update
>

Dr. Lars Hanke

unread,
Jun 30, 2014, 6:20:02 AM6/30/14
to
Thanks Rowland, this gives a more comprehensive view.

> The problem is probably that you are only searching on port 389, try
> this search:
> ldbsearch -LLL -x -h localhost -p 3268 -b "DC=example,DC=com" -s sub -D
> "CN=Administrator,CN=Users,DC=example,DC=com" -w <ADpassword>

The syntax looks like ldapsearch instead of ldbsearch, but yes this
search returns the DNS entries maintained by the AD DC. It does not
contain any entry for a machine calles samba4, i.e. the error that it
cannot be added since it exists already is wrong, remember:

client 172.16.6.242#40938: updating zone 'ad.microsult.de/NONE': update
unsuccessful: samba4.ad.microsult.de/A: 'RRset exists (value dependent)'
prerequisite not satisfied (NXRRSET)

Still the only entity about the joined machine is:

ldapsearch -LLL -x -h localhost -p 3268 -b "DC=ad,DC=microsult,DC=de" -s
sub -D "CN=Administrator,CN=Users,DC=ad,DC=microsult,DC=de" -W | grep -i
samba4 | grep ^dn:
Enter LDAP Password:
dn: CN=samba4,CN=Computers,DC=ad,DC=microsult,DC=de

The process logging the error is named, but it claims to propagate an
error from within samba_dlz. Too tired to dig into the code tonight ...

... and we learned that the DNS records except root servers are not
stored in sam.ldb. However, a construct like:

for f in `find / -type f -name '*.ldb'`; do echo File: $f; ldbsearch
--url="$f" | grep -i samba | grep ^dn: ; done

showed it's in

private/sam.ldb.d/DC=DOMAINDNSZONES,DC=AD,DC=MICROSULT,DC=DE.ldb

but no, there's no trace of any machine called samba4 in it.

Cheers,
0 new messages