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

On 11/20/2015 7:40 AM, Ole Traupe wrote:
>
>
> Am 20.11.2015 um 11:54 schrieb mathias dufresne:
>> Hi Ole,
>>
>> I'm still not answering your issue but I come back to speak about 
>> TTL. Perhaps someone would be able to bring us some light on that.
>>
>> This morning I'm trying to reproduce the way I do broke my test AD 
>> domain. This leads me to deal with SOA record (I broke my test AD 
>> seizing FSMO roles before removing old FSMO owner, SOA was not 
>> changed during that process and I suspect this was one of the point 
>> leading to all issues this test domain has)
>>
>> Anyway:
>> samba-tool dns query m700 samba.domain.tld samba.domain.tld SOA -k yes
>>   Name=, Records=1, Children=0
>>     SOA: serial=1, refresh=900, retry=600, expire=86400, 
>> *minttl=3600*, ns=m700.samba.domain.tld., 
>> email=hostmaster.samba.domain.tld. (flags=600000f0, serial=1, 
>> *ttl=3600*)
>>   Name=_msdcs, Records=0, Children=0
>>   Name=_sites, Records=0, Children=1
>>   Name=_tcp, Records=0, Children=4
>>   Name=_udp, Records=0, Children=2
>>   Name=DomainDnsZones, Records=0, Children=2
>>   Name=ForestDnsZones, Records=0, Children=2
>>   Name=m700, Records=0, Children=0
>>
>> This shows us TTL is in fact equal to minimumttl inside AD DB.
>
> Not for me:
>
> 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)
>
>
>>
>> According to 
>>
http://stackoverflow.com/questions/20297531/meaning-of-the-five-fields-of-the-answer-section-in-dig-query
>> the second member of dig's answer section is TTL.
>>
>> dig -t soa samba.domain.tld
>> ...
>> samba.domain.tld. *3593* IN      SOA m700.samba.domain.tld. 
>> hostmaster.samba.domain.tld. 1 900 600 86400 3600
>> ...
>>  When yesterday the same request gave the following answer:
>>
>> ...
>> samba.domain.tld. *1715* IN      SOA DC1.samba.domain.tld. 62 900 600 
>> 86400 3600
>> ...
>>
>> So I ran several that same command and each the value displayed as 
>> second member (here 1715 or 3593) was descreased by the same amount 
>> of second as the time between my command launchs.
>>
>> It seems this shown TTL is declared TTL (or minttl) minus the amount 
>> of seconds since last renewal of this TTL. No idae why this 
>> behaviour. If someone knows, I would be pleased to learn :)
>
> Yes, I thought so. This is "remaining TTL" for you.
>
> Interestingly, for me this value is always constant and equals 1h, no 
> matter what.
>
>
> 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.

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?







-- 
-James

