Tsig error with server tsig verify failure samba

Arch Linux You are not logged in. #1 2021-03-08 11:00:48 samba dynamic updates — TSIG error System: — current Arch Linux on Epyc, new installation— samba AD DC configured once with internal-dns, once with BIND9 Error:On any version (Internal, BIND9) the command# samba_dnsupdate —verbose —all-namesresults in screen filling up with DDNS and error messages. […]

Содержание

  1. Arch Linux
  2. #1 2021-03-08 11:00:48
  3. samba dynamic updates — TSIG error
  4. #2 2021-03-08 11:40:41
  5. Re: samba dynamic updates — TSIG error
  6. #3 2021-03-08 13:35:23
  7. Re: samba dynamic updates — TSIG error
  8. #4 2021-03-08 13:50:50
  9. Re: samba dynamic updates — TSIG error
  10. #5 2021-03-08 13:55:54
  11. Re: samba dynamic updates — TSIG error
  12. #6 2021-03-08 14:43:36
  13. Re: samba dynamic updates — TSIG error
  14. #7 2021-03-08 14:48:37
  15. Re: samba dynamic updates — TSIG error
  16. #8 2021-03-08 19:29:38
  17. Re: samba dynamic updates — TSIG error
  18. #9 2021-03-08 22:13:12
  19. Re: samba dynamic updates — TSIG error
  20. SSSD New Groups not Added to User Tsing Verify Failure Update Failed REFUSED
  21. Tsig error with server tsig verify failure update failed refused
  22. NOTAUTH(BADKEY)
  23. update failed: NOTAUTH
  24. update failed: REFUSED
  25. req_response: request 0x74c62008: unexpected error
  26. Procedure for troubleshooting
  27. Network traffic sniffing
  28. Thread: Problems setting up samba bind9_dlz on Ubuntu 18.04
  29. Problems setting up samba bind9_dlz on Ubuntu 18.04

Arch Linux

You are not logged in.

#1 2021-03-08 11:00:48

samba dynamic updates — TSIG error

System:
— current Arch Linux on Epyc, new installation
— samba AD DC configured once with internal-dns, once with BIND9

Error:
On any version (Internal, BIND9) the command
# samba_dnsupdate —verbose —all-names
results in screen filling up with DDNS and error messages. The last three lines:

; TSIG error with server: tsig verify failure
Failed nsupdate: 2
Failed update of 34 entries

I am out of ideas, where the error messages come from. Old search results tell that these messages can be safely ignored. Yet I did have issues with Clients and DDNS and Kerberos. So I reinstalled with BIND9 backend to no avail — same error.

Any hint where I went wrong or what I have overlooked is greatly appreciated.

my smb.conf:
# Global parameters
[global]
netbios name = dc1
realm = INTRANET.DOMAIN.TLD
server role = active directory domain controller
server services = dns, s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate
workgroup = INTRANET
idmap_ldb:use rfc2307 = yes
tls enabled = yes
tls keyfile = tls/key.pem
tls certfile = tls/cert.pem
tls cafile = tls/ca.pem

[sysvol]
path = /var/lib/samba/sysvol
read only = No

[netlogon]
path = /var/lib/samba/sysvol/intranet.domain.tld/scripts
read only = No

#2 2021-03-08 11:40:41

Re: samba dynamic updates — TSIG error

At the moment, your DC is using the internal dns server, but you do not have any forwarders.

Does the DC use its own ipaddress (not 127.0.0.1) as its first nameserver in /etc/resolv.conf ?

#3 2021-03-08 13:35:23

Re: samba dynamic updates — TSIG error

At the moment, your DC is using the internal dns server, but you do not have any forwarders.

Do you need to configure the forwarder in smb.conf too when using BIND9? I assumed configuring in BIND is sufficient.

Does the DC use its own ipaddress (not 127.0.0.1) as its first nameserver in /etc/resolv.conf ?

It uses 127.0.0.1 and ::1

Did the following:
1. disable IPv6 for now until it works under IPv4
2. Set forwarder in smb.conf and
3. set IP address (not 127.0.0.1) for resolv.
4. edited hosts ofc too

# samba_dnsupdate —verbose —all-names

result (just snippets):

force update: SRV _ldap._tcp.ForestDnsZones.intranet.example.com dc1.intranet.example.com 389
force update: SRV _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.intranet.example.com dc1.intranet.example.com 389
29 DNS updates and 0 DNS deletes needed
Successfully obtained Kerberos ticket to DNS/dc1.intranet.example.com as dc1$
update(nsupdate): A dc1.intranet.example.com 192.168.178.204
Calling nsupdate for A dc1.intranet.example.com 192.168.178.204 (add)
Successfully obtained Kerberos ticket to DNS/dc1.intranet.example.com as dc1$
Outgoing update query:
;; ->>HEADER >HEADER >HEADER Offline

#4 2021-03-08 13:50:50

Re: samba dynamic updates — TSIG error

PS: updated post — 4. for changes, added hosts and resolv.conf

#5 2021-03-08 13:55:54

Re: samba dynamic updates — TSIG error

Setting the forwarders in the bind9 conf files would be enough, but you are not using bind9 (if you are using the smb.conf you posted), your ‘server services’ line has ‘dns’ in it, this means you are using the internal dns server.
When you ‘tried’ to upgrade to bind9, did you run ‘samba_upgradedns’ ?

#6 2021-03-08 14:43:36

Re: samba dynamic updates — TSIG error

Setting the forwarders in the bind9 conf files would be enough, but you are not using bind9 (if you are using the smb.conf you posted), your ‘server services’ line has ‘dns’ in it, this means you are using the internal dns server.
When you ‘tried’ to upgrade to bind9, did you run ‘samba_upgradedns’ ?

My bad, I had already tested with internal again, when I posted the smb.conf

The local DNS changed the behaviour. Changes:
1. As shown above changed resolv.conf and hosts
2. switched back to BIND9
3. updated smb.conf

Current smb.conf:
# Global parameters
[global]
netbios name = DC1
realm = INTRANET.EXAMPLE.COM
server role = active directory domain controller
server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate
workgroup = INTRANET
dns forwarder = 192.168.178.1
idmap_ldb:use rfc2307 = yes
tls enabled = yes
tls keyfile = tls/key.pem
tls certfile = tls/cert.pem
tls cafile = tls/ca.pem

[sysvol]
path = /var/lib/samba/sysvol
read only = No

[netlogon]
path = /var/lib/samba/sysvol/intranet.example.com/scripts
read only = No
—————-
Can samba even work with this BIND version?

]# named -v
BIND 9.16.12 (Stable Release)
[root@dc1

]# samba -V
Version 4.13.4

The error on dynamic DNS updates changed to:

dns_tkey_gssnegotiate: TKEY is unacceptable
Failed nsupdate: 1
Failed update of 29 entries

To no avail. I cant seem to see where I went wrong

#7 2021-03-08 14:48:37

Re: samba dynamic updates — TSIG error

