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

[Ole Traupe]

Hi,

I tested the AD (Samba4) domain log-in on Windows 7 clients and Linux
member servers with my PDC being offline (plugged the cable). It is not
working so well.

On Windows it initially takes forever. It works again after rebooting
the client, which seems to be the easiest solution (can be performed by
the user).

On Linux member servers, ssh log-in eventually times out. It works
again, after I manually swap the DNS server order in the
/etc/resolv.conf and the KDC provider order in the /etc/krb5.conf. But
manual intervention is clearly not preferred here.

According to the sanity checks for domain controllers and members
servers on the wiki setup and troubleshooting pages, my domain is
working at its best.

Is this due to DNS and kerberos timeouts accumulating? What is the best
way of dealing with this?

Best,
Ole



--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

[Rowland Penny]

On 11/11/15 15:20, Ole Traupe wrote:
> Hi,
>
> I tested the AD (Samba4) domain log-in on Windows 7 clients and Linux
> member servers with my PDC being offline (plugged the cable). It is
> not working so well.
>
> On Windows it initially takes forever. It works again after rebooting
> the client, which seems to be the easiest solution (can be performed
> by the user).
>
> On Linux member servers, ssh log-in eventually times out. It works
> again, after I manually swap the DNS server order in the
> /etc/resolv.conf and the KDC provider order in the /etc/krb5.conf. But
> manual intervention is clearly not preferred here.

What have you got in /etc/resolv.conf on your first DC (please don't
call it a PDC) , your second DC and a Unix client.

Your /etc/krb5.conf only needs to look like this:

libdefaults]
default_realm = SAMDOM.EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = true

DNS should find your DCs

Are you running ntp on all the Unix machines?

Rowland

[Ole Traupe]

Am 11.11.2015 um 17:05 schrieb Rowland Penny:
> On 11/11/15 15:20, Ole Traupe wrote:
>> Hi,
>>
>> I tested the AD (Samba4) domain log-in on Windows 7 clients and Linux
>> member servers with my PDC being offline (plugged the cable). It is
>> not working so well.
>>
>> On Windows it initially takes forever. It works again after rebooting
>> the client, which seems to be the easiest solution (can be performed
>> by the user).
>>
>> On Linux member servers, ssh log-in eventually times out. It works
>> again, after I manually swap the DNS server order in the
>> /etc/resolv.conf and the KDC provider order in the /etc/krb5.conf.
>> But manual intervention is clearly not preferred here.
>
> What have you got in /etc/resolv.conf on your first DC (please don't
> call it a PDC) , your second DC and a Unix client.

My resolv.conf files are "crossed":

# First_DC:
nameserver IP_OF_SECOND_DC
nameserver IP_OF_FIRST_DC
search my.domain.com

# Second_DC _AND_ member servers:
nameserver IP_OF_FIRST_DC
nameserver IP_OF_SECOND_DC
search my.domain.com

>
> Your /etc/krb5.conf only needs to look like this:
>
> libdefaults]
> default_realm = SAMDOM.EXAMPLE.COM
> dns_lookup_realm = false
> dns_lookup_kdc = true

It is, on the DCs. On the member server it is like this:

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = MY.DOMAIN.COM

dns_lookup_realm = false
dns_lookup_kdc = true

ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true

[realms]
MY.DOMAIN.COM = {
kdc = first_dc.my.domain.com
kdc = second_dc.my.domain.com
admin_server = first_dc.my.domain.com
default_domain = my.domain.com
}

[domain_realm]
my.domain.com = MY.DOMAIN.COM
.my.domain.com = MY.DOMAIN.COM

If the First_DC is online, it is working perfectly.

The above "swapping" of the config lines was meant for the member
server. Without swapping the lines in the resolv.conf I can ping the
Second_DC (if the First_DC is offline), but it takes 5+ seconds before I
get a response (DNS related)?. So I figured the issue might be a too
long timeout.

I am running ntp on all linux machines, and my time is in sync.

Thanks for your help, Rowland!

[Harry Jede]

On 11:06:29 wrote Ole Traupe:

> Hi,
>
> I tested the AD (Samba4) domain log-in on Windows 7 clients and Linux
> member servers with my PDC being offline (plugged the cable). It is
> not working so well.
>
> On Windows it initially takes forever. It works again after rebooting
> the client, which seems to be the easiest solution (can be performed
> by the user).
>
> On Linux member servers, ssh log-in eventually times out. It works
> again, after I manually swap the DNS server order in the
> /etc/resolv.conf and the KDC provider order in the /etc/krb5.conf.
> But manual intervention is clearly not preferred here.
>
> According to the sanity checks for domain controllers and members
> servers on the wiki setup and troubleshooting pages, my domain is
> working at its best.
>
> Is this due to DNS and kerberos timeouts accumulating?

It is DNS related.

> What is the best way of dealing with this?

The *best way* is a HA solution for your DNS Servers, but its expensive.

The DNS client (resolver) caches the srv records for 15 minutes aka 900
seconds.

ipconfig /flushdns drops the cache. Reboot does the same.

On server side you may set shorter TTL for the server records, but then
you have more DNS traffic. On small netwoks (sites up to 20 clients, no
wifi) I have good experience with a TTL of 180.

> Best,
> Ole


--

Gruss
Harry Jede

[Ole Traupe]

Am 12.11.2015 um 11:22 schrieb Harry Jede:
> On 11:06:29 wrote Ole Traupe:
>> Hi,
>>
>> I tested the AD (Samba4) domain log-in on Windows 7 clients and Linux
>> member servers with my PDC being offline (plugged the cable). It is
>> not working so well.
>>
>> On Windows it initially takes forever. It works again after rebooting
>> the client, which seems to be the easiest solution (can be performed
>> by the user).
>>
>> On Linux member servers, ssh log-in eventually times out. It works
>> again, after I manually swap the DNS server order in the
>> /etc/resolv.conf and the KDC provider order in the /etc/krb5.conf.
>> But manual intervention is clearly not preferred here.
>>
>> According to the sanity checks for domain controllers and members
>> servers on the wiki setup and troubleshooting pages, my domain is
>> working at its best.
>>
>> Is this due to DNS and kerberos timeouts accumulating?
> It is DNS related.
>
>> What is the best way of dealing with this?
> The *best way* is a HA solution for your DNS Servers, but its expensive.
>
> The DNS client (resolver) caches the srv records for 15 minutes aka 900
> seconds.
>
> ipconfig /flushdns drops the cache. Reboot does the same.

Will try this, thank you!

>
> On server side you may set shorter TTL for the server records, but then
> you have more DNS traffic. On small netwoks (sites up to 20 clients, no
> wifi) I have good experience with a TTL of 180.

Ok. So I do this on my Samba DCs (my domain DNS servers), and this will
affect Windows and Linux domain clients/member servers likewise?

[Harry Jede]

On 12:55:46 wrote Ole Traupe:

Theoretically yes. Assume you have a imap or web server installed on
your DC ( bad idea). I am pretty sure that some mail clients and
browsers have their own cache for ip adressess. So the a records may be
cached on application level. How do this caches works?

The soa record should only be used by the resolver libs.

The srv txt records are used by many apps. ie the netlogon process.
Netlogon picks randomly one dc, if more than one record exist for a
site. If this dc is down or unreachable, netlogon try this dc until ttl
times out and then try the next one. This is at least true for windows
xp, not for 2000. Should be true for all current windows versions.

--

Gruss
Harry Jede

[Ole Traupe]

>>> On server side you may set shorter TTL for the server records, but
>>> then you have more DNS traffic. On small netwoks (sites up to 20
>>> clients, no wifi) I have good experience with a TTL of 180.
>> Ok. So I do this on my Samba DCs (my domain DNS servers), and this
>> will affect Windows and Linux domain clients/member servers
>> likewise?
> Theoretically yes. Assume you have a imap or web server installed on
> your DC ( bad idea). I am pretty sure that some mail clients and
> browsers have their own cache for ip adressess. So the a records may be
> cached on application level. How do this caches works?
>
> The soa record should only be used by the resolver libs.
>
> The srv txt records are used by many apps. ie the netlogon process.
> Netlogon picks randomly one dc, if more than one record exist for a
> site. If this dc is down or unreachable, netlogon try this dc until ttl
> times out and then try the next one. This is at least true for windows
> xp, not for 2000. Should be true for all current windows versions.
>

Sorry that I ask again, I have little experience with DNS.

I have A records for all my DCs in "my.domain.com" and
"_msdcs.my.domain.com". I have SOA and NS records in both places, but
only for the First_DC (FSMO role holder). Is that ok?

Only SOA and NS records have TTL settings. Do I have to change both?
From your above comment I take that you would advise it. Otherwise,
trying to resolve a host wouldn't be diagnostic of the DNS request
during the logon process.

To whom it may concern: TTL seems to be set to 1h, by default, with Samba4.

[L.P.H. van Belle]

Ahi Ole,

An hany site.

http://blogs.msdn.com/b/servergeeks/archive/2014/07/12/dns-records-that-are-required-for-proper-functionality-of-active-directory.aspx

greetz,

Louis


> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-...@lists.samba.org] Namens Ole Traupe
> Verzonden: donderdag 12 november 2015 15:33
> Aan: sa...@lists.samba.org
> Onderwerp: Re: [Samba] Authentication to Secondary Domain Controller
> initially fails when PDC is offline

[Ole Traupe]

Thx!

[Ole Traupe]

Ok, according to the table behind that link the A records for the DCs in
"_msdcs.my.domain.com" are optional.

Am 12.11.2015 um 16:17 schrieb L.P.H. van Belle:

> Ahi Ole,
>
> An hany site.
>
> http://blogs.msdn.com/b/servergeeks/archive/2014/07/12/dns-records-that-are-required-for-proper-functionality-of-active-directory.aspx
>
> greetz,
>
> Louis
>
>

[Ole Traupe]

> It is DNS related.
>
>> What is the best way of dealing with this?
> The *best way* is a HA solution for your DNS Servers, but its expensive.
>
> The DNS client (resolver) caches the srv records for 15 minutes aka 900
> seconds.
>
> ipconfig /flushdns drops the cache. Reboot does the same.
>
> On server side you may set shorter TTL for the server records, but then
> you have more DNS traffic. On small netwoks (sites up to 20 clients, no
> wifi) I have good experience with a TTL of 180.

Harry, I tried this - unsuccessfully.

I have TTL settings in a) the SOA and b) the NS record of the FQDN and
the _msdcs.FQDN sections in my Windows RSAT DNS console. None of these 4
entries I can change: I get something like "The Source Of Authority
(SOA) cannot be updated. The record already exists."

Do you have an idea how to accomplish this? Currently the setting is 1h,
which is pretty long.

Ole

[mathias dufresne]

Hi Ole,

You want to change SOA of your AD domain?

Here some working command:
samba-tool dns update <working DC> samba.domain.tld \
samba.domain.tld SOA \
'oldSOA.samba.domain.tld. hostmaster.samba.domain.tld. 58 900 600 86400
3600' \
'newSOA.samba.domain.tld. hostmaster.saba.domain.tld. 59 900 600 86400
3600' -k yes

