samba - May 2016 - Samba4 AD DNS -- AD Subdomain vs Clients accessing on different subdomain

2016-05-06 9:39 GMT+02:00 Rowland penny <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
>

On 06/05/16 13:01, mathias dufresne wrote:
> 2016-05-06 9:39 GMT+02:00 Rowland penny <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?
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:
> 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
>>

> 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
tmaerz at brewerscience.com <mailto:tmaerz at 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.
> On May 6, 2016, at 11:10 AM, Rowland penny <rpenny at samba.org>
wrote:
> 
> On 06/05/16 13:01, mathias dufresne wrote:
>> 2016-05-06 9:39 GMT+02:00 Rowland penny <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?
> 
> 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
<http://hostname.companyname.com/>, which clients use to connect to
> the servers/services. They also have ad.companyname.com
<http://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:
>> 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
>>> 
> 
> 
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba

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>