[Samba] Authentication to Secondary Domain Controller initially fails when PDC is offline
mathias dufresne
infractory at gmail.com
Sun Nov 22 10:15:49 UTC 2015
I would try with one more site associated to main site network(s) and put
both DCs in Default-First-Site-Name with that Default-First-Site-Name
associated with no network.
Without DC available in client's site the client should try to find a DC in
Default-First-Site-Name I believe.
2015-11-22 4:43 GMT+01:00 Allen Chen <achen at harbourfrontcentre.com>:
> I can prove this within my environment:
> at the main site: one DC server(samba 4.1.13), one dhcp server, two DNS
> servers(forward AD query to two AD servers),
> at the branch site: one DC server(samba 4.1.13), one dhcp server, one DNS
> server(forward AD query to two AD server),
> DNSs on client machines point to the DNS servers(not point to the DC).
> The two DCs are synced and do their work properly without any issue(almost
> one year, connected via openVPN).
> Two sites are configured(using windows sites and services tool):
> one site for branch with its subnet, and the Default-First-Site-Name
> for the main site with its subnets.
> Clients at branch automatically log in to the branch DC, and clients at
> the main site automatically log in to the main site DC.
> Everything is working as supposed.
> but one thing doesn't work as the subject says:
> I power off the DC at the main site, or just kill samba process, login
> hangs at main site.
> I start samba service, I can log in immediately.
> I don't know why it doesn't use the DC at branch site when the main site
> DC is offline.
>
> If anybody has similar settings, can you share your experience when one DC
> is offline?
>
> Thanks,
> Allen
>
>
> DC at branch site,
> On 11/20/2015 12:35 PM, James wrote:
>
>> 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.
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> Allen Chen
> Network Administrator
> IT
>
> Harbourfront Centre
>
> 235 Queens Quay West, Toronto, ON
> M5J 2G8, Canada | harbourfrontcentre.com <
> http://www.harbourfrontcentre.com>
> Office: +1 416 973 7973
> Cell: +1 416 556 2493
>
>
>
>
> --
> 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