This needs you performed some kinit before using an account able to modify
this entry (by default only administrator is able to that I expect).

This must be done for the two DNS zones of your domain:
samba.domain.tld + _msdcs.samba.domain.tld

First number of replacement record (here "59") is serial number.
Replication of change seemed to work without changing that serial number
but as DNS love to rely on it, changing that serial should be a good idea.

Hoping this helps...

Cheers,

mathias

[Ole Traupe]

Mathias, thank you very much for your comprehensive instructions!

Just one question: Harry suggested that, in order to overcome the below
DNS related problems, the TTL would have to be adjusted (lowered).
However, the TTL seems to be the only time value not covered by the
command provided by you.

Is it really the TTL that is the culprit or is it rather the first time
value (something like "Refresh value" in english)?

Do you know this?

Ole

Am 19.11.2015 um 11:19 schrieb mathias dufresne:
> Hi Ole,
>
> You want to change SOA of your AD domain?
>
> Here some working command:
> samba-tool dns update <working DC> samba.domain.tld \
> samba.domain.tld SOA \
> 'oldSOA.samba.domain.tld. hostmaster.samba.domain.tld. 58 900 600
> 86400 3600' \
> 'newSOA.samba.domain.tld. hostmaster.saba.domain.tld. 59 900 600 86400
> 3600' -k yes
>
> This needs you performed some kinit before using an account able to
> modify this entry (by default only administrator is able to that I
> expect).
>
> This must be done for the two DNS zones of your domain:
> samba.domain.tld + _msdcs.samba.domain.tld
>
> First number of replacement record (here "59") is serial number.
> Replication of change seemed to work without changing that serial
> number but as DNS love to rely on it, changing that serial should be a
> good idea.
>
> Hoping this helps...
>
> Cheers,
>
> mathias
>
>
> 2015-11-18 16:44 GMT+01:00 Ole Traupe <ole.t...@tu-berlin.de

> <mailto:ole.t...@tu-berlin.de>>:

[mathias dufresne]

No idea about your main issue, I was merely answering to your last question
about changing SOA record.

Here is another view of that command:
samba-tool dns update <server> <zone> <name> SOA \
'OLDnameserver email serial refresh retry expire minimumttl' \
'NEWnameserver email serial refresh retry expire minimumttl'

I'm not too confident with DNS internals so I'm not sure if the TTL you
mentioned is or isn't "expire" or "minimumttl".

After digging a little bit it seems previous line is completely wrong,
neither "expire" nor "minimumttl" are "TTL".
This because :
dig -t SOA SAMBADOMAIN.TLD
...
samba.domain.tld. 1715 IN SOA DC1.samba.domain.tld. 62 900 600
86400 3600
...

And from what I just read in dig "ANSWER SECTION" the second field is the
TTL, so 1715 in my case, which as nothing to do with "expire" (86400) or
"minimumtll" (3600).

And that makes me wondering how TTL can be less than "minimumttl"...

So, the short way: the command I gave do not seem to be designed to help
you changing TTL. Sorry : )

Cheers,

mathias

[Ole Traupe]

Ok, I see. Nevertheless, thank you very much for your effort!

I must say that I can't actually believe that no one knows an answer to
this problem. It must affect MANY people using Samba DCs. According to
all the tests on the wiki, everything is working fine. Then I pull the
plug on my first DC and no one can log on. And this time I waited far
longer than the suggested "refresh interval" of 15 min - even longer
than the value called "TTL" in the GUI of 1h. I also tried "ipconfig
/flushdns" on my windows client. Does not improve the situation. Only a
reboot solves the issue. But that would be no acceptable practice for
Linux member servers. And it doesn't seem to help, anyway (just tried this).

It is one of the first and most important tests for a domain to see what
happens if the first DC is down. Without a working take-over, other DCs
are nothing more than backup (replication) targets, and the domain is
not fail-safe.

This can't be the end of the story, right?

Ole

> <mailto:ole.t...@tu-berlin.de>>:

>> <mailto:ole.t...@tu-berlin.de>>:

[mathias dufresne]

Here to avoid issue when some DC is down I rely on MS Windows client
behaviour. Windows clients are asking DNS for list of all DC (according to
their sites, relying on client IP to define on which AD site this client
is). Once the client has this list of all DC it launch some LDAP requests
(I believe) and will use as its own DC for that session one of the first
DCs which were able to reply the LDAP request.
If your client is not in default-site this chosen DC will stay in cache as
default DC during 24h if I'm not wrong. If your client is in default-site I
believe the cache is 15min, so after 15min it will relaunch the whole
discovery process.

At least, from that, sites are important : )

Now to be back on resilience question, *you must always have several DCs*
to be sure at any moment your client will always find at least one DC
available. Use VMs to lower cost, but still, build several DCs.

I have also added two DNS servers which forward all DNS queries to AD when
the requeset is about AD and if the request is not about AD zone, this
request is sent to normal DNS (those internal of the company I work for).
These two DNS share a virtual IP and I have an awful hand-writed-script to
move that VIP from on DNS to the other.

Why these two DNS?
I don't want to change clients configuration, they will continue to use
main DNS servers (those from the company I work for). These main DNS
servers will forward all requeset for AD zone to AD DNS servers (in fact to
my two little DNS servers and these little DNS servers will forward request
to AD DNS servers)
I don't want (and I won't be able) to change the list of DC up and running
on main DNS servers. And that list is bound to change, so I need a way to
change it.

This is a bit heavy and I'm not yet sure to keep on the long run. But for
now it seems to work...

Cheers,

mathias

[Mueller]

Within a real windows 2008 Domain it ist he same behaviour. Even there you need the clients to reboot.
This feature got lost after the beta status of samba 4. I had a test environment with the first betas and it worked there without any issue. Even mapping the shares by domain
worked: \\my.domain\share. Test this with the new versions, it will fail. (only netlogon will do).
Would be fine samba does it better. Samba 4 ist to close building windows AD server. It would be a great step it adds his own better features.

Greetings

Daniel


EDV Daniel Müller

Leitung EDV
Tropenklinik Paul-Lechler-Krankenhaus
Paul-Lechler-Str. 24
72076 Tübingen
Tel.: 07071/206-463, Fax: 07071/206-499
eMail: mue...@tropenklinik.de
Internet: www.tropenklinik.de




-----Ursprüngliche Nachricht-----
Von: Ole Traupe [mailto:ole.t...@tu-berlin.de]
Gesendet: Donnerstag, 19. November 2015 16:26
An: mathias dufresne <infra...@gmail.com>
Cc: samba <sa...@lists.samba.org>
Betreff: Re: [Samba] Authentication to Secondary Domain Controller initially fails when PDC is offline

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

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

Cheers,

mathias

[Ole Traupe]

Although I don't know what "dig" actually means, I was able to dig up
the following for my SOA:

my.domain.tld. 3600 IN SOA DC2.my.domain.tld.
hostmaster.my.domain.tld. 29 180 600 86400 180

This is after I reduced refresh interval and minimum TTL to 3 min (180
s). Still, the TTL of the SOA itself is 1h (3600 s).

This strongly suggests, that the TTL for DNS info *provided by* the SOA
is not necessarily related to the TTL of the SOA record *itself*.

Might that be? Could that be the reason why reducing minimum TTL doesn't
solve the login problem? How to change the TTL of the SOA record? Does
that even make sense?

Nevertheless, I want to re-state that waiting longer than the TTL of 1h
after pulling the (Ethernet) plug on my first DC didn't improve the
situation, either.

Ole


Am 19.11.2015 um 14:04 schrieb mathias dufresne:

> <mailto:ole.t...@tu-berlin.de>>:

>> <mailto:ole.t...@tu-berlin.de>>:

[mathias dufresne]

I would not perform test unplugging DC ethernet cables but rather
unplugging clients ethernet cables.

This because you seem to have already several DC 'at least 2 as one is
called DC2) so normally, if you don't have a too bad karma, both servers
should go down at same time.
But your client can become unavailable to reach your working DCs. A user
with a laptop can use his laptop outside of your LAN.
And what seems to me important is that user can use his laptop when it
can't discuss with DCs.

On your enterprise LAN the whole AD should not become unavailable: you
designed it for it is always available (several DC are meant for that
purpose) so that seems to me a non-relevant test case. But of course I
don't know your context and perhaps it is a valid test case for you ;)

[Ole Traupe]

Mathias, thanks for the hint, but I don't really care about that
scenario at the moment. We have local accounts on the machines for that
purpose. And it has nothing to do with domains being fail-safe. Clients
can have problems.

However, my homes and other shares are on a Samba4 file server. And
without authentication working properly, my users can't work. As simple
as that.

Ole

Am 20.11.2015 um 12:07 schrieb mathias dufresne:
> I would not perform test unplugging DC ethernet cables but rather
> unplugging clients ethernet cables.
>
> This because you seem to have already several DC 'at least 2 as one is
> called DC2) so normally, if you don't have a too bad karma, both
> servers should go down at same time.
> But your client can become unavailable to reach your working DCs. A
> user with a laptop can use his laptop outside of your LAN.
> And what seems to me important is that user can use his laptop when it
> can't discuss with DCs.
>
> On your enterprise LAN the whole AD should not become unavailable: you
> designed it for it is always available (several DC are meant for that
> purpose) so that seems to me a non-relevant test case. But of course I
> don't know your context and perhaps it is a valid test case for you ;)
>
> 2015-11-20 11:56 GMT+01:00 Ole Traupe <ole.t...@tu-berlin.de

> <mailto:ole.t...@tu-berlin.de>>:

>> <mailto:ole.t...@tu-berlin.de>>:

>>> <ole.t...@tu-berlin.de <mailto:ole.t...@tu-berlin.de>>:

[Rowland Penny]

On 20/11/15 11:07, mathias dufresne wrote:
> I would not perform test unplugging DC ethernet cables but rather
> unplugging clients ethernet cables.

That is a totally different problem there, if there are no DCs
available, can users still login?
'winbind offline logon = yes' will deal with this

Rowland

>
> This because you seem to have already several DC 'at least 2 as one is
> called DC2) so normally, if you don't have a too bad karma, both servers
> should go down at same time.
> But your client can become unavailable to reach your working DCs. A user
> with a laptop can use his laptop outside of your LAN.
> And what seems to me important is that user can use his laptop when it
> can't discuss with DCs.
>
> On your enterprise LAN the whole AD should not become unavailable: you
> designed it for it is always available (several DC are meant for that
> purpose) so that seems to me a non-relevant test case. But of course I
> don't know your context and perhaps it is a valid test case for you ;)
>
>

[Ole Traupe]

Thanks for the clarification, Daniel. And I like to think my users are
fast thinkers and might restart their machines eventually. But without
file and compute (Samba 4 member) servers being accessible, my
infrastructure virtually is down.

Again I ask: am I the only one having this problem? It must affect many
users of a basic Samba4 setup: two or more DCs, some Windows clients and
the eventual Linux member server - and the wish to be able to go on
holidays without worrying all the time that the

