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

Ole Traupe ole.traupe at tu-berlin.de
Fri Nov 20 11:14:00 UTC 2015


Mathias, thanks for the hint, but I don't really care about that 
scenario at the moment. We have local accounts on the machines for that 
purpose. And it has nothing to do with domains being fail-safe. Clients 
can have problems.

However, my homes and other shares are on a Samba4 file server. And 
without authentication working properly, my users can't work. As simple 
as that.

Ole


Am 20.11.2015 um 12:07 schrieb mathias dufresne:
> I would not perform test unplugging DC ethernet cables but rather 
> unplugging clients ethernet cables.
>
> This because you seem to have already several DC 'at least 2 as one is 
> called DC2) so normally, if you don't have a too bad karma, both 
> servers should go down at same time.
> But your client can become unavailable to reach your working DCs. A 
> user with a laptop can use his laptop outside of your LAN.
> And what seems to me important is that user can use his laptop when it 
> can't discuss with DCs.
>
> On your enterprise LAN the whole AD should not become unavailable: you 
> designed it for it is always available (several DC are meant for that 
> purpose) so that seems to me a non-relevant test case. But of course I 
> don't know your context and perhaps it is a valid test case for you ;)
>
> 2015-11-20 11:56 GMT+01:00 Ole Traupe <ole.traupe at tu-berlin.de 
> <mailto:ole.traupe at tu-berlin.de>>:
>
>     Although I don't know what "dig" actually means, I was able to dig
>     up the following for my SOA:
>
>     my.domain.tld.       3600    IN      SOA DC2.my.domain.tld.
>     hostmaster.my.domain.tld. 29 180 600 86400 180
>
>     This is after I reduced refresh interval and minimum TTL to 3 min
>     (180 s). Still, the TTL of the SOA itself is 1h (3600 s).
>
>     This strongly suggests, that the TTL for DNS info *provided by*
>     the SOA is not necessarily related to the TTL of the SOA record
>     *itself*.
>
>     Might that be? Could that be the reason why reducing minimum TTL
>     doesn't solve the login problem? How to change the TTL of the SOA
>     record? Does that even make sense?
>
>     Nevertheless, I want to re-state that waiting longer than the TTL
>     of 1h after pulling the (Ethernet) plug on my first DC didn't
>     improve the situation, either.
>
>     Ole
>
>
>     Am 19.11.2015 um 14:04 schrieb mathias dufresne:
>>     No idea about your main issue, I was merely answering to your
>>     last question about changing SOA record.
>>
>>     Here is another view of that command:
>>     samba-tool dns update <server> <zone> <name> SOA \
>>     'OLDnameserver email serial refresh retry expire minimumttl' \
>>     'NEWnameserver email serial refresh retry expire minimumttl'
>>
>>     I'm not too confident with DNS internals so I'm not sure if the
>>     TTL you mentioned is or isn't "expire" or "minimumttl".
>>
>>     After digging a little bit it seems previous line is completely
>>     wrong, neither "expire" nor "minimumttl" are "TTL".
>>     This because :
>>     dig -t SOA SAMBADOMAIN.TLD
>>     ...
>>     samba.domain.tld. 1715 IN      SOA DC1.samba.domain.tld. 62 900
>>     600 86400 3600
>>     ...
>>
>>     And from what I just read in dig "ANSWER SECTION" the second
>>     field is the TTL, so 1715 in my case, which as nothing to do with
>>     "expire" (86400) or "minimumtll" (3600).
>>
>>     And that makes me wondering how TTL can be less than "minimumttl"...
>>
>>     So, the short way: the command I gave do not seem to be designed
>>     to help you changing TTL. Sorry : )
>>
>>     Cheers,
>>
>>     mathias
>>
>>     2015-11-19 13:43 GMT+01:00 Ole Traupe <ole.traupe at tu-berlin.de
>>     <mailto:ole.traupe at tu-berlin.de>>:
>>
>>         Mathias, thank you very much for your comprehensive instructions!
>>
>>         Just one question: Harry suggested that, in order to overcome
>>         the below DNS related problems, the TTL would have to be
>>         adjusted (lowered). However, the TTL seems to be the only
>>         time value not covered by the command provided by you.
>>
>>         Is it really the TTL that is the culprit or is it rather the
>>         first time value (something like "Refresh value" in english)?
>>
>>         Do you know this?
>>
>>         Ole
>>
>>
>>
>>         Am 19.11.2015 um 11:19 schrieb mathias dufresne:
>>>         Hi Ole,
>>>
>>>         You want to change SOA of your AD domain?
>>>
>>>         Here some working command:
>>>         samba-tool dns update <working DC> samba.domain.tld \
>>>         samba.domain.tld SOA \
>>>         'oldSOA.samba.domain.tld. hostmaster.samba.domain.tld. 58
>>>         900 600 86400 3600' \
>>>         'newSOA.samba.domain.tld. hostmaster.saba.domain.tld. 59 900
>>>         600 86400 3600' -k yes
>>>
>>>         This needs you performed some kinit before using an account
>>>         able to modify this entry (by default only administrator is
>>>         able to that I expect).
>>>
>>>         This must be done for the two DNS zones of your domain:
>>>         samba.domain.tld + _msdcs.samba.domain.tld
>>>
>>>         First number of replacement record (here "59") is serial
>>>         number. Replication of change seemed to work without
>>>         changing that serial number but as DNS love to rely on it,
>>>         changing that serial should be a good idea.
>>>
>>>         Hoping this helps...
>>>
>>>         Cheers,
>>>
>>>         mathias
>>>
>>>
>>>         2015-11-18 16:44 GMT+01:00 Ole Traupe
>>>         <ole.traupe at tu-berlin.de <mailto:ole.traupe at tu-berlin.de>>:
>>>
>>>
>>>                 It is DNS related.
>>>
>>>                     What is the best way of dealing with this?
>>>
>>>                 The *best way* is a HA solution for your DNS
>>>                 Servers, but its expensive.
>>>
>>>                 The DNS client (resolver) caches the srv records for
>>>                 15 minutes aka 900
>>>                 seconds.
>>>
>>>                 ipconfig /flushdns drops the cache. Reboot does the
>>>                 same.
>>>
>>>                 On server side you may set shorter TTL for the
>>>                 server records, but then
>>>                 you have more DNS traffic. On small netwoks (sites
>>>                 up to 20 clients, no
>>>                 wifi) I have good experience with a TTL of 180.
>>>
>>>
>>>             Harry, I tried this - unsuccessfully.
>>>
>>>             I have TTL settings in a) the SOA and b) the NS record
>>>             of the FQDN and the _msdcs.FQDN sections in my Windows
>>>             RSAT DNS console. None of these 4 entries I can change:
>>>             I get something like "The Source Of Authority (SOA)
>>>             cannot be updated. The record already exists."
>>>
>>>             Do you have an idea how to accomplish this? Currently
>>>             the setting is 1h, which is pretty long.
>>>
>>>             Ole
>>>
>>>
>>>
>>>
>>>             -- 
>>>             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