samba - Jun 2016 - inconsistent DNS information, windows domain member issues..

> -----Ursprüngliche Nachricht-----
> Von: Rowland penny [mailto:rpenny at samba.org]
> Gesendet: Sonntag, 5. Juni 2016 17:46
> An: Jo <j.o.l at live.com>
> Cc: 'samba' <samba at lists.samba.org>
> Betreff: Re: AW: [Samba] inconsistent DNS information, windows domain
> member issues..
> 
> On 05/06/16 13:43, Jo wrote:
> >> Your DCs really need to be running at all times, so that
replication
> >> can work properly, also each DC should use the other for their DNS
> >> server, anything unknown to the DNS servers on the DCs should be
> >> forwarded to an external DNS that does know or can find out.
> > I understand that they need to be up simultaneously for replication,
but
> otherwise that should not be the case. Or why? Imho the point of
> redundancy is that you can tolerate failure. In fact I would like to run
this on
> two bananas but haven´t found a usable distribution so far that offers
recent
> versions of Samba (and supports encryption at least of the relevant data).
> Running the windows hosts all the time is not an option due to noise,
energy
> consumption, etc.
> 
> I take it that by 'bananas' you mean 'banana-pi', this
probably suffers
> from the same problems as the rpi, you will probably have to build Samba
> yourself and it will probably be unable to cope with a lot of users etc.
Compared to the Pi the Banana Pro is roughly twice as fast and has gigabit
network - it runs all my external networking (bind, nginx reverse proxies and
websites) very well, but I am aware it slows down communication considerably if
I proxy internal communication (file transfer) through it. For now I assume it
should be OK for the number of users and systems I plan to connect, both in the
order of 10-20, but the challenge is to get it running in the first place and
then sustainable (available, up to date, secure, and with backups).
> 
> You need to understand that if you only have one DC running, it will
> keep trying to contact the other, and any changes made on the running DC
> will need to be replicated to the other when it does come back up.
> 
> >
> > The point of whether the DC should use the respective other DC for DNS
is
> obviously debated here. The DCs do have an upstream forwarder configured
> in bind.
> 
> If you have two DCs, they need to use each other for DNS or you can get
> what is called 'islanding'
> 
> >
> >> Can you please post  /etc/resolv.conf, /etc/hosts and
/etc/krb5.conf from
> >> each DC, can you also post the smb.conf file from each DC.
> >>
> > joachim at dc1:~$ cat /etc/resolv.conf
> > # Dynamic resolv.conf(5) file for glibc resolver(3) generated by
> resolvconf(8)
> > #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE
> OVERWRITTEN
> > nameserver 192.168.177.21
> > search samba.domain
> 
> It is not really a good idea to run 'resolvconf' on a fixed ip
machine
> (I take it the DCs do have fixed ipaddresses), I suggest you remove it
> and then set /etc/resolv.conf to:
> 
> nameserver 192.168.177.22
> nameserver 192.168.177.21
> search samba.domain
> 
> Switch the 'nameserver' lines for the second DC
Sorry, reminds me about asking for legal advice. Ask two lawyers, get three
opinions, of course conflicting. Afaik the recommended way on Ubuntu is to put
the configuration in /etc/network/interfaces:
# The primary network interface
auto enp0s3
iface enp0s3 inet static
        address 192.168.15.22
        netmask 255.255.255.0
        gateway 192.168.15.1
        dns-nameservers 192.168.15.22
        dns-search samba.lindenberg.one