I followed Rowlands advice to have the "default realm" as the only line
in my krb5.conf. So kerberos related fails/timeouts can't be the issue
any more.

I followed another advice regarding the TTL for DNS info. I have found
no way to reduce the TTL of my SOA record, so far (if that is even
possible or helpful). So I just waited longer than the TTL of 1h, and it
didn't help for logons on my member servers.

There is one experimental hint from Rowland open to add one "NS" entry
for my second DC. But as my domain has already gone productive, I don't
feel so experimental right now.

Also there is the advice from mathias to put the clients in the
default-site, which might or might not reduce their cache hold time to
15 min (otherwise 24h) and might or might not help the issue on Win
clients. Again, this won't help on member servers, though.
Mathias, is this confirmed? Plus: Apparently, I have no "default-site"
in my DNS. I have something called
"Default-First-Site-Name._sites.my.domain.tld". Is that what you mean?

Also from Mathias, there is a - seemingly very profound - setup for
variable DNS servers (thank you for outlining this!), which is - I am
afraid - beyond my scope at the moment.

I don't want to seem unappreciative of your attempts to help. I just
can't believe that this important issue is not already taken care of.

Ole

[Ole Traupe]

Am 20.11.2015 um 13:08 schrieb Rowland Penny:
> On 20/11/15 11:07, mathias dufresne wrote:
>> I would not perform test unplugging DC ethernet cables but rather
>> unplugging clients ethernet cables.
>
> That is a totally different problem there, if there are no DCs
> available, can users still login?
> 'winbind offline logon = yes' will deal with this

Thanks for pointing this out, Rowland. I think, on Windows this is
possible, too. Sometimes, The Windows logon is successful during my test
scenario after waiting 1+ minutes. I was wondering whether this was an
offline logon. Seems reasonable to me.

>
> Rowland
>
>>
>> This because you seem to have already several DC 'at least 2 as one is
>> called DC2) so normally, if you don't have a too bad karma, both servers
>> should go down at same time.
>> But your client can become unavailable to reach your working DCs. A user
>> with a laptop can use his laptop outside of your LAN.
>> And what seems to me important is that user can use his laptop when it
>> can't discuss with DCs.
>>
>> On your enterprise LAN the whole AD should not become unavailable: you
>> designed it for it is always available (several DC are meant for that
>> purpose) so that seems to me a non-relevant test case. But of course I
>> don't know your context and perhaps it is a valid test case for you ;)

If I am not totally stupid, this is exactly, what I want to achieve. But
obviously, I can't authenticate against any other than the first DC.

[Ole Traupe]

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?

[Mueller]

The only way this would work out oft he box would be to ctdb (custer) samba4 dcs! So one dc is down the logged on users are transfered to the next without great delay. But status now this is not possible for dcs, only for member servers.

EDV Daniel Müller

Leitung EDV
Tropenklinik Paul-Lechler-Krankenhaus
Paul-Lechler-Str. 24
72076 Tübingen
Tel.: 07071/206-463, Fax: 07071/206-499
eMail: mue...@tropenklinik.de
Internet: www.tropenklinik.de




-----Ursprüngliche Nachricht-----
Von: Ole Traupe [mailto:ole.t...@tu-berlin.de]

Gesendet: Freitag, 20. November 2015 13:20
An: mue...@tropenklinik.de; 'mathias dufresne' <infra...@gmail.com>

[Rowland Penny]

On 20/11/15 13:22, Mueller wrote:
> The only way this would work out oft he box would be to ctdb (custer) samba4 dcs! So one dc is down the logged on users are transfered to the next without great delay. But status now this is not possible for dcs, only for member servers.
>
>
>
> EDV Daniel Müller
>
>

Ah, slight problem with that, you cannot use ctdb with a DC.

Rowland

[James]

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

[mathias dufresne]

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

[James]

On 11/20/2015 10:17 AM, mathias dufresne wrote:
>
>
> 2015-11-20 15:11 GMT+01:00 James <lingpa...@gmail.com

> <mailto:lingpa...@gmail.com>>:

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.







--
-James

[Allen Chen]

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,

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

[mathias dufresne]

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.

[mathias dufresne]

> As I was not confident at all neither regarding NS declaration in MS AD I
did installed 2 DCs running MS Windows 2008 R2 and then configured on them
one AD domain msad.domain.tld to check.

Both MS DCs are hosting the DNS 2 zones msad.domain.tld and
_msdcs.msad.domain.tld.
When joining the second DC dcpromo.exe complains it was not able to find
SOA for related zones.

Domain name:
msad.domain.tld

DC names / IP:
win2k8r2-01.msad.domain.tld / 10.1.1.211
win2k8r2-02.msad.domain.tld / 10.1.1.212

------------------------------------------------------------
A msad.domain.tld
------------------------------------------------------------
dig @10.1.1.212 -t A msad.domain.tld | egrep 'ANSWER |ADDITIONAL ' -A3
;; ANSWER SECTION:
msad.domain.tld. 600 IN A 10.1.1.211
msad.domain.tld. 600 IN A 10.1.1.212

dig @10.1.1.211 -t A msad.domain.tld | egrep 'ANSWER |ADDITIONAL ' -A3
;; ANSWER SECTION:
msad.domain.tld. 600 IN A 10.1.1.212
msad.domain.tld. 600 IN A 10.1.1.211
------------------------------------------------------------


------------------------------------------------------------
NS msad.domain.tld
------------------------------------------------------------
dig @10.1.1.211 -t NS msad.domain.tld | egrep 'ANSWER |ADDITIONAL ' -A3
;; ANSWER SECTION:
msad.domain.tld. 3600 IN NS win2k8r2-01.msad.domain.tld.
msad.domain.tld. 3600 IN NS win2k8r2-02.msad.domain.tld.

;; ADDITIONAL SECTION:
win2k8r2-01.msad.domain.tld. 3600 IN A 10.1.1.211
win2k8r2-02.msad.domain.tld. 3600 IN A 10.1.1.212

dig @10.1.1.212 -t NS msad.domain.tld | egrep 'ANSWER |ADDITIONAL ' -A3
;; ANSWER SECTION:
msad.domain.tld. 3600 IN NS win2k8r2-02.msad.domain.tld.
msad.domain.tld. 3600 IN NS win2k8r2-01.msad.domain.tld.

;; ADDITIONAL SECTION:
win2k8r2-02.msad.domain.tld. 3600 IN A 10.1.1.212
win2k8r2-01.msad.domain.tld. 3600 IN A 10.1.1.211
------------------------------------------------------------


------------------------------------------------------------
SAO msad.domain.tld
------------------------------------------------------------
dig @10.1.1.211 -t SOA msad.domain.tld | egrep 'ANSWER |ADDITIONAL ' -A3
;; ANSWER SECTION:
msad.domain.tld. 3600 IN SOA
win2k8r2-01.msad.domain.tld. hostmaster.msad.domain.tld. 38 900 600 86400
3600

;; ADDITIONAL SECTION:
win2k8r2-01.msad.domain.tld. 3600 IN A 10.1.1.211

dig @10.1.1.212 -t SOA msad.domain.tld | egrep 'ANSWER |ADDITIONAL ' -A3
;; ANSWER SECTION:
msad.domain.tld. 3600 IN SOA
win2k8r2-02.msad.domain.tld. hostmaster.msad.domain.tld. 38 900 600 86400
3600

;; ADDITIONAL SECTION:
win2k8r2-02.msad.domain.tld. 3600 IN A 10.1.1.212
------------------------------------------------------------

So SOA is the DC which replies. This suits the given definition as we can
modify DNS zones on each DC with DNS service running and each DC can
propagate modifications.

NS are all declared as they are authoritative name servers, this also suits
given definition: each DC can reply DNS request with certainty because of
replication.

This domain as no client, it was built only for testing that.

It seems there is some round-robin stuff on SN and A RR: running several
times same request on same DC change the answer for records A and NS:
dig @10.1.1.211 -t A msad.domain.tld | egrep 'ANSWER |ADDITIONAL ' -A3
;; ANSWER SECTION:
msad.domain.tld. 600 IN A 10.1.1.211
msad.domain.tld. 600 IN A 10.1.1.212

dig @10.1.1.211 -t A msad.domain.tld | egrep 'ANSWER |ADDITIONAL ' -A3
;; ANSWER SECTION:
msad.domain.tld. 600 IN A 10.1.1.212
msad.domain.tld. 600 IN A 10.1.1.211


Once more: I'm not an expert. I'm just sending here my thoughts, trying to
understand.

Best regards all and have a nice weekend,

mathias

[Ole Traupe]

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

And this would speed up the whole process? Is this a guess or your
experience?

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

I am sorry about the confusion. I demoted my DC1 a while ago due to
hardware problems. I mean to replace it, because currently my First_DC
(FSMO role holder and SOA) is a virtual machine on a storage server
which isn't ideal for many reasons.

Currently I have DC2 (First_DC) and DC3 (Second_DC). Had I paid
attention to this, I would have changed the names in the text and output
snippets I posted.

Again: I apologize.

[Ole Traupe]

Thanks for pointing this out, Daniel.

Only, I still don't know what exactly is the problem:

a) my clients go on asking the same (wrong) DNS server (offline First_DC)
b) my clients keep on getting the same answer: "your logon server is DC
X" (offline First_DC)

Which one is it?

Ole

[Ole Traupe]

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

Mathias, thank you, I will try this. This is very similar to what
Rowland suggested. Sorry for not testing this earlier, there were other
things I had to attend to.

What I ask myself: this is the content of my /etc/resolv.conf (without
">", of course)

> search my.domain.tld
> nameserver __IP_of_First_DC__
> nameserver __IP_of_Second_DC__

This doesn't do the trick? Or will the client ask the NS, who the NS for
the AD domain is?

[Ole Traupe]

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

You mean Samba DCs or DCs in general?

I am not sure I understand the above. Do you suggest to create another
NS record for the Second_DC, or not to?

In the resolv.conf on my member servers both DCs are listed as DNS
servers. I like to think that the member servers eventually ask the
second DNS server, if the first won't respond. This seems to be
reflected by ping taking more than 5 s for the first packet to arrive.

BUT what does the second DNS server (Second_DC) reply? Which logon
server does it announce?

[James]

Your host file is queried first before your dns server. I say usually
because you can change this behavior. This would speed up the process of
resolving your DNS servers IP to a hostname.

So is your DC2 now the SOA? Did you create the SOA RR for DC2?

--
-James

[James]

On 11/26/2015 11:12 AM, Ole Traupe wrote:
>
>>> 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.
>

> You mean Samba DCs or DCs in general?
>
> I am not sure I understand the above. Do you suggest to create another
> NS record for the Second_DC, or not to?
>
> In the resolv.conf on my member servers both DCs are listed as DNS
> servers. I like to think that the member servers eventually ask the
> second DNS server, if the first won't respond. This seems to be
> reflected by ping taking more than 5 s for the first packet to arrive.
>
> BUT what does the second DNS server (Second_DC) reply? Which logon
> server does it announce?
>
>