2015-11-20 15:11 GMT+01:00 James <lingpanda101 at gmail.com>:
> On 11/20/2015 7:40 AM, Ole Traupe wrote:
>
>>
>>
>> Am 20.11.2015 um 11:54 schrieb mathias dufresne:
>>
>>> Hi Ole,
>>>
>>> I'm still not answering your issue but I come back to speak
about TTL.
>>> Perhaps someone would be able to bring us some light on that.
>>>
>>> This morning I'm trying to reproduce the way I do broke my test
AD
>>> domain. This leads me to deal with SOA record (I broke my test AD
seizing
>>> FSMO roles before removing old FSMO owner, SOA was not changed
during that
>>> process and I suspect this was one of the point leading to all
issues this
>>> test domain has)
>>>
>>> Anyway:
>>> samba-tool dns query m700 samba.domain.tld samba.domain.tld SOA -k
yes
>>>   Name=, Records=1, Children=0
>>>     SOA: serial=1, refresh=900, retry=600, expire=86400,
*minttl=3600*,
>>> ns=m700.samba.domain.tld., email=hostmaster.samba.domain.tld.
>>> (flags=600000f0, serial=1, *ttl=3600*)
>>>   Name=_msdcs, Records=0, Children=0
>>>   Name=_sites, Records=0, Children=1
>>>   Name=_tcp, Records=0, Children=4
>>>   Name=_udp, Records=0, Children=2
>>>   Name=DomainDnsZones, Records=0, Children=2
>>>   Name=ForestDnsZones, Records=0, Children=2
>>>   Name=m700, Records=0, Children=0
>>>
>>> This shows us TTL is in fact equal to minimumttl inside AD DB.
>>>
>>
>> Not for me:
>>
>> 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)
>>
>>
>>
>>> According to
>>>
http://stackoverflow.com/questions/20297531/meaning-of-the-five-fields-of-the-answer-section-in-dig-query
>>> the second member of dig's answer section is TTL.
>>>
>>> dig -t soa samba.domain.tld
>>> ...
>>> samba.domain.tld. *3593* IN      SOA m700.samba.domain.tld.
>>> hostmaster.samba.domain.tld. 1 900 600 86400 3600
>>> ...
>>>  When yesterday the same request gave the following answer:
>>>
>>> ...
>>> samba.domain.tld. *1715* IN      SOA DC1.samba.domain.tld. 62 900
600
>>> 86400 3600
>>> ...
>>>
>>> So I ran several that same command and each the value displayed as
>>> second member (here 1715 or 3593) was descreased by the same amount
of
>>> second as the time between my command launchs.
>>>
>>> It seems this shown TTL is declared TTL (or minttl) minus the
amount of
>>> seconds since last renewal of this TTL. No idae why this behaviour.
If
>>> someone knows, I would be pleased to learn :)
>>>
>>
>> Yes, I thought so. This is "remaining TTL" for you.
>>
>> Interestingly, for me this value is always constant and equals 1h, no
>> matter what.
>>
>>
>> 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.
>
> 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?
>
> --
> -James
>
>
> I thought all name servers of a given zone should be declared as NS for
they can all reply to queries.
But on my AD there is only one NS, the SOA.
In fact I thought the SOA was here to distinguish which NS among all NS is
the master.

With only one NS record when several DNS are present for the same zone, I
expect only one NS will reply to every request so, according to what I had
understood about DNS, only one DC will receive all requests from clients.

If I'm right, why Samba does not add NS when a DC is joined?

Today I played with fsmo seize. I haven't checked NS records until now. I
have 2 DCs, DC1 & DC2, DC2 became new FSMO, I also modified SOA record to
set SOA on DC2.
Looking for NS record of my AD I have only DC1 as NS when DC2 is SOA.

Ole,

I would declare DC2 as NS. Then once DC1 is off, when a client would ask
for NS list of your AD this client would receive DC1 + DC2 and would have
more chances to send its request to DC2.

Then you re-run your test with only DC2 up and running.
Note DNS have need time to be updated if you are using others DNS servers
between clients and AD DCs.

