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

mathias dufresne infractory at gmail.com
Thu Dec 24 13:06:56 UTC 2015

Using ldbsearch we can find needed informations if we know AD Sites names

Sites informations are stored in CN=CONFIGURATION,DC=SAMBA,DC=DOMAIN,DC=TLD.

Here there is a CN=Sites which seems to contains Sites informations.

Next using a search with -b
list object related to <site-name>.

And we would find in there a CN=Servers which contains server list.

So using a manually created Sites list we can create missing entries.

Next question is what are these missing entries :)

2015-12-24 12:16 GMT+01:00 mathias dufresne <infractory at gmail.com>:

> Hi James and everyone,
> There is a real issue with samba_dnsupdate and DNS records creation with
> Samba 4 as AD when it comes to AD Sites.
> Samba does not seems to create at all any Site relevant DNS record. As AD
> relies on DNS to find DC on the correct AD site, if no DNS entry is created
> related to AD Site, no usage of AD Sites.
> Here Win client ask for domain
> 11:37:28.671044 IP >
> dns1.ad.dgfip.finances.gouv.fr.domain: 50244+ SRV? _ldap._tcp.pdc._
> msdcs.ad.dgfip.finances.gouv.fr. (65)
> 11:37:28.671308 IP dns1.ad.dgfip.finances.gouv.fr.domain >
> 50244 1/2/3 SRV m702.ad.dgfip.finances.gouv.fr.:389 0
> 100 (202)
> Just after that it asks for kerberos service on "SCIF" AD Site:
> 11:44:59.550011 IP >
> dns1.ad.dgfip.finances.gouv.fr.domain: 17936+ SRV?
> _kerberos._tcp.SCIF._sites.dc._msdcs.AD.DGFIP.FINANCES.GOUV.FR. (80)
> 11:44:59.550979 IP dns1.ad.dgfip.finances.gouv.fr.domain >
> 17936 NXDomain 0/0/0 (80)
> And no entry.
> So falling back to domain without site mentioned
> 11:44:59.621886 IP >
> dns1.ad.dgfip.finances.gouv.fr.domain: 40345+ SRV? _kerberos._tcp.dc._
> 11:44:59.622133 IP dns1.ad.dgfip.finances.gouv.fr.domain >
> 40345 5/5/5 SRV m704.ad.dgfip.finances.gouv.fr.:88 0
> 100, SRV m705.ad.dgfip.finances.gouv.fr.:88 0 100, SRV
> m702.ad.dgfip.finances.gouv.fr.:88 0 100, SRV
> m706.ad.dgfip.finances.gouv.fr.:88 0 100, SRV
> m703.ad.dgfip.finances.gouv.fr.:88 0 100 (468)
> In DNS MS console from RSAT we can see a directory "_sites" in default
> domain zone and in _msdcs domain zone. There is no directory related to
> others sites.
> In samba.domain.tld -> _sites -> Default-First-Site-Name there are entries
> related to DC and associated SRV records.
> I expect this should be the same for any AD Site we configure.
> And solving these lack of DNS configuration should help to deal with AD
> Sites and so with AD failover.
> I did tried to use samba_dnsupdate to create these entries but nothing
> related to AD Sites except for Default-First-Site-Name site.
> To be able to manage that first thing would be to have a samba command to
> list declared Sites (samba-tool sites list ?) then we should have a command
> to list declared DC in that site.
> Then we would be able to rely on samba commands to list sites and DC in
> each sites, so we would be able to script something to create needed
> entries (these needed entries should be the same or almost as
> for Default-First-Site-Name, anyway tcpdump could help to find which
> entries are requested by clients).
> Best regards, wishing you all a merry Christmas : )
> mathias
> 2015-12-23 20:37 GMT+01:00 mathias dufresne <infractory at gmail.com>:
>> Hi James,
>> First thanks for you detailed answer and the tests you did to be able to
>> write this.
>> Before reading your mail I was believing MS Windows keeps only one
>> credentials, those for last connected account. This is why I did not pushed
>> too far authentication process.
>> Tomorrow I'm back to work and I'll redo this test, using some others
>> users to test than some I have already used to connect on that MS Windows
>> acting as client.
>> I'll try to power down the DC in the morning and I'll try to make tests
>> in the afternoon. If I can't tomorrow I won't be able to do these tests
>> before January.
>> The caching of credentials is default behaviour of Windows systems yes.
>> You can have similar behavior on Linux with SSSD and also Winbind or nslcd,
>> I believe (so I'm not sure).
>> SSSD is also supposed to come with AD Sites management but I missed
>> something during the few time I tried that. Two reasons could have made me
>> failed on that: a too old SSSD version or a bad admin (me). I expect it's
>> the latter.
>> What I wrote about NS and SOA came from a discussion I had several weeks
>> ago with one person managing Bind daily for the company I work for. She
>> agreed client should not use NS nor SOA but as this is not one of her
>> problem, this was just thoughts (but her thoughts seems more trustable as
>> most of mines :D)
>> 2015-12-23 19:46 GMT+01:00 James <lingpanda101 at gmail.com>:
>>> 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
>>> Site2 <> is
>>> I would create 2 additional AD Sites : Site1 + Site2
>>> To AD site "Site1" I would associate and associate also DC1
>>> To AD site "Site2" I would associate and associate also DC2
>>> To Default-First-Site-Name no network is associated but both DC must be in
>>> that site too.
>>> Client from 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> <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> <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
>>> 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> <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

More information about the samba mailing list