DNS can be very confusing. You do not need to create a NS record for
your second DC if the zone is directory integrated. By default the DC is
authoritative for that zone.

[Rowland Penny]

Probably with windows it is, but not with Samba AD, you only get one NS
and one SOA. The only authoritative Samba AD DC is the first one, when
you join a second DC, it runs the same code that created the SOA during
the first DCs provision and because the SOA already exists, it fails.

Rowland

[Rowland Penny]

What SOA RR for DC2?

You can only have one SOA record.

Rowland

[James]

I meant did he update the SOA record to reflect that DC2 is now SOA.

--
-James

[James]

Yikes! Are you saying DC's with directory integrated zones are not
authoritative for them? That means a NS record needs to be created
manually for each DC added.

--
-James

[mathias dufresne]

I would verify the 2 DC are declared on every client as DNS servers. To
avoid the need to declare all DCs on all clients you can add one (or more)
pure DNS server which will receive all requests and forward those for AD to
AD DC. When having lot of DC this second way could be finally easier.

This DNS must have a forward zone similar as that:
------------------------------------
zone "ad.domain.tld" IN {
type forward;
forward only;
forwarders {
10.1.0.1;
10.1.0.2;
10.2.8.1;
10.2.8.2;
};
};
--------------------------------

All mentioned IP address are DC.

Then as OP as two separated networks with one DC per network (let's call
them "main site" and "remote site") I would create 2 site using DSSITE.msc
in addition of "Default-First-Site-Name" as follow:
"Default-First-Site-Name" containing DC1 + DC1, no network associated.
"Main-site" containing DC1, associated to main site networks (for example
10.1.0.0/16, to suit previous example)
"Remote-site" containing DC2, associated to all networks related to this
remote site (for example 10.2.8.0/24)

This because I think a Windows client tries first to find a DC on one
AD-site matching its IP (ie if client has IP 10.1.2.3 this client will
belong to "Main-site" and will try to find a DC belonging to "Main-site").
And if a client does not find any DC available on its AD-site, this client
will look for a DC in Default-First-Site-Name, that's why in that site all
DC should be declared.

Of course each client must be able to resolve AD DNS zones from any (or at
least, several) DC as DCs are meant to serve all clients in case of
fail-over.

Cheers,

mathias

[Rowland Penny]

Yes, that's about the size of it. no matter how many DCs you join, you
only have one NS, the original DC.

I have been trying to alter the code, but I am struggling to get another
NS record added during the join, it doesn't help that I have no idea
what a windows DC SOA record looks like, does each DC have a separate
SOA record? or is it like the Samba SOA record and there is only one
with multiple NS records?

Rowland

[James]

Each DC should contain only one SOA. This by default is the DC that
originally created it. Samba currently does it correctly by creating
just the one during provision.

This is what a Windows SOA should look like.

@ IN SOA nameserver.example.microsoft.com. postmaster.example.microsoft.com. (
1 ; serial number
3600 ; refresh [1h]
600 ; retry [10m]
86400 ; expire [1d]
3600 ) ; min TTL [1h]




--
-James

[mathias dufresne]

Yes each Windows has SOA record. In fact I expect there is no SOA record
really on MS AD. I expect SOA management is something like when a DC
receive request for SOA it replies "I am SOA".
On MS AD all DC have a NS record. My second mail about that thread from
Sunday the 22nd of November is showing different DNS queries I did on MS AD
domain (a 2008 r2 domain with only 2 DC, Microsoft DC).

Finally I would look into samba_dnsupdate to add creation of NS record. I
expect this tool is run when samba starts.
Unfortunately I did not find the right option to add to samba_dnsupdate for
it really creates DNS entries. Even with kerberos ticket already created
before running that command. I received a mail recently about another Samba
user using internal DNS for his AD hosted by Samba. This person was facing
same issue has me (missing DNS entries, samba_dnsupdate not adding
entries). To workaround that issue he modified samba_dnsupdate and he
commented that line (line 413):
os.unlink(tmpfile)

Doing that samba_dnsupdate does not remove tmp file. This tmp file contains
nsupdate commands which are launched by samba_dnsupdate.
Finally he uses these nsupdate commands from tmp files without -g option
and he's DNS entries are now created.
I must say I did yet try that process.

[mathias dufresne]

Something important I forget in my last mail is the person I mentioned has
configured is samba with "allow dns updates = nonsecure" for nsupdate works.

[Rowland Penny]

On 27/11/15 15:24, mathias dufresne wrote:
>
>
> 2015-11-27 15:49 GMT+01:00 Rowland Penny <rowlandpe...@gmail.com

> <mailto:rowlandpe...@gmail.com>>:

If you follow the 'join' code, you end up at 'add_at_record' in
sambadns.py. This is run by the initial provision and again when any DCs
are joined. I have tried adding a check to see if the SOA exists and
only creating it if it doesn't, otherwise just add the NS records etc, I
can add the A record for the subsequent DC bit not its NS record. This
is what the initial SOA record looks like:

dn:
DC=@,DC=samdom.example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=samdom,DC=example,DC=com
objectClass: top
objectClass: dnsNode
instanceType: 4
whenCreated: 20151106115624.0Z
uSNCreated: 3657
showInAdvancedViewOnly: TRUE
name: @
objectGUID: 7ad014c4-c1e9-4cb4-9f0d-96d0272af23d
objectCategory:
CN=Dns-Node,CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com
dc: @
whenChanged: 20151122115408.0Z
dnsRecord: NDR: struct dnsp_DnssrvRpcRecord
wDataLength : 0x004f (79)
wType : DNS_TYPE_SOA (6)
version : 0x05 (5)
rank : DNS_RANK_ZONE (240)
flags : 0x0000 (0)
dwSerial : 0x00000062 (98)
dwTtlSeconds : 0x00000e10 (3600)
dwReserved : 0x00000000 (0)
dwTimeStamp : 0x00377e73 (3636851)
data : union dnsRecordData(case 6)
soa: struct dnsp_soa
serial : 0x00000063 (99)
refresh : 0x00000384 (900)
retry : 0x00000258 (600)
expire : 0x00015180 (86400)
minimum : 0x00000e10 (3600)
mname : dc1.samdom.example.com
rname : hostmaster.samdom.example.com

dnsRecord: NDR: struct dnsp_DnssrvRpcRecord
wDataLength : 0x001a (26)
wType : DNS_TYPE_NS (2)
version : 0x05 (5)
rank : DNS_RANK_ZONE (240)
flags : 0x0000 (0)
dwSerial : 0x00000062 (98)
dwTtlSeconds : 0x00000384 (900)
dwReserved : 0x00000000 (0)
dwTimeStamp : 0x00000000 (0)
data : union dnsRecordData(case 2)
ns : dc1.samdom.example.com

dnsRecord: NDR: struct dnsp_DnssrvRpcRecord
wDataLength : 0x0004 (4)
wType : DNS_TYPE_A (1)
version : 0x05 (5)
rank : DNS_RANK_ZONE (240)
flags : 0x0000 (0)
dwSerial : 0x00000062 (98)
dwTtlSeconds : 0x00000384 (900)
dwReserved : 0x00000000 (0)
dwTimeStamp : 0x00000000 (0)
data : union dnsRecordData(case 1)
ipv4 : 192.168.0.5

uSNChanged: 29974
distinguishedName:
DC=@,DC=samdom.example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=samdom,DC=example,DC=com


I can add the NS record for the second DC with samba-tool, but not by
modifying the 'add_at_record' code.

I tried doing an internet search, but cannot find anything that shows
the SOA objects in AD for a windows server, so I don't know if windows
uses separate SOA object records for each DC, or is it just one SOA
object record (like Samba uses) with an NS record added for each DC.

Rowland

[Rowland Penny]

On 27/11/15 15:38, mathias dufresne wrote:
> Something important I forget in my last mail is the person I mentioned has
> configured is samba with "allow dns updates = nonsecure" for nsupdate works.
>
>
>

You don't need to do this if Samba etc is set up correctly, I use Bind9
and DHCP (Now with failover!) and do not have that line in smb.conf.

Rowland

[James]

Rowland,

This is what I have been able to dig up but nothing concrete.

https://www.petri.com/forums/forum/microsoft-networking-services/active-directory/18697-ad-zones-and-dns-soa-records

and

http://www.dell.com/support/article/us/en/19/SLN156678/en

Both state that each DC should have it's own SOA if it's directory
integrated. However looking here

http://blogs.msmvps.com/acefekay/2013/04/30/dns-zone-types-explained-and-their-significance-in-active-directory/

says that the SOA should rotate.














--
-James

[Rowland Penny]

Hi, thanks for that, but I am fairly sure I have already seen them, or
others just like them, the problem is that windows is a point & click OS
and that is all I have been able to find. I cannot find anywhere an
example of what a SOA record looks like in a windows AD database. All I
can find says that every DC should have a SOA record, now does this mean
one like Samba's, where it is just one AD object with multiple NS
records (one per DC), or should there actually be an individual SOA
record per DC, if so, then Samba's DNS server is very possibly broken.

Does anybody have an ldif from a windows AD domain showing the SOA
records and are they willing to share it??

Rowland

[James]

Rowland,

This document
https://technet.microsoft.com/en-us/library/dd197552%28v=ws.10%29.aspx
states the following.

"The authoritative DNS server for the zone containing the client FQDN
responds to the SOA-type query.

For standard primary zones, the primary server (owner) returned in the
SOA query response is fixed and static. It always matches the exact DNS
name as it appears in the SOA RR stored with the zone. If, however, the
zone being updated is directory-integrated, any DNS server that is
running on a domain controller for the Active Directory domain in the
FQDN can respond and *dynamically insert its own name as the primary
server (owner) of the zone in the SOA query response*."*

*I found this link
http://rakhesh.com/windows/soa-records-and-dynamic-dns-in-windows/ where
this users example seems to corroborate this. All my nslookups report
only one primary name server. It appears my Zone is behaving as a
primary and not a directory-intergrated.







--
-James

[mathias dufresne]

> Rowland,

I'll have a look on both MS DC I prepared 10 days ago to see if there is a
LDAP for SOA in MS AD database.
As shown 10 days ago MS DC always reply "I am SOA" when they have DNS
service started which is not mandatory if you have already a DNS
infrastructure (from DCs or any other DNS).

[Rowland Penny]

This would help with what I am trying to find out.

I can find on the internet multiple instances of 'every DC running dns
should have a SOA record', but I cannot find any concrete examples of an
ldif that shows this. Does each DC have a separate SOA record in AD, or
is there just one SOA record and the DC just claims to be the SOA, or is
there just one SOA record with an NS record for each DC. Samba would
seem to be the later, but I am struggling with adding the NS record for
a new DC during the join, I think what happens is that the NS record
does get added, but is wiped out when replication kicks in. It is very
easy to add the NS record after the join with samba-tool.

Rowland

[mj]

