[Samba] Authentication to Secondary Domain Controller initially fails when PDC is offline

mathias dufresne infractory at gmail.com
Fri Nov 27 14:46:04 UTC 2015


I would verify the 2 DC are declared on every client as DNS servers. To
avoid the need to declare all DCs on all clients you can add one (or more)
pure DNS server which will receive all requests and forward those for AD to
AD DC. When having lot of DC this second way could be finally easier.

This DNS must have a forward zone similar as that:
------------------------------------
zone "ad.domain.tld" IN {
  type forward;
  forward only;
  forwarders {
    10.1.0.1;
    10.1.0.2;
    10.2.8.1;
    10.2.8.2;
  };
};
--------------------------------

All mentioned IP address are DC.

Then as OP as two separated networks with one DC per network (let's call
them "main site" and "remote site") I would create 2 site using DSSITE.msc
in addition of "Default-First-Site-Name" as follow:
"Default-First-Site-Name" containing DC1 + DC1, no network associated.
"Main-site" containing DC1, associated to main site networks (for example
10.1.0.0/16, to suit previous example)
"Remote-site" containing DC2, associated to all networks related to this
remote site (for example 10.2.8.0/24)

This because I think a Windows client tries first to find a DC on one
AD-site matching its IP (ie if client has IP 10.1.2.3 this client will
belong to "Main-site" and will try to find a DC belonging to "Main-site").
And if a client does not find any DC available on its AD-site, this client
will look for a DC in Default-First-Site-Name, that's why in that site all
DC should be declared.

Of course each client must be able to resolve AD DNS zones from any (or at
least, several) DC as DCs are meant to serve all clients in case of
fail-over.

Cheers,

mathias


2015-11-27 15:19 GMT+01:00 Rowland Penny <rowlandpenny241155 at gmail.com>:

> On 27/11/15 13:18, James wrote:
>
>> On 11/26/2015 10:35 AM, Ole Traupe wrote:
>>
>>>
>>> ANYWAYS, I would like to approach from a different direction:
>>>>>
>>>>> If my first DC is offline, a ping on any of my domain machines takes
>>>>> 5+ seconds to resolve. I figure that my logon problems reflect multiple
>>>>> such timeouts during the logon process accumulating to a total duration not
>>>>> accepted by the unix logon mechanism.
>>>>>
>>>>> If there would be ANY way to reduce the time (to 1 s or something) a
>>>>> machines waits until it finally accepts that a DNS server just won't
>>>>> respond and goes over to the next one... - that actually might solve the
>>>>> issue.
>>>>>
>>>>> Is there an option for this on unix machines?
>>>>>
>>>>> Ole
>>>>>
>>>> You can add your DC's to your hosts file. Usually your hosts file is
>>>> queried first, prior to DNS for resolve.
>>>>
>>>
>>> And this would speed up the whole process? Is this a guess or your
>>> experience?
>>>
>>>
>>>> One thing I notice a bit odd is this
>>>>
>>>> SOA: serial=29, refresh=180, retry=600, expire=86400, minttl=180,
>>>> *ns=DC2.my.domain.tld.*, email=hostmaster.my.domain.tld. (flags=600000f0,
>>>> serial=0, ttl=3600)
>>>>
>>>> Normally your name server would be the same as your DC who is SOA. Did
>>>> you manually change this from DC1 to DC2? What DC is your SOA?
>>>>
>>>
>>> I am sorry about the confusion. I demoted my DC1 a while ago due to
>>> hardware problems. I mean to replace it, because currently my First_DC
>>> (FSMO role holder and SOA) is a virtual machine on a storage server which
>>> isn't ideal for many reasons.
>>>
>>> Currently I have DC2 (First_DC) and DC3 (Second_DC). Had I paid
>>> attention to this, I would have changed the names in the text and output
>>> snippets I posted.
>>>
>>> Again: I apologize.
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> Your host file is queried first before your dns server. I say usually
>> because you can change this behavior. This would speed up the process of
>> resolving your DNS servers IP to a hostname.
>>
>> So is your DC2 now the SOA? Did you create the SOA RR for DC2?
>>
>>
> What SOA RR for DC2?
>
> You can only have one SOA record.
>
> Rowland
>
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>


More information about the samba mailing list