PS: again sorry for posting the wrong smb.conf — usually not my style. Its just: I am sitting on failed dynamic DNS updates for some time — and I plain dont see whats wrong ;(.

#8 2021-03-08 19:29:38

Re: samba dynamic updates — TSIG error

When you are changing between dns servers, are you running ‘samba_upgradedns’ and if you are, are you running it correctly ? add ‘—help’ to the command to see the various options.

Your version of Bind9 should be okay, there was a problem, but it was fixed in 4.12.x

You could try using ‘—use-samba-tool’ with your ‘samba_dnsupdate’ command.

#9 2021-03-08 22:13:12

Re: samba dynamic updates — TSIG error

When you are changing between dns servers, are you running ‘samba_upgradedns’ and if you are, are you running it correctly ? add ‘—help’ to the command to see the various options.

Your version of Bind9 should be okay, there was a problem, but it was fixed in 4.12.x

You could try using ‘—use-samba-tool’ with your ‘samba_dnsupdate’ command.

I attached the output — its different with —use-samba-tool:

Источник

SSSD New Groups not Added to User Tsing Verify Failure Update Failed REFUSED

After adding a user to a group in Active Directory and looking for that group to appear with the user on a Linux server linked to AD via SSSD, noticing that the group is not added to the user

Checking the SSSD daemon status

part is the problem here.

For further reference, the server’s /etc/sssd/sssd.conf file looks like…

domains = co.local config_file_version = 2 services = nss, pam

ad_domain = co.local krb5_realm = CO.LOCAL realmd_tags = manages-system joined-with-samba cache_credentials = False id_provider = ad krb5_store_password_if_offline = False default_shell = /bin/bash ldap_id_mapping = False ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_group_gid_number = gidNumber use_fully_qualified_names = False fallback_homedir = /home/%u access_provider = ad default_domain_suffix = co.local

Note that we recently changed our primary DNS server and the /etc/resolv.conf file does reflect these changes, but I suspect that this is very related.

Does anyone with more experience with SSSD have any debugging tips or know what could be going wrong here

after checking a server where the DNS was not updated when initially checking SSDs status I see

then after restarting the service, see

and checking the groups for a given user shows the updated groups being correctly associated with the user. Yet even then, after some time, when checking again I see that the

error is back and at some time even later checking the groups for the user is back to the old settings.

Источник

Tsig error with server tsig verify failure update failed refused

BIND is very strict about syntax and configuring and it does not forgive missing dot characters. The more complex a troubleshooting can be. nsupdate itself can already declare different errors. These ways and means for error limitation and elimination are to be addressed here.

Normally, send of nsupdate does not return if the update was successful.

NOTAUTH(BADKEY)

If you get an output like

; TSIG error with server: tsig indicates error
update failed: NOTAUTH(BADKEY)

then most of the time the cause lies in a faulty key or in the incorrect indication of the key. This can happen, for example, if an incorrect key name or the wrong algorithm was specified with the key command or the -k option.
An equivalent log message in /var/log/messages, /var/bind/security_info.log or journalctl looks like this:

22-Feb-2018 11:55:03.991 error: client 178.25.30.4#56421: request has invalid signature: TSIG ddns.example.org: tsig verify failure (BADKEY)

update failed: NOTAUTH

NOTAUTH means only «not authoritative». This means that, e.g. tries to change the local caching DNS. However, this happens quite unintentionally relatively easily in connection with a more extensive BIND configuration with, for example, views. The most common case may be that you just land in the wrong view. Here it may help to adjust the internal view.

update failed: REFUSED

Receiving the following error message from nsupdate to a send indicates either a misconfiguration of the parameters of the update-policy configuration option in the configuration file /etc/named.conf or /etc/bind/named.conf.local or an incorrect specification within nsupdate with respect to the DNS records being changed.

The log message is then usually as follows:

26-Feb-2018 17:58:14.244 info: client 178.174.206.155#39513/key ddns.example.org: updating zone ‘example.org/IN’: update failed: rejected by secure update (REFUSED)

req_response: request 0x74c62008: unexpected error

Here helps, what has already been mentioned elsewhere. BIND will create a .jnl file in the same directory if the respective zone file is successfully updated. As soon as the associated zone file is changed — even if it is just the serial number — this error occurs. Here it only helps to delete the .jnl file and provide the zone file with a new serial number, in order to then restart BIND.

Procedure for troubleshooting

Most of the time, nsupdate will provide the message first; Communication with server failed: timed out on. This can mean a lot, including the fact that because of a firewall the connection to the BIND server is denied. So, the first step is to check the open ports on the server:

# nmap dns.example.org
Starting Nmap 6.47 at 2018-02-27 09:43 CET
Nmap scan report for dns.example.org (178.65.12.2)
Host is up (0.038s latency).
Not shown: 996 filtered ports
PORT STATE SERVICE
53/tcp open domain
80/tcp closed http
443/tcp closed https
3128/tcp closed squid-http

Nmap done: 1 IP address (1 host up) scanned in 21.43 seconds

With the port scanner nmap can be very easily show which ports and especially if port 53 is open.

But also nsupdate offers further possibilities to provide more informative information. For example, options -v and -L 3 switch to verbose and debug level 3. In addition, show displays the current message, which contains all the prerequisites and updates since the last submission. While answer displays the answer.

# nsupdate -v -L 3 -k /etc/ssl/Kdyndns.example.org.+163+46242.private
27-Feb-2018 18:36:48.223 dns_requestmgr_create
27-Feb-2018 18:36:48.224 dns_requestmgr_create: 0x74d05f08
> server ns.example.org
> zone example.org
> update delete dyndns.example.org
> update add dndns.example.org 18000 A 84.189.213.55
> send
27-Feb-2018 18:37:28.194 dns_request_createvia
27-Feb-2018 18:37:28.194 request_render
27-Feb-2018 18:37:28.194 requestmgr_attach: 0x74d05f08: eref 1 iref 1
27-Feb-2018 18:37:28.194 mgr_gethash
27-Feb-2018 18:37:28.195 dns_request_createvia: request 0x74c48008
27-Feb-2018 18:37:28.230 req_connected: request 0x74c48008
27-Feb-2018 18:37:28.230 req_send: request 0x74c48008
27-Feb-2018 18:37:28.231 req_senddone: request 0x74c48008
27-Feb-2018 18:37:28.266 req_response: request 0x74c48008: unexpected error
27-Feb-2018 18:37:28.266 req_cancel: request 0x74c48008
27-Feb-2018 18:37:28.266 req_sendevent: request 0x74c48008
; Communication with server failed: unexpected error
27-Feb-2018 18:37:28.266 dns_request_destroy: request 0x74c48008
27-Feb-2018 18:37:28.266 req_destroy: request 0x74c48008
27-Feb-2018 18:37:28.266 requestmgr_detach: 0x74d05f08: eref 1 iref 0

Network traffic sniffing

However, reading the network traffic both on the Ethernet interface of the client and on the Ethernet card of the BIND server also helps to isolate the error. So listen to tcpdump here

tcpdump -vvveni eth0 port 53

not only eth0 , but also filters out all data packets except the DNS service. With -vvv one receives an extremely detailed output, while -n leads a display of the IP and port numbers instead of names and -e provides for the display of the Ethernetaddresses.

Источник

Thread: Problems setting up samba bind9_dlz on Ubuntu 18.04

Thread Tools
Display

Problems setting up samba bind9_dlz on Ubuntu 18.04

I followed the following guides to setup samba as an additional active directory server to my windows server with bind9 dns:

The active directory replication works, but the dns replication does not work. When I’m running «samba_dnsupdate —all-names» I get the following output:
; TSIG error with server: tsig verify failure
; TSIG error with server: tsig verify failure
update failed: REFUSED
; TSIG error with server: tsig verify failure
update failed: REFUSED
; TSIG error with server: tsig verify failure
; TSIG error with server: tsig verify failure
; TSIG error with server: tsig verify failure
; TSIG error with server: tsig verify failure
; TSIG error with server: tsig verify failure
; TSIG error with server: tsig verify failure
; TSIG error with server: tsig verify failure
; TSIG error with server: tsig verify failure
; TSIG error with server: tsig verify failure
; TSIG error with server: tsig verify failure
; TSIG error with server: tsig verify failure
; TSIG error with server: tsig verify failure
; TSIG error with server: tsig verify failure
; TSIG error with server: tsig verify failure
; TSIG error with server: tsig verify failure
; TSIG error with server: tsig verify failure
Failed update of 19 entries

Here is a list of versions:
Ubuntu: 18.04
Samba: 4.7.6-Ubuntu
bind9: 9.11.3-1ubuntu1.11-UbuntuAnd this is my smb.conf:

[global]
netbios name = DC01
realm = DOMAIN.COM
server role = active directory domain controller
workgroup = DOMAIN.COM
dns forwarder = 172.17.1.1
idmap_ldb:use rfc2307 = yes

template shell = /bin/bash
winbind use default domain = true
winbind offline logon = false
winbind nss info = rfc2307
winbind enum users = yes
winbind enum groups = yes
server services = -dns

[netlogon]
path = /var/lib/samba/sysvol/domain.com/scripts
read only = No

[sysvol]
path = /var/lib/samba/sysvol
read only = No

I’m not really sure if samba is even using bind9. I’ve enabled the logging of bind9, but I cannot see any logs when running the dns update. Did I miss a step to activate the bind9 module?

Last edited by b-david; November 22nd, 2019 at 02:08 PM .

Источник

Источник

hortimech wrote:

When you are changing between dns servers, are you running ‘samba_upgradedns’ and if you are, are you running it correctly ? add ‘—help’ to the command to see the various options.

samba_upgradedns —dns-backend=BIND9_DLZ

hortimech wrote:

Your version of Bind9 should be okay, there was a problem, but it was fixed in 4.12.x

Thank you.

hortimech wrote:

You could try using ‘—use-samba-tool’ with your ‘samba_dnsupdate’ command.

I attached the output — its different with —use-samba-tool:

———————————————————————————
# samba_dnsupdate —verbose —all-names —use-samba-tool
IPs: [‘192.168.178.204’]
force update: A dc1.intranet.example.com 192.168.178.204
force update: CNAME 085a9ea9-7f3a-4048-88ee-db948fa2975f._msdcs.intranet.example.com dc1.intranet.example.com
force update: NS intranet.example.com dc1.intranet.example.com
force update: NS _msdcs.intranet.example.com dc1.intranet.example.com
force update: A intranet.example.com 192.168.178.204
force update: SRV _ldap._tcp.intranet.example.com dc1.intranet.example.com 389
force update: SRV _ldap._tcp.dc._msdcs.intranet.example.com dc1.intranet.example.com 389
force update: SRV _ldap._tcp.191857a8-808d-4410-b65e-64a0ff5b9386.domains._msdcs.intranet.example.com dc1.intranet.example.com 389
force update: SRV _kerberos._tcp.intranet.example.com dc1.intranet.example.com 88
force update: SRV _kerberos._udp.intranet.example.com dc1.intranet.example.com 88
force update: SRV _kerberos._tcp.dc._msdcs.intranet.example.com dc1.intranet.example.com 88
force update: SRV _kpasswd._tcp.intranet.example.com dc1.intranet.example.com 464
force update: SRV _kpasswd._udp.intranet.example.com dc1.intranet.example.com 464
force update: SRV _ldap._tcp.Default-First-Site-Name._sites.intranet.example.com dc1.intranet.example.com 389
force update: SRV _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.intranet.example.com dc1.intranet.example.com 389
force update: SRV _kerberos._tcp.Default-First-Site-Name._sites.intranet.example.com dc1.intranet.example.com 88
force update: SRV _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.intranet.example.com dc1.intranet.example.com 88
force update: SRV _ldap._tcp.pdc._msdcs.intranet.example.com dc1.intranet.example.com 389
force update: A gc._msdcs.intranet.example.com 192.168.178.204
force update: SRV _gc._tcp.intranet.example.com dc1.intranet.example.com 3268
force update: SRV _ldap._tcp.gc._msdcs.intranet.example.com dc1.intranet.example.com 3268
force update: SRV _gc._tcp.Default-First-Site-Name._sites.intranet.example.com dc1.intranet.example.com 3268
force update: SRV _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.intranet.example.com dc1.intranet.example.com 3268
force update: A DomainDnsZones.intranet.example.com 192.168.178.204
force update: SRV _ldap._tcp.DomainDnsZones.intranet.example.com dc1.intranet.example.com 389
force update: SRV _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.intranet.example.com dc1.intranet.example.com 389
force update: A ForestDnsZones.intranet.example.com 192.168.178.204
force update: SRV _ldap._tcp.ForestDnsZones.intranet.example.com dc1.intranet.example.com 389
force update: SRV _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.intranet.example.com dc1.intranet.example.com 389
29 DNS updates and 0 DNS deletes needed
Successfully obtained Kerberos ticket to DNS/dc1.intranet.example.com as dc1$
update (samba-tool): A dc1.intranet.example.com 192.168.178.204
Calling samba-tool dns for A dc1.intranet.example.com 192.168.178.204 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘intranet.example.com’, ‘dc1’, ‘A’, ‘192.168.178.204’]
ERROR: Record already exist; record could not be added. zone[intranet.example.com] name[dc1]
Failed ‘samba-tool dns’ based update of A dc1.intranet.example.com 192.168.178.204
update (samba-tool): CNAME 085a9ea9-7f3a-4048-88ee-db948fa2975f._msdcs.intranet.example.com dc1.intranet.example.com
Calling samba-tool dns for CNAME 085a9ea9-7f3a-4048-88ee-db948fa2975f._msdcs.intranet.example.com dc1.intranet.example.com (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘_msdcs.intranet.example.com’, ‘085a9ea9-7f3a-4048-88ee-db948fa2975f’, ‘CNAME’, ‘dc1.intranet.example.com’]
ERROR: Record already exist; record could not be added. zone[_msdcs.intranet.example.com] name[085a9ea9-7f3a-4048-88ee-db948fa2975f]
Failed ‘samba-tool dns’ based update of CNAME 085a9ea9-7f3a-4048-88ee-db948fa2975f._msdcs.intranet.example.com dc1.intranet.example.com
update (samba-tool): NS intranet.example.com dc1.intranet.example.com
Calling samba-tool dns for NS intranet.example.com dc1.intranet.example.com (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘intranet.example.com’, ‘@’, ‘NS’, ‘dc1.intranet.example.com’]
ERROR: Record already exist; record could not be added. zone[intranet.example.com] name[@]
Failed ‘samba-tool dns’ based update of NS intranet.example.com dc1.intranet.example.com
update (samba-tool): NS _msdcs.intranet.example.com dc1.intranet.example.com
Calling samba-tool dns for NS _msdcs.intranet.example.com dc1.intranet.example.com (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘_msdcs.intranet.example.com’, ‘@’, ‘NS’, ‘dc1.intranet.example.com’]
ERROR: Record already exist; record could not be added. zone[_msdcs.intranet.example.com] name[@]
Failed ‘samba-tool dns’ based update of NS _msdcs.intranet.example.com dc1.intranet.example.com
update (samba-tool): A intranet.example.com 192.168.178.204
Calling samba-tool dns for A intranet.example.com 192.168.178.204 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘intranet.example.com’, ‘@’, ‘A’, ‘192.168.178.204’]
ERROR: Record already exist; record could not be added. zone[intranet.example.com] name[@]
Failed ‘samba-tool dns’ based update of A intranet.example.com 192.168.178.204
update (samba-tool): SRV _ldap._tcp.intranet.example.com dc1.intranet.example.com 389
Calling samba-tool dns for SRV _ldap._tcp.intranet.example.com dc1.intranet.example.com 389 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘intranet.example.com’, ‘_ldap._tcp’, ‘SRV’, ‘dc1.intranet.example.com 389 0 100’]
ERROR: Record already exist; record could not be added. zone[intranet.example.com] name[_ldap._tcp]
Failed ‘samba-tool dns’ based update of SRV _ldap._tcp.intranet.example.com dc1.intranet.example.com 389
update (samba-tool): SRV _ldap._tcp.dc._msdcs.intranet.example.com dc1.intranet.example.com 389
Calling samba-tool dns for SRV _ldap._tcp.dc._msdcs.intranet.example.com dc1.intranet.example.com 389 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘_msdcs.intranet.example.com’, ‘_ldap._tcp.dc’, ‘SRV’, ‘dc1.intranet.example.com 389 0 100’]
ERROR: Record already exist; record could not be added. zone[_msdcs.intranet.example.com] name[_ldap._tcp.dc]
Failed ‘samba-tool dns’ based update of SRV _ldap._tcp.dc._msdcs.intranet.example.com dc1.intranet.example.com 389
update (samba-tool): SRV _ldap._tcp.191857a8-808d-4410-b65e-64a0ff5b9386.domains._msdcs.intranet.example.com dc1.intranet.example.com 389
Calling samba-tool dns for SRV _ldap._tcp.191857a8-808d-4410-b65e-64a0ff5b9386.domains._msdcs.intranet.example.com dc1.intranet.example.com 389 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘_msdcs.intranet.example.com’, ‘_ldap._tcp.191857a8-808d-4410-b65e-64a0ff5b9386.domains’, ‘SRV’, ‘dc1.intranet.example.com 389 0 100’]
ERROR: Record already exist; record could not be added. zone[_msdcs.intranet.example.com] name[_ldap._tcp.191857a8-808d-4410-b65e-64a0ff5b9386.domains]
Failed ‘samba-tool dns’ based update of SRV _ldap._tcp.191857a8-808d-4410-b65e-64a0ff5b9386.domains._msdcs.intranet.example.com dc1.intranet.example.com 389
update (samba-tool): SRV _kerberos._tcp.intranet.example.com dc1.intranet.example.com 88
Calling samba-tool dns for SRV _kerberos._tcp.intranet.example.com dc1.intranet.example.com 88 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘intranet.example.com’, ‘_kerberos._tcp’, ‘SRV’, ‘dc1.intranet.example.com 88 0 100’]
ERROR: Record already exist; record could not be added. zone[intranet.example.com] name[_kerberos._tcp]
Failed ‘samba-tool dns’ based update of SRV _kerberos._tcp.intranet.example.com dc1.intranet.example.com 88
update (samba-tool): SRV _kerberos._udp.intranet.example.com dc1.intranet.example.com 88
Calling samba-tool dns for SRV _kerberos._udp.intranet.example.com dc1.intranet.example.com 88 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘intranet.example.com’, ‘_kerberos._udp’, ‘SRV’, ‘dc1.intranet.example.com 88 0 100’]
ERROR: Record already exist; record could not be added. zone[intranet.example.com] name[_kerberos._udp]
Failed ‘samba-tool dns’ based update of SRV _kerberos._udp.intranet.example.com dc1.intranet.example.com 88
update (samba-tool): SRV _kerberos._tcp.dc._msdcs.intranet.example.com dc1.intranet.example.com 88
Calling samba-tool dns for SRV _kerberos._tcp.dc._msdcs.intranet.example.com dc1.intranet.example.com 88 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘_msdcs.intranet.example.com’, ‘_kerberos._tcp.dc’, ‘SRV’, ‘dc1.intranet.example.com 88 0 100’]
ERROR: Record already exist; record could not be added. zone[_msdcs.intranet.example.com] name[_kerberos._tcp.dc]
Failed ‘samba-tool dns’ based update of SRV _kerberos._tcp.dc._msdcs.intranet.example.com dc1.intranet.example.com 88
update (samba-tool): SRV _kpasswd._tcp.intranet.example.com dc1.intranet.example.com 464
Calling samba-tool dns for SRV _kpasswd._tcp.intranet.example.com dc1.intranet.example.com 464 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘intranet.example.com’, ‘_kpasswd._tcp’, ‘SRV’, ‘dc1.intranet.example.com 464 0 100’]
ERROR: Record already exist; record could not be added. zone[intranet.example.com] name[_kpasswd._tcp]
Failed ‘samba-tool dns’ based update of SRV _kpasswd._tcp.intranet.example.com dc1.intranet.example.com 464
update (samba-tool): SRV _kpasswd._udp.intranet.example.com dc1.intranet.example.com 464
Calling samba-tool dns for SRV _kpasswd._udp.intranet.example.com dc1.intranet.example.com 464 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘intranet.example.com’, ‘_kpasswd._udp’, ‘SRV’, ‘dc1.intranet.example.com 464 0 100’]
ERROR: Record already exist; record could not be added. zone[intranet.example.com] name[_kpasswd._udp]
Failed ‘samba-tool dns’ based update of SRV _kpasswd._udp.intranet.example.com dc1.intranet.example.com 464
update (samba-tool): SRV _ldap._tcp.Default-First-Site-Name._sites.intranet.example.com dc1.intranet.example.com 389
Calling samba-tool dns for SRV _ldap._tcp.Default-First-Site-Name._sites.intranet.example.com dc1.intranet.example.com 389 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘intranet.example.com’, ‘_ldap._tcp.Default-First-Site-Name._sites’, ‘SRV’, ‘dc1.intranet.example.com 389 0 100’]
ERROR: Record already exist; record could not be added. zone[intranet.example.com] name[_ldap._tcp.Default-First-Site-Name._sites]
Failed ‘samba-tool dns’ based update of SRV _ldap._tcp.Default-First-Site-Name._sites.intranet.example.com dc1.intranet.example.com 389
update (samba-tool): SRV _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.intranet.example.com dc1.intranet.example.com 389
Calling samba-tool dns for SRV _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.intranet.example.com dc1.intranet.example.com 389 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘_msdcs.intranet.example.com’, ‘_ldap._tcp.Default-First-Site-Name._sites.dc’, ‘SRV’, ‘dc1.intranet.example.com 389 0 100’]
ERROR: Record already exist; record could not be added. zone[_msdcs.intranet.example.com] name[_ldap._tcp.Default-First-Site-Name._sites.dc]
Failed ‘samba-tool dns’ based update of SRV _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.intranet.example.com dc1.intranet.example.com 389
update (samba-tool): SRV _kerberos._tcp.Default-First-Site-Name._sites.intranet.example.com dc1.intranet.example.com 88
Calling samba-tool dns for SRV _kerberos._tcp.Default-First-Site-Name._sites.intranet.example.com dc1.intranet.example.com 88 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘intranet.example.com’, ‘_kerberos._tcp.Default-First-Site-Name._sites’, ‘SRV’, ‘dc1.intranet.example.com 88 0 100’]
ERROR: Record already exist; record could not be added. zone[intranet.example.com] name[_kerberos._tcp.Default-First-Site-Name._sites]
Failed ‘samba-tool dns’ based update of SRV _kerberos._tcp.Default-First-Site-Name._sites.intranet.example.com dc1.intranet.example.com 88
update (samba-tool): SRV _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.intranet.example.com dc1.intranet.example.com 88
Calling samba-tool dns for SRV _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.intranet.example.com dc1.intranet.example.com 88 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘_msdcs.intranet.example.com’, ‘_kerberos._tcp.Default-First-Site-Name._sites.dc’, ‘SRV’, ‘dc1.intranet.example.com 88 0 100’]
ERROR: Record already exist; record could not be added. zone[_msdcs.intranet.example.com] name[_kerberos._tcp.Default-First-Site-Name._sites.dc]
Failed ‘samba-tool dns’ based update of SRV _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.intranet.example.com dc1.intranet.example.com 88
update (samba-tool): SRV _ldap._tcp.pdc._msdcs.intranet.example.com dc1.intranet.example.com 389
Calling samba-tool dns for SRV _ldap._tcp.pdc._msdcs.intranet.example.com dc1.intranet.example.com 389 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘_msdcs.intranet.example.com’, ‘_ldap._tcp.pdc’, ‘SRV’, ‘dc1.intranet.example.com 389 0 100’]
ERROR: Record already exist; record could not be added. zone[_msdcs.intranet.example.com] name[_ldap._tcp.pdc]
Failed ‘samba-tool dns’ based update of SRV _ldap._tcp.pdc._msdcs.intranet.example.com dc1.intranet.example.com 389
update (samba-tool): A gc._msdcs.intranet.example.com 192.168.178.204
Calling samba-tool dns for A gc._msdcs.intranet.example.com 192.168.178.204 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘_msdcs.intranet.example.com’, ‘gc’, ‘A’, ‘192.168.178.204’]
ERROR: Record already exist; record could not be added. zone[_msdcs.intranet.example.com] name[gc]
Failed ‘samba-tool dns’ based update of A gc._msdcs.intranet.example.com 192.168.178.204
update (samba-tool): SRV _gc._tcp.intranet.example.com dc1.intranet.example.com 3268
Calling samba-tool dns for SRV _gc._tcp.intranet.example.com dc1.intranet.example.com 3268 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘intranet.example.com’, ‘_gc._tcp’, ‘SRV’, ‘dc1.intranet.example.com 3268 0 100’]
ERROR: Record already exist; record could not be added. zone[intranet.example.com] name[_gc._tcp]
Failed ‘samba-tool dns’ based update of SRV _gc._tcp.intranet.example.com dc1.intranet.example.com 3268
update (samba-tool): SRV _ldap._tcp.gc._msdcs.intranet.example.com dc1.intranet.example.com 3268
Calling samba-tool dns for SRV _ldap._tcp.gc._msdcs.intranet.example.com dc1.intranet.example.com 3268 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘_msdcs.intranet.example.com’, ‘_ldap._tcp.gc’, ‘SRV’, ‘dc1.intranet.example.com 3268 0 100’]
ERROR: Record already exist; record could not be added. zone[_msdcs.intranet.example.com] name[_ldap._tcp.gc]
Failed ‘samba-tool dns’ based update of SRV _ldap._tcp.gc._msdcs.intranet.example.com dc1.intranet.example.com 3268
update (samba-tool): SRV _gc._tcp.Default-First-Site-Name._sites.intranet.example.com dc1.intranet.example.com 3268
Calling samba-tool dns for SRV _gc._tcp.Default-First-Site-Name._sites.intranet.example.com dc1.intranet.example.com 3268 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘intranet.example.com’, ‘_gc._tcp.Default-First-Site-Name._sites’, ‘SRV’, ‘dc1.intranet.example.com 3268 0 100’]
ERROR: Record already exist; record could not be added. zone[intranet.example.com] name[_gc._tcp.Default-First-Site-Name._sites]
Failed ‘samba-tool dns’ based update of SRV _gc._tcp.Default-First-Site-Name._sites.intranet.example.com dc1.intranet.example.com 3268
update (samba-tool): SRV _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.intranet.example.com dc1.intranet.example.com 3268
Calling samba-tool dns for SRV _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.intranet.example.com dc1.intranet.example.com 3268 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘_msdcs.intranet.example.com’, ‘_ldap._tcp.Default-First-Site-Name._sites.gc’, ‘SRV’, ‘dc1.intranet.example.com 3268 0 100’]
ERROR: Record already exist; record could not be added. zone[_msdcs.intranet.example.com] name[_ldap._tcp.Default-First-Site-Name._sites.gc]
Failed ‘samba-tool dns’ based update of SRV _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.intranet.example.com dc1.intranet.example.com 3268
update (samba-tool): A DomainDnsZones.intranet.example.com 192.168.178.204
Calling samba-tool dns for A DomainDnsZones.intranet.example.com 192.168.178.204 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘intranet.example.com’, ‘DomainDnsZones’, ‘A’, ‘192.168.178.204’]
ERROR: Record already exist; record could not be added. zone[intranet.example.com] name[DomainDnsZones]
Failed ‘samba-tool dns’ based update of A DomainDnsZones.intranet.example.com 192.168.178.204
update (samba-tool): SRV _ldap._tcp.DomainDnsZones.intranet.example.com dc1.intranet.example.com 389
Calling samba-tool dns for SRV _ldap._tcp.DomainDnsZones.intranet.example.com dc1.intranet.example.com 389 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘intranet.example.com’, ‘_ldap._tcp.DomainDnsZones’, ‘SRV’, ‘dc1.intranet.example.com 389 0 100’]
ERROR: Record already exist; record could not be added. zone[intranet.example.com] name[_ldap._tcp.DomainDnsZones]
Failed ‘samba-tool dns’ based update of SRV _ldap._tcp.DomainDnsZones.intranet.example.com dc1.intranet.example.com 389
update (samba-tool): SRV _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.intranet.example.com dc1.intranet.example.com 389
Calling samba-tool dns for SRV _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.intranet.example.com dc1.intranet.example.com 389 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘intranet.example.com’, ‘_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones’, ‘SRV’, ‘dc1.intranet.example.com 389 0 100’]
ERROR: Record already exist; record could not be added. zone[intranet.example.com] name[_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones]
Failed ‘samba-tool dns’ based update of SRV _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.intranet.example.com dc1.intranet.example.com 389
update (samba-tool): A ForestDnsZones.intranet.example.com 192.168.178.204
Calling samba-tool dns for A ForestDnsZones.intranet.example.com 192.168.178.204 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘intranet.example.com’, ‘ForestDnsZones’, ‘A’, ‘192.168.178.204’]
ERROR: Record already exist; record could not be added. zone[intranet.example.com] name[ForestDnsZones]
Failed ‘samba-tool dns’ based update of A ForestDnsZones.intranet.example.com 192.168.178.204
update (samba-tool): SRV _ldap._tcp.ForestDnsZones.intranet.example.com dc1.intranet.example.com 389
Calling samba-tool dns for SRV _ldap._tcp.ForestDnsZones.intranet.example.com dc1.intranet.example.com 389 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘intranet.example.com’, ‘_ldap._tcp.ForestDnsZones’, ‘SRV’, ‘dc1.intranet.example.com 389 0 100’]
ERROR: Record already exist; record could not be added. zone[intranet.example.com] name[_ldap._tcp.ForestDnsZones]
Failed ‘samba-tool dns’ based update of SRV _ldap._tcp.ForestDnsZones.intranet.example.com dc1.intranet.example.com 389
update (samba-tool): SRV _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.intranet.example.com dc1.intranet.example.com 389
Calling samba-tool dns for SRV _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.intranet.example.com dc1.intranet.example.com 389 (add)
Calling samba-tool dns add -k no -P [‘192.168.178.204’, ‘intranet.example.com’, ‘_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones’, ‘SRV’, ‘dc1.intranet.example.com 389 0 100’]
ERROR: Record already exist; record could not be added. zone[intranet.example.com] name[_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones]
Failed ‘samba-tool dns’ based update of SRV _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.intranet.example.com dc1.intranet.example.com 389
Failed update of 29 entries

