Sssd tsig error with server tsig verify failure - Исправление ошибок и поиск оптимальных решений проблем

Содержание

Arch Linux
#1 2021-03-08 11:00:48
samba dynamic updates — TSIG error
#2 2021-03-08 11:40:41
Re: samba dynamic updates — TSIG error
#3 2021-03-08 13:35:23
Re: samba dynamic updates — TSIG error
#4 2021-03-08 13:50:50
Re: samba dynamic updates — TSIG error
#5 2021-03-08 13:55:54
Re: samba dynamic updates — TSIG error
#6 2021-03-08 14:43:36
Re: samba dynamic updates — TSIG error
#7 2021-03-08 14:48:37
Re: samba dynamic updates — TSIG error
#8 2021-03-08 19:29:38
Re: samba dynamic updates — TSIG error
#9 2021-03-08 22:13:12
Re: samba dynamic updates — TSIG error
sssd: tkey query failed (dyndns_update) #5383
Comments
Footer
ddns tsig verify failure when forwarding updates to PDNS #2911
Comments
Minor Dynamic DNS fixes #66
Conversation
Choose a reason for hiding this comment

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: tkey query failed (dyndns_update) #5383

On a running NethServer 7.4 with local AD accounts provider an error message is logged to the journal every day at the same hour.

Steps to reproduce

Expected behavior

No error in the journal

Actual behavior

The query matches the same error line in the same hour every day and when sssd is restarted

Components

See also

Thanks to @fasttech and André Wismer

The text was updated successfully, but these errors were encountered:

krb5_realm = DPNET.NETHESIS.IT
default_domain_suffix = dpnet.nethesis.it

The DynDNS update query fails. In journalctl -u sssd :

Samba DC log (increased log level)

tcpdump output, tcpdump -i br0 -s 65535 -w capture.pcap ‘host 192.168.122.55 and port 53’ :

The same issue is reproducible on a plain CentOS7 too.

The «tkey query failed» lines correspond to failed PTR updates. They can be disabled by setting dyndns_update_ptr = false in sssd.conf

However «tsig verify failure» lines still remain. It seems not to be a real issue though:

Unfortunately also TSIG failure is reported as an error, even if server reported success and nsupdate understands it. — https://bugzilla.redhat.com/show_bug.cgi?id=1394320#c9

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

ddns tsig verify failure when forwarding updates to PDNS #2911

I get a tsig verify failure when attempting to forward dynamic updates to a powerDNS authoritative master server via a BIND server and the allow-update-forwarding BIND option . This seems to be an issue with how powerDNS signs the response. I’ve tested the same configuration with BIND as the master and I get a proper response.

I’m running PowerDNS version: 3.4.7 compiled on RHEL 6 with gcc-c++-4.4.7-16.el6.x86_64 and boost-devel-1.41.0-27.el6.x86_64

Steps to reproduce: Configure BIND as a slave for a zone and enable update forwarding, PDNS as master and protect updates with TSIG. Run nsupdate against the slave server. See below for detail configuration.

I send TSIG signed dynamic update requests via the nsupdate utility to the slave server (BIND). The BIND server forwards the request to PDNS. This seems to be working — PDNS receives the request and validates the TSIG key sent by nsupdate, it also makes the requested dynamic update. However, there seems to be an issue with the PowerDNS TSIG response. Nsupdate reports an invalid tsig response (‘TSIG error with server: tsig verify failure’). I also have the same issue if I use dnspython library to send updates.

This seems to be an issue with PowerDNS. If I use BIND as both master and slave I do not get the same TSIG error.

The PDNS server is configured as a hidden master and listening on port 5353.

nsupdate in debug mode:

Power DNS domain and domainmetadeta configuration

I’m using ISC BIND 9.9.8 as a slave server and allow dynamic dns update forwarding using BIND’s ‘allow-update-forwarding’ option. The BIND server is listening port 53.

The text was updated successfully, but these errors were encountered:

Источник

Minor Dynamic DNS fixes #66

Conversation

This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters

To provide a bit more information, one of the fixes is to correct NULL being printed here(https://fedorahosted.org/sssd/ticket/3220):

nsupdate_msg_create_common: Creating update message for realm [(null)].

For the other(https://bugzilla.redhat.com/show_bug.cgi?id=1386748), It is not uncommon for nsupdate to successfully update DNS records but report the error below which results in return(2) to be called inside nsupdate code

It is easy to reproduce with AD DNS changing Dynamic DNS to ‘Nonsecure and secure’ on the Zone Properties.

This patch allows PTR records to continue when this happens, however in this case our debug log messages still report failure and I think some improvement should be made here(not sure how exactly though)

It would be nice to correct this at the nsupdate level if this is not the expected behavior also.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

There was a problem hiding this comment.

The reason will be displayed to describe this comment to others. Learn more.

I tried removing line 446 because it creates a blank line in the nsupdate message, but it caused dyndns tests to fail

Thank you for the patch. I wonder if you were actually able to reproduce the bug? If so, can you help me reproduce it locally?

Please try reproducing this on a SSSD — AD provider configured system using AD as a DNS server with the below steps:

In the AD Properties of a DNS Forward Zone, change Dynamic Updates drop-down to Nonsecure and secure

Remove A/AAAA and PTR records from Active Directory DNS for the SSSD system

Restart SSSD to trigger the nsupdate call

Check the reverse zone in AD for PTR records, they do not get created but the A/AAAA records do

With the patch, both forward and reverse records should be created, IIRC this was reproducible with Windows Server 2008 R2 and Server 2012.

@jhrozek Do you pan to review the patch?

On Wed, Nov 23, 2016 at 06:05:10AM -0800, lslebodn wrote:

Feel free to take over the review, I’m currently busy with other work.

I let fellow developers to review it.

The commit DYNDNS: Update PTR record after non-fatal error has been successfully tested and confirmed fixed by a SSSD user with RHEL 6 and RHEL7 systems.

Firstly, sorry this patch has been waiting for so long.
I’ll try to reproduce the issue and review it Tomorrow.

btw I’m fine with the patch, I was just waiting for Justin’s confirmation that the patch indeed helps the customer.

But please, go ahead and review it again, I only scrolled through the patch so a second review wouldn’t hurt.

Thank you @fidencio @jhrozek
2 different customers confirmed this fix addressed their issue with the PTR record not being created. If you are not able to easily reproduce easily then perhaps this is sufficient enough of a test.

I’ve tried to reproduce the issue but, so far, I’ve failed (mainly due to a lack of knowledge).
Let me drop a few questions in order to try to understand better how to setup my AD server here and how things are related to each other on server side.

How is the Reverse Lookup Zone created at the first place?

How is the PTR record created at the first place?

When you click in the A/AAAA SSSD entry, is the «Update associated pointer (PTR) record» checkbox enabled?
3.1) In case the checkbox is enabled, is the patch still needed?

Do we know, from SSSD side, what’s the value of this in the AD server?

So far I’m afraid we may change on SSSD’s side something that is responsibility of the server. In other words, that we may end up doing a workaround to solve a mis-configured server (and I really would like to avoid this situation).

@fidencio
No problem, thanks for looking into this.

Once the DNS role is installed, create a Reverse Zone in the AD DNS MMC(right click Reverse-Lookup zones and click New Zone)

The idea is that SSSD will create the forward A and reverse zone PTR records when nsupdate gets called, the testing of this PR would be done with no existing PTR record for this SSSD system.

Yes it is checked, I believe this checkbox only tells AD the update the IP address of the PTR record when the forward A record address is manually updated but this checkbox should not be relevant when there is no existing PTR record
3.1) Yes, because the problem is nsupdate will still not create the Reverse PTR record when the TSIG error is encountered

Sorry, I don’t quite follow this last question.

The root problem here is actually that the error TSIG error with server: tsig verify failure can happen within nsupdate code even when the A/AAAA record is successfully added. When this happens, the nsupdate child process returns non-zero which causes SSSD to consider it a failure and abort the PTR record update operation. I believe there are various reasons which can cause the error mentioned above but I was able to reproduce one of them with the reproducer steps mentioned here in the PR.

This fix will ignore the non-zero update and try to update the PTR record regardless of the nsupdate return code. I am planning on submitting a bug to nsupdate to address the root issue of why we have the TSIG error but in the meantime I think it would be useful to make SSSD more capable of handling updates even when there are errors which could happen with nsupdate.

Actually, the ticket https://fedorahosted.org/sssd/ticket/3227 has a comment from pspacek If the update failed, the records will be incorrect in any case. Personally I think we should try to update all record types and let admins to deal with potential inconsistencies.

Sorry for the long comment, feel free to continue the discussion on IRC or if you have any questions let me know. Thank you @fidencio !