On 11/20/2015 10:17 AM, mathias dufresne wrote:
>
>
> 2015-11-20 15:11 GMT+01:00 James <lingpanda101 at gmail.com 
> <mailto:lingpanda101 at gmail.com>>:
>
>     On 11/20/2015 7:40 AM, Ole Traupe wrote:
>
>
>
>         Am 20.11.2015 um 11:54 schrieb mathias dufresne:
>
>             Hi Ole,
>
>             I'm still not answering your issue but I come back to
>             speak about TTL. Perhaps someone would be able to bring us
>             some light on that.
>
>             This morning I'm trying to reproduce the way I do broke my
>             test AD domain. This leads me to deal with SOA record (I
>             broke my test AD seizing FSMO roles before removing old
>             FSMO owner, SOA was not changed during that process and I
>             suspect this was one of the point leading to all issues
>             this test domain has)
>
>             Anyway:
>             samba-tool dns query m700 samba.domain.tld
>             samba.domain.tld SOA -k yes
>               Name=, Records=1, Children=0
>                 SOA: serial=1, refresh=900, retry=600, expire=86400,
>             *minttl=3600*, ns=m700.samba.domain.tld.,
>             email=hostmaster.samba.domain.tld. (flags=600000f0,
>             serial=1, *ttl=3600*)
>               Name=_msdcs, Records=0, Children=0
>               Name=_sites, Records=0, Children=1
>               Name=_tcp, Records=0, Children=4
>               Name=_udp, Records=0, Children=2
>               Name=DomainDnsZones, Records=0, Children=2
>               Name=ForestDnsZones, Records=0, Children=2
>               Name=m700, Records=0, Children=0
>
>             This shows us TTL is in fact equal to minimumttl inside AD DB.
>
>
>         Not for me:
>
>         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)
>
>
>
>             According to
>            
http://stackoverflow.com/questions/20297531/meaning-of-the-five-fields-of-the-answer-section-in-dig-query
>             the second member of dig's answer section is TTL.
>
>             dig -t soa samba.domain.tld
>             ...
>             samba.domain.tld. *3593* IN      SOA
>             m700.samba.domain.tld. hostmaster.samba.domain.tld. 1 900
>             600 86400 3600
>             ...
>              When yesterday the same request gave the following answer:
>
>             ...
>             samba.domain.tld. *1715* IN      SOA DC1.samba.domain.tld.
>             62 900 600 86400 3600
>             ...
>
>             So I ran several that same command and each the value
>             displayed as second member (here 1715 or 3593) was
>             descreased by the same amount of second as the time
>             between my command launchs.
>
>             It seems this shown TTL is declared TTL (or minttl) minus
>             the amount of seconds since last renewal of this TTL. No
>             idae why this behaviour. If someone knows, I would be
>             pleased to learn :)
>
>
>         Yes, I thought so. This is "remaining TTL" for you.
>
>         Interestingly, for me this value is always constant and equals
>         1h, no matter what.
>
>
>         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.
>
>     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?
>
>     -- 
>     -James
>
>
> I thought all name servers of a given zone should be declared as NS 
> for they can all reply to queries.
> But on my AD there is only one NS, the SOA.
> In fact I thought the SOA was here to distinguish which NS among all 
> NS is the master.
>
> With only one NS record when several DNS are present for the same 
> zone, I expect only one NS will reply to every request so, according 
> to what I had understood about DNS, only one DC will receive all 
> requests from clients.
>
> If I'm right, why Samba does not add NS when a DC is joined?
>
> Today I played with fsmo seize. I haven't checked NS records until 
> now. I have 2 DCs, DC1 & DC2, DC2 became new FSMO, I also modified SOA 
> record to set SOA on DC2.
> Looking for NS record of my AD I have only DC1 as NS when DC2 is SOA.
>
> Ole,
>
> I would declare DC2 as NS. Then once DC1 is off, when a client would 
> ask for NS list of your AD this client would receive DC1 + DC2 and 
> would have more chances to send its request to DC2.
>
> Then you re-run your test with only DC2 up and running.
> Note DNS have need time to be updated if you are using others DNS 
> servers between clients and AD DCs.
The SOA RR identifies a primary DNS name server for the zone as the best 
source of information for the data within that zone and as a entity 
processing the updates for the zone.

The NS resource record is used to notate which DNS servers are 
designated as authoritative for the zone. Listing a server in the NS RR, 
it becomes known to others as an authoritative server for the zone. This 
means that any server specified in the NS RR is to be considered an 
authoritative source by others, and is able to answer with certainty any 
queries made for names included in the zone.

Much of the above was taken almost verbatim from online Microsoft tech 
documents.  I don't believe that DC's create NS records by default.







-- 
-James

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

>
>
>
>
>
>
>

> they can all reply to queries.
> But on my AD there is only one NS, the SOA.
> In fact I thought the SOA was here to distinguish which NS among all NS is
> the master.
>
> With only one NS record when several DNS are present for the same zone, I
> expect only one NS will reply to every request so, according to what I had
> understood about DNS, only one DC will receive all requests from clients.
>
> If I'm right, why Samba does not add NS when a DC is joined?
>
> Today I played with fsmo seize. I haven't checked NS records until now.
I
> have 2 DCs, DC1 & DC2, DC2 became new FSMO, I also modified SOA record
to
> set SOA on DC2.
> Looking for NS record of my AD I have only DC1 as NS when DC2 is SOA.
>
> Ole,
>
> I would declare DC2 as NS. Then once DC1 is off, when a client would ask
> for NS list of your AD this client would receive DC1 + DC2 and would have
> more chances to send its request to DC2.
>
> Then you re-run your test with only DC2 up and running.
> Note DNS have need time to be updated if you are using others DNS servers
> between clients and AD DCs.
Mathias, thank you, I will try this. This is very similar to what 
Rowland suggested. Sorry for not testing this earlier, there were other 
things I had to attend to.