Источник

Введение

Статья основана на материалах из wiki.samba.org
В материалы внесены существенные изменения, отражающие работу с современной версией Bind9.

Для того, чтобы создать контроллер домена Samba Active Directory (AD), в первую очередь нужно создать и настроить DNS-сервер.
Для использования с ОС Astra Linux рекомендуется DNS-сервер BIND9, входящий в комплект дистрибутивов.

Далее описывается базовая инсталляция BIND9, которую, в дальнейшем, можно будет использовать для  Samba AD DC.
Для перехода с использования внутренней службы DNS Samba на использование сервера Bind9 также см. Изменение службы DNS контроллера домена AD Samba.

Установка Bind

Процедуру установки пакета bind cм. DNS-сервер BIND9

Настройка BIND

Добавлять зоны перенаправления и реверсивные зоны домена AD в файлы named.conf, не нужно, так как эти зоны хранятся динамически в  AD.

Создание файла зоны localhost и файла реверсивной зоны  0.0.127.in-addr.arpa

Файлы зоны localhost и файла реверсивной зоны  0.0.127.in-addr.arpa при установке пакета создаются автоматически
(файлы /etc/bind/db.local и /etc/bind/db.127 соответственнно).

Запуск сервиса

Для запуска/перезапуска сервиса BIND используйте команды

