[Samba] After joining domain, Samba uses the workgroup name, not the FQDN when running the net ads command

Wed Dec 2 22:39:18 UTC 2015

All the DNS stuff checks out. The names resolve as they should (They pass
all checks Mathias suggested). They all give the exact same answers.
hostname -A is showing correctly.

I nuked the boxed and reinstalled. Same problem. It simply won't request
the ActiveDirectory SRV records from WINDOWS.CORP.XXX.COM, it requests them
from WINDOWS and is disappointed when there isn't any DNS setup there.

Why does samba keep wanting to use the workgroup name instead of the FQDN?
Is there some sort of logging we can enable to figure out why it's choosing
to behave this way?

Rowland: Dnsmasq is not running on the AD subdomain. Those requests are
passed immediately to the windows boxen.

On Wed, Dec 2, 2015 at 10:40 AM, Rowland Penny <rowlandpenny241155 at gmail.com
> wrote:

> On 02/12/15 16:27, Jonathan S. Fisher wrote:
>
>> Great thanks, I'll start digging into that. So your running theory is that
>> one of the DNS resolution attempts is returning .WINDOWS not .
>> WINDOWS.CORP.XXX.com?
>>
>
> This is not your problem.
>
> Rowland
>
>
>
>> On Wed, Dec 2, 2015 at 10:07 AM, mathias dufresne <infractory at gmail.com>
>> wrote:
>>
>> OK, sorry, I haven't re-read the whole thread carefully enough.
>>>  From what I understand sometimes your DNS request are truncated, asking
>>> for
>>> machineName.windows rahter than
>>> machineName.windows.rest.of.your.domain.tld
>>>
>>> So you have to find what is cutting your DNS requests. If I'm wrong,
>>> don't
>>> read the rest :p
>>>
>>> First I would test my DNS resolution using dig, host or nslookup and
>>> check
>>> with tcpdump if that resolution is working correctly. If request is not
>>> truncated your issue comes from something else than your DNS resolution
>>> configuration.
>>> ex:
>>> dig @192.168.127.129  whiskey.windows.corp.XXX.com
>>> dig @192.168.127.141  whiskey.windows.corp.XXX.com
>>> dig @192.168.112.4  whiskey.windows.corp.XXX.com
>>>
>>>
>>> If it works, I would continue with simple command, perhaps a kinit as
>>> that
>>> one should, I believe, also launch several DNS query (if your krb5.conf
>>> is
>>> still alsmot empty).
>>> Here you continue to check with tcpdump what DNS request your client is
>>> launching (ex: on the client: tcpdump -i eth0 port domain)
>>>
>>> The point is to define where is the issue, removing points where doubt
>>> exists.
>>> DNS queries are DNS queries. Kerberos seems to be acting simply just for
>>> a
>>> kinit.
>>>
>>> Finally once dig and kinit are working, you could dig into Samba
>>> configuration.
>>>
>>> 2015-12-02 16:34 GMT+01:00 Jonathan S. Fisher <
>>> jonathan at springventuregroup.com>:
>>>
>>> Dnsmasq is not running locally! Disabling it would do nothing but stop
>>>> DHCP and DNS forwarding for 2000+ soon to be irate people.
>>>>
>>>> What I am going to do however is bypass DHCP completely and assign a
>>>> static address with DNS pointed straight at active directory. If that
>>>>
>>> still
>>>
>>>> doesn't work, I think I can definitely narrow this down to a bug in
>>>>
>>> Active
>>>
>>>> Directory, our AD configuration, or a bug in Samba.
>>>>
>>>> On Wed, Dec 2, 2015 at 6:08 AM, mathias dufresne <infractory at gmail.com>
>>>> wrote:
>>>>
>>>> Can't you just disable dnsmasq service?
>>>>>
>>>>> You don't seem to be too much confident in that tool and you have DNS
>>>>> issue...
>>>>>
>>>>> dnsmasq has most certainly a good reason to exist. I just don't know
>>>>> it.
>>>>> In
>>>>> IT for work we generally don't need such tool as infrastructures of
>>>>> companies are meant to be stable. As the clients configuration.
>>>>>
>>>>> So I would start with dnsmasq removal, then I would [learn how to]
>>>>> configure manually this client, then I would re-run test, starting with
>>>>> small tests (DNS with dig/nslookup, kinit...)
>>>>>
>>>>> 2015-12-01 21:40 GMT+01:00 Jonathan S. Fisher <
>>>>> jonathan at springventuregroup.com>:
>>>>>
>>>>> So everything with the hostname with now resolving correctly, without
>>>>>>
>>>>> the
>>>>>
>>>>>> 127.0.1.1 hack anymore. We just had to make sure DHCP was handing out
>>>>>>
>>>>> the
>>>>>
>>>>>> correct domain, which it is now:
>>>>>>
>>>>>> $ hostname -d
>>>>>> windows.corp.XXX.com
>>>>>> $ hostname -f
>>>>>> freeradius.windows.corp.XXX.com
>>>>>>
>>>>>> I deleted all the shared secrets, removed the computer from AD and
>>>>>> rejoined... but of course, we're still getting the exact same issue...
>>>>>>
>>>>> :(
>>>>>
>>>>>> It's still trying to query the wrong DNS entry.
>>>>>>
>>>>>>
>>>>>> On Tue, Dec 1, 2015 at 12:12 PM, Rowland Penny <
>>>>>> rowlandpenny241155 at gmail.com
>>>>>>
>>>>>>> wrote:
>>>>>>> On 01/12/15 17:27, Jonathan S. Fisher wrote:
>>>>>>>
>>>>>>> It isn't running, one of the first things I do when setting up a
>>>>>>>>
>>>>>>> new
>>>
>>>> DC
>>>>>
>>>>>> is
>>>>>>
>>>>>>> to remove nscd if it is installed.
>>>>>>>> Ah ok... well this isn't a DC, just a member... is NSCD ok to run
>>>>>>>>
>>>>>>> as
>>>
>>>> a
>>>>>
>>>>>> member? Otherwise I can remove it.
>>>>>>>>
>>>>>>>> I would remove it, everything dns wise should come from an AD DC
>>>>>>>
>>>>>>>
>>>>>>> you get a caching dnsmasq server as standard
>>>>>>>> Not on ubuntu server...  There is no dnsmasq package installed nor
>>>>>>>>
>>>>>>> is it
>>>>>
>>>>>> in
>>>>>>>> ps -ef
>>>>>>>>
>>>>>>>> Ah, so no GUI then, ok in this case you probably wont have Network
>>>>>>>
>>>>>> Manager
>>>>>>
>>>>>>> installed either.
>>>>>>>
>>>>>>> If you have to have that 127.0.1.1 line in /etc/hosts, you have dns
>>>>>>>
>>>>>>>> problems.
>>>>>>>> I'll try to figure out how to get the client to have a FQDN without
>>>>>>>>
>>>>>>> the
>>>>>
>>>>>> line in /etc/hosts
>>>>>>>>
>>>>>>>> If this machine is going to be a fileserver, you would probably be
>>>>>>>
>>>>>> better
>>>>>
>>>>>> using a fixed ip, but if you going to have other Unix domain members
>>>>>>>
>>>>>> using
>>>>>>
>>>>>>> dhcp, you need to sort this problem.
>>>>>>>
>>>>>>>
>>>>>>> I really am starting to hate Active Directory...
>>>>>>>>
>>>>>>>> I just hate microsoft, it cuts out the middle man :-D
>>>>>>>
>>>>>>> Rowland
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Dec 1, 2015 at 11:22 AM, Rowland Penny <
>>>>>>>> rowlandpenny241155 at gmail.com
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>> On 01/12/15 17:09, Jonathan S. Fisher wrote:
>>>>>>>>>
>>>>>>>>> So your client did no DNS lookups?? That's crazy. Could they be
>>>>>>>>>
>>>>>>>> cached?
>>>>>
>>>>>> (Can you disable nscd if you have it running and try again?)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It isn't running, one of the first things I do when setting up a
>>>>>>>>>
>>>>>>>> new DC
>>>>>
>>>>>> is
>>>>>>>>> to remove nscd if it is installed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Why, in your deity's name, why?????
>>>>>>>>> I'm starting my own caliphate. Seems to be all the rage these
>>>>>>>>>
>>>>>>>> days.
>>>
>>>> Dnsmasq isn't running locally... it's the main DNS server at
>>>>>>>>> 192.168.127.129. At one time I guess we were running Bind, but he
>>>>>>>>> switched
>>>>>>>>> to dnsmasq for simplicity. If there's a legit reason why Windows
>>>>>>>>>
>>>>>>>> needs
>>>>>
>>>>>> to
>>>>>>
>>>>>>> handle 100% of the DNS and DHCP for the network... well that's a
>>>>>>>>>
>>>>>>>> little
>>>>>
>>>>>> scary of a thought. Are these things in no way interoperable?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Ubuntu, you get a caching dnsmasq server as standard, this is
>>>>>>>>> controlled by Network Manager, this shouldn't be running on an AD
>>>>>>>>>
>>>>>>>> client
>>>>>>
>>>>>>> (note this is only from my experience, it seems to interfere with
>>>>>>>>>
>>>>>>>> AD
>>>
>>>> dns).
>>>>>>>>>
>>>>>>>>> DHCP doesn't need to be running on the DC, but it needs to give
>>>>>>>>>
>>>>>>>> your
>>>
>>>> client the required info, see my previous post for what mine
>>>>>>>>>
>>>>>>>> sends.
>>>
>>>> Your AD clients need to use your AD DCs as their DNS servers,
>>>>>>>>>
>>>>>>>> anything
>>>>>
>>>>>> your DCs don't know about i.e. google should be forwarded to a DNS
>>>>>>>>>
>>>>>>>> server
>>>>>>
>>>>>>> that does i.e. your dnsmasq machine
>>>>>>>>>
>>>>>>>>> Your problem isn't that net is using the workgroup name, it is
>>>>>>>>>
>>>>>>>> that
>>>
>>>> your
>>>>>>
>>>>>>> machine doesn't seem to know who it is and where the DCs are :-)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Mind you, until you get 'hostname -f' to return your FQDN, it will
>>>>>>>>>
>>>>>>>> not
>>>>>
>>>>>> work correctly.
>>>>>>>>> Well this "works" right now with what I put into /etc/hosts. Are
>>>>>>>>>
>>>>>>>> you
>>>
>>>> saying it has to work purely from dhcp?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If you have to have that 127.0.1.1 line in /etc/hosts, you have
>>>>>>>>>
>>>>>>>> dns
>>>
>>>> problems.
>>>>>>>>>
>>>>>>>>> Rowland
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>> To unsubscribe from this list go to the following URL and read the
>>>>>>> instructions:  https://lists.samba.org/mailman/options/samba
>>>>>>>
>>>>>>> --
>>>>>> Email Confidentiality Notice: The information contained in this
>>>>>> transmission is confidential, proprietary or privileged and may be
>>>>>>
>>>>> subject
>>>>>
>>>>>> to protection under the law, including the Health Insurance
>>>>>>
>>>>> Portability
>>>
>>>> and
>>>>>
>>>>>> Accountability Act (HIPAA). The message is intended for the sole use
>>>>>>
>>>>> of
>>>
>>>> the
>>>>>
>>>>>> individual or entity to whom it is addressed. If you are not the
>>>>>>
>>>>> intended
>>>>>
>>>>>> recipient, you are notified that any use, distribution or copying of
>>>>>>
>>>>> the
>>>
>>>> message is strictly prohibited and may subject you to criminal or
>>>>>>
>>>>> civil
>>>
>>>> penalties. If you received this transmission in error, please contact
>>>>>>
>>>>> the
>>>>>
>>>>>> sender immediately by replying to this email and delete the material
>>>>>>
>>>>> from
>>>>>
>>>>>> any computer.
>>>>>> --
>>>>>> To unsubscribe from this list go to the following URL and read the
>>>>>> instructions:  https://lists.samba.org/mailman/options/samba
>>>>>>
>>>>>> --
>>>>> To unsubscribe from this list go to the following URL and read the
>>>>> instructions:  https://lists.samba.org/mailman/options/samba
>>>>>
>>>>>
>>>> Email Confidentiality Notice: The information contained in this
>>>> transmission is confidential, proprietary or privileged and may be
>>>>
>>> subject
>>>
>>>> to protection under the law, including the Health Insurance Portability
>>>>
>>> and
>>>
>>>> Accountability Act (HIPAA). The message is intended for the sole use of
>>>>
>>> the
>>>
>>>> individual or entity to whom it is addressed. If you are not the
>>>> intended
>>>> recipient, you are notified that any use, distribution or copying of the
>>>> message is strictly prohibited and may subject you to criminal or civil
>>>> penalties. If you received this transmission in error, please contact
>>>> the
>>>> sender immediately by replying to this email and delete the material
>>>> from
>>>> any computer.
>>>>
>>>> --
>>> To unsubscribe from this list go to the following URL and read the
>>> instructions:  https://lists.samba.org/mailman/options/samba
>>>
>>>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>

-- 
Email Confidentiality Notice: The information contained in this 
transmission is confidential, proprietary or privileged and may be subject 
to protection under the law, including the Health Insurance Portability and 
Accountability Act (HIPAA). The message is intended for the sole use of the 
individual or entity to whom it is addressed. If you are not the intended 
recipient, you are notified that any use, distribution or copying of the 
message is strictly prohibited and may subject you to criminal or civil 
penalties. If you received this transmission in error, please contact the 
sender immediately by replying to this email and delete the material from 
any computer.