What I ask myself: this is the content of my /etc/resolv.conf (without 
">", of course)

 > search my.domain.tld
 > nameserver __IP_of_First_DC__
 > nameserver __IP_of_Second_DC__

This doesn't do the trick? Or will the client ask the NS, who the NS for 
the AD domain is?

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?

-- 
-James

On 11/26/2015 11:12 AM, Ole Traupe wrote:
>
>>> Then you re-run your test with only DC2 up and running.
>>> Note DNS have need time to be updated if you are using others DNS 
>>> servers between clients and AD DCs.
>> The SOA RR identifies a primary DNS name server for the zone as the 
>> best source of information for the data within that zone and as a 
>> entity processing the updates for the zone.
>>
>> The NS resource record is used to notate which DNS servers are 
>> designated as authoritative for the zone. Listing a server in the NS 
>> RR, it becomes known to others as an authoritative server for the 
>> zone. This means that any server specified in the NS RR is to be 
>> considered an authoritative source by others, and is able to answer 
>> with certainty any queries made for names included in the zone.
>>
>> Much of the above was taken almost verbatim from online Microsoft 
>> tech documents.  I don't believe that DC's create NS records by
default.
>
> You mean Samba DCs or DCs in general?
>
> I am not sure I understand the above. Do you suggest to create another 
> NS record for the Second_DC, or not to?
>
> In the resolv.conf on my member servers both DCs are listed as DNS 
> servers. I like to think that the member servers eventually ask the 
> second DNS server, if the first won't respond. This seems to be 
> reflected by ping taking more than 5 s for the first packet to arrive.
>
> BUT what does the second DNS server (Second_DC) reply? Which logon 
> server does it announce?
>
>
DNS can be very confusing. You do not need to create a NS record for 
your second DC if the zone is directory integrated. By default the DC is 
authoritative for that zone.

-- 
-James

On 27/11/15 13:23, James wrote:
> On 11/26/2015 11:12 AM, Ole Traupe wrote:
>>
>>>> Then you re-run your test with only DC2 up and running.
>>>> Note DNS have need time to be updated if you are using others
DNS
>>>> servers between clients and AD DCs.
>>> The SOA RR identifies a primary DNS name server for the zone as the
>>> best source of information for the data within that zone and as a 
>>> entity processing the updates for the zone.
>>>
>>> The NS resource record is used to notate which DNS servers are 
>>> designated as authoritative for the zone. Listing a server in the
NS
>>> RR, it becomes known to others as an authoritative server for the 
>>> zone. This means that any server specified in the NS RR is to be 
>>> considered an authoritative source by others, and is able to answer
>>> with certainty any queries made for names included in the zone.
>>>
>>> Much of the above was taken almost verbatim from online Microsoft 
>>> tech documents.  I don't believe that DC's create NS
records by
>>> default.
>>
>> You mean Samba DCs or DCs in general?
>>
>> I am not sure I understand the above. Do you suggest to create 
>> another NS record for the Second_DC, or not to?
>>
>> In the resolv.conf on my member servers both DCs are listed as DNS 
>> servers. I like to think that the member servers eventually ask the 
>> second DNS server, if the first won't respond. This seems to be 
>> reflected by ping taking more than 5 s for the first packet to arrive.
>>
>> BUT what does the second DNS server (Second_DC) reply? Which logon 
>> server does it announce?
>>
>>
> DNS can be very confusing. You do not need to create a NS record for 
> your second DC if the zone is directory integrated. By default the DC 
> is authoritative for that zone.
>
Probably with windows it is, but not with Samba AD, you only get one NS 
and one SOA. The only authoritative Samba AD DC is the first one, when 
you join a second DC, it runs the same code that created the SOA during 
the first DCs provision and because the SOA already exists, it fails.

Rowland