Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[Samba] inconsistent DNS information, windows domain member issues..
443 views
Skip to first unread message
Jo
Jun 5, 2016, 5:20:02 AM6/5/16
to
I joined a Windows 10 Pro system to my (still experimental) domain. The
windows system actually hosts DC2 as a VM, and another Windows (Server 2008
R2) at another location hosts DC1 also as a VM. The two locations are
connected via a VPN, both systems run only when needed. The windows system
does not directly use DC2 for DNS but instead talks to a DNS resolver that
delegates the samba Domain to DC2. DC2 uses itself as nameserver.
I am observing the following issues that may be related or not:
* When I do a nslookup samba.domain DC2 I get the address of DC1,
nslookup DC2.sambadomain DC2 fails. Nslookup DC1.samba.domain DC2 works.
When I use dig @DC2 samba.domain it returns DC1 only. Dig samba.domain ANY
returns
;; ANSWER SECTION:
samba.domain. 3600 IN SOA dc2.samba. domain. hostmaster.samba.
domain. 1 900 600 86400 3600
samba. domain. 900 IN NS dc1.samba. domain.
samba. domain. 900 IN A 192.168.177.21
;; ADDITIONAL SECTION:
dc1.samba. domain. 900 IN A 192.168.177.21
Same information @DC2 or the local resolver of the network
* On windows nslookup -type=ANY samba.domain. (note the .)
Server: netgear.local
Address: 192.168.15.2
samba.domain
primary name server = dc2.samba. domain
responsible mail addr = hostmaster.samba.domain
serial = 1
refresh = 900 (15 mins)
retry = 600 (10 mins)
expire = 86400 (1 day)
default TTL = 3600 (1 hour)
samba. domain nameserver = dc1.samba. domain
samba. domain internet address = 192.168.177.21
dc1.samba. domain internet address = 192.168.177.21
* windows nslookup -type=ANY samba.domain (without .) looks for
samba.domain.domain. Is this OK or does it point to a problematic search
configuration?
* When I use the DNS mmc snap-in I can see a host record for dc2. I
can also see a host record for the windows system reflecting the IP address
before the system moved to the other location. I tried to update that, but
got an error message (translated from German) like “the database of the
local security authority is internally inconsistent”. The snap-in is ultra
slow via VPN, but what makes me more nervous are the to me inconsistent
views on the DNS – nslookup showing DC2, mmc showing DC1 as the NS.
* In windows management console, only some of the domain
users&principals are shown with the name domain\identity, most of them are
shown S-xxx. With the one use shown domain\user I can logon to the windows
system however (likely with cached credentials, but don´t dare to change
them to confirm)
* When I try to modify folder permissions on the windows system, I get
a message “Unable to contact Active Directory to access or verify claim
types”
* On DC2: kinit Administrator returns “kinit: Cannot contact any KDC
for realm ‘samba.domain’ while getting initial credentials. This one was
easy to fix by adding the domain to /etc/krb5.conf. I am putting this in as
I changed configuration at this point..
* In an attempt to get Samba return DC2 as a nameserver I tried
samba-tool dns add dc2 samba.domain @ NS dc2.samba.domain.
Password for [Admini...@SAMBA.DOMAIN]:
ERROR(runtime): uncaught exception - (-1073741643, '{Device Timeout} The
specified I/O operation on %hs was not completed before the time-out period
expired.')
File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py", line
175, in _run
return self.run(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/samba/netcmd/dns.py", line 1062, in
run
dns_conn = dns_connect(server, self.lp, self.creds)
File "/usr/lib/python2.7/dist-packages/samba/netcmd/dns.py", line 40, in
dns_connect
dns_conn = dnsserver.dnsserver(binding_str, lp, creds)
in another attempt the command produced “Record added successfully”, but
using dig or nslookup I cannot find it. It is shown in the DNS mmc snap-in
(at least now). Restarting bind did not help.
* Following
https://wiki.samba.org/index.php/Check_and_fix_DNS_entries_on_DC_joins I
tried
root@dc2:/etc/bind# samba-tool dns add dc1 samba.domain DC2 A 192.168.15.22
-UAdministrator
Password for [SAMBA\Administrator]:
ERROR: Record already exists
root@dc2:/etc/bind# samba-tool dns add dc2 samba.domain DC2 A 192.168.15.22
-UAdministrator
Password for [SAMBA\Administrator]:
ERROR: Record already exists
root@dc2:/etc/bind# host -t A DC2.samba.domain
Host DC2.samba.lindenberg.one not found: 3(NXDOMAIN)
How should I proceed there?
I don´t know how to fix the inconsistent DNS entries and get windows to
work. Please advise.
Thanks, Joachim
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
windows system actually hosts DC2 as a VM, and another Windows (Server 2008
R2) at another location hosts DC1 also as a VM. The two locations are
connected via a VPN, both systems run only when needed. The windows system
does not directly use DC2 for DNS but instead talks to a DNS resolver that
delegates the samba Domain to DC2. DC2 uses itself as nameserver.
I am observing the following issues that may be related or not:
* When I do a nslookup samba.domain DC2 I get the address of DC1,
nslookup DC2.sambadomain DC2 fails. Nslookup DC1.samba.domain DC2 works.
When I use dig @DC2 samba.domain it returns DC1 only. Dig samba.domain ANY
returns
;; ANSWER SECTION:
samba.domain. 3600 IN SOA dc2.samba. domain. hostmaster.samba.
domain. 1 900 600 86400 3600
samba. domain. 900 IN NS dc1.samba. domain.
samba. domain. 900 IN A 192.168.177.21
;; ADDITIONAL SECTION:
dc1.samba. domain. 900 IN A 192.168.177.21
Same information @DC2 or the local resolver of the network
* On windows nslookup -type=ANY samba.domain. (note the .)
Server: netgear.local
Address: 192.168.15.2
samba.domain
primary name server = dc2.samba. domain
responsible mail addr = hostmaster.samba.domain
serial = 1
refresh = 900 (15 mins)
retry = 600 (10 mins)
expire = 86400 (1 day)
default TTL = 3600 (1 hour)
samba. domain nameserver = dc1.samba. domain
samba. domain internet address = 192.168.177.21
dc1.samba. domain internet address = 192.168.177.21
* windows nslookup -type=ANY samba.domain (without .) looks for
samba.domain.domain. Is this OK or does it point to a problematic search
configuration?
* When I use the DNS mmc snap-in I can see a host record for dc2. I
can also see a host record for the windows system reflecting the IP address
before the system moved to the other location. I tried to update that, but
got an error message (translated from German) like “the database of the
local security authority is internally inconsistent”. The snap-in is ultra
slow via VPN, but what makes me more nervous are the to me inconsistent
views on the DNS – nslookup showing DC2, mmc showing DC1 as the NS.
* In windows management console, only some of the domain
users&principals are shown with the name domain\identity, most of them are
shown S-xxx. With the one use shown domain\user I can logon to the windows
system however (likely with cached credentials, but don´t dare to change
them to confirm)
* When I try to modify folder permissions on the windows system, I get
a message “Unable to contact Active Directory to access or verify claim
types”
* On DC2: kinit Administrator returns “kinit: Cannot contact any KDC
for realm ‘samba.domain’ while getting initial credentials. This one was
easy to fix by adding the domain to /etc/krb5.conf. I am putting this in as
I changed configuration at this point..
* In an attempt to get Samba return DC2 as a nameserver I tried
samba-tool dns add dc2 samba.domain @ NS dc2.samba.domain.
Password for [Admini...@SAMBA.DOMAIN]:
ERROR(runtime): uncaught exception - (-1073741643, '{Device Timeout} The
specified I/O operation on %hs was not completed before the time-out period
expired.')
File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py", line
175, in _run
return self.run(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/samba/netcmd/dns.py", line 1062, in
run
dns_conn = dns_connect(server, self.lp, self.creds)
File "/usr/lib/python2.7/dist-packages/samba/netcmd/dns.py", line 40, in
dns_connect
dns_conn = dnsserver.dnsserver(binding_str, lp, creds)
in another attempt the command produced “Record added successfully”, but
using dig or nslookup I cannot find it. It is shown in the DNS mmc snap-in
(at least now). Restarting bind did not help.
* Following
https://wiki.samba.org/index.php/Check_and_fix_DNS_entries_on_DC_joins I
tried
root@dc2:/etc/bind# samba-tool dns add dc1 samba.domain DC2 A 192.168.15.22
-UAdministrator
Password for [SAMBA\Administrator]:
ERROR: Record already exists
root@dc2:/etc/bind# samba-tool dns add dc2 samba.domain DC2 A 192.168.15.22
-UAdministrator
Password for [SAMBA\Administrator]:
ERROR: Record already exists
root@dc2:/etc/bind# host -t A DC2.samba.domain
Host DC2.samba.lindenberg.one not found: 3(NXDOMAIN)
How should I proceed there?
I don´t know how to fix the inconsistent DNS entries and get windows to
work. Please advise.
Thanks, Joachim
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
Rowland penny
Jun 5, 2016, 7:00:03 AM6/5/16
to
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.
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.
Rowland
Jo
Jun 5, 2016, 8:50:02 AM6/5/16
to
> -----Ursprüngliche Nachricht-----
> Von: samba [mailto:samba-...@lists.samba.org] Im Auftrag von
> Rowland penny
> Gesendet: Sonntag, 5. Juni 2016 12:49
> An: sa...@lists.samba.org
> Betreff: Re: [Samba] inconsistent DNS information, windows domain
> member issues..
Yes and yes.
>
> 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.
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.
>
> 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@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
joachim@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
joachim@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
joachim@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@dc1:~$
I detected that in krb5.conf the real was missing and added that now. Not sure whether this changes something.
joachim@dc2:~$ 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.15.22
search samba.domain
joachim@dc2:~$ cat /etc/hosts
127.0.0.1 localhost
192.168.15.22 dc2 dc2.samba.domain
192.168.177.21 dc1 dc1.samba.domain
joachim@dc2:~$ 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]
SAMBA.domain = {
kdc = dc2.samba.domain:88
kdc = dc1.samba.domain:88
admin_server = dc1.samba.domain
}
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
joachim@dc2:~$ cat /etc/samba/smb.conf
# Global parameters
[global]
workgroup = SAMBA
realm = samba.domain
netbios name = DC2
server role = active directory domain controller
server services = rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate, smb
dcerpc endpoint servers = epmapper, wkssvc, rpcecho, samr, netlogon, lsarpc, spoolss, drsuapi, dssetup, unixinfo, browser, eventlog6, backupkey, dnsserver, winreg, srvsvc
[netlogon]
path = /var/lib/samba/sysvol/samba.domain/scripts
read only = No
[sysvol]
path = /var/lib/samba/sysvol
read only = No
joachim@dc2:~$
One new piece of mosaic:
root@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@dc2:/home/joachim#
I tried to follow https://wiki.samba.org/index.php/Dns_tkey_negotiategss:_TKEY_is_unacceptable, 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@dc2:/home/joachim# klist -k /var/lib/samba/private/secrets.keytab
Keytab name: FILE:/var/lib/samba/private/secrets.keytab
KVNO Principal
---- --------------------------------------------------------------------------
1 HOST/d...@SAMBA.DOMAIN
1 HOST/dc2.samb...@SAMBA.DOMAIN
1 DC2$@SAMBA.DOMAIN
1 HOST/d...@SAMBA.DOMAIN
1 HOST/dc2.samb...@SAMBA.DOMAIN
1 DC2$@SAMBA.DOMAIN
1 HOST/d...@SAMBA.DOMAIN
1 HOST/dc2.samb...@SAMBA.DOMAIN
1 DC2$@SAMBA.DOMAIN
1 HOST/d...@SAMBA.DOMAIN
1 HOST/dc2.samb...@SAMBA.DOMAIN
1 DC2$@SAMBA.DOMAIN
1 HOST/d...@SAMBA.DOMAIN
1 HOST/dc2.samb...@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?
Thanks, Joachim
> Von: samba [mailto:samba-...@lists.samba.org] Im Auftrag von
> Rowland penny
> Gesendet: Sonntag, 5. Juni 2016 12:49
> An: sa...@lists.samba.org
> Betreff: Re: [Samba] inconsistent DNS information, windows domain
> member issues..
>
> 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.
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.
>
> 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.
>
# 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
joachim@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
joachim@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
joachim@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@dc1:~$
I detected that in krb5.conf the real was missing and added that now. Not sure whether this changes something.
joachim@dc2:~$ 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.15.22
search samba.domain
joachim@dc2:~$ cat /etc/hosts
127.0.0.1 localhost
192.168.15.22 dc2 dc2.samba.domain
192.168.177.21 dc1 dc1.samba.domain
joachim@dc2:~$ 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]
SAMBA.domain = {
kdc = dc2.samba.domain:88
kdc = dc1.samba.domain:88
admin_server = dc1.samba.domain
}
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
joachim@dc2:~$ cat /etc/samba/smb.conf
# Global parameters
[global]
workgroup = SAMBA
realm = samba.domain
netbios name = DC2
server role = active directory domain controller
server services = rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate, smb
dcerpc endpoint servers = epmapper, wkssvc, rpcecho, samr, netlogon, lsarpc, spoolss, drsuapi, dssetup, unixinfo, browser, eventlog6, backupkey, dnsserver, winreg, srvsvc
[netlogon]
path = /var/lib/samba/sysvol/samba.domain/scripts
read only = No
[sysvol]
path = /var/lib/samba/sysvol
read only = No
joachim@dc2:~$
One new piece of mosaic:
root@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@dc2:/home/joachim#
I tried to follow https://wiki.samba.org/index.php/Dns_tkey_negotiategss:_TKEY_is_unacceptable, 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@dc2:/home/joachim# klist -k /var/lib/samba/private/secrets.keytab
Keytab name: FILE:/var/lib/samba/private/secrets.keytab
KVNO Principal
---- --------------------------------------------------------------------------
1 HOST/d...@SAMBA.DOMAIN
1 HOST/dc2.samb...@SAMBA.DOMAIN
1 DC2$@SAMBA.DOMAIN
1 HOST/d...@SAMBA.DOMAIN
1 HOST/dc2.samb...@SAMBA.DOMAIN
1 DC2$@SAMBA.DOMAIN
1 HOST/d...@SAMBA.DOMAIN
1 HOST/dc2.samb...@SAMBA.DOMAIN
1 DC2$@SAMBA.DOMAIN
1 HOST/d...@SAMBA.DOMAIN
1 HOST/dc2.samb...@SAMBA.DOMAIN
1 DC2$@SAMBA.DOMAIN
1 HOST/d...@SAMBA.DOMAIN
1 HOST/dc2.samb...@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?
Thanks, Joachim
Rowland penny
Jun 5, 2016, 11:50:03 AM6/5/16
to
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
>> 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.
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.
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.
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@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
(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
> joachim@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
[libdefaults]
default_realm = SAMBA.DOMAIN
Everything else is unneeded or the default.
> joachim@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@dc1:~$
The files on the second DC should be similar to the first, except for
the obvious name & ip changes.
How have you set up Bind, can you post your named.conf files.
Jo
Jun 5, 2016, 1:30:03 PM6/5/16
to
> -----Ursprüngliche Nachricht-----
> Von: Rowland penny [mailto:rpe...@samba.org]
> Gesendet: Sonntag, 5. Juni 2016 17:46
> An: Jo <j....@live.com>
> Cc: 'samba' <sa...@lists.samba.org>
> Betreff: Re: AW: [Samba] inconsistent DNS information, windows domain
> member issues..
>
>
> 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@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@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...
Which explains why it worked without defining the domain on DC1. OK, I removed the garbage...
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@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@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@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@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@dc2:/home/joachim#
I just also tried to replace the nonexisting dns.keytab with secrets.keytab - then I get
root@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)
> Von: Rowland penny [mailto:rpe...@samba.org]
> Gesendet: Sonntag, 5. Juni 2016 17:46
> An: Jo <j....@live.com>
> Cc: 'samba' <sa...@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).
> >> 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.
>
> 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@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
# 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@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
>
> How have you set up Bind, can you post your named.conf files.
// 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@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@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@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@dc2:/home/joachim#
I just also tried to replace the nonexisting dns.keytab with secrets.keytab - then I get
root@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@dc2:/home/joachim#
...instead of the "TKEY is unacceptable" before.
root@dc2:/home/joachim#
Rowland penny
Jun 5, 2016, 3:00:04 PM6/5/16
to
On 05/06/16 18:25, Jo wrote:
>> -----Ursprüngliche Nachricht-----
>> Von: Rowland penny [mailto:rpe...@samba.org]
>> Gesendet: Sonntag, 5. Juni 2016 17:46
>> An: Jo <j....@live.com>
>> Cc: 'samba' <sa...@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
>> -----Ursprüngliche Nachricht-----
>> Von: Rowland penny [mailto:rpe...@samba.org]
>> Gesendet: Sonntag, 5. Juni 2016 17:46
>> An: Jo <j....@live.com>
>> Cc: 'samba' <sa...@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).
were talking 100-200 users etc
# 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
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.
the DC for its own DNS.
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@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@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";
> };
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@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:
> root@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";
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@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@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@dc2:/home/joachim#
>
> I just also tried to replace the nonexisting dns.keytab with secrets.keytab - then I get
> root@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@dc2:/home/joachim#
>
> ...instead of the "TKEY is unacceptable" before.
/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@dc1:~# ktutil
ktutil: rkt /usr/local/samba/private/dns.keytab
ktutil: l
slot KVNO Principal
---- ----
---------------------------------------------------------------------
1 1 DNS/dc1.samdom....@SAMDOM.EXAMPLE.COM
2 1 dns...@SAMDOM.EXAMPLE.COM
3 1 DNS/dc1.samdom....@SAMDOM.EXAMPLE.COM
4 1 dns...@SAMDOM.EXAMPLE.COM
5 1 DNS/dc1.samdom....@SAMDOM.EXAMPLE.COM
6 1 dns...@SAMDOM.EXAMPLE.COM
7 1 DNS/dc1.samdom....@SAMDOM.EXAMPLE.COM
8 1 dns...@SAMDOM.EXAMPLE.COM
9 1 DNS/dc1.samdom....@SAMDOM.EXAMPLE.COM
10 1 dns...@SAMDOM.EXAMPLE.COM
ktutil: q
mathias dufresne
Jun 6, 2016, 6:10:03 AM6/6/16
to
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."
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."
Jo
Jun 8, 2016, 4:00:03 PM6/8/16
to
I am omitting a lot of old stuff..
> mathias dufresne
> Gesendet: Montag, 6. Juni 2016 12:01
> An: Rowland penny <rpe...@samba.org>
> Cc: samba <sa...@lists.samba.org>; Jo <j....@live.com>
> Betreff: Re: [Samba] inconsistent DNS information, windows domain
> member issues..
>
> 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).
>
My bind is running as root right now, and the authorizations look ok to me. Also don´t see log entries that contradict that.
> 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."
>
I am also not a native speaker in English but my take is the same.
[dropped lots]
Now with the changes I still get the following in the log of dc2, at least occasionally.
[2016/06/08 20:10:13.832105, 0] ../source4/librpc/rpc/dcerpc_sock.c:240(continue_ip_open_socket)
Failed to connect host 192.168.177.21 (7fb38333-aced-4ce8-9a15-a3f6459ecc2a._msdcs.samba.lindenberg.one) on port 135 - NT_STATUS_CONNECTION_REFUSED.
I write occasionally because I tried restarting samba on dc2 and then the message did not appear.
Nothing suspicious in log of dc1.
Getting back to my initial issue list:
> -----Ursprüngliche Nachricht-----
> Von: samba [mailto:samba-...@lists.samba.org] Im Auftrag von Jo
> Gesendet: Sonntag, 5. Juni 2016 11:06
> An: 'samba' <sa...@lists.samba.org>
> Betreff: [Samba] inconsistent DNS information, windows domain member
> issues..
>
> * windows nslookup -type=ANY samba.domain (without .) looks for
> samba.domain.domain. Is this OK or does it point to a problematic search
> configuration?
>
Works properly now. DNS mmc snap-in shows consistent information.
>
> * In windows management console, only some of the domain
> users&principals are shown with the name domain\identity, most of them
> are shown S-xxx. With the one use shown domain\user I can logon to the
> windows system however (likely with cached credentials, but don´t dare
> to change them to confirm)
>
> * When I try to modify folder permissions on the windows system, I
> get
> a message “Unable to contact Active Directory to access or verify claim
> types”
>
These two issues still exist.
> * On DC2: kinit Administrator returns “kinit: Cannot contact any KDC
> for realm ‘samba.domain’ while getting initial credentials. This one was
> easy to fix by adding the domain to /etc/krb5.conf. I am putting this in as I
> changed configuration at this point..
>
Working.
In essence, the windows member is unable to use any information from Samba. The lookup described in https://wiki.samba.org/index.php/Testing_DNS_Name_Resolution does work and reports both dcs as expected.
I checked the Windows system log. There is some noise about group policies and missing updates of the host address. The most relevant record shows:
"This computer was not able to set up a secure session with a domain controller in domain SAMBA due to the following:
There are currently no logon servers available to service the logon request.
This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.
ADDITIONAL INFO
If this computer is a domain controller for the specified domain, it sets up the secure session to the primary domain controller emulator in the specified domain. Otherwise, this computer sets up the secure session to any domain controller in the specified domain."
Looks like Windows 10 Pro expects encrypted configuration by default - which is totally OK to me. But which connection(s)? LDAP as in https://wiki.samba.org/index.php/Configuring_LDAP_over_SSL_(LDAPS)_on_a_Samba_AD_DC? And what certificates does a Windows host trust by default. I can easily use a Letsencrypt certificate if that is OK to windows..
Thanks once more for your support.
Joachim
> mathias dufresne
> Gesendet: Montag, 6. Juni 2016 12:01
> An: Rowland penny <rpe...@samba.org>
> Cc: samba <sa...@lists.samba.org>; Jo <j....@live.com>
> Betreff: Re: [Samba] inconsistent DNS information, windows domain
> member issues..
>
> 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.
>
Worked, thanks a lot.
> 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."
>
[dropped lots]
Now with the changes I still get the following in the log of dc2, at least occasionally.
[2016/06/08 20:10:13.832105, 0] ../source4/librpc/rpc/dcerpc_sock.c:240(continue_ip_open_socket)
Failed to connect host 192.168.177.21 (7fb38333-aced-4ce8-9a15-a3f6459ecc2a._msdcs.samba.lindenberg.one) on port 135 - NT_STATUS_CONNECTION_REFUSED.
I write occasionally because I tried restarting samba on dc2 and then the message did not appear.
Nothing suspicious in log of dc1.
Getting back to my initial issue list:
> -----Ursprüngliche Nachricht-----
> Von: samba [mailto:samba-...@lists.samba.org] Im Auftrag von Jo
> Gesendet: Sonntag, 5. Juni 2016 11:06
> An: 'samba' <sa...@lists.samba.org>
> Betreff: [Samba] inconsistent DNS information, windows domain member
> issues..
>
> I joined a Windows 10 Pro system to my (still experimental) domain. The
> windows system actually hosts DC2 as a VM, and another Windows
> (Server 2008
> R2) at another location hosts DC1 also as a VM. The two locations are
> connected via a VPN, both systems run only when needed. The windows
> system does not directly use DC2 for DNS but instead talks to a DNS
> resolver that delegates the samba Domain to DC2. DC2 uses itself as
> nameserver.
>
>
>
> I am observing the following issues that may be related or not:
>
> * When I do a nslookup samba.domain DC2 I get the address of DC1,
> nslookup DC2.sambadomain DC2 fails. Nslookup DC1.samba.domain DC2
> works.
> When I use dig @DC2 samba.domain it returns DC1 only. Dig
> samba.domain ANY returns
>
Dig reports now the same information on dc1 and dc2. However it reports the old and the new IP address of DC2. I was able to clean this up by deleting the extra A record. Afterwards the extra A record was gone. Same for nslookup on Ubuntu.
> windows system actually hosts DC2 as a VM, and another Windows
> (Server 2008
> R2) at another location hosts DC1 also as a VM. The two locations are
> connected via a VPN, both systems run only when needed. The windows
> system does not directly use DC2 for DNS but instead talks to a DNS
> resolver that delegates the samba Domain to DC2. DC2 uses itself as
> nameserver.
>
>
>
> I am observing the following issues that may be related or not:
>
> * When I do a nslookup samba.domain DC2 I get the address of DC1,
> nslookup DC2.sambadomain DC2 fails. Nslookup DC1.samba.domain DC2
> works.
> When I use dig @DC2 samba.domain it returns DC1 only. Dig
> samba.domain ANY returns
>
> * windows nslookup -type=ANY samba.domain (without .) looks for
> samba.domain.domain. Is this OK or does it point to a problematic search
> configuration?
>
>
> * In windows management console, only some of the domain
> users&principals are shown with the name domain\identity, most of them
> are shown S-xxx. With the one use shown domain\user I can logon to the
> windows system however (likely with cached credentials, but don´t dare
> to change them to confirm)
>
> * When I try to modify folder permissions on the windows system, I
> get
> a message “Unable to contact Active Directory to access or verify claim
> types”
>
> * On DC2: kinit Administrator returns “kinit: Cannot contact any KDC
> for realm ‘samba.domain’ while getting initial credentials. This one was
> easy to fix by adding the domain to /etc/krb5.conf. I am putting this in as I
> changed configuration at this point..
>
In essence, the windows member is unable to use any information from Samba. The lookup described in https://wiki.samba.org/index.php/Testing_DNS_Name_Resolution does work and reports both dcs as expected.
I checked the Windows system log. There is some noise about group policies and missing updates of the host address. The most relevant record shows:
"This computer was not able to set up a secure session with a domain controller in domain SAMBA due to the following:
There are currently no logon servers available to service the logon request.
This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.
ADDITIONAL INFO
If this computer is a domain controller for the specified domain, it sets up the secure session to the primary domain controller emulator in the specified domain. Otherwise, this computer sets up the secure session to any domain controller in the specified domain."
Looks like Windows 10 Pro expects encrypted configuration by default - which is totally OK to me. But which connection(s)? LDAP as in https://wiki.samba.org/index.php/Configuring_LDAP_over_SSL_(LDAPS)_on_a_Samba_AD_DC? And what certificates does a Windows host trust by default. I can easily use a Letsencrypt certificate if that is OK to windows..
Thanks once more for your support.
Joachim
mathias dufresne
Jun 10, 2016, 7:30:03 AM6/10/16
to
2016-06-08 21:47 GMT+02:00 Jo <j....@live.com>:
> I am omitting a lot of old stuff..
>
> > -----Ursprüngliche Nachricht-----
> > Von: samba [mailto:samba-...@lists.samba.org] Im Auftrag von
> > mathias dufresne
> > Gesendet: Montag, 6. Juni 2016 12:01
> > An: Rowland penny <rpe...@samba.org>
> > Cc: samba <sa...@lists.samba.org>; Jo <j....@live.com>
> > Betreff: Re: [Samba] inconsistent DNS information, windows domain
> > member issues..
> >
> > 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.
> >
> Worked, thanks a lot.
>
> > 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).
> >
> My bind is running as root right now, and the authorizations look ok to
> me. Also don´t see log entries that contradict that.
>
If you are running Bind9 DLZ DNS back-end, try "dig -t SOA
> I am omitting a lot of old stuff..
>
> > -----Ursprüngliche Nachricht-----
> > Von: samba [mailto:samba-...@lists.samba.org] Im Auftrag von
> > mathias dufresne
> > Gesendet: Montag, 6. Juni 2016 12:01
> > An: Rowland penny <rpe...@samba.org>
> > Cc: samba <sa...@lists.samba.org>; Jo <j....@live.com>
> > Betreff: Re: [Samba] inconsistent DNS information, windows domain
> > member issues..
> >
> > 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.
> >
> Worked, thanks a lot.
>
> > 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).
> >
> My bind is running as root right now, and the authorizations look ok to
> me. Also don´t see log entries that contradict that.
>
samba.lindenberg.one @<ip dc1>" then change <ip dc1> to <ip dc2>.
These both command should reply in "ANSWER SECTION" <ip dc1> when asking
that to DC1 and <ip dc2> when asked to DC2.
A simple way I use to check my Bind are well configured is to launch
"samba_dnsupdate" (when /etc/resolv.conf point to local DC). Doing that
samba_dnsupdate is using nsupdate which is part of Bind utils, nsupdate
uses DNS protocol to push updates into AD, into the DNS server received as
SOA (SOA means Start Of authority which means nothing for most of us but
SOA means "where to push updates" in fact, so nsupdate will ask for SOA -
that's why the previous requests ;) - and use the received SOA - which
should be local server - to push updates).
If samba_dnsupdate works without errors, even when doing "samba_dnsupdate
--all-names", Bind should be OK locally if /etc/resolv.conf point to local
server.
Not clear, that bunch of explanations... Hoping it is understable :s
>
> > 2016-06-05 20:46 GMT+02:00 Rowland penny <rpe...@samba.org>:
> [dropped lots]
>
> Now with the changes I still get the following in the log of dc2, at least
> occasionally.
>
> [2016/06/08 20:10:13.832105, 0]
> ../source4/librpc/rpc/dcerpc_sock.c:240(continue_ip_open_socket)
> Failed to connect host 192.168.177.21
> (7fb38333-aced-4ce8-9a15-a3f6459ecc2a._msdcs.samba.lindenberg.one) on port
> 135 - NT_STATUS_CONNECTION_REFUSED.
>
dig 7fb38333-aced-4ce8-9a15-a3f6459ecc2a._msdcs.samba.lindenberg.one
from all DC (if DC DNS resolver point to themselves, if they point to same
DNS server, use @<DC IP> in addition to really test DNS on all your DCs)
Answer of that dig should be some CNAME. That record is used for
replication and must exist for replilcation works (I believe at least ;)
If it appears only when asking to on DC, databases are not well synched.
My very not perfect script to for ce synchronisation:
#!/bin/bash
sam=/var/lib/samba/private/sam.ldb
function usage() {
echo "This script is meant to replicate data coming from given DC"
echo "Usage:"
echo "$0 <IP source>"
echo "or"
echo "$0 <source DC name>"
exit 1
}
if [ ! "$1" ] || ! ping -c 1 $1 > /dev/null 2>&1
then
usage
fi
DC_SRC=$1
DC_DST=`hostname`
for DIT in `ls $sam.d | grep -v metadata.tdb | sed -e s/.ldb$//`
do
echo $DIT
samba-tool drs replicate $DC_DST $DC_SRC $DIT --add-ref --sync-forced
--sync-all --full-sync --local
done
0 new messages