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

[James]

On 12/23/2015 12:39 PM, mathias dufresne wrote:
> And for Ole, the OP, to solve its own failover issue:
> As there is 2 physical sites and only 2 DC.
> Let's say
> Site1 is 10.1.0.0/16
> Site2 is 10.2.0.0/16
> I would create 2 additional AD Sites : Site1 + Site2
> To AD site "Site1" I would associate 10.1.0.0/16 and associate also DC1
> To AD site "Site2" I would associate 10.2.0.0/16 and associate also DC2
> To Default-First-Site-Name no network is associated but both DC must be in
> that site too.
>
> Client from 10.2.0.0/16 will be asked to launch DNS query to look for DC on
> "Site2" and as long as DC2 is UP this client should use DC2.
> DC2 is out. This means no DC is available for client's AD site, so the
> client fall back to default behaviour which is finding a DC
> in Default-First-Site-Name where the DC are declared ==> this client would
> be able to use DC1 to authenticate.
>
> Cheers
>
> mathias
>
>
>
>
> 2015-12-23 18:14 GMT+01:00 mathias dufresne <infractory at gmail.com>:
>
>> Once both DC were rebooted, after the MS Windows was also rebooted (here I
>> could have just wait I think) this MS Windows client is connecting on DC
>> from its AD Site again.
>>
>> 2015-12-23 16:51 GMT+01:00 mathias dufresne <infractory at gmail.com>:
>>
>>> Hi all,
>>>
>>> Firs I apologize I did not manage to find time to reply earlier.
>>>
>>> The initial issue was about how Samba AD react when one DC is out and
>>> more specifically about what happen when FSMO ower is unreachable (poweroff
>>> in Ole tests).
>>>
>>> This issue is solved using a correct AD Sites configuration.
>>>
>>> Here I kept 3 DCs in my domain.
>>> Sites:
>>> I set up a second site named "authentication" and I've added in that site
>>> 2 DCs, including FSMO owner.
>>> On that "authentication" site I've added the network on which my clients
>>> are.
>>> On "Default-First-Site-Name" I do not configured any network addresses.
>>> All 3 DCs are declared in "Default-First-Site-Name".
>>>
>>> All DC up behaviour:
>>> The windows client when connecting ask to AD for a DC, AD answer this
>>> client it depends of "authentication" site and this client re-launch DNS
>>> requests taking in account AD Site information to retrieve DC list for that
>>> site.
>>> Then the client connects to AD.
>>>
>>> To check which AD DC was used to connected on: launch "cmd" then in that
>>> window type "set". In "set" result there is a line
>>> LOGONSERVER=<DCname>
>>> This is the DC used for connection (and later normally).
>>>
>>> The test:
>>> I powered off both DC in "authentication" site. So only one DC is up and
>>> running, the one *outside* of that site.
>>> Login in Windows works.
>>> Using cmd -> set -> LOGONSERVER=<the last remaining DC>
>>>
>>> I waited something like one hour then I rebooted my MS Windows client. I
>>> can still log in using differnt accounts (administrator then my own
>>> account).
>>> This MS Windows client is still using the only running DC, the one
>>> outside of client's site, this because this DC is in
>>> Default-First-Site-Name.
>>>
>>> This behaviour is normal. It is Site behaviour. It is AD Sites purpose.
>>>
>>> So configuring AD Sites correctly would solve the issue about failover.
>>>
>>>
>>> DNS issue:
>>> SOA and NS records are used when DNS servers are discussing together but
>>> not when a DNS client is asking for records (execpt for SOA or NS
>>> obvisouly).
>>> SOA and NS records are, in my understanding, used when the DNS server
>>> receive a request for a zone this server does not know. In that specific
>>> case the DNS server must find a name server for that zone, so our DNS
>>> server is asking to upper level for a NS in the mentioned zone.
>>>
>>> So, if my understanding is correct, client never uses NS record (not in
>>> normal mode). And so there is no much issue that Samba DNS has only one SOA
>>> and one NS.
>>>
>>> Regarding NS records, I create them manually because it matches our real
>>> configuration (each DC is DNS, each DNS as NS record).
>>>
>>> The point to make Samba AD works with internal is to work around the
>>> issue of samba_dnsupdate. At least it is all I have to do on all domains I
>>> tested, even with the 4.3.3.
>>>
>>> samba_dnsupdate could work with some option in smb.conf to grant unsecure
>>> update of DNS zones.
>>> If you don't want to allow unsecure update, use the awk script I provided
>>> in that thread days (or weeks) ago.
>>>
>>> I use Samba AD with Internal DNS with no issue except for samba_dnsupdate
>>> which not able to create internal record. To solve that issue I provided
>>> here a awk script which extract from samba_dnsupdate needed information to
>>> force recrods creation using samba-tool. This awk script is not dangerous:
>>> you can run it as much you want, it just tries to create entries. If entry
>>> exists, an error is displayed:
>>> ERROR: Record already exists
>>>
>>> If you are afraid of that script you can modify its behaviour replacing:
>>> cmd = "samba-tool dns add "
>>> with
>>> cmd = "echo samba-tool dns add "
>>>
>>> Then the script will do nothing except display what command could be run
>>> to force DNS records creation.
>>>
>>> With all needed DNS records and a well configured AD Sites failover
>>> works. Nicely.
>>>
>>> A last note: 3 DCs means 3 DNS servers. You want your DC can be down so
>>> your clients MUST have all DC declared as "nameserver" in /etc/resolv.conf.
>>>
>>> Another strategy is to build one Bind server with one zone configured
>>> with the exact same name as AD domain, this zone will do forward only and
>>> will forward to all DCs.
>>> Doing that your clients can have only one DNS configured: the one with
>>> Bind forwarding to DCs.
>>> This bind zone config:
>>> ------------------
>>> zone "samba.domain.tld" IN {
>>>    type forward;
>>>    forward only;
>>>    forwarders {
>>>      IP_DC1;
>>>      IP_DC2;
>>>      IP_DC3;
>>>    };
>>> };
>>> -------------------
>>>
>>> I hope you will finally be able to have failover working Ole.
>>>
>>>
>>>
>>>
>>> 2015-12-22 11:44 GMT+01:00 Ole Traupe <ole.traupe at tu-berlin.de>:
>>>
>>>>
>>>>>>> Can I suggest that you do what I did, create your own small test
>>>>>>> domain in VMs using Bind9
>>>>>>>
>>>>>> Yes, that is a good idea. However, from what I had read before, much
>>>>>> of it on the Samba wiki, I was expecting Samba4 to just work with multiple
>>>>>> DCs. I still wonder why no one ever seems to have tested or questioned that
>>>>>> (publicly). And I don't feel that I have to question something myself that
>>>>>> is broadly recommended: use the internal DNS unless you really have to do
>>>>>> otherwise (even by the developers, it seems). In addition, bind9 working
>>>>>> with multiple DC's does not necessarily mean that internal DNS won't.
>>>>>>
>>>>>>
>>>>> I am going to discuss this with Marc and the rest of the team, like
>>>>> you, I am surprised that nobody has raised this before. I have always used
>>>>> Samba with Bind9, so was unaware of this possible problem, it only came to
>>>>> head for me when you mentioned it. I then found I only had one NS  record
>>>>> in the SOA and this lead to where we are now.
>>>>>
>>>> Hi Rowland,
>>>>
>>>> Again: thanks a lot for your support.
>>>>
>>>> Merry Christmas and good holidays to the list!
>>>>
>>>> Ole
>>>>
>>>>
>>>>
>>>>> I also feel the need to would like to state that I am a part-time admin
>>>>>> and I can't test something for a year or so (like others) before I go into
>>>>>> production. With Samba 4 I was rather happy to find something that won't
>>>>>> require so much work (although it feels differently now, partially due to
>>>>>> me being more or less a newbee to unix-based systems, I guess).
>>>>>>
>>>>> It doesn't need much looking after, once you have got it up and running
>>>>> :-)
>>>>>
>>>>> Rowland
>>>>>
>>>>
>>>> --
>>>> To unsubscribe from this list go to the following URL and read the
>>>> instructions:  https://lists.samba.org/mailman/options/samba
>>>>
>>>
Mathias,

     I discovered similar issues after testing for Ole. I have sites and 