Источник

Источник

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

Источник

11.04.2022

Добрый день.

Подскажите в чем может быть проблема, накатываю свежую систему на ПК, ядро generic, ставлю по инструкции sssd, ввожу в домен, пишет что все успешно, перезагружаю ПК и пытаюсь войти доменным пользователем, на секунду происходит вход и потом выбрасывает на экран логона, и так каждый раз, не пускает никаким доменным пользователем, sssd при этом сообщает что ПК в домене, по логам видно что авторизация вроде как происходит:

Код:

Apr 11 09:21:22 ADMWS-UMZ003 fly-dm: localhost:100[15075]: pam_unix(fly-dm:auth): authentication failure; logname= uid=0 euid=0 tty=localhost:100 ruser= rhost=localhost  user=test@zakaz.local
Apr 11 09:21:22 ADMWS-UMZ003 fly-dm: localhost:100[15075]: pam_sss(fly-dm:auth): authentication success; logname= uid=0 euid=0 tty=localhost:100 ruser= rhost=localhost user=test@zakaz.local
Apr 11 09:21:23 ADMWS-UMZ003 fly-dm: localhost:100[15075]: pam_unix(fly-dm:session): session opened for user test@zakaz.local by (uid=0)
Apr 11 09:21:23 ADMWS-UMZ003 systemd-logind[904]: New session 740 of user test.
Apr 11 09:21:23 ADMWS-UMZ003 systemd: pam_unix(systemd-user:session): session opened for user test by (uid=0)
Apr 11 09:21:23 ADMWS-UMZ003 fly-dm: localhost:100[15075]: pam_unix(fly-dm:session): session closed for user test@zakaz.local
Apr 11 09:21:23 ADMWS-UMZ003 systemd-logind[904]: Removed session 740.

kinit вообще лезет в другой домен, а после перенастройки вечно в ошибку падает:

Код:

kinit: KDC reply did not match expectations while getting initial credentials

oko

11.04.2022

imho, вначале разберитесь с проблемами kinit. Из-за него вся свистопляска. Грубо говоря, не может юзер по Kerberos авторизоваться в домене и, как следствие, в ОС…
Ориентируйтесь по указанной ошибке kinit как, например, тут…

12.04.2022

С kinit разобрался, пришлось полностью настраивать krb5.conf
Но вход в систему все еще не осуществляется, так же не входит даже в консольный режим

oko

12.04.2022

В графике/консоли авторизация невозможна для доменных юзеров или для локальных тоже? Если локальных тоже не пускает, то дело в работе подсистемы pam-аутентификации — нужно копать в эту сторону…
Так-то логи бы посмотреть как syslog, так и на стороне сервера-контроллера домена…

12.04.2022

Не пускает только доменных пользователей, и только при настройке sssd, winbind работает.
Скажите какие именно, скину, заодно и сам может пойму куда смотреть

oko

12.04.2022

to JoKeR174
Классика в виде /var/log/auth.log, /var/log/syslog (если туда сыпятся все события — проверяйте по *.* в /etc/rsyslog.conf), и аналогичных системных журналов сервера-контроллера (Система, Безопасность). Нужны события по отбою авторизации. Контроллер домена каким-нибудь файрволлом не прикрыт случайно (это так, на всякий случай уточнение)?
По-прежнему есть подозрение, что косячит Kerberos. Тикет запрашивается и отрабатывает корректно при вводе правильных уч.данных? И покажите, пожалуй, финальный вариант /etc/krb5.conf…

13.04.2022

Все куски логов в момент попытки входа
На контроллере домена в эти моменты зарегистрированы такие события:

Код:

Запрошен билет проверки подлинности Kerberos(TGT).

Сведения об учетной записи:
    Имя учетной записи:        mov
    Предоставленное имя сферы:    ZAKAZ.LOCAL
    Идентификатор пользователя:            ZAKAZmov

Сведения о службе:
    Имя службы:        krbtgt
    Код службы:        ZAKAZkrbtgt

Сведения о сети:
    Адрес клиента:        192.168.151.109
    Порт клиента:        46763

Дополнительные сведения:
    Параметры билета:        0x50010010
    Код результата:        0x0
    Тип шифрования билета:    0x12
    Тип предварительной проверки подлинности:    2

Сведения о сертификате:
    Имя поставщика сертификата:     
    Серийный номер сертификата: 
    Отпечаток сертификата:     