...and I prefer to keep configuration as local as possible, especially as
occasionally I need to move systems from one location to the other. With respect
to the islands issue Andrew recommended to use the DC on the DC. I am aware of
the monitoring issue, but I definitely expect less updates to the DC contents
then outages of the network in between. And for my experiments I can wake them
explicitly as needed.
> > joachim at dc1:~$ cat /etc/hosts
> > 127.0.0.1       localhost
> > 192.168.177.21  dc1 dc1.samba.domain
> > 192.168.15.22   dc2 dc2.samba.domain
> >
> > # The following lines are desirable for IPv6 capable hosts
> > #::1     localhost ip6-localhost ip6-loopback
> > #ff02::1 ip6-allnodes
> > #ff02::2 ip6-allrouters
> 
> nothing wrong there, except you don't need the line for the other DC
The line for the other DC helps with digging both for comparisions...
> 
> > joachim at dc1:~$ cat /etc/krb5.conf
> > [libdefaults]
> >          default_realm = SAMBA.DOMAIN
> >
> > # The following krb5.conf variables are only for MIT Kerberos.
> >          krb4_config = /etc/krb.conf
> >          krb4_realms = /etc/krb.realms
> >          kdc_timesync = 1
> >          ccache_type = 4
> >          forwardable = true
> >          proxiable = true
> >
> > # The following encryption type specification will be used by MIT
Kerberos
> > # if uncommented.  In general, the defaults in the MIT Kerberos code
are
> > # correct and overriding these specifications only serves to disable
new
> > # encryption types as they are added, creating interoperability
problems.
> > #
> > # Thie only time when you might need to uncomment these lines and
> change
> > # the enctypes is if you have local software that will break on ticket
> > # caches containing ticket encryption types it doesn't know about
(such as
> > # old versions of Sun Java).
> >
> > #       default_tgs_enctypes = des3-hmac-sha1
> > #       default_tkt_enctypes = des3-hmac-sha1
> > #       permitted_enctypes = des3-hmac-sha1
> >
> > # The following libdefaults parameters are only for Heimdal Kerberos.
> >          v4_instance_resolve = false
> >          v4_name_convert = {
> >                  host = {
> >                          rcmd = host
> >                          ftp = ftp
> >                  }
> >                  plain = {
> >                          something = something-else
> >                  }
> >          }
> >          fcc-mit-ticketflags = true
> >
> > [realms]
> >          ATHENA.MIT.EDU = {
> >                  kdc = kerberos.mit.edu:88
> >                  kdc = kerberos-1.mit.edu:88
> >                  kdc = kerberos-2.mit.edu:88
> >                  admin_server = kerberos.mit.edu
> >                  default_domain = mit.edu
> >          }
> >          MEDIA-LAB.MIT.EDU = {
> >                  kdc = kerberos.media.mit.edu
> >                  admin_server = kerberos.media.mit.edu
> >          }
> >          ZONE.MIT.EDU = {
> >                  kdc = casio.mit.edu
> >                  kdc = seiko.mit.edu
> >                  admin_server = casio.mit.edu
> >          }
> >          MOOF.MIT.EDU = {
> >                  kdc = three-headed-dogcow.mit.edu:88
> >                  kdc = three-headed-dogcow-1.mit.edu:88
> >                  admin_server = three-headed-dogcow.mit.edu
> >          }
> >          CSAIL.MIT.EDU = {
> >                  kdc = kerberos-1.csail.mit.edu
> >                  kdc = kerberos-2.csail.mit.edu
> >                  admin_server = kerberos.csail.mit.edu
> >                  default_domain = csail.mit.edu
> >                  krb524_server = krb524.csail.mit.edu
> >          }
> >          IHTFP.ORG = {
> >                  kdc = kerberos.ihtfp.org
> >                  admin_server = kerberos.ihtfp.org
> >          }
> >          GNU.ORG = {
> >                  kdc = kerberos.gnu.org
> >                  kdc = kerberos-2.gnu.org
> >                  kdc = kerberos-3.gnu.org
> >                  admin_server = kerberos.gnu.org
> >          }
> >          1TS.ORG = {
> >                  kdc = kerberos.1ts.org
> >                  admin_server = kerberos.1ts.org
> >          }
> >          GRATUITOUS.ORG = {
> >                  kdc = kerberos.gratuitous.org
> >                  admin_server = kerberos.gratuitous.org
> >          }
> >          DOOMCOM.ORG = {
> >                  kdc = kerberos.doomcom.org
> >                  admin_server = kerberos.doomcom.org
> >          }
> >          ANDREW.CMU.EDU = {
> >                  kdc = kerberos.andrew.cmu.edu
> >                  kdc = kerberos2.andrew.cmu.edu
> >                  kdc = kerberos3.andrew.cmu.edu
> >                  admin_server = kerberos.andrew.cmu.edu
> >                  default_domain = andrew.cmu.edu
> >          }
> >          CS.CMU.EDU = {
> >                  kdc = kerberos.cs.cmu.edu
> >                  kdc = kerberos-2.srv.cs.cmu.edu
> >                  admin_server = kerberos.cs.cmu.edu
> >          }
> >          DEMENTIA.ORG = {
> >                  kdc = kerberos.dementix.org
> >                  kdc = kerberos2.dementix.org
> >                  admin_server = kerberos.dementix.org
> >          }
> >          stanford.edu = {
> >                  kdc = krb5auth1.stanford.edu
> >                  kdc = krb5auth2.stanford.edu
> >                  kdc = krb5auth3.stanford.edu
> >                  master_kdc = krb5auth1.stanford.edu
> >                  admin_server = krb5-admin.stanford.edu
> >                  default_domain = stanford.edu
> >          }
> >          UTORONTO.CA = {
> >                  kdc = kerberos1.utoronto.ca
> >                  kdc = kerberos2.utoronto.ca
> >                  kdc = kerberos3.utoronto.ca
> >                  admin_server = kerberos1.utoronto.ca
> >                  default_domain = utoronto.ca
> >          }
> >
> > [domain_realm]
> >          .mit.edu = ATHENA.MIT.EDU
> >          mit.edu = ATHENA.MIT.EDU
> >          .media.mit.edu = MEDIA-LAB.MIT.EDU
> >          media.mit.edu = MEDIA-LAB.MIT.EDU
> >          .csail.mit.edu = CSAIL.MIT.EDU
> >          csail.mit.edu = CSAIL.MIT.EDU
> >          .whoi.edu = ATHENA.MIT.EDU
> >          whoi.edu = ATHENA.MIT.EDU
> >          .stanford.edu = stanford.edu
> >          .slac.stanford.edu = SLAC.STANFORD.EDU
> >          .toronto.edu = UTORONTO.CA
> >          .utoronto.ca = UTORONTO.CA
> >
> > [login]
> >          krb4_convert = true
> >          krb4_get_tickets = false
> 
> Here's the thing, your /etc/krb5.conf only needs to look like this:
> 
> [libdefaults]
>          default_realm = SAMBA.DOMAIN
> 
> Everything else is unneeded or the default.
Which explains why it worked without defining the domain on DC1. OK, I removed
the garbage...
> 
> > joachim at dc1:~$ cat /etc/samba/smb.conf
> > # Global parameters
> > [global]
> >          workgroup = SAMBA
> >          realm = SAMBA.DOMAIN
> >          netbios name = DC1
> >          server role = active directory domain controller
> >          server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc,
drepl,
> winbindd, ntp_signd, kcc, dnsupdate
> >          idmap_ldb:use rfc2307 = yes
> >
> > [netlogon]
> >          path = /var/lib/samba/sysvol/samba.domain/scripts
> >          read only = No
> >
> > [sysvol]
> >          path = /var/lib/samba/sysvol
> >          read only = No
> > joachim at dc1:~$
> 
> This looks ok.
> 
> The files on the second DC should be similar to the first, except for
> the obvious name & ip changes.
> 
> >
> >
> >
> > One new piece of mosaic:
> >
> > root at dc2:/home/joachim# tail /var/log/samba/log.samba
> > [2016/06/05 14:28:12.674356,  0]
> ../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
> >    /usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is
> unacceptable
> > [2016/06/05 14:28:12.697076,  0]
> ../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
> >    /usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is
> unacceptable
> > [2016/06/05 14:28:12.719968,  0]
> ../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
> >    /usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is
> unacceptable
> > [2016/06/05 14:28:12.743569,  0]
> ../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
> >    /usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is
> unacceptable
> > [2016/06/05 14:28:12.756246,  0]
> ../source4/dsdb/dns/dns_update.c:294(dnsupdate_nameupdate_done)
> >    ../source4/dsdb/dns/dns_update.c:294: Failed DNS update -
> NT_STATUS_UNSUCCESSFUL
> > root at dc2:/home/joachim#
> >
> > I tried to follow
> https://wiki.samba.org/index.php/Dns_tkey_negotiategss:_TKEY_is_unaccep
> table, but may be that is outdated? I found a keytab file at
> /var/lib/samba/private/secrets.keytab and it contains what is described on
> the wiki page:
> >
> > root at dc2:/home/joachim# klist -k
/var/lib/samba/private/secrets.keytab
> > Keytab name: FILE:/var/lib/samba/private/secrets.keytab
> > KVNO Principal
> > ----
--------------------------------------------------------------------------
> >     1 HOST/dc2 at SAMBA.DOMAIN
> >     1 HOST/dc2.samba.domain at SAMBA.DOMAIN
> >     1 DC2$@SAMBA.DOMAIN
> >     1 HOST/dc2 at SAMBA.DOMAIN
> >     1 HOST/dc2.samba.domain at SAMBA.DOMAIN
> >     1 DC2$@SAMBA.DOMAIN
> >     1 HOST/dc2 at SAMBA.DOMAIN
> >     1 HOST/dc2.samba.domain at SAMBA.DOMAIN
> >     1 DC2$@SAMBA.DOMAIN
> >     1 HOST/dc2 at SAMBA.DOMAIN
> >     1 HOST/dc2.samba.domain at SAMBA.DOMAIN
> >     1 DC2$@SAMBA.DOMAIN
> >     1 HOST/dc2 at SAMBA.DOMAIN
> >     1 HOST/dc2.samba.domain at SAMBA.DOMAIN
> >     1 DC2$@SAMBA.DOMAIN
> >
> > Do I have to update some configuration path to point to that file?
Create a
> link? Or what else to check?
> >
> >
> >
> 
> Are you running an ntp server on each DC? if not, I suggest you do.
I am running ntpd as a client. Why should I configure a server? Which Samba or
AD client uses an ntp server on a DC by default?
> 
> How have you set up Bind, can you post your named.conf files.
root at dc2:/home/joachim# cat /etc/bind/named.conf
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/bind.keys";

root at dc2:/home/joachim# cat /etc/bind/named.conf.options
options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        forwarders {
                192.168.15.2;
        };

       
//=======================================================================       
// If BIND logs error messages about the root key being expired,
        // you will need to update your keys.  See https://www.isc.org/bind-keys
       
//=======================================================================       
dnssec-validation no; #auto;

        auth-nxdomain no;    # conform to RFC1035
#       listen-on-v6 { any; };
        allow-query-cache { any; };
        allow-query { any; };
# allow-recursion { any;192.168.0.0/16;localhost; };
        allow-recursion { any; };
        tkey-gssapi-keytab "/var/lib/samba/private/dns.keytab";
};

root at dc2:/home/joachim# cat /etc/bind/named.conf.local
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

zone "domain" {
        type master;
        file "/etc/bind/lindenberg.one";
#       allow-transfer { 192.168.177.8 };
        allow-update { key rndc-key; };
};

include "/var/lib/samba/private/named.conf";

I am ommitting named.conf.default-zones as I did not touch that. Note that I do
have a zone file for domain but it is not really used right now. Samba.domain is
obviously a subdomain served by Samba. And one extra you did not ask for...

root at dc2:/home/joachim# cat /var/lib/samba/private/named.conf
# This DNS configuration is for BIND 9.8.0 or later with dlz_dlopen support.
#
# This file should be included in your main BIND configuration file
#
# For example with
# include "/var/lib/samba/private/named.conf";

#
# This configures dynamically loadable zones (DLZ) from AD schema
# Uncomment only single database line, depending on your BIND version
#
dlz "AD DNS Zone" {
    # For BIND 9.8.x
    # database "dlopen
/usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9.so";

    # For BIND 9.9.x
    # database "dlopen
/usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_9.so";

    # For BIND 9.10.x
     database "dlopen
/usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_10.so";
};

root at dc2:/home/joachim#

I just also tried to replace the nonexisting dns.keytab with secrets.keytab -
then I get
root at dc2:/home/joachim# tail /var/log/samba/log.samba
[2016/06/05 19:16:29.377544,  0]
../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
  /usr/sbin/samba_dnsupdate: update failed: REFUSED