> I can find on the internet multiple instances of 'every DC running dns
> should have a SOA record', but I cannot find any concrete examples of an
> ldif that shows this. Does each DC have a separate SOA record in AD, or
> is there just one SOA record and the DC just claims to be the SOA, or is
> there just one SOA record with an NS record for each DC. Samba would
> seem to be the later, but I am struggling with adding the NS record for
> a new DC during the join, I think what happens is that the NS record
> does get added, but is wiped out when replication kicks in. It is very
> easy to add the NS record after the join with samba-tool.
>
> Rowland
>

Hi,

I remember vaguely that someone once told me that MS DCs always announce
themselves as the soa if asked. If they always reply that, perhaps there
is no need for it to actually be in the database (so it would perhaps
not show up in an ldif)

MJ

[Rowland Penny]

On 02/12/15 10:31, mj wrote:
>> I can find on the internet multiple instances of 'every DC running dns
>> should have a SOA record', but I cannot find any concrete examples of an
>> ldif that shows this. Does each DC have a separate SOA record in AD, or
>> is there just one SOA record and the DC just claims to be the SOA, or is
>> there just one SOA record with an NS record for each DC. Samba would
>> seem to be the later, but I am struggling with adding the NS record for
>> a new DC during the join, I think what happens is that the NS record
>> does get added, but is wiped out when replication kicks in. It is very
>> easy to add the NS record after the join with samba-tool.
>>
>> Rowland
>>
> Hi,
>
> I remember vaguely that someone once told me that MS DCs always
> announce themselves as the soa if asked. If they always reply that,
> perhaps there is no need for it to actually be in the database (so it
> would perhaps not show up in an ldif)
>
> MJ
>

This is what I think happens and if this is the case, then samba itself
will have to do this, but I have added an NS record for the 2nd DC to
the SOA record with samba-tool and if I use nslookup I get this:

nslookup
> set querytype=soa
> samdom.example.com
Server: 192.168.0.5
Address: 192.168.0.5#53

samdom.example.com
origin = dc1.samdom.example.com
mail addr = hostmaster.samdom.example.com
serial = 101
refresh = 900
retry = 600
expire = 86400
minimum = 3600

If I then exit from nslookup and swap the nameservers in
/etc/resolv.conf and rerun nslookup, I get this:

nslookup
> set querytype=soa
> samdom.example.com
Server: 192.168.0.6
Address: 192.168.0.6#53

samdom.example.com
origin = dc2.samdom.example.com
mail addr = hostmaster.samdom.example.com
serial = 101
refresh = 900
retry = 600
expire = 86400
minimum = 3600

Which, to me, says that both DCs are authoritative for the domain, if
this is correct, I just need to find a way of adding the NS record
during the join.

Rowland

[mathias dufresne]

That seems really simpler to merely reply "I am SOA" than having one entry
in LDAP for each DC running DNS. Just for replilcation it would generate
mess.
In MS AD world you can disable DNS after you built your AD, in that case
there is one NS record per zone to remove, I don't know if MS DC do that
but that's sound already complex enough to not have added removing of SOA
LDAP entry on each DC in addition to this NS removal...

For all that I expect there is no SOA record in MS AD LDAP tree.

I'll try to remember to test removing DNS service from one MS DC, to check
is NS records are modified...

[mathias dufresne]

Rowland,

What did you request as DNS? Samba + Bind + DLZ ?
If yes, the fact your two DNS are replying "I am SOA" is a feature from
Bind9 or from DLZ patch.

That's important as a standard Samba AD designed without Bind is using LDAP
defined entry for SOA. Asking to the five Samba DC I have here who's SOA,
they all replied the same server, the one declared in SOA LDAP entry.
Of course all DC are declared as NS in that zone.

That behavior is the same for SAMBA.DOMAIN.TLD zone and for
_msdcs.SAMBA.DOAMIN.TLD zone.

And where is SOA is important as samba_dnsupdate is using, sometimes, that
SOA to guess where to push changes. I'm absolutely sure of that because I
started to interest myself in SOA after samba_dnsupdate complains about my
SOA which was not pointing to the right server.

[Rowland Penny]

On 02/12/15 11:59, mathias dufresne wrote:
> Rowland,
>
> What did you request as DNS? Samba + Bind + DLZ ?
> If yes, the fact your two DNS are replying "I am SOA" is a feature from
> Bind9 or from DLZ patch.

Yes, I use bind9 with the dlz backend.

>
> That's important as a standard Samba AD designed without Bind is using LDAP
> defined entry for SOA. Asking to the five Samba DC I have here who's SOA,
> they all replied the same server, the one declared in SOA LDAP entry.
> Of course all DC are declared as NS in that zone.

Not sure if this is a bind9 feature, does your SOA record have the NS
records for all the DCs, if not, then the first DC will be the only
Authoritative server.

[mathias dufresne]

2015-12-02 13:24 GMT+01:00 Rowland Penny <rowlandpe...@gmail.com>:

> On 02/12/15 11:59, mathias dufresne wrote:
>
>> Rowland,
>>
>> What did you request as DNS? Samba + Bind + DLZ ?
>> If yes, the fact your two DNS are replying "I am SOA" is a feature from
>> Bind9 or from DLZ patch.
>>
>
> Yes, I use bind9 with the dlz backend.
>
>
>> That's important as a standard Samba AD designed without Bind is using
>> LDAP
>> defined entry for SOA. Asking to the five Samba DC I have here who's SOA,
>> they all replied the same server, the one declared in SOA LDAP entry.
>> Of course all DC are declared as NS in that zone.
>>
>
> Not sure if this is a bind9 feature, does your SOA record have the NS
> records for all the DCs, if not, then the first DC will be the only
> Authoritative server.

For me, I can be wrong, SOA is referencing one and only one DNS server. You
can haev several NS and only one SOA. That's why I said several that I
think MS DC reply "I am SOA" and I don't wrote that I think MS DCreply "I
am one SOA".

In Samba AD there is a LDAP entry for SOA record. This entry references
only one server. I have several NS declared, one per DC as all my DC (Samba
standard DC, no bind-dlz) are hosting the two DNS zones.

Now about if the fact your Bind DNS servers are behaving like MS DNS, as my
Samba DNS are not behaving like MS DNS, I expect this behavior change comes
from the fact we are not using the same DNS servers.
As when DNS request are sent from clients to DNS servers Samba is not
involved (your client ask directly to your Bind9-dlz servers) I think the
difference in our DNS SOA replies comes from the fact our DNS softwares are
different.

This can be easily tested from your side: you have a Bind9-dlz
infrastructure, use it to create a new fake zone, build that zone
identically as the one used by Samba, perhaps just renaming your AD zone,
then you will be able to ask your own Bind9-dlz DNS server about SOA for
that new zone. Then you'll see if your Bind reply "I am SOA" or if they
reply "this one is SOA".

[Ole Traupe]

>> What SOA RR for DC2?
>>
>> You can only have one SOA record.
>>
>> Rowland
>>
>>
> I meant did he update the SOA record to reflect that DC2 is now SOA.
>

Sorry that I wasn't responding for so long. As I stated earlier (sorry
for the confusion), I demoted DC1 a while ago. So DC2 is now SOA and
that is reflected by my DNS. Lets talk about first/second DC isntead.

Ole

[Ole Traupe]