sudo systemctl start bind9
sudo systemctl restart bind9

Проверка зон

Следующие примеры запрашивают у сервиса DNS информацию о локальной машине (127.0.0.1).

Проверка зоны перенаправления localhost

Команда:

host -t A localhost 127.0.0.1

Образец ответа:

Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
localhost has address 127.0.0.1

Проверка реверсивной зоны 0.0.127.in-addr.arpa.

Команда:

host -t PTR 127.0.0.1 127.0.0.1

Образец ответа:

Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
1.0.0.127.in-addr.arpa domain name pointer localhost.

Настройка модуля BIND9_DLZ

Эту настройку следует выполнять после выполнения назначения Samba на роль контроллера AD, так как нужный конфигурационный файл /var/lib/samba/bind-dns/named.conf появится только после этого назначения.

Эта часть статьи написана на основе материлов из wiki.samba.org

Во время назначения Samba на роль контроллера домена AD автоматически создаётся конфигурационный файл /var/lib/samba/bind-dns/named.conf службы BIND9:

 Нажмите, чтобы развернуть

# 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/bind-dns/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»;

   # For BIND 9.11.x
   database «dlopen /usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_11.so»;
};

Для включения модуля BIND9_DLZ:

Добавить команду включения в конфигурационый файл /etc/bind/named.conf:

include «/var/lib/samba/bind-dns/named.conf»;

Определить используемую версию bind командой:

sudo named -v

Отредактировать файл /var/lib/samba/bind-dns/named.conf, и убедиться, что раскомментировна строка, соответствующая используемой версии BIND.
При написании этой статьи использовалась версия BIND 9.11.

Разрешить доступ к файлу /var/lib/samba/bind-dns/named.conf:

Проверить правильность конфигурации:

sudo named-checkconf

Перезапустить сервис bind9:

sudo systemctl restart bind9

Ошибка /usr/sbin/samba_dnsupdate: ; TSIG error with server: tsig verify failure

Сообщения в системном журнале вида «/usr/sbin/samba_dnsupdate: update failed: REFUSED» и связанные с ними сообщения об ошибках обновления DNS можно игнорировать.

Ошибка «status: FORMERR» при обращении к DNS-серверу Windows AD

Пример:

dig SRV _ldap._tcp.windomain.ru

; <<>> DiG 9.11.3-1ubuntu1.5-Debian <<>> SRV _ldap._tcp.windomain.ru
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 16281
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ad69f89824966028 (echoed)
;; QUESTION SECTION:
;_ldap._tcp.windomain.ru. IN SRV

;; Query time: 0 msec
;; SERVER: 10.0.2.10#53(10.0.2.10)
;; WHEN: Fri Dec 06 08:52:19 MSK 2019
;; MSG SIZE rcvd: 64