services configured as well. It took over a hour for issues to arise 
after shutting down my DC that held all my FSMO roles and SOA record.

I decided to do a quick packet capture just now. I shutdown my DC that 
holds all the roles and SOA record. I logged into the workstation and 
reviewed the trace. I can see the workstation attempt to locate the SRV 
records needed from the first DC. It failed so it then asked my 2nd DC 
in my site. It resolved the SRV records and it allowed me to log in. 
This process never asks for the SOA. I can rule out it plays no part? It 
seems fail over works as expected.

I decided to shutdown my 2nd DC in my site as test. Logged in as another 
user(It allowed me) and reviewed the trace. I can see where the 
workstation attempts to ask both DC's in the site for the SRV records. 
Of course it fails but I see no trace of authentication happening. Why 
did it allow me to log in? I look at the windows event viewer and review 
the auth log. I find this.

Logon Type:            11

New Logon:
     Security ID:        DOMAIN\duser
     Account Name:        duser
     Account Domain:        DOMAIN
     Logon ID:        0x7b11e9
     Logon GUID:        {00000000-0000-0000-0000-000000000000}

I decided to research logon type 11. I find this.

*Logon Type 11 – CachedInteractive*

Windows supports a feature called Cached Logons which facilitate mobile 
users. When you are not connected to the your organization’s network and 
attempt to logon to your laptop with a domain account there’s no domain 
controller available to the laptop with which to verify your 
identity. To solve this problem, Windows caches a hash of the 
credentials of the last 10 interactive domain logons. Later when no 
domain controller is available, Windows uses these hashes to verify your 
identity when you attempt to logon with a domain account.

I assume this is a windows only feature and not a linux feature? This 
was on a wired workstation and not a mobile device. The issues with 
authentication only arouse from mobile devices and only after 
approximately an hour of the "primary" DC being down.




-- 
-James