Сведения о сертификате предоставляются только в том случае, если сертификат использовался для предварительной проверки подлинности.

Типы предварительной проверки подлинности, параметры билета, типы шифрования и коды результата определены в стандарте RFC 4120.

Код:

Запрошен билет проверки подлинности Kerberos(TGT).

Сведения об учетной записи:
    Имя учетной записи:        mov
    Предоставленное имя сферы:    ZAKAZ.LOCAL
    Идентификатор пользователя:            ZAKAZmov

Сведения о службе:
    Имя службы:        krbtgt
    Код службы:        ZAKAZkrbtgt

Сведения о сети:
    Адрес клиента:        ::ffff:192.168.151.109
    Порт клиента:        37984

Дополнительные сведения:
    Параметры билета:        0x50010010
    Код результата:        0x0
    Тип шифрования билета:    0x12
    Тип предварительной проверки подлинности:    2

Сведения о сертификате:
    Имя поставщика сертификата:     
    Серийный номер сертификата: 
    Отпечаток сертификата:     

Сведения о сертификате предоставляются только в том случае, если сертификат использовался для предварительной проверки подлинности.

Типы предварительной проверки подлинности, параметры билета, типы шифрования и коды результата определены в стандарте RFC 4120.

Код:

Запрошен билет службы Kerberos.

Сведения об учетной записи:
    Имя учетной записи:        mov@ZAKAZ.LOCAL
    Домен учетной записи:        ZAKAZ.LOCAL
    GUID входа:        {d5a06320-9143-6ff6-e2bd-99aab7fa2320}

Сведения о службе:
    Имя службы:        ADMWS-UMZ003$
    Идентификатор службы:        ZAKAZADMWS-UMZ003$

Сведения о сети:
    Адрес клиента:        ::ffff:192.168.151.109
    Порт клиента:        37986

Дополнительные сведения:
    Параметры билета:        0x50810000
    Тип шифрования билета:    0x12
    Код ошибки:        0x0
    Службы передачи:    -

Данное событие возникает каждый раз при запросе доступа к ресурсу, такому как компьютер или служба Windows.  Поле "Имя службы" указывает ресурс, доступ к которому запрашивался.

Это событие можно связать с событиями входа Windows, сравнивая поля "GUID входа" каждого из событий.  Событие входа регистрируется на компьютере, к которому запрашивался доступ. Часто этот компьютер отличается от контроллера домена, выдавшего билет службы.

Параметры билета, типы шифрования и коды ошибок определены в стандарте RFC 1510.

При запросе тикета вроде все отрабатывается нормально, ошибок нет, в klist отображается

Код:

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: mov@ZAKAZ.LOCAL

Valid starting       Expires              Service principal
13.04.2022 08:34:36  13.04.2022 18:34:36  krbtgt/ZAKAZ.LOCAL@ZAKAZ.LOCAL
        renew until 14.04.2022 08:34:34

Вот krb5

Код:

[libdefaults]
    default_realm = ZAKAZ.LOCAL
    kdc_timesync = 1
    ccache_type = 4
    forwardable = true
    proxiable = true
    fcc-mit-ticketflags = true
    dns_lookup_realm = false
    dns_lookup_kdc = true
    v4_instance_resolve = false
    v4_name_convert = {
        host = {
            rcmd = host
            ftp = ftp
        }
        plain = {
            something = something-else
        }
    }

[realms]
    ZAKAZ.LOCAL = {
    admin_server = dc1.zakaz.local
    kdc = dc1.zakaz.local
    kdc = dc2.zakaz.local
    default_domain = ZAKAZ.LOCAL
    }

[domain_realm]
    .zakaz.local = ZAKAZ.LOCAL
    zakaz.local = ZAKAZ.LOCAL
[login]
    krb4_convert = false
    krb4_get_tickets = false

6 КБ
Просмотры: 45
4 КБ
Просмотры: 47

oko

13.04.2022

to JoKeR174
Мде, особых проблем не вижу. Разве что директива «default_domain» обычно мелкими описывает домен — есть же строки конвертации в секции domain_realm…
Еще dns_lookup_realm = false вообще бы убрал. И, возможно, имеет смысл добавить в секцию libdefaults директивы default_tgs_enctypes и default_tkt_enctypes с описанием разрешенных стандартов шифрования. Особенно, если в вашем домене все переведено на AES и RC4/DES/прочее явно заблокированы в политиках безопасности. Иначе билет-то будет запрашиваться, но по минимальному стандарту шифрования, что приведет к сбою его выдачи и эксплуатации. Впрочем, klist у вас отрабатывает, значит, дело не в этом…
Плохо, что syslog пустой — надеялся там увидеть корень проблемы…

