samba - Nov 2015 - Authentication to Secondary Domain Controller initially fails when PDC is offline

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

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

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

On 20/11/15 11:07, mathias dufresne wrote:
> I would not perform test unplugging DC ethernet cables but rather
> unplugging clients ethernet cables.
That is a totally different problem there, if there are no DCs 
available, can users still login?
'winbind offline logon = yes' will deal with this

Rowland
>
> 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 ;)
>
>