[2016/06/05 19:16:29.404010,  0]
../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
  /usr/sbin/samba_dnsupdate: update failed: REFUSED
[2016/06/05 19:16:29.430791,  0]
../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
  /usr/sbin/samba_dnsupdate: update failed: REFUSED
[2016/06/05 19:16:29.458506,  0]
../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
  /usr/sbin/samba_dnsupdate: update failed: REFUSED
[2016/06/05 19:16:29.472351,  0]
../source4/dsdb/dns/dns_update.c:294(dnsupdate_nameupdate_done)
  ../source4/dsdb/dns/dns_update.c:294: Failed DNS update -
NT_STATUS_UNSUCCESSFUL
root at dc2:/home/joachim#

...instead of the "TKEY is unacceptable"
before.
> 
> Rowland
> 
>

On 05/06/16 18:25, Jo wrote:
>> -----Ursprüngliche Nachricht-----
>> Von: Rowland penny [mailto:rpenny at samba.org]
>> Gesendet: Sonntag, 5. Juni 2016 17:46
>> An: Jo <j.o.l at live.com>
>> Cc: 'samba' <samba at lists.samba.org>
>> Betreff: Re: AW: [Samba] inconsistent DNS information, windows domain
>> member issues..
>>
>> On 05/06/16 13:43, Jo wrote:
>>>> Your DCs really need to be running at all times, so that
replication
>>>> can work properly, also each DC should use the other for their
DNS
>>>> server, anything unknown to the DNS servers on the DCs should
be
>>>> forwarded to an external DNS that does know or can find out.
>>> I understand that they need to be up simultaneously for
replication, but
>> otherwise that should not be the case. Or why? Imho the point of
>> redundancy is that you can tolerate failure. In fact I would like to
run this on
>> two bananas but haven´t found a usable distribution so far that offers
recent
>> versions of Samba (and supports encryption at least of the relevant
data).
>> Running the windows hosts all the time is not an option due to noise,
energy
>> consumption, etc.
>>
>> I take it that by 'bananas' you mean 'banana-pi', this
probably suffers
>> from the same problems as the rpi, you will probably have to build
Samba
>> yourself and it will probably be unable to cope with a lot of users
etc.
> Compared to the Pi the Banana Pro is roughly twice as fast and has gigabit
network - it runs all my external networking (bind, nginx reverse proxies and
websites) very well, but I am aware it slows down communication considerably if
I proxy internal communication (file transfer) through it. For now I assume it
should be OK for the number of users and systems I plan to connect, both in the
order of 10-20, but the challenge is to get it running in the first place and
then sustainable (available, up to date, secure, and with backups).
OK, it should be able to cope with that, it would be a different if you 
were talking 100-200 users etc
>
>> You need to understand that if you only have one DC running, it will
>> keep trying to contact the other, and any changes made on the running
DC
>> will need to be replicated to the other when it does come back up.
>>
>>> The point of whether the DC should use the respective other DC for
DNS is
>> obviously debated here. The DCs do have an upstream forwarder
configured
>> in bind.
>>
>> If you have two DCs, they need to use each other for DNS or you can get
>> what is called 'islanding'
>>
>>>> Can you please post  /etc/resolv.conf, /etc/hosts and
/etc/krb5.conf from
>>>> each DC, can you also post the smb.conf file from each DC.
>>>>
>>> joachim at dc1:~$ cat /etc/resolv.conf
>>> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by
>> resolvconf(8)
>>> #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE
>> OVERWRITTEN
>>> nameserver 192.168.177.21
>>> search samba.domain
>> It is not really a good idea to run 'resolvconf' on a fixed ip
machine
>> (I take it the DCs do have fixed ipaddresses), I suggest you remove it
>> and then set /etc/resolv.conf to:
>>
>> nameserver 192.168.177.22
>> nameserver 192.168.177.21
>> search samba.domain
>>
>> Switch the 'nameserver' lines for the second DC
> Sorry, reminds me about asking for legal advice. Ask two lawyers, get three
opinions, of course conflicting. Afaik the recommended way on Ubuntu is to put
the configuration in /etc/network/interfaces:
> # The primary network interface
> auto enp0s3
> iface enp0s3 inet static
>          address 192.168.15.22
>          netmask 255.255.255.0
>          gateway 192.168.15.1
>          dns-nameservers 192.168.15.22
>          dns-search samba.lindenberg.one
and mine is:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
     address 192.168.0.5
     netmask 255.255.255.0
     network 192.168.0.0
     broadcast 192.168.0.255
     gateway 192.168.0.1

