[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
list.
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
'CN=<site-name>,CN=Sites,CN=CONFIGURATION,DC=SAMBA,DC=DOMAIN,DC=TLD' we can
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 10.207.102.32.50193 >
> 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 >
> 10.207.102.32.50193: 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 10.207.102.32.52905 >
> 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 >
> 10.207.102.32.52905: 17936 NXDomain 0/0/0 (80)
> And no entry.
>
> So falling back to domain without site mentioned
> 11:44:59.621886 IP 10.207.102.32.58708 >
> dns1.ad.dgfip.finances.gouv.fr.domain: 40345+ SRV? _kerberos._tcp.dc._
> msdcs.AD.DGFIP.FINANCES.GOUV.FR. (68)
> 11:44:59.622133 IP dns1.ad.dgfip.finances.gouv.fr.domain >
> 10.207.102.32.58708: 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 10.1.0.0/16
>>> Site2 <http://10.1.0.0/16Site2> 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> <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
>>> 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> <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