13.04.2022

При попытке зайти в консольный режим syslog выдает

Код:

Apr 13 15:34:07 ADMWS-UMZ003 systemd[1]: Stopping System Security Services Daemon...
Apr 13 15:34:07 ADMWS-UMZ003 sssd[nss]: Shutting down
Apr 13 15:34:07 ADMWS-UMZ003 sssd[be[zakaz.local]]: Shutting down
Apr 13 15:34:07 ADMWS-UMZ003 sssd[pam]: Shutting down
Apr 13 15:34:07 ADMWS-UMZ003 sssd[ifp]: Shutting down
Apr 13 15:34:07 ADMWS-UMZ003 sssd[4575]: Attempted to unregister path (path[0] = org path[1] = freedesktop) which isn't registered
Apr 13 15:34:07 ADMWS-UMZ003 sssd[4575]: Attempted to unregister path (path[0] = org path[1] = freedesktop) which isn't registered
Apr 13 15:34:07 ADMWS-UMZ003 sssd[4575]: Attempted to unregister path (path[0] = org path[1] = freedesktop) which isn't registered
Apr 13 15:34:07 ADMWS-UMZ003 systemd[1]: Stopped System Security Services Daemon.
Apr 13 15:34:07 ADMWS-UMZ003 systemd[1]: Starting System Security Services Daemon...
Apr 13 15:34:08 ADMWS-UMZ003 sssd: Starting up
Apr 13 15:34:08 ADMWS-UMZ003 sssd[be[zakaz.local]]: Starting up
Apr 13 15:34:08 ADMWS-UMZ003 sssd[nss]: Starting up
Apr 13 15:34:08 ADMWS-UMZ003 sssd[ifp]: Starting up
Apr 13 15:34:08 ADMWS-UMZ003 sssd[pam]: Starting up
Apr 13 15:34:08 ADMWS-UMZ003 systemd[1]: Started System Security Services Daemon.
Apr 13 15:34:09 ADMWS-UMZ003 sssd[23389]: ; TSIG error with server: tsig verify failure
Apr 13 15:34:09 ADMWS-UMZ003 sssd[23389]: update failed: REFUSED
Apr 13 15:34:09 ADMWS-UMZ003 sssd[23389]: ; TSIG error with server: tsig verify failure
Apr 13 15:34:09 ADMWS-UMZ003 sssd[23389]: update failed: REFUSED
Apr 13 15:34:33 ADMWS-UMZ003 systemd[1]: getty@tty1.service: Service has no hold-off time, scheduling restart.
Apr 13 15:34:33 ADMWS-UMZ003 systemd[1]: Stopped Getty on tty1.
Apr 13 15:34:33 ADMWS-UMZ003 systemd[1]: Started Getty on tty1.
Apr 13 15:34:53 ADMWS-UMZ003 systemd[1]: getty@tty1.service: Service has no hold-off time, scheduling restart.
Apr 13 15:34:53 ADMWS-UMZ003 systemd[1]: Stopped Getty on tty1.
Apr 13 15:34:53 ADMWS-UMZ003 systemd[1]: Started Getty on tty1.

oko

13.04.2022

to JoKeR174
А покажите-ка выхлоп systemctl status sssd

13.04.2022

to JoKeR174
А покажите-ка выхлоп systemctl status sssd

Код:

● sssd.service - System Security Services Daemon
   Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2022-04-13 15:34:08 +05; 32min ago
 Main PID: 23389 (sssd)
    Tasks: 5 (limit: 4915)
   CGroup: /system.slice/sssd.service
           ├─23389 /usr/sbin/sssd -i --logger=files
           ├─23391 /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain zakaz.local --uid 0 --gid 0 --logger=files
           ├─23392 /usr/lib/x86_64-linux-gnu/sssd/sssd_nss --uid 0 --gid 0 --logger=files
           ├─23393 /usr/lib/x86_64-linux-gnu/sssd/sssd_pam --uid 0 --gid 0 --logger=files
           └─23394 /usr/lib/x86_64-linux-gnu/sssd/sssd_ifp --uid 0 --gid 0 --logger=files

oko

13.04.2022