Ошибка возникает из-за того, что DNS-сервер Windows AD, вопреки действующим стандартам, считает ошибкой низвестные ему опции запроса (стандарты требуют просто игнорировать такие опции).

Вариант обхода — использовать в команде dig опцию +nocookie (или +noends):

dig SRV _ldap._tcp.windomain.ru +nocookie

; <<>> DiG 9.11.3-1ubuntu1.5-Debian <<>> SRV _ldap._tcp.windomain.ru +nocookie
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46065
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;_ldap._tcp.windomain.ru. IN SRV

;; ANSWER SECTION:
_ldap._tcp.windomain.ru. 600 IN SRV 0 100 389 swin.windomain.ru.
_ldap._tcp.windomain.ru. 900 IN SRV 0 100 389 ad.windomain.ru.

;; ADDITIONAL SECTION:
swin.windomain.ru. 3600 IN A 10.0.2.10
ad.windomain.ru. 900 IN A 10.0.2.250

;; Query time: 0 msec
;; SERVER: 10.0.2.10#53(10.0.2.10)
;; WHEN: Fri Dec 06 08:58:06 MSK 2019
;; MSG SIZE rcvd: 156

Источник

  1. Problems setting up samba bind9_dlz on Ubuntu 18.04

    I followed the following guides to setup samba as an additional active directory server to my windows server with bind9 dns:

    https://www.tecmint.com/join-additio…r-replication/
    https://wiki.samba.org/index.php/BIN…roubleshooting

    The active directory replication works, but the dns replication does not work. When I’m running «samba_dnsupdate —all-names» I get the following output:
    ; TSIG error with server: tsig verify failure
    ; TSIG error with server: tsig verify failure
    update failed: REFUSED
    ; TSIG error with server: tsig verify failure
    update failed: REFUSED
    ; TSIG error with server: tsig verify failure
    ; TSIG error with server: tsig verify failure
    ; TSIG error with server: tsig verify failure
    ; TSIG error with server: tsig verify failure
    ; TSIG error with server: tsig verify failure
    ; TSIG error with server: tsig verify failure
    ; TSIG error with server: tsig verify failure
    ; TSIG error with server: tsig verify failure
    ; TSIG error with server: tsig verify failure
    ; TSIG error with server: tsig verify failure
    ; TSIG error with server: tsig verify failure
    ; TSIG error with server: tsig verify failure
    ; TSIG error with server: tsig verify failure
    ; TSIG error with server: tsig verify failure
    ; TSIG error with server: tsig verify failure
    ; TSIG error with server: tsig verify failure
    Failed update of 19 entries

    Here is a list of versions:
    Ubuntu: 18.04
    Samba: 4.7.6-Ubuntu
    bind9: 9.11.3-1ubuntu1.11-UbuntuAnd this is my smb.conf:

    [global]
    netbios name = DC01
    realm = DOMAIN.COM
    server role = active directory domain controller
    workgroup = DOMAIN.COM
    dns forwarder = 172.17.1.1
    idmap_ldb:use rfc2307 = yes

    template shell = /bin/bash
    winbind use default domain = true
    winbind offline logon = false
    winbind nss info = rfc2307
    winbind enum users = yes
    winbind enum groups = yes
    server services = -dns

    [netlogon]
    path = /var/lib/samba/sysvol/domain.com/scripts
    read only = No

    [sysvol]
    path = /var/lib/samba/sysvol
    read only = No

    I’m not really sure if samba is even using bind9. I’ve enabled the logging of bind9, but I cannot see any logs when running the dns update. Did I miss a step to activate the bind9 module?

    Last edited by b-david; November 22nd, 2019 at 02:08 PM.

  2. Re: Problems setting up samba bind9_dlz on Ubuntu 18.04

    I’d suggest contacting the Samba mailing lists.
    They are usually quite willing to help and many of the Samba developers post there.
    Many of the online guides for Samba are quite out of date.

  3. Re: Problems setting up samba bind9_dlz on Ubuntu 18.04

  4. Re: Problems setting up samba bind9_dlz on Ubuntu 18.04

    As far as I understand this only disables the samba integrated dns server. I found this in the following guide:

    https://wiki.samba.org/index.php/Cha…_a_Samba_AD_DC

  5. Re: Problems setting up samba bind9_dlz on Ubuntu 18.04

    What if you use that rather than BIND?

  6. Re: Problems setting up samba bind9_dlz on Ubuntu 18.04

    I’ve just tried that, but I’m getting the exact same errors with the internal service.

  7. Re: Problems setting up samba bind9_dlz on Ubuntu 18.04

    I was now able to solve the problem with some hints from the samba mailing list. Here is the link to the discussion:

    https://lists.samba.org/archive/samb…er/227160.html