> Hi, If you can bear with me, I am trying to get the join to add the NS
> for the joining DC to the SOA, I believe I may be near to get this
> working (after leading myself down the garden path, what I tried
> previously, didn't work), once it does, I should be able answer your
> question, my test domain is using the internal dns.
>
> Rowland


I am happy to hear that and hope that solves the problem! I have tested
fail-over now with the new NS record, but the situation is more or less
the same:

- created the NS record and waited until I found the record to be replicated
- restarted the windows machine I wanted to test this on
- suspended the 1st DC (currently a VM)
- tried to log-on to the windows test machine
- results:

1. first log-on for a user takes ~30 seconds (on a second test it was up
to 60 s)
2. following second log-on takes only 5 s
3. third log-on takes 2-3 s

Confirmed this with a second user, the same time-out pattern. Seems to
me that Windows 7 keeps its default DC but is willing to make exceptions
on a user basis?

However, I cannot say whether this actually is a server authentication
or an offline log-on. I looked into the Windows logs ("Security") but
didn't find anything conclusive.


Two other things to mention:

- From Windows, I can access my home and other network shares (located
on a Samba 4 member server) as usual with out any problem (which is good!!)

- But when I try to ssh to a member server, it still takes forever, and
a 'kinit' on a member server gives this:
"kinit: Cannot contact any KDC for realm 'MY.DOMAIN.TLD' while
getting initial credentials"


My /etc/krb5.conf looks like this (following your suggestions, Rowland,
as everything else are defaults):

[libdefaults]
default_realm = MY.DOMAIN.TLD

And my /etc/resolv.conf is this:

search my.domain.tld
nameserver IP_of_1st_DC
nameserver IP_of_2nd_DC


So from a Windows client point of view, I am more or less fine (even
without restarting the machines). But it would be great if I could
log-in to the Linux member servers as well.

[Rowland penny]

I am getting nearer, I can now add another NS record to the SOA whilst
joining a DC, it's the wrong record, but it was added :-D

Now to get it to add the correct NS record (after I figure out just
where I went wrong).

Rowland

[Rowland penny]

OK, I have now created the correct SOA NS record whilst joining a new DC
using the internal DNS server. If I run nslookup against each test DC, I
get back the same nameserver. If I do the same on my normal domain that
uses Bind9, I get a different nameserver from each DC.

TESTDOMAIN:

root@testdc2:~# nslookup
> set querytype=soa
> example.lan
Server: 192.168.0.240
Address: 192.168.0.240#53

example.lan
origin = testdc1.example.lan
mail addr = hostmaster.example.lan
serial = 3

refresh = 900
retry = 600
expire = 86400
minimum = 3600

Swap nameservers in resolv.conf

root@testdc2:~# nslookup
> set querytype=soa
> example.lan
Server: 192.168.0.241
Address: 192.168.0.241#53

example.lan
origin = testdc1.example.lan
mail addr = hostmaster.example.lan
serial = 3

refresh = 900
retry = 600
expire = 86400
minimum = 3600

NORMAL DOMAIN:

root@dc1:~# nslookup

> set querytype=soa
> samdom.example.com
Server: 192.168.0.6
Address: 192.168.0.6#53

samdom.example.com
origin = dc2.samdom.example.com
mail addr = hostmaster.samdom.example.com
serial = 101
refresh = 900
retry = 600
expire = 86400
minimum = 3600

swap nameservers in resolv.conf

root@dc1:~# nslookup

> set querytype=soa
> samdom.example.com
Server: 192.168.0.5
Address: 192.168.0.5#53

samdom.example.com
origin = dc1.samdom.example.com
mail addr = hostmaster.samdom.example.com
serial = 101
refresh = 900
retry = 600
expire = 86400
minimum = 3600

Sorry Kia, but I think the moral of the story here is, don't use the
internal dns server, use bind9 instead.

[mathias dufresne]

To check which DC was used to connect on simply type "set" in MSDOS console
(cmd). Then look for a line which contain a DC name.

For Windows they should try to find a DC at logon time, according to their
IP address and AD sites configuration as explained earlier I think. This
process includes DNS SRV request to find LDAP server list and then LDAP
requests are sent to received SRV to find one working server, something
like one replying the quicker (that's a foggy notion for me :)

For Linux and kinit that should be based on DNS resolution and caching if
some. Now how kinit chose a Kerberos server from DNS I no real idea.
It is possible to force usage of one particular kerberos server forcing it
in some configuration file and then using that file in $KRB5_CONFIG
environment variable. At least you could use that to test if kinit works
when forced on the remaining server.

But that does not answer the question of failover for Linux parts :(

[Ole Traupe]

> - But when I try to ssh to a member server, it still takes forever,
> and a 'kinit' on a member server gives this:
> "kinit: Cannot contact any KDC for realm 'MY.DOMAIN.TLD' while
> getting initial credentials"
>
>
> My /etc/krb5.conf looks like this (following your suggestions,
> Rowland, as everything else are defaults):
>
> [libdefaults]
> default_realm = MY.DOMAIN.TLD
>
> And my /etc/resolv.conf is this:
>
> search my.domain.tld
> nameserver IP_of_1st_DC
> nameserver IP_of_2nd_DC

Any idea why I still get this when trying to log on to a member server
while the first DC is down?

# kinit: Cannot contact any KDC for realm 'MY.DOMAIN.TLD' while getting
initial credentials

[L.P.H. van Belle]

Hai Ole,

Can you run on the member where you logged in.

host -t SRV _ldap._tcp.samdom.example.com.
host -t SRV _kerberos._udp.samdom.example.com.

host -t A dc1.samdom.example.com.
host -t A dc2.samdom.example.com.

and again with
search my.domain.tld
nameserver IP_of_2st_DC
nameserver IP_of_1nd_DC

looks ok to me sofare.

Greetz,

Louis


> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-...@lists.samba.org] Namens Ole Traupe
> Verzonden: woensdag 9 december 2015 17:33
> Aan: sa...@lists.samba.org
> Onderwerp: Re: [Samba] Authentication to Secondary Domain Controller
> initially fails when PDC is offline

[James]

On 12/9/2015 11:33 AM, Ole Traupe wrote:
>
>> - But when I try to ssh to a member server, it still takes forever,
>> and a 'kinit' on a member server gives this:
>> "kinit: Cannot contact any KDC for realm 'MY.DOMAIN.TLD' while
>> getting initial credentials"
>>
>>
>> My /etc/krb5.conf looks like this (following your suggestions,
>> Rowland, as everything else are defaults):
>>
>> [libdefaults]
>> default_realm = MY.DOMAIN.TLD
>>
>> And my /etc/resolv.conf is this:
>>
>> search my.domain.tld
>> nameserver IP_of_1st_DC
>> nameserver IP_of_2nd_DC
>
> Any idea why I still get this when trying to log on to a member server
> while the first DC is down?
>
> # kinit: Cannot contact any KDC for realm 'MY.DOMAIN.TLD' while
> getting initial credentials
>
> Ole
>
>
>

Ole,

Can you try a few things? All on your member server. What is the
output of

testparm | grep "name resolve order"

kdestroy -A

kinit admini...@MY.DOMAIN.TLD -V

--
-James

[James]

On 12/9/2015 11:33 AM, Ole Traupe wrote:
>

>> - But when I try to ssh to a member server, it still takes forever,
>> and a 'kinit' on a member server gives this:
>> "kinit: Cannot contact any KDC for realm 'MY.DOMAIN.TLD' while
>> getting initial credentials"
>>
>>
>> My /etc/krb5.conf looks like this (following your suggestions,
>> Rowland, as everything else are defaults):
>>
>> [libdefaults]
>> default_realm = MY.DOMAIN.TLD
>>
>> And my /etc/resolv.conf is this:
>>
>> search my.domain.tld
>> nameserver IP_of_1st_DC
>> nameserver IP_of_2nd_DC
>
> Any idea why I still get this when trying to log on to a member server
> while the first DC is down?
>
> # kinit: Cannot contact any KDC for realm 'MY.DOMAIN.TLD' while
> getting initial credentials
>
> Ole
>
>
>

Ole,

I was trying to look back through your posts so excuse me if you
have answered this. What was your original krb.conf file contents? A few
things that may work is to specify the kdc and not rely on dns. for
instance.

[libdefaults]
default_realm = MY.DOMAIN.TLD
dns_lookup_kdc = false
dns_lookup_realm = false

[realms]
MY.DOMAIN.TLD = {
kdc = IP of First DC
kdc = IP of Second DC
}

--
-James

[Rowland penny]

If you have to do that, then there is something wrong with your dns and
you need to fix this, dns is an important part of AD and really needs to
work correctly.

I have been doing some testing with dns and with the internal dns
server, even if you add another NS to the SOA record, you only have one
NS. It seems the only way to get each DC to think it is a NS, is to use
bind9.

Rowland

[James]

Rowland,

I can understand that to be true. However it could apply in
situations where DNS traffic would like to be kept to a minimum. At
least that was my mind set when I researched using this config.





--
-James

[L.P.H. van Belle]

> I have been doing some testing with dns and with the internal dns
> server, even if you add another NS to the SOA record, you only have one
> NS. It seems the only way to get each DC to think it is a NS, is to use
> bind9.
>

Hai

A good to know, some versions of samba, i dont know which do have this problem also if u use bind9_dlz.

So, my question to the readers, if you use samba4 DC with bind9_DLZ and you have 2 or more DC's, check all you zones of you have also the same number of NS servers.

I know from my install, i had only 1 DC as NS record, i manualy added the second the zones.

Greetz,

Louis

[Rowland penny]

On 10/12/15 07:32, L.P.H. van Belle wrote:
>> I have been doing some testing with dns and with the internal dns
>> server, even if you add another NS to the SOA record, you only have one
>> NS. It seems the only way to get each DC to think it is a NS, is to use
>> bind9.
>>
> Hai
>
> A good to know, some versions of samba, i dont know which do have this problem also if u use bind9_dlz.
>
> So, my question to the readers, if you use samba4 DC with bind9_DLZ and you have 2 or more DC's, check all you zones of you have also the same number of NS servers.
>
> I know from my install, i had only 1 DC as NS record, i manualy added the second the zones.
>
> Greetz,
>
> Louis
>
>
>
>

You will only have 1 DC as NS, nothing adds the second (or any other
subsequent DCs) NS record to the SOA records.

Rowland

[L.P.H. van Belle]

I was wondering why because in a full windows domain, every DC has an NS record.

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-...@lists.samba.org] Namens Rowland penny
> Verzonden: donderdag 10 december 2015 10:10

> Aan: sa...@lists.samba.org
> Onderwerp: Re: [Samba] Authentication to Secondary Domain Controller
> initially fails when PDC is offline
>

[Rowland penny]

On 10/12/15 09:23, L.P.H. van Belle wrote:
> I was wondering why because in a full windows domain, every DC has an NS record.
>
>

When you join a DC, the basic info is added to AD and then when the
samba deamon is started, samba_dnsupdate is run, this uses the file
dns_update_list to add (if required) various dns records. Guess what dns
records are not in that file?

However, even if you add the missing NS records to the SOA records, if
you use the internal dns server, you will still only have one NS, this
appears to be your first DC. I am beginning to think that if you have
more than one DC, you should forget the internal DNS server and use
BIND_DLZ instead.

[L.P.H. van Belle]

Hai,

Ah, ok, wel, yeah, i was missing the NS on the SOA.

This is imo a bug, i dont know it this is by design for samba,
so maybe a samba dev can answere this since every joined DC should have a NS record on the SOA as far as i know, but thats my opinion and i can be wrong here.


Greetz,

Louis

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-...@lists.samba.org] Namens Rowland penny

> Verzonden: donderdag 10 december 2015 10:41

> Aan: sa...@lists.samba.org
> Onderwerp: Re: [Samba] Authentication to Secondary Domain Controller
> initially fails when PDC is offline
>

[Rowland penny]

When I can figure how to get into the new GitHub setup, I will be
proposing a patch for this, it just needs three line adding to
dns_update_list.

[Rowland penny]

If anybody is interested, this is the results of my testing, first here
are the results of adding an NS record to the dns domain SOA record for
the second DC on a domain using the internal dns server:

root@testdc1:~# dig SOA +multiline home.lan

; <<>> DiG 9.9.5-4~bpo70+1-Debian <<>> SOA +multiline home.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10153
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;home.lan. IN SOA

;; ANSWER SECTION:
home.lan. 3600 IN SOA testdc1.home.lan. hostmaster.home.lan. (
1 ; serial
900 ; refresh (15 minutes)
600 ; retry (10 minutes)
86400 ; expire (1 day)
3600 ; minimum (1 hour)
)

;; Query time: 28 msec
;; SERVER: 192.168.0.241#53(192.168.0.241)
;; WHEN: Thu Dec 10 11:35:46 GMT 2015
;; MSG SIZE rcvd: 81

root@testdc2:~# dig SOA +multiline home.lan

; <<>> DiG 9.9.5-4~bpo70+1-Debian <<>> SOA +multiline home.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23755
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;home.lan. IN SOA

;; ANSWER SECTION:
home.lan. 3600 IN SOA testdc1.home.lan. hostmaster.home.lan. (
1 ; serial
900 ; refresh (15 minutes)
600 ; retry (10 minutes)
86400 ; expire (1 day)
3600 ; minimum (1 hour)
)

;; Query time: 56 msec
;; SERVER: 192.168.0.240#53(192.168.0.240)
;; WHEN: Thu Dec 10 11:36:14 GMT 2015
;; MSG SIZE rcvd: 81

As you can see, even though each DC is using the other DC as its
nameserver in /etc/resolv.conf, they both return the same info, now
compare that with the info from a domain that uses bind9 as the dns server:

root@dc1:~# dig SOA +multiline samdom.example.com

; <<>> DiG 9.9.5-9+deb8u2-Debian <<>> SOA +multiline samdom.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59426
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;samdom.example.com. IN SOA

;; ANSWER SECTION:
samdom.example.com. 3600 IN SOA dc2.samdom.example.com.
hostmaster.samdom.example.com. (
101 ; serial
900 ; refresh (15 minutes)
600 ; retry (10 minutes)
86400 ; expire (1 day)
3600 ; minimum (1 hour)
)

;; AUTHORITY SECTION:
samdom.example.com. 900 IN NS dc1.samdom.example.com.
samdom.example.com. 900 IN NS dc2.samdom.example.com.

;; ADDITIONAL SECTION:
dc1.samdom.example.com. 900 IN A 192.168.0.5
dc2.samdom.example.com. 900 IN A 192.168.0.6

;; Query time: 7 msec
;; SERVER: 192.168.0.6#53(192.168.0.6)
;; WHEN: Thu Dec 10 11:41:22 GMT 2015
;; MSG SIZE rcvd: 162

root@dc2:~# dig SOA +multiline samdom.example.com

; <<>> DiG 9.9.5-9+deb8u2-Debian <<>> SOA +multiline samdom.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16889
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;samdom.example.com. IN SOA

