[Samba] Samba4 AD DNS -- AD Subdomain vs Clients accessing on different subdomain

[Thomas Maerz]

Mathias,

You seem to have a pretty good grasp on my problem. I checked and the machine thinks it’s hostname was on the root companyname.com domain. I’ve changed this to ad.companyname.com to see if that makes any difference. I also provisioned a Server 2016 TP5 vanilla AD tree to see if the issue is reproducible on an actual Microsoft domain controller. If I have time I will run tcpdump to see what’s happening under the hood and report back.

Thanks for the input!
Thomas

> On May 6, 2016, at 7:01 AM, mathias dufresne <infractory at gmail.com> wrote:
> 
> 2016-05-06 9:39 GMT+02:00 Rowland penny <rpenny at samba.org <mailto:rpenny at samba.org>>:
> 
>> On 05/05/16 21:46, Thomas Maerz wrote:
>> 
>>> Hello,
>>> 
>>> We have an issue we’ve been struggling with for quite some time since we
>>> rolled out 10 Samba4 domain controllers at our main office and all remote
>>> sites about 3 years ago.
>>> 
>>> Simplified Current Configuration:
>>> 
>>> 2 DCs at main site with internal DNS using subdomain ad.companyname.com
>>> 2 BIND CentOS servers serving all intranet DNS requests — main zone:
>>> companyname.com
>>> 2 BIND CentOS servers serving all external site DNS requests — main zone:
>>> companyname.com
>>> 
>>> In this configuration, we have configured the internal BIND servers to
>>> have the S4 AD DCs internal DNS as authoritative for ad.companyname.com,
>>> so clients connected to the BIND servers can resolve anything Samba needs
>>> them to. This allows all client machines on the LAN to resolve any dynamic
>>> DNS address AD creates, join the domain, etc, and it’s easy to configure
>>> when provisioning new DCs. (This is important with so many DCs).
>>> 
>>> When we provision servers which are bound to the domain, clients access
>>> them via DNS entries configured on the main BIND DNS servers, so they have
>>> addresses like hostname.companyname.com, which clients use to connect to
>>> the servers/services. They also have ad.companyname.com hostnames
>>> created by S4 internal DNS, but we don’t point clients at those names.
>>> 
>>> The problem:
>>> 
>>> Some services (mostly OS X server that we’ve noticed so far) when bound
>>> to AD don’t seem to like having the clients pointed at a different DNS name
>>> than the samba subdomain. For example:
>>> 
>>> OS X Server, bound to AD, running SMB file server:
>>> 
>>> When connecting to fileserver.companyname.com
>>> The user must authenticate as ad.companyname.com\shortname OR
>>> The user must authenticate as shortname at ad.brewerscience.com
>>> Using AD\shortname does not work
>>> When connecting to fileserver.ad.brewerscience.com
>>> The user can authenticate as just short name
>>> 
>>> Another example:
>>> 
>>> OS X Server, bound to AD, running Profile Manager:
>>> 
>>> Users can authenticate to the PHP web interface
>>> Users can’t authenticate during device enrollment on the iOS device with
>>> their AD credentials
>>> 
>>> Notes:
>>> 
>>> In the first example, one solution is to simply point the clients at
>>> fileserver.ad.companyname.com, but management is resistant to this idea.
>>> In the second example for the profile manager MDM, The server lives on the
>>> DMZ so that off-campus clients still connect to the MDM and it has both
>>> internal and external DNS entries, so having a public facing
>>> ad.companyname.com address is not a great option.
>>> 
>>> Questions:
>>> 
>>> Would setting up a WINS server help with this?
>>> 
>> 
>> Probably not
>> 
>> Would setting a default search domain from DHCP help with this?
>>> 
>> 
>> Possibly
>> 
>> Is there some way to have a Samba4 AD-Joined host have a domain name on
>>> the base domain (actually, not just a separate record on BIND pointing to
>>> the same IP)?
>>> If so, is it possible to do this with the internal DNS?
>>> Is there some way to integrate Samba4 AD DNS directly with my intranet
>>> BIND DNS setup so that domain-joined hosts get DNS names not the base DNS
>>> domain (companyname.com)?
>>> 
>> 
>> Your main problem is that your DCs dns servers are not authoritative for
>> the AD domain. Make the DCs authoritative for the AD domain, with 10 DCs
>> you will probably be better off running Bind on the DCs. Once the DCs are
>> authoritative, make them forward anything they do not know i.e. internet
>> etc to your intranet DNS servers.
>> 
>> Rowland
> 
> 
> @Rowland:
> The original poster claimed that his AD DNS server are authoritative.
> 
> The AD DNS server using internal DNS backend has nothing - according to my
> own knowledge - to not being authoritative. They own the zones, they host
> them, they manage them, they are the only servers able to reply directly to
> request on these zones...
> 
> So why these AD DNS server would not be authoritative of their own zones?
> 
> @Thomas:
> I would use tcpdump or any traffic analyser, filtering on domain port (TCP
> + UDP), on the member servers where you have issues.
> 
> The point would be to see how behaves these servers regarding DNS requests
> (around your issues).
> 
> Adding a search in resolv.conf would be a first point to try, but not sure
> it solves the issue.
> 
> Louis van Belle told me there is a kernel configuration item to store the
> domain of current server, that configuring domain suffix in that place is
> sometimes better than doing it into resolv.conf. Unfortunately that was for
> Linux systems, I have no idea how to do that (or there is a meaning trying
> that) on Mac OS.
> 
> What seems to important is that your servers "think" they belong to AD
> domain. In any ways. I had issues for some times ago with AD DC when they
> weren't well configured about domain suffix. That was when I was trying to
> use internal DNS (which I stopped because it is not comparable with Bind,
> to say the least).
> When I said servers should "think" they belong to AD domain is when you ask
> them for FQDN they reply <hostname>.<AD domain>.
> With Linux :
> "hostname -f" has to reply <hostname>.<AD domain> when hostname should
> reply only <hostname>.
> 
> According to the fact that your company seems to love their old (or real)
> domain suffix, servers are configured to reply <hostname>.<company name>
> rather than <hostname>.<AD domain>.
> I have no idea why that would perturb things, but as these "things" are
> numerous, one could rely on that and make the whole process to hang because
> confusion between domains suffixes.
> 
> 
> 
>> 
>> 
>> 
>> 
>> --
>> To unsubscribe from this list go to the following URL and read the
>> instructions:  https://lists.samba.org/mailman/options/samba <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 <https://lists.samba.org/mailman/options/samba>