Источник

After adding a user to a group in Active Directory and looking for that group to appear with the user on a linux server linked to AD via SSSD, noticing that the group is not added to the user (even after restarting the sssd service).

Checking the SSSD daemon status, I see…

[root@airflowetl ~]# systemctl status sssd
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2020-01-21 15:54:14 HST; 9min ago
 Main PID: 87108 (sssd)
   CGroup: /system.slice/sssd.service
           ├─87108 /usr/sbin/sssd -i --logger=files
           ├─87111 /usr/libexec/sssd/sssd_be --domain co.local --uid 0 --gid 0 --logger=files
           ├─87112 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
           └─87113 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files

Jan 21 15:54:14 airflowetl.co.local sssd_be[87111]: GSSAPI client step 1
Jan 21 15:54:14 airflowetl.co.local sssd_be[87111]: GSSAPI client step 1
Jan 21 15:54:14 airflowetl.co.local sssd_be[87111]: GSSAPI client step 1
Jan 21 15:54:14 airflowetl.co.local sssd_be[87111]: GSSAPI client step 2
Jan 21 15:54:14 airflowetl.co.local systemd[1]: Started System Security Services Daemon.
Jan 21 15:54:15 airflowetl.co.local sssd[87108]: ; TSIG error with server: tsig verify failure
Jan 21 15:54:15 airflowetl.co.local sssd[87108]: update failed: REFUSED
Jan 21 15:54:15 airflowetl.co.local sssd[87108]: ; TSIG error with server: tsig verify failure
Jan 21 15:54:15 airflowetl.co.local sssd[87108]: update failed: REFUSED
Jan 21 16:00:40 airflowetl.co.local sssd[be[co.local]][87111]: Warning: user would have been denie....
Hint: Some lines were ellipsized, use -l to show in full.

I’m guessing the

update failed: REFUSED

part is the problem here.

For further reference, the server’s /etc/sssd/sssd.conf file looks like…

[root@airflowetl ~]# cat /etc/sssd/sssd.conf

[sssd]
domains = co.local
config_file_version = 2
services = nss, pam

[domain/co.local]
ad_domain = co.local
krb5_realm = CO.LOCAL
realmd_tags = manages-system joined-with-samba
cache_credentials = False
id_provider = ad
krb5_store_password_if_offline = False
default_shell = /bin/bash
ldap_id_mapping = False
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_group_gid_number = gidNumber
use_fully_qualified_names = False
fallback_homedir = /home/%u
access_provider = ad
default_domain_suffix = co.local

Some OS info:

[root@airflowetl ~]# lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: CentOS
Description:    CentOS Linux release 7.4.1708 (Core)
Release:        7.4.1708
Codename:       Core

Note that we recently changed our primary DNS server and the /etc/resolv.conf file does reflect these changes, but I suspect that this is very related.