to JoKeR174
Странно, ожидал увидеть ошибку TSIG как в случае локального входа. Тогда было бы как тут…
Вообще, нашел свою же заметку про sssd в AstraLinux. Посмотрите, проверьте, возможно поможет. Пока у меня иных мыслей нет…

14.04.2022

Попробовал, ничего не изменилось к сожалению.
При всем при этом через терминал и команду “su login” получается залогиниться под доменным пользователем, и через ssh login@127.0.01 получается

oko

14.04.2022

to JoKeR174
Все страннее и страннее (с)
Значит, Kerberos и механизмы авторизации в домене отрабатывают. Хотя… неплохо бы посмотреть трафик по-середине, что же там передается в момент login по ssh и чего не передается при стандартном графическом входе…
И это не может быть проблема Fly-DM/WM, поскольку консольный вход под доменным юзером у вас также не работает…
Тогда у меня остается один вариант: косячит демон sssd — служба не стартует до момента авторизации в системе локального юзера/админа. Проверить элементарно — зайти под локальным, разлогиниться и зайти под доменным. Впрочем, не до конца понял — этот момент тоже пробовали?

15.04.2022

Да, так пробовал, пробовал открывать сессию в окне, не пускает
Момент авторизации по ssh:

Код:

Apr 15 08:26:02 ADMWS-UMZ003 sshd[10493]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1  user=mov
Apr 15 08:26:03 ADMWS-UMZ003 sshd[10493]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1 user=mov
Apr 15 08:26:03 ADMWS-UMZ003 sshd[10493]: Accepted password for mov from 127.0.0.1 port 40736 ssh2
Apr 15 08:26:03 ADMWS-UMZ003 sshd[10493]: pam_unix(sshd:session): session opened for user mov by (uid=0)
Apr 15 08:26:03 ADMWS-UMZ003 systemd-logind[893]: New session 52 of user mov.
Apr 15 08:26:03 ADMWS-UMZ003 systemd: pam_unix(systemd-user:session): session opened for user mov by (uid=0)
Apr 15 08:26:03 ADMWS-UMZ003 sshd[10493]: lastlog_write_entry: Error writing to /var/log/lastlog: File too large

Код:

Apr 15 08:26:03 ADMWS-UMZ003 systemd[1]: Created slice User Slice of mov.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[1]: Starting User Manager for UID 975401130...
Apr 15 08:26:03 ADMWS-UMZ003 systemd[1]: Started Session 52 of user mov.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Listening on GnuPG network certificate management daemon.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Reached target Timers.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Reached target Paths.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Listening on GnuPG cryptographic agent and passphrase cache.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Reached target Sockets.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Reached target Basic System.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Reached target Default.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Startup finished in 22ms.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[1]: Started User Manager for UID 975401130.

oko

15.04.2022

to JoKeR174
В порядке бреда — удалите файл /var/log/lastlog и либо рестартаните rsyslog, либо перезагрузитесь (понятно, что это в минимуме решит трабблу с ошибкой в логе, но вдруг на lastlog еще что-то завязано — надо бы поглядеть)…
Еще мне откровенно не нравится, что по PAM авторизацию отбивает, а дальше sssd ее принимает. Не настолько хорошо разбираюсь в sssd-интеграции в домен, чтобы делать выводы. Но, кажись, проблемное место найдено, потому что процессы локального входа могут быть по-прежнему завязаны на PAM, который не срабатывает. Или в /etc/ssh/sshd_config параметр UsePam = no?…

15.04.2022

После удаления стал ругаться что файла нет, после создания руками начинает также ругаться на этот файл.
Впрочем при логоне su login такой ошибки нет.
В sshd_config параметр UsePam yes.
По поводу PAM авторизации, пробовал сменить очередность, тогда отбивает авторизацию напрочь:

Код:

Apr 15 15:19:15 ADMWS-UMZ003 su[18894]: pam_sss(su:auth): authentication failure; logname=adminumz uid=1000 euid=0 tty=/dev/pts/0 ruser=adminumz rhost= user=mov
Apr 15 15:19:15 ADMWS-UMZ003 su[18894]: pam_sss(su:auth): received for user mov: 7 (Сбой при проверке подлинности)
Apr 15 15:19:18 ADMWS-UMZ003 su[18894]: pam_unix(su:auth): authentication failure; logname=adminumz uid=1000 euid=0 tty=/dev/pts/0 ruser=adminumz rhost=  user=mov
Apr 15 15:19:20 ADMWS-UMZ003 su[18894]: pam_authenticate: Authentication failure
Apr 15 15:19:20 ADMWS-UMZ003 su[18894]: FAILED su for mov by adminumz
Apr 15 15:19:20 ADMWS-UMZ003 su[18894]: - /dev/pts/0 adminumz:mov

