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

[Thomas Maerz]

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 shor...@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?
Would setting a default search domain from DHCP help with this?
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)?
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

[Rowland penny]

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

[mathias dufresne]

@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.

[Rowland penny]

He posted this:

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.

Clients are not being pointed correctly, clients joined to the domain
should be pointed at the DCs first, anything they do not know, they ask
their forwarders.

He needs to stop using his main DNS servers for queries about the AD
domain and as you have pointed out, his clients need to use the DNS
domain name of the AD DCs

Rowland

[Thomas Maerz]

> Clients are not being pointed correctly, clients joined to the domain should be pointed at the DCs first, anything they do not know, they ask their forwarders.

Although I agree that what you’re suggesting is a sane configuration, there are other ways to do it and I have tried it both ways. As I’ve explained in my first post, curgently all clients are pointed at BIND servers which forward all requests for ad.companyname.com to the S4 AD DC DNS servers. The S4 AD servers are authoritative for zone ad.companyname.com. The zone is resolvable whether or not you point at the BIND servers or the DCs directly.

> He needs to stop using his main DNS servers for queries about the AD domain and as you have pointed out, his clients need to use the DNS domain name of the AD DCs

My DNS configuration is working — BUT I have also pointed the clients directly at the Samba4 domain controller DNS servers and that does not make any difference. Few of the computers are joined to the domain (They are macs). This domain is primarily used for authentication.

Thomas Maerz
Network/Systems Administrator
Brewer Science, Inc.
A+ NET+ CCENT MCDST
tma...@brewerscience.com <mailto:tma...@brewerscience.com>
work: 573-364-0444 x1402
cell: 573-612-1349

CONFIDENTIALITY NOTICE
This message (and any of its attachments) is intended for the addressee and may contain confidential information, may be attorney-client privileged, and may constitute inside or non-public information under federal or state laws. Unauthorized use of this information is strictly prohibited and may be unlawful. If you have received this email transmission in error, please immediately notify the sender by return email, delete the email and any attachments, and empty any folders containing the discarded information.

> addresses like hostname.companyname.com <http://hostname.companyname.com/>, which clients use to connect to
> the servers/services. They also have ad.companyname.com <http://ad.companyname.com/> hostnames

[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 <infra...@gmail.com> wrote:
>
> 2016-05-06 9:39 GMT+02:00 Rowland penny <rpe...@samba.org <mailto:rpe...@samba.org>>:

>> 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>

[mathias dufresne]

2016-05-06 19:49 GMT+02:00 Thomas Maerz <tma...@brewerscience.com>:

>
> > Clients are not being pointed correctly, clients joined to the domain
> should be pointed at the DCs first, anything they do not know, they ask
> their forwarders.
>
> Although I agree that what you’re suggesting is a sane configuration,
> there are other ways to do it and I have tried it both ways. As I’ve
> explained in my first post, curgently all clients are pointed at BIND
> servers which forward all requests for ad.companyname.com to the S4 AD DC
> DNS servers. The S4 AD servers are authoritative for zone
> ad.companyname.com. The zone is resolvable whether or not you point at
> the BIND servers or the DCs directly.
>
>

I'm working for a pretty big company and as every pretty big company they
are pretty much teams managing IT things. Regarding DNS things that I
didn't knew well I first went into DNS team office to speak about
integrating AD in their information system. Of course I was directed to the
person who know the better their DNS configuration, how to manage it. This
person was aware about AD, she managed Bind servers and DNS questions for
years. Her reply was to produce a configuration which is very like what
described Thomas.
What we are supposed to do once will go to prod mode is to declare AD zones
with type = forward on company's DNS server. The type forward for zones
could be seen as a trick to avoid looking for NS for a given, the zone we
declare with type = forward, because in that zone we declare forwarders
which are, in our cases, AD DNS servers. So when main DNS receive a DNS
request for AD zone this Bind server check its own zones, it find the
forward zone which match the request, look into that zone and discover that
the request must be forwarded to some others DNS servers which are listed
with IP addresses. The main DNS server forward the request, receive the
reply (found or or not) and forward the reply to the client.

Now I must say Rowland was right when he wrote "clients joined to the
domain should be pointed at the DCs first". This would have been a mistake
if the sentence was "clients joined to the domain MUST be pointed at the
DCs first".

Example to clarify: the point is the client can resolve AD zone, nothing
else.
We can buy a domain to some registrar.

We prepare 4 DC, 2 are declared as DNS server on our registrar.

For that works these two MUST have a valid public IP on the internet where
Bind is listening.

We declare two NS on our AD zones, the two DNS servers declared into the
registrar. Now any DNS server on the net can resolve any records from our
AD zones. And our client can resolve AD zones using their ISP DNS servers
or using the two internal DNS server (if they can reach them) or using the
two public AD DNS servers.

No need to point client resolver to AD DNS server. The need is to
understand DNS enough to make it work.

DNS is meant to be stacked. One resolver, any reply, because DNS servers
know how to ask each other to find replies.

> He needs to stop using his main DNS servers for queries about the AD
> domain and as you have pointed out, his clients need to use the DNS domain
> name of the AD DCs
>
> My DNS configuration is working — BUT I have also pointed the clients
> directly at the Samba4 domain controller DNS servers and that does not make
> any difference. Few of the computers are joined to the domain (They are
> macs). This domain is primarily used for authentication.
>
>

No real surprise what does not as the issue should not come from DNS stack
but from client configuration.
No surprise neither reading that your client thought it belongs to
companyname.tld rather than ad.companyname.tld. Change that and the issue
should disappear. Something should not read Kerberos configuration to know
what realm to use but rather relies on system's FQDN and use the system's
FQDN to extract domain name to be use as realm. "realm" could be replaced
by "AD domain" in previous sentence if the issue is from non-kerberos tool.

As mentioned in my first mail Louis explained me on Linux systems you can
set FQDN using /etc/hosts but also using some sysctl.conf parameter, some
kernel parameter. This configuration through Kernel parameter is a deeper
configuration - from what I feel I understood, no more than feelings, sorry
- and should apply better than if you only configure that system through
/etc/hosts.

Best regards,

mathias dufresne