Does anyone with more experience with SSSD have any debugging tips or know what could be going wrong here?

UPDATE:

after checking a server where the DNS was not updated (rather the server is using the secondary DNS), when initially checking sssd status I see

[root@hwdatalake datalake]# systemctl status sssd
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2020-01-22 12:55:22 HST; 21h ago
 Main PID: 95837 (sssd)
   CGroup: /system.slice/sssd.service
           ├─95837 /usr/sbin/sssd -i --logger=files
           ├─95838 /usr/libexec/sssd/sssd_be --domain co.local --uid 0 --gid 0 --logger=files
           ├─95839 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
           └─95840 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files

Jan 22 12:55:17 hwdatalake.co.local systemd[1]: Starting System Security Services Daemon...
Jan 22 12:55:17 hwdatalake.co.local sssd[95837]: Starting up
Jan 22 12:55:17 hwdatalake.co.local sssd[be[co.local]][95838]: Starting up
Jan 22 12:55:22 hwdatalake.co.local sssd[pam][95840]: Starting up
Jan 22 12:55:22 hwdatalake.co.local sssd[nss][95839]: Starting up
Jan 22 12:55:22 hwdatalake.co.local systemd[1]: Started System Security Services Daemon.
Jan 22 12:56:50 hwdatalake.co.local sssd[be[co.local]][95838]: Backend is offline

then after restarting the service, see

[root@hwdatalake datalake]# systemctl status sssd
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2020-01-23 10:19:05 HST; 15s ago
 Main PID: 98653 (sssd)
   CGroup: /system.slice/sssd.service
           ├─98653 /usr/sbin/sssd -i --logger=files
           ├─98654 /usr/libexec/sssd/sssd_be --domain co.local --uid 0 --gid 0 --logger=files
           ├─98655 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
           └─98656 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files

Jan 23 10:18:54 hwdatalake.co.local systemd[1]: Starting System Security Services Daemon...
Jan 23 10:18:54 hwdatalake.co.local sssd[98653]: Starting up
Jan 23 10:18:54 hwdatalake.co.local sssd[be[co.local]][98654]: Starting up
Jan 23 10:19:05 hwdatalake.co.local sssd[nss][98655]: Starting up
Jan 23 10:19:05 hwdatalake.co.local sssd[pam][98656]: Starting up
Jan 23 10:19:05 hwdatalake.co.local systemd[1]: Started System Security Services Daemon.

and checking the groups for a given user shows the updated groups being correctly associated with the user. Yet even then, after some time, when checking again I see that the

Jan 23 10:20:33 hwdatalake.co.local sssd[be[co.local]][98654]: Backend is offline

error is back and at some time even later checking the groups for the user is back to the old settings.

Источник


Description


Bernhard Loos



2016-11-11 17:30:43 UTC

Description of problem:
I have a Fedora 25 Workstation Machine and 2 Debian Jessie machines in a Windows Active Directory domain. All of them were joined with realmd and use sssd.
None of them are able to update their PTR DNS records which makes reverse lookups impossible which in turn leads to various kerberos problems.
The actual problem appears to be, that nsupdate can't authenticate to the AD.
The error message is "; TSIG error with server: tsig verify failure".


Version-Release number of selected component (if applicable):
sssd-1.14.2-1
bind-utils-9.10.3-2.P3
krb5-libs-1.14.4-4
samba-client-4.5.0-3


How reproducible:
always


Steps to Reproduce:
1. join the machine to the domain using realmd
2. stop the sssd service
3. run sssd -d 0xffff -i as root
4. search the point where sssd tries to update the dns records with nsupdate
I can't reproduce the error message with plain nsupdate on fedora (I get a different kerberos error), but I can do so on debian.

Actual results:
The nsupdate command prints "; TSIG error with server: tsig verify failure" during update of the A (forward) records and returns 2 (funnily the update still succeeds). sssd interprets this as an error and doesn't even try to update the PTR (reverse) record. The reverse record update needs TSIG authentication, of it fails.

Expected results:
The PTR record in the AD gets created and nslookup of the IP of the machine succeeds.

Additional info:
This problem also affects debian jessie in a similar form.


Comment 2


Bernhard Loos



2016-11-15 19:06:33 UTC

With the HOWTO (by the way the commands given there are invalid) I managed to reproduce the problem with plain nsupdate. No matter what I do, the DNS server doesn't accept the kerberos ticket, I always get the "; TSIG error with server: tsig verify failure" error.
I did set up a new AD domain for testing pruporses and unfortunately I can't reproduce the problem there (nsupdate works as expected).

I also did some tracing with wireshark to figure out how Windows 7 behaves.
It updates the A record with unauthenticated DNS update commands and the PTR record is set by the DHCP server, by request of the windows DHCP client. If I use the fqdn.fqdn option in dhclient, I can get the same behavior and everything seems to work.

I'm not exactly sure what the best solution would look like, maybe to configure dhclient to match the Windows behavior.
I can provide additional information but I'm not all that sure what would be helpful. A debug log from nsupdate doesn't seem to contain anything useful.


Comment 3


Jakub Hrozek



2016-11-16 10:40:35 UTC

I think it would still be helpful to provide the (sanitized if needed) nsupdate message dump, at least as a reference for other users..


Comment 4


Bernhard Loos



2016-11-16 12:45:54 UTC

I managed to reproduce the problem in my test setup. It's actually very simple, but I got confused by a missing reverse lookup zone in our AD :/

Basically, it's enough to enable unsafe dynamic DNS update in the DNS server configuration.
In this case the GSS-TSIG authentication always fails. The DNS server still runs the query and the update succeeds, but nsupdate returns an error (return code 2).
I'm not sure, if nsupdate should return success in this case, or if sssd should ignore this return code. Windows clients always seem to try an unauthenticated update first and switch to an authenticated update if this fails.

I will attach an nsupdate log, if you need any further informations, please don't hesitate to ask.


Comment 5


Bernhard Loos



2016-11-16 12:48:16 UTC

Created attachment 1221136 [details]
nsupdate log with authentication

nsupdate command used:
server dc.testdomain.example.com
zone testdomain.example.com
update del fedora25.testdomain.example.com A
send


Comment 6


Jakub Hrozek



2016-11-16 13:19:19 UTC

Interesting, I'm not sure what leads nsupdate to return 2 if the update in fact succeeds. Maybe Tomas (CC) knows?


Comment 7


Tomáš Hozza



2016-11-21 13:35:31 UTC

I'm adding Petr Mensik (soon to be official BIND maintainer) to CC as I will not have time to look into this in near future and I would have to inspect the code to tell where may be the problem.


Comment 11


Fedora End Of Life



2017-11-16 18:55:58 UTC

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.


Comment 12


Fedora End Of Life



2017-12-12 10:35:19 UTC

Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Источник

Понравилась статья? Поделить с друзьями:
  • Tsig error with server tsig indicates error
  • Tsgame exe ошибка приложения
  • Tsc ошибка наличия риббона
  • Tsa ошибка хонда crv
  • Tsa на хонде что это ошибка