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

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

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

And to get mentioned entries list I used:
"samba_dnsupdate --verbose --all-names | grep Default-First-Site-name"

This list 8 DNS records related to Default Site.

Next was to change Default-First... by the name of another AD Site (sed is
still working :p)

I was able to create DNS entries which were missing for one of my sites.

Next, test:
Back on one Windows on the network associated to that AD Site, reboot it,
and tcpdump on my DNS server (all requests goes through this DNS server)

1° Site related DNS SRV request:
35752:15:24:38.907301 IP 10.156.248.244.64390 >
dns1.ad.dgfip.finances.gouv.fr.domain: 23013+ *SRV?
_ldap._tcp.authentification._sites.dc.*_msdcs.ad.dgfip.finances.gouv.fr.
(88)
2° Site related DNS SRV reply:
35753-15:24:38.907520 IP dns1.ad.dgfip.finances.gouv.fr.domain >
10.156.248.244.64390: 23013 2/2/4 *SRV* *m705.ad.dgfip.finances.gouv.fr.:389
0 100, SRV m706.ad.dgfip.finances.gouv.fr.:389 0 100* (291)

3° Then A request on one DC returned by previous request:
35754-15:24:38.908731 IP 10.156.248.244.56932 >
dns1.ad.dgfip.finances.gouv.fr.domain: 16037+ *A?
m705.ad.dgfip.finances.gouv.fr <http://m705.ad.dgfip.finances.gouv.fr>*.
(48)
4° the reply:
35755-15:24:38.908859 IP dns1.ad.dgfip.finances.gouv.fr.domain >
10.156.248.244.56932: 16037 1/2/2 *A 10.156.248.222* (135)

Now my Windows clients receive answer when they request SRV record
according to the AD site they belong to.

I must say I've also manually declared each DC as NS. As explained
yesterday evening I don't think this should be important (even if I say the
contrary few weeks ago).
NS record should be used only when clients use a DNS server which is not AD
DNS and if the declared DNS server on client do not need to ask upper level
for NS.
This is so badly described here is an example of my thought:
With AD Domain = samba.org
and Win_client -> DNS server non-AD and nothing configured on this DNS to
help it to find samba.org name servers

When Win_client request DNS server about samba.org, as DNS server do not
know anything about samba.org, the DNS server would ask to root DNS server
(the one for ORG) which servers are responsible for samba.org. Here is the
case where NS should be used.

And with my lack of knowledge about DNS I don't see any other case where NS
should be used.




2015-12-24 14:06 GMT+01:00 mathias dufresne <infractory at gmail.com>:
> 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
>>>>
>>>>
>>>
>>
>