Just because Ubuntu puts nameservers in there doesn't mean you have to, 
but it is your domain and you get to make your own decisions.
>
> ...and I prefer to keep configuration as local as possible, especially as
occasionally I need to move systems from one location to the other. With respect
to the islands issue Andrew recommended to use the DC on the DC. I am aware of
the monitoring issue, but I definitely expect less updates to the DC contents
then outages of the network in between. And for my experiments I can wake them
explicitly as needed.
He seems to be by himself there, even Microsoft don't recommend using 
the DC for its own DNS.
>
>>> joachim at dc1:~$ cat /etc/hosts
>>> 127.0.0.1       localhost
>>> 192.168.177.21  dc1 dc1.samba.domain
>>> 192.168.15.22   dc2 dc2.samba.domain
>>>
>>> # The following lines are desirable for IPv6 capable hosts
>>> #::1     localhost ip6-localhost ip6-loopback
>>> #ff02::1 ip6-allnodes
>>> #ff02::2 ip6-allrouters
>> nothing wrong there, except you don't need the line for the other
DC
> The line for the other DC helps with digging both for comparisions...
>
>>> joachim at dc1:~$ cat /etc/krb5.conf
>>> [libdefaults]
>>>           default_realm = SAMBA.DOMAIN
>>>
>>> # The following krb5.conf variables are only for MIT Kerberos.
>>>           krb4_config = /etc/krb.conf
>>>           krb4_realms = /etc/krb.realms
>>>           kdc_timesync = 1
>>>           ccache_type = 4
>>>           forwardable = true
>>>           proxiable = true
>>>
>>> # The following encryption type specification will be used by MIT
Kerberos
>>> # if uncommented.  In general, the defaults in the MIT Kerberos
code are
>>> # correct and overriding these specifications only serves to
disable new
>>> # encryption types as they are added, creating interoperability
problems.
>>> #
>>> # Thie only time when you might need to uncomment these lines and
>> change
>>> # the enctypes is if you have local software that will break on
ticket
>>> # caches containing ticket encryption types it doesn't know
about (such as
>>> # old versions of Sun Java).
>>>
>>> #       default_tgs_enctypes = des3-hmac-sha1
>>> #       default_tkt_enctypes = des3-hmac-sha1
>>> #       permitted_enctypes = des3-hmac-sha1
>>>
>>> # The following libdefaults parameters are only for Heimdal
Kerberos.
>>>           v4_instance_resolve = false
>>>           v4_name_convert = {
>>>                   host = {
>>>                           rcmd = host
>>>                           ftp = ftp
>>>                   }
>>>                   plain = {
>>>                           something = something-else
>>>                   }
>>>           }
>>>           fcc-mit-ticketflags = true
>>>
>>> [realms]
>>>           ATHENA.MIT.EDU = {
>>>                   kdc = kerberos.mit.edu:88
>>>                   kdc = kerberos-1.mit.edu:88
>>>                   kdc = kerberos-2.mit.edu:88
>>>                   admin_server = kerberos.mit.edu
>>>                   default_domain = mit.edu
>>>           }
>>>           MEDIA-LAB.MIT.EDU = {
>>>                   kdc = kerberos.media.mit.edu
>>>                   admin_server = kerberos.media.mit.edu
>>>           }
>>>           ZONE.MIT.EDU = {
>>>                   kdc = casio.mit.edu
>>>                   kdc = seiko.mit.edu
>>>                   admin_server = casio.mit.edu
>>>           }
>>>           MOOF.MIT.EDU = {
>>>                   kdc = three-headed-dogcow.mit.edu:88
>>>                   kdc = three-headed-dogcow-1.mit.edu:88
>>>                   admin_server = three-headed-dogcow.mit.edu
>>>           }
>>>           CSAIL.MIT.EDU = {
>>>                   kdc = kerberos-1.csail.mit.edu
>>>                   kdc = kerberos-2.csail.mit.edu
>>>                   admin_server = kerberos.csail.mit.edu
>>>                   default_domain = csail.mit.edu
>>>                   krb524_server = krb524.csail.mit.edu
>>>           }
>>>           IHTFP.ORG = {
>>>                   kdc = kerberos.ihtfp.org
>>>                   admin_server = kerberos.ihtfp.org
>>>           }
>>>           GNU.ORG = {
>>>                   kdc = kerberos.gnu.org
>>>                   kdc = kerberos-2.gnu.org
>>>                   kdc = kerberos-3.gnu.org
>>>                   admin_server = kerberos.gnu.org
>>>           }
>>>           1TS.ORG = {
>>>                   kdc = kerberos.1ts.org
>>>                   admin_server = kerberos.1ts.org
>>>           }
>>>           GRATUITOUS.ORG = {
>>>                   kdc = kerberos.gratuitous.org
>>>                   admin_server = kerberos.gratuitous.org
>>>           }
>>>           DOOMCOM.ORG = {
>>>                   kdc = kerberos.doomcom.org
>>>                   admin_server = kerberos.doomcom.org
>>>           }
>>>           ANDREW.CMU.EDU = {
>>>                   kdc = kerberos.andrew.cmu.edu
>>>                   kdc = kerberos2.andrew.cmu.edu
>>>                   kdc = kerberos3.andrew.cmu.edu
>>>                   admin_server = kerberos.andrew.cmu.edu
>>>                   default_domain = andrew.cmu.edu
>>>           }
>>>           CS.CMU.EDU = {
>>>                   kdc = kerberos.cs.cmu.edu
>>>                   kdc = kerberos-2.srv.cs.cmu.edu
>>>                   admin_server = kerberos.cs.cmu.edu
>>>           }
>>>           DEMENTIA.ORG = {
>>>                   kdc = kerberos.dementix.org
>>>                   kdc = kerberos2.dementix.org
>>>                   admin_server = kerberos.dementix.org
>>>           }
>>>           stanford.edu = {
>>>                   kdc = krb5auth1.stanford.edu
>>>                   kdc = krb5auth2.stanford.edu
>>>                   kdc = krb5auth3.stanford.edu
>>>                   master_kdc = krb5auth1.stanford.edu
>>>                   admin_server = krb5-admin.stanford.edu
>>>                   default_domain = stanford.edu
>>>           }
>>>           UTORONTO.CA = {
>>>                   kdc = kerberos1.utoronto.ca
>>>                   kdc = kerberos2.utoronto.ca
>>>                   kdc = kerberos3.utoronto.ca
>>>                   admin_server = kerberos1.utoronto.ca
>>>                   default_domain = utoronto.ca
>>>           }
>>>
>>> [domain_realm]
>>>           .mit.edu = ATHENA.MIT.EDU
>>>           mit.edu = ATHENA.MIT.EDU
>>>           .media.mit.edu = MEDIA-LAB.MIT.EDU
>>>           media.mit.edu = MEDIA-LAB.MIT.EDU
>>>           .csail.mit.edu = CSAIL.MIT.EDU
>>>           csail.mit.edu = CSAIL.MIT.EDU
>>>           .whoi.edu = ATHENA.MIT.EDU
>>>           whoi.edu = ATHENA.MIT.EDU
>>>           .stanford.edu = stanford.edu
>>>           .slac.stanford.edu = SLAC.STANFORD.EDU
>>>           .toronto.edu = UTORONTO.CA
>>>           .utoronto.ca = UTORONTO.CA
>>>
>>> [login]
>>>           krb4_convert = true
>>>           krb4_get_tickets = false
>> Here's the thing, your /etc/krb5.conf only needs to look like this:
>>
>> [libdefaults]
>>           default_realm = SAMBA.DOMAIN
>>
>> Everything else is unneeded or the default.
> Which explains why it worked without defining the domain on DC1. OK, I
removed the garbage...
>
>>> joachim at dc1:~$ cat /etc/samba/smb.conf
>>> # Global parameters
>>> [global]
>>>           workgroup = SAMBA
>>>           realm = SAMBA.DOMAIN
>>>           netbios name = DC1
>>>           server role = active directory domain controller
>>>           server services = s3fs, rpc, nbt, wrepl, ldap, cldap,
kdc, drepl,
>> winbindd, ntp_signd, kcc, dnsupdate
>>>           idmap_ldb:use rfc2307 = yes
>>>
>>> [netlogon]
>>>           path = /var/lib/samba/sysvol/samba.domain/scripts
>>>           read only = No
>>>
>>> [sysvol]
>>>           path = /var/lib/samba/sysvol
>>>           read only = No
>>> joachim at dc1:~$
>> This looks ok.
>>
>> The files on the second DC should be similar to the first, except for
>> the obvious name & ip changes.
>>
>>>
>>>
>>> One new piece of mosaic:
>>>
>>> root at dc2:/home/joachim# tail /var/log/samba/log.samba
>>> [2016/06/05 14:28:12.674356,  0]
>> ../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
>>>     /usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is
>> unacceptable
>>> [2016/06/05 14:28:12.697076,  0]
>> ../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
>>>     /usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is
>> unacceptable
>>> [2016/06/05 14:28:12.719968,  0]
>> ../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
>>>     /usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is
>> unacceptable
>>> [2016/06/05 14:28:12.743569,  0]
>> ../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
>>>     /usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is
>> unacceptable
>>> [2016/06/05 14:28:12.756246,  0]
>> ../source4/dsdb/dns/dns_update.c:294(dnsupdate_nameupdate_done)
>>>     ../source4/dsdb/dns/dns_update.c:294: Failed DNS update -
>> NT_STATUS_UNSUCCESSFUL
>>> root at dc2:/home/joachim#
>>>
>>> I tried to follow
>> https://wiki.samba.org/index.php/Dns_tkey_negotiategss:_TKEY_is_unaccep
>> table, but may be that is outdated? I found a keytab file at
>> /var/lib/samba/private/secrets.keytab and it contains what is described
on
>> the wiki page:
>>> root at dc2:/home/joachim# klist -k
/var/lib/samba/private/secrets.keytab
>>> Keytab name: FILE:/var/lib/samba/private/secrets.keytab
>>> KVNO Principal
>>> ----
--------------------------------------------------------------------------
>>>      1 HOST/dc2 at SAMBA.DOMAIN
>>>      1 HOST/dc2.samba.domain at SAMBA.DOMAIN
>>>      1 DC2$@SAMBA.DOMAIN
>>>      1 HOST/dc2 at SAMBA.DOMAIN
>>>      1 HOST/dc2.samba.domain at SAMBA.DOMAIN
>>>      1 DC2$@SAMBA.DOMAIN
>>>      1 HOST/dc2 at SAMBA.DOMAIN
>>>      1 HOST/dc2.samba.domain at SAMBA.DOMAIN
>>>      1 DC2$@SAMBA.DOMAIN
>>>      1 HOST/dc2 at SAMBA.DOMAIN
>>>      1 HOST/dc2.samba.domain at SAMBA.DOMAIN
>>>      1 DC2$@SAMBA.DOMAIN
>>>      1 HOST/dc2 at SAMBA.DOMAIN
>>>      1 HOST/dc2.samba.domain at SAMBA.DOMAIN
>>>      1 DC2$@SAMBA.DOMAIN
>>>
>>> Do I have to update some configuration path to point to that file?
Create a
>> link? Or what else to check?
>>>
>>>
>> Are you running an ntp server on each DC? if not, I suggest you do.
> I am running ntpd as a client. Why should I configure a server? Which Samba
or AD client uses an ntp server on a DC by default?
Well mine for one, time is important to AD, so if you set up the DC as 
an ntp server and your clients use this, your domain time will be correct.
>
>> How have you set up Bind, can you post your named.conf files.
> root at dc2:/home/joachim# cat /etc/bind/named.conf
> // This is the primary configuration file for the BIND DNS server named.
> //
> // Please read /usr/share/doc/bind9/README.Debian.gz for information on the
> // structure of BIND configuration files in Debian, *BEFORE* you customize
> // this configuration file.
> //
> // If you are just adding zones, please do that in
/etc/bind/named.conf.local
>
> include "/etc/bind/named.conf.options";
> include "/etc/bind/named.conf.local";
> include "/etc/bind/named.conf.default-zones";
> include "/etc/bind/bind.keys";
I do not have the last line.
>
> root at dc2:/home/joachim# cat /etc/bind/named.conf.options
> options {
>          directory "/var/cache/bind";
>
>          // If there is a firewall between you and nameservers you want
>          // to talk to, you may need to fix the firewall to allow multiple
>          // ports to talk.  See http://www.kb.cert.org/vuls/id/800113
>
>          // If your ISP provided one or more IP addresses for stable
>          // nameservers, you probably want to use them as forwarders.
>          // Uncomment the following block, and insert the addresses
replacing
>          // the all-0's placeholder.
>
>          forwarders {
>                  192.168.15.2;
>          };
>
>         
//=======================================================================>   
// If BIND logs error messages about the root key being expired,
>          // you will need to update your keys.  See
https://www.isc.org/bind-keys
>         
//=======================================================================>   
dnssec-validation no; #auto;
>
>          auth-nxdomain no;    # conform to RFC1035
> #       listen-on-v6 { any; };
>          allow-query-cache { any; };
>          allow-query { any; };
> # allow-recursion { any;192.168.0.0/16;localhost; };
>          allow-recursion { any; };
>          tkey-gssapi-keytab "/var/lib/samba/private/dns.keytab";
> };
Mine is:

options {
         auth-nxdomain yes;
         directory "/var/cache/bind";
         version "0.0.7";
         notify no;
         empty-zones-enable no;
         allow-query { 127.0.0.1; 192.168.0.0/24; };
         allow-recursion { 192.168.0.0/24; };
         forwarders { 8.8.8.8; 8.8.4.4; };
         allow-transfer { none; };
         dnssec-validation auto;

         listen-on-v6 { none; };
         listen-on port 53 { 192.168.0.5; 127.0.0.1; };
         tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab";
};
> root at dc2:/home/joachim# cat /etc/bind/named.conf.local
> //
> // Do any local configuration here
> //
>
> // Consider adding the 1918 zones here, if they are not used in your
> // organization
> //include "/etc/bind/zones.rfc1918";
>
> zone "domain" {
>          type master;
>          file "/etc/bind/lindenberg.one";
> #       allow-transfer { 192.168.177.8 };
>          allow-update { key rndc-key; };
> };
>
> include "/var/lib/samba/private/named.conf";
And mine is:

include "/usr/local/samba/private/named.conf";

It looks like you are trying to use flatfiles along with bind_dlz. I 
would suggest you remove this from named.conf.local:

zone "domain" {
         type master;
         file "/etc/bind/lindenberg.one";
#       allow-transfer { 192.168.177.8 };
         allow-update { key rndc-key; };
};

>
> I am ommitting named.conf.default-zones as I did not touch that. Note that
I do have a zone file for domain but it is not really used right now.
Samba.domain is obviously a subdomain served by Samba. And one extra you did not
ask for...
>
> root at dc2:/home/joachim# cat /var/lib/samba/private/named.conf
> # This DNS configuration is for BIND 9.8.0 or later with dlz_dlopen
support.
> #
> # This file should be included in your main BIND configuration file
> #
> # For example with
> # include "/var/lib/samba/private/named.conf";
>
> #
> # This configures dynamically loadable zones (DLZ) from AD schema
> # Uncomment only single database line, depending on your BIND version
> #
> dlz "AD DNS Zone" {
>      # For BIND 9.8.x
>      # database "dlopen
/usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9.so";
>
>      # For BIND 9.9.x
>      # database "dlopen
/usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_9.so";
>
>      # For BIND 9.10.x
>       database "dlopen
/usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_10.so";
> };
As long as you are using Bind 9.10, that should work.
>
> root at dc2:/home/joachim#
>
> I just also tried to replace the nonexisting dns.keytab with secrets.keytab
- then I get
> root at dc2:/home/joachim# tail /var/log/samba/log.samba
> [2016/06/05 19:16:29.377544,  0]
../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
>    /usr/sbin/samba_dnsupdate: update failed: REFUSED
> [2016/06/05 19:16:29.404010,  0]
../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
>    /usr/sbin/samba_dnsupdate: update failed: REFUSED
> [2016/06/05 19:16:29.430791,  0]
../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
>    /usr/sbin/samba_dnsupdate: update failed: REFUSED
> [2016/06/05 19:16:29.458506,  0]
../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
>    /usr/sbin/samba_dnsupdate: update failed: REFUSED
> [2016/06/05 19:16:29.472351,  0]
../source4/dsdb/dns/dns_update.c:294(dnsupdate_nameupdate_done)
>    ../source4/dsdb/dns/dns_update.c:294: Failed DNS update -
NT_STATUS_UNSUCCESSFUL
> root at dc2:/home/joachim#
>
> ...instead of the "TKEY is unacceptable" before.
Hmm, I compile Samba myself, so everything is in /usr/local/samba and in 
/usr/local/samba/private I have:

/usr/local/samba/private/dns.keytab
/usr/local/samba/private/secrets.keytab

So the question has to be, why haven't you got a 'dns.keytab', mine 
contains this:

root at dc1:~# ktutil
ktutil:  rkt /usr/local/samba/private/dns.keytab
ktutil:  l
slot KVNO Principal
---- ---- 
---------------------------------------------------------------------
    1    1 DNS/dc1.samdom.example.com at SAMDOM.EXAMPLE.COM
    2    1               dns-dc1 at SAMDOM.EXAMPLE.COM
    3    1 DNS/dc1.samdom.example.com at SAMDOM.EXAMPLE.COM
    4    1               dns-dc1 at SAMDOM.EXAMPLE.COM
    5    1 DNS/dc1.samdom.example.com at SAMDOM.EXAMPLE.COM
    6    1               dns-dc1 at SAMDOM.EXAMPLE.COM
    7    1 DNS/dc1.samdom.example.com at SAMDOM.EXAMPLE.COM
    8    1               dns-dc1 at SAMDOM.EXAMPLE.COM
    9    1 DNS/dc1.samdom.example.com at SAMDOM.EXAMPLE.COM
   10    1               dns-dc1 at SAMDOM.EXAMPLE.COM
ktutil:  q

Rowland

To regenerate dns.keytab I expect you only need to relaunch
samba_upgradedns --dns-backend=BIND9_DLZ.
If I'm wrong (it happens quiet often) you would have to first launch:
samba_upgradedns --dns-backend=SAMBA_INTERNAL
and then
samba_upgradedns --dns-backend=BIND9_DLZ

Here you should have a dns.keytab.

Now, right issues: dns related files in samba/private must be accessible to
the UNIX user running Bind process. That means changing rights on files and
on private (at least "x" permission to go through it).

And another note about 'islanding': this issue does not exist on recent
Samba. In fact I never had this issue with any of Samba version we tried,
and we tried almost all since 4.1.x (a big year). The issue wasn't there
when we tried to make Samba's internal DNS working (what we stopped) and is
not there also using Bind9+DLZ DNS backend.
Islanding (https://support.microsoft.com/en-us/kb/275278) is solved in MS
Windows Server 2012. It's a stupid bug from MS, they - as everyone - do
mistakes sometimes. Samba team also do mistakes sometimes, but that one
wasn't reproduced. Islanding does not exist with Samba AD DC.

Obviously you can use localhost as DNS resolver only once you have joined
the DC to the domain and after replication happened. Otherwise your new DC
will have empty DNS zones and so no reply.

If my English understanding is correct enough this was even told by Andrew
Bartlett in a mail from May the 26th around 20h20 UTC, the title was
"[Samba] DC2: TKEY is unacceptable, Failed DNS update?":
"Yes, it should use itself as the DNS server, once the initial
registration work is done."

2016-06-05 20:46 GMT+02:00 Rowland penny <rpenny at samba.org>:
> On 05/06/16 18:25, Jo wrote:
>
>> -----Ursprüngliche Nachricht-----
>>> Von: Rowland penny [mailto:rpenny at samba.org]
>>> Gesendet: Sonntag, 5. Juni 2016 17:46
>>> An: Jo <j.o.l at live.com>
>>> Cc: 'samba' <samba at lists.samba.org>
>>> Betreff: Re: AW: [Samba] inconsistent DNS information, windows
domain
>>> member issues..
>>>
>>> On 05/06/16 13:43, Jo wrote:
>>>
>>>> Your DCs really need to be running at all times, so that
replication
>>>>> can work properly, also each DC should use the other for
their DNS
>>>>> server, anything unknown to the DNS servers on the DCs
should be
>>>>> forwarded to an external DNS that does know or can find
out.
>>>>>
>>>> I understand that they need to be up simultaneously for
replication, but
>>>>
>>> otherwise that should not be the case. Or why? Imho the point of
>>> redundancy is that you can tolerate failure. In fact I would like
to run
>>> this on
>>> two bananas but haven´t found a usable distribution so far that
offers
>>> recent
>>> versions of Samba (and supports encryption at least of the relevant
>>> data).
>>> Running the windows hosts all the time is not an option due to
noise,
>>> energy
>>> consumption, etc.
>>>
>>> I take it that by 'bananas' you mean 'banana-pi',
this probably suffers
>>> from the same problems as the rpi, you will probably have to build
Samba
>>> yourself and it will probably be unable to cope with a lot of users
etc.
>>>
>> Compared to the Pi the Banana Pro is roughly twice as fast and has
>> gigabit network - it runs all my external networking (bind, nginx
reverse
>> proxies and websites) very well, but I am aware it slows down
communication
>> considerably if I proxy internal communication (file transfer) through
it.
>> For now I assume it should be OK for the number of users and systems I
plan
>> to connect, both in the order of 10-20, but the challenge is to get it
>> running in the first place and then sustainable (available, up to date,
>> secure, and with backups).
>>
>
> OK, it should be able to cope with that, it would be a different if you
> were talking 100-200 users etc
>
>
>
>> You need to understand that if you only have one DC running, it will
>>> keep trying to contact the other, and any changes made on the
running DC
>>> will need to be replicated to the other when it does come back up.
>>>
>>> The point of whether the DC should use the respective other DC for
DNS is
>>>>
>>> obviously debated here. The DCs do have an upstream forwarder
configured
>>> in bind.
>>>
>>> If you have two DCs, they need to use each other for DNS or you can
get
>>> what is called 'islanding'
>>>
>>> Can you please post  /etc/resolv.conf, /etc/hosts and
/etc/krb5.conf from
>>>>> each DC, can you also post the smb.conf file from each DC.
>>>>>
>>>>> joachim at dc1:~$ cat /etc/resolv.conf
>>>> # Dynamic resolv.conf(5) file for glibc resolver(3) generated
by
>>>>
>>> resolvconf(8)
>>>
>>>> #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE
>>>>
>>> OVERWRITTEN
>>>
>>>> nameserver 192.168.177.21
>>>> search samba.domain
>>>>
>>> It is not really a good idea to run 'resolvconf' on a fixed
ip machine
>>> (I take it the DCs do have fixed ipaddresses), I suggest you remove
it
>>> and then set /etc/resolv.conf to:
>>>
>>> nameserver 192.168.177.22
>>> nameserver 192.168.177.21
>>> search samba.domain
>>>
>>> Switch the 'nameserver' lines for the second DC
>>>
>> Sorry, reminds me about asking for legal advice. Ask two lawyers, get
>> three opinions, of course conflicting. Afaik the recommended way on
Ubuntu
>> is to put the configuration in /etc/network/interfaces:
>> # The primary network interface
>> auto enp0s3
>> iface enp0s3 inet static
>>          address 192.168.15.22
>>          netmask 255.255.255.0
>>          gateway 192.168.15.1
>>          dns-nameservers 192.168.15.22
>>          dns-search samba.lindenberg.one
>>
>
> and mine is:
>
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
>
> # The loopback network interface
> auto lo
> iface lo inet loopback
>
> # The primary network interface
> allow-hotplug eth0
> iface eth0 inet static
>     address 192.168.0.5
>     netmask 255.255.255.0
>     network 192.168.0.0
>     broadcast 192.168.0.255
>     gateway 192.168.0.1
>
> Just because Ubuntu puts nameservers in there doesn't mean you have to,
> but it is your domain and you get to make your own decisions.
>
>
>> ...and I prefer to keep configuration as local as possible, especially
as
>> occasionally I need to move systems from one location to the other.
With
>> respect to the islands issue Andrew recommended to use the DC on the
DC. I
>> am aware of the monitoring issue, but I definitely expect less updates
to
>> the DC contents then outages of the network in between. And for my
>> experiments I can wake them explicitly as needed.
>>
>
> He seems to be by himself there, even Microsoft don't recommend using
the
> DC for its own DNS.
>
>
>
>> joachim at dc1:~$ cat /etc/hosts
>>>> 127.0.0.1       localhost
>>>> 192.168.177.21  dc1 dc1.samba.domain
>>>> 192.168.15.22   dc2 dc2.samba.domain
>>>>
>>>> # The following lines are desirable for IPv6 capable hosts
>>>> #::1     localhost ip6-localhost ip6-loopback
>>>> #ff02::1 ip6-allnodes
>>>> #ff02::2 ip6-allrouters
>>>>
>>> nothing wrong there, except you don't need the line for the
other DC
>>>
>> The line for the other DC helps with digging both for comparisions...
>>
>> joachim at dc1:~$ cat /etc/krb5.conf
>>>> [libdefaults]
>>>>           default_realm = SAMBA.DOMAIN
>>>>
>>>> # The following krb5.conf variables are only for MIT Kerberos.
>>>>           krb4_config = /etc/krb.conf
>>>>           krb4_realms = /etc/krb.realms
>>>>           kdc_timesync = 1
>>>>           ccache_type = 4
>>>>           forwardable = true
>>>>           proxiable = true
>>>>
>>>> # The following encryption type specification will be used by
MIT
>>>> Kerberos
>>>> # if uncommented.  In general, the defaults in the MIT Kerberos
code are
>>>> # correct and overriding these specifications only serves to
disable new
>>>> # encryption types as they are added, creating interoperability
>>>> problems.
>>>> #
>>>> # Thie only time when you might need to uncomment these lines
and
>>>>
>>> change
>>>
>>>> # the enctypes is if you have local software that will break on
ticket
>>>> # caches containing ticket encryption types it doesn't know
about (such
>>>> as
>>>> # old versions of Sun Java).
>>>>
>>>> #       default_tgs_enctypes = des3-hmac-sha1
>>>> #       default_tkt_enctypes = des3-hmac-sha1
>>>> #       permitted_enctypes = des3-hmac-sha1
>>>>
>>>> # The following libdefaults parameters are only for Heimdal
Kerberos.
>>>>           v4_instance_resolve = false
>>>>           v4_name_convert = {
>>>>                   host = {
>>>>                           rcmd = host
>>>>                           ftp = ftp
>>>>                   }
>>>>                   plain = {
>>>>                           something = something-else
>>>>                   }
>>>>           }
>>>>           fcc-mit-ticketflags = true
>>>>
>>>> [realms]
>>>>           ATHENA.MIT.EDU = {
>>>>                   kdc = kerberos.mit.edu:88
>>>>                   kdc = kerberos-1.mit.edu:88
>>>>                   kdc = kerberos-2.mit.edu:88
>>>>                   admin_server = kerberos.mit.edu
>>>>                   default_domain = mit.edu
>>>>           }
>>>>           MEDIA-LAB.MIT.EDU = {
>>>>                   kdc = kerberos.media.mit.edu
>>>>                   admin_server = kerberos.media.mit.edu
>>>>           }
>>>>           ZONE.MIT.EDU = {
>>>>                   kdc = casio.mit.edu
>>>>                   kdc = seiko.mit.edu
>>>>                   admin_server = casio.mit.edu
>>>>           }
>>>>           MOOF.MIT.EDU = {
>>>>                   kdc = three-headed-dogcow.mit.edu:88
>>>>                   kdc = three-headed-dogcow-1.mit.edu:88
>>>>                   admin_server = three-headed-dogcow.mit.edu
>>>>           }
>>>>           CSAIL.MIT.EDU = {
>>>>                   kdc = kerberos-1.csail.mit.edu
>>>>                   kdc = kerberos-2.csail.mit.edu
>>>>                   admin_server = kerberos.csail.mit.edu
>>>>                   default_domain = csail.mit.edu
>>>>                   krb524_server = krb524.csail.mit.edu
>>>>           }
>>>>           IHTFP.ORG = {
>>>>                   kdc = kerberos.ihtfp.org
>>>>                   admin_server = kerberos.ihtfp.org
>>>>           }
>>>>           GNU.ORG = {
>>>>                   kdc = kerberos.gnu.org
>>>>                   kdc = kerberos-2.gnu.org
>>>>                   kdc = kerberos-3.gnu.org
>>>>                   admin_server = kerberos.gnu.org
>>>>           }
>>>>           1TS.ORG = {
>>>>                   kdc = kerberos.1ts.org
>>>>                   admin_server = kerberos.1ts.org
>>>>           }
>>>>           GRATUITOUS.ORG = {
>>>>                   kdc = kerberos.gratuitous.org
>>>>                   admin_server = kerberos.gratuitous.org
>>>>           }
>>>>           DOOMCOM.ORG = {
>>>>                   kdc = kerberos.doomcom.org
>>>>                   admin_server = kerberos.doomcom.org
>>>>           }
>>>>           ANDREW.CMU.EDU = {
>>>>                   kdc = kerberos.andrew.cmu.edu
>>>>                   kdc = kerberos2.andrew.cmu.edu
>>>>                   kdc = kerberos3.andrew.cmu.edu
>>>>                   admin_server = kerberos.andrew.cmu.edu
>>>>                   default_domain = andrew.cmu.edu
>>>>           }
>>>>           CS.CMU.EDU = {
>>>>                   kdc = kerberos.cs.cmu.edu
>>>>                   kdc = kerberos-2.srv.cs.cmu.edu
>>>>                   admin_server = kerberos.cs.cmu.edu
>>>>           }
>>>>           DEMENTIA.ORG = {
>>>>                   kdc = kerberos.dementix.org
>>>>                   kdc = kerberos2.dementix.org
>>>>                   admin_server = kerberos.dementix.org
>>>>           }
>>>>           stanford.edu = {
>>>>                   kdc = krb5auth1.stanford.edu
>>>>                   kdc = krb5auth2.stanford.edu
>>>>                   kdc = krb5auth3.stanford.edu
>>>>                   master_kdc = krb5auth1.stanford.edu
>>>>                   admin_server = krb5-admin.stanford.edu
>>>>                   default_domain = stanford.edu
>>>>           }
>>>>           UTORONTO.CA = {
>>>>                   kdc = kerberos1.utoronto.ca
>>>>                   kdc = kerberos2.utoronto.ca
>>>>                   kdc = kerberos3.utoronto.ca
>>>>                   admin_server = kerberos1.utoronto.ca
>>>>                   default_domain = utoronto.ca
>>>>           }
>>>>
>>>> [domain_realm]
>>>>           .mit.edu = ATHENA.MIT.EDU
>>>>           mit.edu = ATHENA.MIT.EDU
>>>>           .media.mit.edu = MEDIA-LAB.MIT.EDU
>>>>           media.mit.edu = MEDIA-LAB.MIT.EDU
>>>>           .csail.mit.edu = CSAIL.MIT.EDU
>>>>           csail.mit.edu = CSAIL.MIT.EDU
>>>>           .whoi.edu = ATHENA.MIT.EDU
>>>>           whoi.edu = ATHENA.MIT.EDU
>>>>           .stanford.edu = stanford.edu
>>>>           .slac.stanford.edu = SLAC.STANFORD.EDU
>>>>           .toronto.edu = UTORONTO.CA
>>>>           .utoronto.ca = UTORONTO.CA
>>>>
>>>> [login]
>>>>           krb4_convert = true
>>>>           krb4_get_tickets = false
>>>>
>>> Here's the thing, your /etc/krb5.conf only needs to look like
this:
>>>
>>> [libdefaults]
>>>           default_realm = SAMBA.DOMAIN
>>>
>>> Everything else is unneeded or the default.
>>>
>> Which explains why it worked without defining the domain on DC1. OK, I
>> removed the garbage...
>>
>> joachim at dc1:~$ cat /etc/samba/smb.conf
>>>> # Global parameters
>>>> [global]
>>>>           workgroup = SAMBA
>>>>           realm = SAMBA.DOMAIN
>>>>           netbios name = DC1
>>>>           server role = active directory domain controller
>>>>           server services = s3fs, rpc, nbt, wrepl, ldap, cldap,
kdc,
>>>> drepl,
>>>>
>>> winbindd, ntp_signd, kcc, dnsupdate
>>>
>>>>           idmap_ldb:use rfc2307 = yes
>>>>
>>>> [netlogon]
>>>>           path = /var/lib/samba/sysvol/samba.domain/scripts
>>>>           read only = No
>>>>
>>>> [sysvol]
>>>>           path = /var/lib/samba/sysvol
>>>>           read only = No
>>>> joachim at dc1:~$
>>>>
>>> This looks ok.
>>>
>>> The files on the second DC should be similar to the first, except
for
>>> the obvious name & ip changes.
>>>
>>>
>>>>
>>>> One new piece of mosaic:
>>>>
>>>> root at dc2:/home/joachim# tail /var/log/samba/log.samba
>>>> [2016/06/05 14:28:12.674356,  0]
>>>>
>>> ../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
>>>
>>>>     /usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is
>>>>
>>> unacceptable
>>>
>>>> [2016/06/05 14:28:12.697076,  0]
>>>>
>>> ../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
>>>
>>>>     /usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is
>>>>
>>> unacceptable
>>>
>>>> [2016/06/05 14:28:12.719968,  0]
>>>>
>>> ../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
>>>
>>>>     /usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is
>>>>
>>> unacceptable
>>>
>>>> [2016/06/05 14:28:12.743569,  0]
>>>>
>>> ../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
>>>
>>>>     /usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is
>>>>
>>> unacceptable
>>>
>>>> [2016/06/05 14:28:12.756246,  0]
>>>>
>>> ../source4/dsdb/dns/dns_update.c:294(dnsupdate_nameupdate_done)
>>>
>>>>     ../source4/dsdb/dns/dns_update.c:294: Failed DNS update -
>>>>
>>> NT_STATUS_UNSUCCESSFUL
>>>
>>>> root at dc2:/home/joachim#
>>>>
>>>> I tried to follow
>>>>
>>>
https://wiki.samba.org/index.php/Dns_tkey_negotiategss:_TKEY_is_unaccep
>>> table, but may be that is outdated? I found a keytab file at
>>> /var/lib/samba/private/secrets.keytab and it contains what is
described
>>> on
>>> the wiki page:
>>>
>>>> root at dc2:/home/joachim# klist -k
/var/lib/samba/private/secrets.keytab
>>>> Keytab name: FILE:/var/lib/samba/private/secrets.keytab
>>>> KVNO Principal
>>>> ----
>>>>
--------------------------------------------------------------------------
>>>>      1 HOST/dc2 at SAMBA.DOMAIN
>>>>      1 HOST/dc2.samba.domain at SAMBA.DOMAIN
>>>>      1 DC2$@SAMBA.DOMAIN
>>>>      1 HOST/dc2 at SAMBA.DOMAIN
>>>>      1 HOST/dc2.samba.domain at SAMBA.DOMAIN
>>>>      1 DC2$@SAMBA.DOMAIN
>>>>      1 HOST/dc2 at SAMBA.DOMAIN
>>>>      1 HOST/dc2.samba.domain at SAMBA.DOMAIN
>>>>      1 DC2$@SAMBA.DOMAIN
>>>>      1 HOST/dc2 at SAMBA.DOMAIN
>>>>      1 HOST/dc2.samba.domain at SAMBA.DOMAIN
>>>>      1 DC2$@SAMBA.DOMAIN
>>>>      1 HOST/dc2 at SAMBA.DOMAIN
>>>>      1 HOST/dc2.samba.domain at SAMBA.DOMAIN
>>>>      1 DC2$@SAMBA.DOMAIN
>>>>
>>>> Do I have to update some configuration path to point to that
file?
>>>> Create a
>>>>
>>> link? Or what else to check?
>>>
>>>>
>>>>
>>>> Are you running an ntp server on each DC? if not, I suggest you
do.
>>>
>> I am running ntpd as a client. Why should I configure a server? Which
>> Samba or AD client uses an ntp server on a DC by default?
>>
>
> Well mine for one, time is important to AD, so if you set up the DC as an
> ntp server and your clients use this, your domain time will be correct.
>
>
>> How have you set up Bind, can you post your named.conf files.
>>>
>> root at dc2:/home/joachim# cat /etc/bind/named.conf
>> // This is the primary configuration file for the BIND DNS server
named.
>> //
>> // Please read /usr/share/doc/bind9/README.Debian.gz for information on
>> the
>> // structure of BIND configuration files in Debian, *BEFORE* you
customize
>> // this configuration file.
>> //
>> // If you are just adding zones, please do that in
>> /etc/bind/named.conf.local
>>
>> include "/etc/bind/named.conf.options";
>> include "/etc/bind/named.conf.local";
>> include "/etc/bind/named.conf.default-zones";
>> include "/etc/bind/bind.keys";
>>
>
> I do not have the last line.
>
>
>> root at dc2:/home/joachim# cat /etc/bind/named.conf.options
>> options {
>>          directory "/var/cache/bind";
>>
>>          // If there is a firewall between you and nameservers you want
>>          // to talk to, you may need to fix the firewall to allow
multiple
>>          // ports to talk.  See http://www.kb.cert.org/vuls/id/800113
>>
>>          // If your ISP provided one or more IP addresses for stable
>>          // nameservers, you probably want to use them as forwarders.
>>          // Uncomment the following block, and insert the addresses
>> replacing
>>          // the all-0's placeholder.
>>
>>          forwarders {
>>                  192.168.15.2;
>>          };
>>
>>
>> 
//=======================================================================>>
// If BIND logs error messages about the root key being expired,
>>          // you will need to update your keys.  See
>> https://www.isc.org/bind-keys
>>
>> 
//=======================================================================>>
dnssec-validation no; #auto;
>>
>>          auth-nxdomain no;    # conform to RFC1035
>> #       listen-on-v6 { any; };
>>          allow-query-cache { any; };
>>          allow-query { any; };
>> # allow-recursion { any;192.168.0.0/16;localhost; };
>>          allow-recursion { any; };
>>          tkey-gssapi-keytab
"/var/lib/samba/private/dns.keytab";
>> };
>>
>
> Mine is:
>
> options {
>         auth-nxdomain yes;
>         directory "/var/cache/bind";
>         version "0.0.7";
>         notify no;
>         empty-zones-enable no;
>         allow-query { 127.0.0.1; 192.168.0.0/24; };
>         allow-recursion { 192.168.0.0/24; };
>         forwarders { 8.8.8.8; 8.8.4.4; };
>         allow-transfer { none; };
>         dnssec-validation auto;
>
>         listen-on-v6 { none; };
>         listen-on port 53 { 192.168.0.5; 127.0.0.1; };
>         tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab";
> };
>
> root at dc2:/home/joachim# cat /etc/bind/named.conf.local
>> //
>> // Do any local configuration here
>> //
>>
>> // Consider adding the 1918 zones here, if they are not used in your
>> // organization
>> //include "/etc/bind/zones.rfc1918";
>>
>> zone "domain" {
>>          type master;
>>          file "/etc/bind/lindenberg.one";
>> #       allow-transfer { 192.168.177.8 };
>>          allow-update { key rndc-key; };
>> };
>>
>> include "/var/lib/samba/private/named.conf";
>>
>
> And mine is:
>
> include "/usr/local/samba/private/named.conf";
>
> It looks like you are trying to use flatfiles along with bind_dlz. I would
> suggest you remove this from named.conf.local:
>
> zone "domain" {
>         type master;
>         file "/etc/bind/lindenberg.one";
> #       allow-transfer { 192.168.177.8 };
>         allow-update { key rndc-key; };
> };
>
>
>
>> I am ommitting named.conf.default-zones as I did not touch that. Note
>> that I do have a zone file for domain but it is not really used right
now.
>> Samba.domain is obviously a subdomain served by Samba. And one extra
you
>> did not ask for...
>>
>> root at dc2:/home/joachim# cat /var/lib/samba/private/named.conf
>> # This DNS configuration is for BIND 9.8.0 or later with dlz_dlopen
>> support.
>> #
>> # This file should be included in your main BIND configuration file
>> #
>> # For example with
>> # include "/var/lib/samba/private/named.conf";
>>
>> #
>> # This configures dynamically loadable zones (DLZ) from AD schema
>> # Uncomment only single database line, depending on your BIND version
>> #
>> dlz "AD DNS Zone" {
>>      # For BIND 9.8.x
>>      # database "dlopen
>> /usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9.so";
>>
>>      # For BIND 9.9.x
>>      # database "dlopen
>> /usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_9.so";
>>
>>      # For BIND 9.10.x
>>       database "dlopen
>> /usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_10.so";
>> };
>>
>
> As long as you are using Bind 9.10, that should work.
>
>
>> root at dc2:/home/joachim#
>>
>> I just also tried to replace the nonexisting dns.keytab with
>> secrets.keytab - then I get
>> root at dc2:/home/joachim# tail /var/log/samba/log.samba
>> [2016/06/05 19:16:29.377544,  0]
>> ../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
>>    /usr/sbin/samba_dnsupdate: update failed: REFUSED
>> [2016/06/05 19:16:29.404010,  0]
>> ../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
>>    /usr/sbin/samba_dnsupdate: update failed: REFUSED
>> [2016/06/05 19:16:29.430791,  0]
>> ../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
>>    /usr/sbin/samba_dnsupdate: update failed: REFUSED
>> [2016/06/05 19:16:29.458506,  0]
>> ../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
>>    /usr/sbin/samba_dnsupdate: update failed: REFUSED
>> [2016/06/05 19:16:29.472351,  0]
>> ../source4/dsdb/dns/dns_update.c:294(dnsupdate_nameupdate_done)
>>    ../source4/dsdb/dns/dns_update.c:294: Failed DNS update -
>> NT_STATUS_UNSUCCESSFUL
>> root at dc2:/home/joachim#
>>
>> ...instead of the "TKEY is unacceptable" before.
>>
>
> Hmm, I compile Samba myself, so everything is in /usr/local/samba and in
> /usr/local/samba/private I have:
>
> /usr/local/samba/private/dns.keytab
> /usr/local/samba/private/secrets.keytab
>
> So the question has to be, why haven't you got a 'dns.keytab',
mine
> contains this:
>
> root at dc1:~# ktutil
> ktutil:  rkt /usr/local/samba/private/dns.keytab
> ktutil:  l
> slot KVNO Principal
> ---- ----
> ---------------------------------------------------------------------
>    1    1 DNS/dc1.samdom.example.com at SAMDOM.EXAMPLE.COM
>    2    1               dns-dc1 at SAMDOM.EXAMPLE.COM
>    3    1 DNS/dc1.samdom.example.com at SAMDOM.EXAMPLE.COM
>    4    1               dns-dc1 at SAMDOM.EXAMPLE.COM
>    5    1 DNS/dc1.samdom.example.com at SAMDOM.EXAMPLE.COM
>    6    1               dns-dc1 at SAMDOM.EXAMPLE.COM
>    7    1 DNS/dc1.samdom.example.com at SAMDOM.EXAMPLE.COM
>    8    1               dns-dc1 at SAMDOM.EXAMPLE.COM
>    9    1 DNS/dc1.samdom.example.com at SAMDOM.EXAMPLE.COM
>   10    1               dns-dc1 at SAMDOM.EXAMPLE.COM
> ktutil:  q
>
>
> Rowland
>
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>