;; ANSWER SECTION:
samdom.example.com. 3600 IN SOA dc1.samdom.example.com.
hostmaster.samdom.example.com. (
101 ; serial
900 ; refresh (15 minutes)
600 ; retry (10 minutes)
86400 ; expire (1 day)
3600 ; minimum (1 hour)
)

;; AUTHORITY SECTION:
samdom.example.com. 900 IN NS dc1.samdom.example.com.
samdom.example.com. 900 IN NS dc2.samdom.example.com.

;; ADDITIONAL SECTION:
dc1.samdom.example.com. 900 IN A 192.168.0.5
dc2.samdom.example.com. 900 IN A 192.168.0.6

;; Query time: 2 msec
;; SERVER: 192.168.0.5#53(192.168.0.5)
;; WHEN: Thu Dec 10 11:41:29 GMT 2015
;; MSG SIZE rcvd: 162

You get a lot more info and each DC is show as being authoritative for
the dns domain

Now, I am no expert when it comes to dns, but using bind9 looks a better
idea to me :-)

[Ole Traupe]

>> Any idea why I still get this when trying to log on to a member
>> server while the first DC is down?
>>
>> # kinit: Cannot contact any KDC for realm 'MY.DOMAIN.TLD' while
>> getting initial credentials
>>
>> Ole
>>
>>
>>
> Ole,
>
> Can you try a few things? All on your member server. What is the
> output of
>
> testparm | grep "name resolve order"

There is no such line.

>
> kdestroy -A
>
> kinit admini...@MY.DOMAIN.TLD -V

Using default cache: /tmp/krb5cc_0
Using principal: admini...@MY.DOMAIN.TLD
Password for admini...@MY.DOMAIN.TLD:
Authenticated to Kerberos v5

[James]

Rowland,

If I remember correctly you swapped the order of the DC's in your
resolv.conf to get these results? Can you see what happens if you were
to leave the resolv.conf order alone and temporally bring one of the
DC's down?

--
-James

[Ole Traupe]

>>
> Ole,
>
> I was trying to look back through your posts so excuse me if you
> have answered this. What was your original krb.conf file contents? A
> few things that may work is to specify the kdc and not rely on dns.
> for instance.
>
> [libdefaults]
> default_realm = MY.DOMAIN.TLD
> dns_lookup_kdc = false
> dns_lookup_realm = false
>
> [realms]
> MY.DOMAIN.TLD = {
> kdc = IP of First DC
> kdc = IP of Second DC
> }
>

Here is the content of /etc/krb5.conf (commented sections were all
effective, initially):

[root@server me]# cat /etc/krb5.conf
#[logging]
# default = FILE:/var/log/krb5libs.log
# kdc = FILE:/var/log/krb5kdc.log
# admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = MY.DOMAIN.TLD
# dns_lookup_realm = false
# dns_lookup_kdc = true
# ticket_lifetime = 24h
# renew_lifetime = 7d
# forwardable = true

#[realms]
# MY.DOMAIN.TLD = {
# kdc = dc1.my.domain.tld
# kdc = dc2.my.domain.tld
# admin_server = dc1.my.domain.tld
# default_domain = my.domain.tld
# }

#[domain_realm]
# my.domain.tld = MY.DOMAIN.TLD
# .my.domain.tld = MY.DOMAIN.TLD

Initially, when the First_DC was offline and I swapped the 'kdc' server
lines in [realms] in krb5.conf and the 'nameserver' lines in resolv.conf
(and restarted the network service; not sure whether the latter was
actually needed), I could kinit on the member server.

[Rowland penny]

OK, stopped samba on dc1

root@dc2:~# dig SOA +multiline samdom.example.com

; <<>> DiG 9.9.5-9+deb8u2-Debian <<>> SOA +multiline samdom.example.com
;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7191

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;samdom.example.com. IN SOA

;; ANSWER SECTION:
samdom.example.com. 3600 IN SOA dc1.samdom.example.com.
hostmaster.samdom.example.com. (
101 ; serial
900 ; refresh (15 minutes)
600 ; retry (10 minutes)
86400 ; expire (1 day)
3600 ; minimum (1 hour)
)

;; AUTHORITY SECTION:

samdom.example.com. 900 IN NS dc2.samdom.example.com.

samdom.example.com. 900 IN NS dc1.samdom.example.com.

;; ADDITIONAL SECTION:
dc1.samdom.example.com. 900 IN A 192.168.0.5
dc2.samdom.example.com. 900 IN A 192.168.0.6

;; Query time: 2 msec
;; SERVER: 192.168.0.5#53(192.168.0.5)

;; WHEN: Thu Dec 10 13:05:20 GMT 2015
;; MSG SIZE rcvd: 162

Hmm, still using bind on dc1, back to dc1 and stopped bind9:

root@dc2:~# dig SOA +multiline samdom.example.com

; <<>> DiG 9.9.5-9+deb8u2-Debian <<>> SOA +multiline samdom.example.com
;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60862

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;samdom.example.com. IN SOA

;; ANSWER SECTION:
samdom.example.com. 3600 IN SOA dc2.samdom.example.com.
hostmaster.samdom.example.com. (
101 ; serial
900 ; refresh (15 minutes)
600 ; retry (10 minutes)
86400 ; expire (1 day)
3600 ; minimum (1 hour)
)

;; AUTHORITY SECTION:

samdom.example.com. 900 IN NS dc2.samdom.example.com.

samdom.example.com. 900 IN NS dc1.samdom.example.com.

;; ADDITIONAL SECTION:
dc1.samdom.example.com. 900 IN A 192.168.0.5
dc2.samdom.example.com. 900 IN A 192.168.0.6

;; Query time: 7 msec
;; SERVER: 192.168.0.6#53(192.168.0.6)

;; WHEN: Thu Dec 10 13:06:24 GMT 2015

;; MSG SIZE rcvd: 162

It is now using itself as the NS

[Ole Traupe]

Am 09.12.2015 um 17:53 schrieb L.P.H. van Belle:
> Hai Ole,
>
> Can you run on the member where you logged in.
>
> host -t SRV _ldap._tcp.samdom.example.com.
> host -t SRV _kerberos._udp.samdom.example.com.
>
> host -t A dc1.samdom.example.com.
> host -t A dc2.samdom.example.com.
>
> and again with
> search my.domain.tld
> nameserver IP_of_2st_DC
> nameserver IP_of_1nd_DC
>

Both times the same:


[root@server me]# host -t SRV _ldap._tcp.my.domain.tld.
_ldap._tcp.my.domain.tld has SRV record 0 100 389 dc1.my.domain.tld.

[root@server me]# host -t SRV _kerberos._udp.my.domain.tld.
_kerberos._udp.my.domain.tld has SRV record 0 100 88 dc1.my.domain.tld.

[root@server me]# host -t A dc1.my.domain.tld.
dc1.my.domain.tld has address IP_of_FirstDC

[root@server me]# host -t A dc2.my.domain.tld.
dc2.my.domain.tld has address IP_of_SecondDC

There is no need to restart network service after altering resolv.conf,
right?

[Rowland penny]

On 10/12/15 13:05, Ole Traupe wrote:
>
>>> Any idea why I still get this when trying to log on to a member
>>> server while the first DC is down?
>>>
>>> # kinit: Cannot contact any KDC for realm 'MY.DOMAIN.TLD' while
>>> getting initial credentials
>>>
>>> Ole
>>>
>>>
>>>
>> Ole,
>>
>> Can you try a few things? All on your member server. What is the
>> output of
>>
>> testparm | grep "name resolve order"
>
> There is no such line.

Try it like this:

testparm -v | grep "name resolve order"

Rowland

[James]

This is the behavior I would expect to see.

--
-James

[Ole Traupe]

Is it possible that kdc server is always the SOA, at least if derived
from DNS and not specified *explicitly* in the krb5.conf?

In my DNS-Manager console I find that

_tcp.dc._msdcs.bpn.tu-berlin.de

contains only 1 "_kerberos" record, and that one points to my First_DC.

Ole

[Ole Traupe]

Am 09.12.2015 um 18:16 schrieb Rowland penny:

Hm, as I said: swapping kdc and nameserver entries on the member server
(and restarting the network service) was able to solve the problem, if I
remember correctly.

[Rowland penny]

On 10/12/15 13:08, Ole Traupe wrote:
>
>
> Am 09.12.2015 um 17:53 schrieb L.P.H. van Belle:
>> Hai Ole,
>>
>> Can you run on the member where you logged in.
>>
>> host -t SRV _ldap._tcp.samdom.example.com.
>> host -t SRV _kerberos._udp.samdom.example.com.
>>
>> host -t A dc1.samdom.example.com.
>> host -t A dc2.samdom.example.com.
>>
>> and again with
>> search my.domain.tld
>> nameserver IP_of_2st_DC
>> nameserver IP_of_1nd_DC
>>
>
> Both times the same:
>
>
> [root@server me]# host -t SRV _ldap._tcp.my.domain.tld.
> _ldap._tcp.my.domain.tld has SRV record 0 100 389 dc1.my.domain.tld.
>
> [root@server me]# host -t SRV _kerberos._udp.my.domain.tld.
> _kerberos._udp.my.domain.tld has SRV record 0 100 88 dc1.my.domain.tld.

You have problems, if you have two DCs, you should get something like this:

root@dc1:~# host -t SRV _ldap._tcp.samdom.example.com
_ldap._tcp.samdom.example.com has SRV record 0 100 389
dc2.samdom.example.com.
_ldap._tcp.samdom.example.com has SRV record 0 100 389
dc1.samdom.example.com.
root@dc1:~# host -t SRV _kerberos._udp.samdom.example.com
_kerberos._udp.samdom.example.com has SRV record 0 100 88
dc1.samdom.example.com.
_kerberos._udp.samdom.example.com has SRV record 0 100 88
dc2.samdom.example.com.

Rowland

[L.P.H. van Belle]

Hai Ole,

Ok, so there is your problem.
If you have 2 DC's, then with the command :
host -t SRV _ldap._tcp.my.domain.tld.
you should see :

_ldap._tcp.my.domain.tld has SRV record 0 100 389 dc1.my.domain.tld.

_ldap._tcp.my.domain.tld has SRV record 0 100 389 dc2.my.domain.tld.

Have a look here https://wiki.samba.org/index.php/Check_and_fix_DNS_entries_on_DC_joins

so you have seen bug 10928 in action ;-)
https://bugzilla.samba.org/show_bug.cgi?id=10928


Greetz,

Louis



> -----Oorspronkelijk bericht-----
> Van: Ole Traupe [mailto:ole.t...@tu-berlin.de]
> Verzonden: donderdag 10 december 2015 14:08
> Aan: L.P.H. van Belle

> Onderwerp: Re: [Samba] Authentication to Secondary Domain Controller
> initially fails when PDC is offline
>
>
>

> Am 09.12.2015 um 17:53 schrieb L.P.H. van Belle:

> > Hai Ole,
> >
> > Can you run on the member where you logged in.
> >
> > host -t SRV _ldap._tcp.samdom.example.com.
> > host -t SRV _kerberos._udp.samdom.example.com.
> >
> > host -t A dc1.samdom.example.com.
> > host -t A dc2.samdom.example.com.
> >
> > and again with
> > search my.domain.tld
> > nameserver IP_of_2st_DC
> > nameserver IP_of_1nd_DC
> >
>

> Both times the same:
>
>
> [root@server me]# host -t SRV _ldap._tcp.my.domain.tld.
> _ldap._tcp.my.domain.tld has SRV record 0 100 389 dc1.my.domain.tld.
>
> [root@server me]# host -t SRV _kerberos._udp.my.domain.tld.
> _kerberos._udp.my.domain.tld has SRV record 0 100 88 dc1.my.domain.tld.
>

> [root@server me]# host -t A dc1.my.domain.tld.
> dc1.my.domain.tld has address IP_of_FirstDC
>
> [root@server me]# host -t A dc2.my.domain.tld.
> dc2.my.domain.tld has address IP_of_SecondDC
>
> There is no need to restart network service after altering resolv.conf,
> right?
>

[Ole Traupe]

Am 10.12.2015 um 14:05 schrieb James:

> On 12/10/2015 7:56 AM, Ole Traupe wrote:
>>
>>>> Any idea why I still get this when trying to log on to a member
>>>> server while the first DC is down?
>>>>
>>>> # kinit: Cannot contact any KDC for realm 'MY.DOMAIN.TLD' while
>>>> getting initial credentials
>>>>
>>>> Ole
>>>>
>>>>
>>>>
>>> Ole,
>>>
>>> Can you try a few things? All on your member server. What is the
>>> output of
>>>
>>> testparm | grep "name resolve order"
>>

>> There is no such line.
>>
>>
>>>

>>> kdestroy -A
>>>
>>> kinit admini...@MY.DOMAIN.TLD -V
>>

>> Using default cache: /tmp/krb5cc_0
>> Using principal: admini...@MY.DOMAIN.TLD
>> Password for admini...@MY.DOMAIN.TLD:
>> Authenticated to Kerberos v5
>>
>>

> Sorry. The command is testparm -v | grep "name resolve order".

name resolve order = lmhosts wins host bcast


>
> It looks like your kinit succeed?
>

yes

[Rowland penny]

This is what is in resolv.conf on each DC:

root@dc1:~# nano /etc/resolv.conf

search samdom.example.com
nameserver 192.168.0.6
nameserver 192.168.0.5

root@dc2:~# nano /etc/resolv.conf

search samdom.example.com
nameserver 192.168.0.5
nameserver 192.168.0.6

dc1.samdom.example.com is 192.168.0.5
dc2.samdom.example.com is 192.168.0.6

Both have just this in /etc/krb5.conf

[libdefaults]
default_realm = SAMDOM.EXAMPLE.COM

Everything is working correctly.

Rowland

[Rowland penny]

On 10/12/15 13:25, Ole Traupe wrote:
> Is it possible that kdc server is always the SOA, at least if derived
> from DNS and not specified *explicitly* in the krb5.conf?
>
> In my DNS-Manager console I find that
>
> _tcp.dc._msdcs.bpn.tu-berlin.de
>
> contains only 1 "_kerberos" record, and that one points to my First_DC.
>
> Ole
>
>
>

Your problem doesn't seem to be a dns problem, you should have two
'kerberos' records and no matter how good your dns is, it cannot obtain
something that isn't there :-)

See Louis's earlier post for how to attempt to fix this, but before you
do anything, restart samba on the second DC and then check the logs,
samba_dnsupdate should add the records you are missing.

[Ole Traupe]

> You have problems, if you have two DCs, you should get something like
> this:
>
> root@dc1:~# host -t SRV _ldap._tcp.samdom.example.com
> _ldap._tcp.samdom.example.com has SRV record 0 100 389
> dc2.samdom.example.com.
> _ldap._tcp.samdom.example.com has SRV record 0 100 389
> dc1.samdom.example.com.
> root@dc1:~# host -t SRV _kerberos._udp.samdom.example.com
> _kerberos._udp.samdom.example.com has SRV record 0 100 88
> dc1.samdom.example.com.
> _kerberos._udp.samdom.example.com has SRV record 0 100 88
> dc2.samdom.example.com.
>
> Rowland

Definitely, good! :)

However, I have been there, done that:
https://wiki.samba.org/index.php/Check_and_fix_DNS_entries_on_DC_joins

This page says nothing about ldap or kerberos... why?!

Ole

[L.P.H. van Belle]

( sorry )
I know about this sinds 28-may-2015 :-/ thats when i noticed this problem.

Give me a few min, i'll get some more info.

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-...@lists.samba.org] Namens Rowland penny

> Verzonden: donderdag 10 december 2015 14:50
> Aan: sa...@lists.samba.org

> Onderwerp: Re: [Samba] Authentication to Secondary Domain Controller
> initially fails when PDC is offline
>

> On 10/12/15 13:40, Ole Traupe wrote:
> >
> >> You have problems, if you have two DCs, you should get something like
> >> this:
> >>
> >> root@dc1:~# host -t SRV _ldap._tcp.samdom.example.com
> >> _ldap._tcp.samdom.example.com has SRV record 0 100 389
> >> dc2.samdom.example.com.
> >> _ldap._tcp.samdom.example.com has SRV record 0 100 389
> >> dc1.samdom.example.com.
> >> root@dc1:~# host -t SRV _kerberos._udp.samdom.example.com
> >> _kerberos._udp.samdom.example.com has SRV record 0 100 88
> >> dc1.samdom.example.com.
> >> _kerberos._udp.samdom.example.com has SRV record 0 100 88
> >> dc2.samdom.example.com.
> >>
> >> Rowland
> >
> > Definitely, good! :)
> >
> > However, I have been there, done that:
> > https://wiki.samba.org/index.php/Check_and_fix_DNS_entries_on_DC_joins
> >
> > This page says nothing about ldap or kerberos... why?!
> >
> > Ole
> >
> >
> >
>

> Probably because either nobody has noticed the problem or the problem
> hasn't been reported before.
>
> Rowland

[Rowland penny]

On 10/12/15 13:40, Ole Traupe wrote:
>

>> You have problems, if you have two DCs, you should get something like
>> this:
>>
>> root@dc1:~# host -t SRV _ldap._tcp.samdom.example.com
>> _ldap._tcp.samdom.example.com has SRV record 0 100 389
>> dc2.samdom.example.com.
>> _ldap._tcp.samdom.example.com has SRV record 0 100 389
>> dc1.samdom.example.com.
>> root@dc1:~# host -t SRV _kerberos._udp.samdom.example.com
>> _kerberos._udp.samdom.example.com has SRV record 0 100 88
>> dc1.samdom.example.com.
>> _kerberos._udp.samdom.example.com has SRV record 0 100 88
>> dc2.samdom.example.com.
>>
>> Rowland
>
> Definitely, good! :)
>
> However, I have been there, done that:
> https://wiki.samba.org/index.php/Check_and_fix_DNS_entries_on_DC_joins
>
> This page says nothing about ldap or kerberos... why?!
>
> Ole
>
>
>

Probably because either nobody has noticed the problem or the problem
hasn't been reported before.

Rowland

[L.P.H. van Belle]

Ok, im using the RSAT tools so howto get more info and fix this.

Start Active Directory Sites and Services
Klik on Sites, Default-First-Site-Name - Server.
Your should see you second DC also, if not, you can add it manualy.
I dont know the samba-tools commands for this one.

In the DNS admin.
Go to _msdcs.YOURDOMAIN.
Look at the aliasses.
These are the names you need in Active Directory Sites and Services
You should see also 2 ! aliasses, if you seeing one, this must be fixed first.

And ! VERY IMPORTANT !!
Under the _msdcs.DOMAINS..
In pdc _tcp here should be ONLY THE PRIMARY DC !

Walk throug the _msdcs for what your missing.
I guest, all the second DC entries.

Have a look als in zone YOURDOMAIN and looin in the _XXX
Here you should have also 1 entry per DC.

Louis

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-...@lists.samba.org] Namens Rowland penny
> Verzonden: donderdag 10 december 2015 14:50
> Aan: sa...@lists.samba.org
> Onderwerp: Re: [Samba] Authentication to Secondary Domain Controller
> initially fails when PDC is offline
>

[Ole Traupe]

Am 10.12.2015 um 14:38 schrieb Rowland penny:
> On 10/12/15 13:25, Ole Traupe wrote:
>> Is it possible that kdc server is always the SOA, at least if
>> derived from DNS and not specified *explicitly* in the krb5.conf?
>>
>> In my DNS-Manager console I find that
>>
>> _tcp.dc._msdcs.bpn.tu-berlin.de
>>
>> contains only 1 "_kerberos" record, and that one points to my First_DC.
>>
>> Ole
>>
>>
>>
>
> Your problem doesn't seem to be a dns problem, you should have two
> 'kerberos' records and no matter how good your dns is, it cannot
> obtain something that isn't there :-)

That's basically what I just wrote...

>
> See Louis's earlier post for how to attempt to fix this, but before
> you do anything, restart samba on the second DC and then check the
> logs, samba_dnsupdate should add the records you are missing.
>
> Rowland
>
>

However, my 2nd DC is not that new, I restarted it many times, just
again (samba service). No DNS records are created anywhere.

If I go through the DNS console, in each and every container there is
some entry for the 1st DC, but none for the 2nd (except on the top
levels: FQDN and _msdcs.FQDN).

Could this have to do with...
a) I demoted my initial 1st DC (seized FSMO roles) and got rid of DNS
entries via this script on the wiki?
b) set up the *new* 2nd DC on the hardware of the prior 1st DC (with the
same IP address)?

[Ole Traupe]

Am 10.12.2015 um 14:49 schrieb Rowland penny:
> On 10/12/15 13:40, Ole Traupe wrote:
>>
>>> You have problems, if you have two DCs, you should get something
>>> like this:
>>>
>>> root@dc1:~# host -t SRV _ldap._tcp.samdom.example.com
>>> _ldap._tcp.samdom.example.com has SRV record 0 100 389
>>> dc2.samdom.example.com.
>>> _ldap._tcp.samdom.example.com has SRV record 0 100 389
>>> dc1.samdom.example.com.
>>> root@dc1:~# host -t SRV _kerberos._udp.samdom.example.com
>>> _kerberos._udp.samdom.example.com has SRV record 0 100 88
>>> dc1.samdom.example.com.
>>> _kerberos._udp.samdom.example.com has SRV record 0 100 88
>>> dc2.samdom.example.com.
>>>
>>> Rowland
>>
>> Definitely, good! :)
>>
>> However, I have been there, done that:
>> https://wiki.samba.org/index.php/Check_and_fix_DNS_entries_on_DC_joins
>>
>> This page says nothing about ldap or kerberos... why?!
>>
>> Ole
>>
>>
>>
>
> Probably because either nobody has noticed the problem or the problem
> hasn't been reported before.
>
> Rowland
>
>

Sounds plausible. ;)

[Rowland penny]

Possibly, but can you try this on your second DC, run 'samba_dnsupdate
--verbose'

Rowland