Попытка входа через консоль:

Код:

Apr 15 15:21:28 ADMWS-UMZ003 login[901]: pam_sss(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=mov
Apr 15 15:21:28 ADMWS-UMZ003 login[901]: pam_sss(login:auth): received for user mov: 7 (Authentication failure)
Apr 15 15:21:31 ADMWS-UMZ003 login[901]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser= rhost=  user=mov
Apr 15 15:21:34 ADMWS-UMZ003 login[901]: FAILED LOGIN (1) on '/dev/tty1' FOR 'mov', Authentication failure

ssh:

Код:

:26 ADMWS-UMZ003 sshd[18984]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1 user=mov
Apr 15 15:23:26 ADMWS-UMZ003 sshd[18984]: pam_sss(sshd:auth): received for user mov: 7 (Authentication failure)
Apr 15 15:23:26 ADMWS-UMZ003 sshd[18984]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1  user=mov
Apr 15 15:23:28 ADMWS-UMZ003 sshd[18984]: Failed password for mov from 127.0.0.1 port 45184 ssh2

oko

15.04.2022

to JoKeR174
Ругается он, очевидно, из-за некорректных прав доступа к файлу. Но не суть…
Попробуйте командой sss_debuglevel 7 включить полное логирование sssd и как тут добавить логирование для PAM. Дальше еще раз зайти-выйти и посмотрим, что получится…
Такое ощущение, что PAM у вас не полностью привязан к sssd…

18.04.2022

krb5_child

Код:

(Mon Apr 18 09:37:46 2022) [[sssd[krb5_child[5799]]]] [privileged_krb5_setup] (0x0080): Cannot open the PAC responder socket
(Mon Apr 18 09:37:47 2022) [[sssd[krb5_child[5799]]]] [sss_send_pac] (0x0040): sss_pac_make_request failed [-1][2].
(Mon Apr 18 09:37:47 2022) [[sssd[krb5_child[5799]]]] [validate_tgt] (0x0040): sss_send_pac failed, group membership for user with principal [mov@ZAKAZ.LOCAL@ZAKAZ.LOCAL] might not be correct.

sssd_nss

Код:

(Mon Apr 18 09:37:36 2022) [sssd[nss]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.
(Mon Apr 18 09:37:36 2022) [sssd[nss]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.
(Mon Apr 18 09:37:36 2022) [sssd[nss]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.
(Mon Apr 18 09:37:37 2022) [sssd[nss]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.
(Mon Apr 18 09:37:46 2022) [sssd[nss]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.
(Mon Apr 18 09:37:47 2022) [sssd[nss]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.
(Mon Apr 18 09:37:48 2022) [sssd[nss]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.
(Mon Apr 18 09:37:50 2022) [sssd[nss]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.

sssd_pam

Код:

(Mon Apr 18 09:37:46 2022) [sssd[pam]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.
(Mon Apr 18 09:37:47 2022) [sssd[pam]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.

sssd_zakaz.local

Код:

(Mon Apr 18 09:37:36 2022) [sssd[be[zakaz.local]]] [check_if_pac_is_available] (0x0040): find_user_entry failed.
(Mon Apr 18 09:37:36 2022) [sssd[be[zakaz.local]]] [check_if_pac_is_available] (0x0040): find_user_entry failed.
(Mon Apr 18 09:37:36 2022) [sssd[be[zakaz.local]]] [sysdb_get_real_name] (0x0040): Cannot find user [fly-dm@zakaz.local] in cache
(Mon Apr 18 09:37:36 2022) [sssd[be[zakaz.local]]] [sysdb_get_real_name] (0x0040): Cannot find user [fly-dm@zakaz.local] in cache

oko

18.04.2022

to JoKeR174
Откровенно говоря, смущает вот это:

У вас там в krb-конфигурациях нигде нет дубляжа домена случайно?
И вот это тоже:

Выходит, что fly-dm (уч.запись для сессии связи Fly-DM с X-Server) почему-то вместо PAM локально ломится в домен через sssd. Не ясно…

Источник

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.

Источник