Tkey query failed gssapi error major unspecified gss failure

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.

Источник

Samba4 DNS bugs

Перодически раз где-то в три дня приходится рестартить самбу, поскольку доменные ПК не могут получить имена других ПК.

DNS_backend=SAMBA_INTERNAL, на всех ПК static ip.

Значение allow dns updates какое стоит? На днях была похожая проблема, правда без потери Kerberos, временно решилось выставлением данного параметра значения nonsecure

Спасибо, попробуем. У меня стояло:

Сосбтвенно, я к тому что данный DC перенесенный с Win2008. И при вывовде samba-tool drs showrepl у меня был некоторый геморой ))

Вот здесь написано, что нужно создать:

Все, разобрался с GUID. По вашему совету выставил nonsecure и пока что-то вроде все ок. Погоняю несколько дней — посмотрю.

Теперь вот такой ВОПРОС: при использовании DNS-бэкенда SAMBA_INTERNAL приходится все компы добавлять в остнастке DNS вручную. Как сделать чтобы сами регистрировались?

Насчет добавления вручную не подскажу, при добавление в домен автоматически добавляются, а без домена, присутствие хоста в записях днс в моем случае не обязательно, поэтому не вникал почему так.
А вообще пришел к выводу что лучше использовать bind.
еще переодически встречал в поисковиках что какая то проблема с зоной local, но о чем конкретно речь там не смотрел.

Источник

Stuck joining Ubuntu Studio 22.04.1 to Active Directory

I am trying to join my freshly installed Ubuntu Studio 22.04.1 to an AD domain hosted on my Synology NAS, by following the instructions in this white paper, starting on page 11 («Joining After Installation via SSSD»).

When I perform the recommended checks on pages 19-20 everything looks fine, but when I run:

as suggested on page 21, I get the expected output as shown in the whitepaper, followed by 5 error messages like this:

The remaining tests on pages 21-24 using sssctl and samba-tool produce the expected results, but when I try to login (from an existing terminal session), I get:

Since the login command is shown entered at what looks like a shell prompt rather than a terminal session prompt, I may have misunderstood the context.

IAC, what can/must I do about the Kerberos errors? Presumably no AD login will be possible without a Kerberos server.

1 Answer 1

I noticed that DNSHostName in the domain contained only the server name of my Ubuntu Studio desktop and not the FQDN. As it proved difficult to change this, I used «realm leave» to remove the client machine from the domain, removed the Computer entry from the Doman Controller (DC) and rejoined the domain. The only thing I am aware of doing differently is that I have left «use_fully_qualified_names = True» in «/etc/sssd/sssd.conf» instead of changing it to «False», an option mentioned at the bottom of page 16 in the whitepaper Now things appear to work as expected. The only peculiarities I have observed are as follows:

1. Due to setting the FQDN in «/etc/hostname» as described on page 10 of the whitepaper, both «hostname» and «hostname -f» return the FQDN.
2. «dig», «host». «nslookup» and «resolvectl query» all return an address of «127.0.1.1» (from 127.0.0.53#53) regardless of whether they are queried with the simple server name or the FQDN.
3. However, reverse lookup works as expected with «dig», «host», «nslookup» and «resolvectl query». All of these return , and .local

None of this seems to cause any problems (so far 😉

Источник

Samba4 DNS bugs

Перодически раз где-то в три дня приходится рестартить самбу, поскольку доменные ПК не могут получить имена других ПК.

DNS_backend=SAMBA_INTERNAL, на всех ПК static ip.

Значение allow dns updates какое стоит? На днях была похожая проблема, правда без потери Kerberos, временно решилось выставлением данного параметра значения nonsecure

Спасибо, попробуем. У меня стояло:

Сосбтвенно, я к тому что данный DC перенесенный с Win2008. И при вывовде samba-tool drs showrepl у меня был некоторый геморой ))

Вот здесь написано, что нужно создать:

Все, разобрался с GUID. По вашему совету выставил nonsecure и пока что-то вроде все ок. Погоняю несколько дней — посмотрю.

Теперь вот такой ВОПРОС: при использовании DNS-бэкенда SAMBA_INTERNAL приходится все компы добавлять в остнастке DNS вручную. Как сделать чтобы сами регистрировались?

Насчет добавления вручную не подскажу, при добавление в домен автоматически добавляются, а без домена, присутствие хоста в записях днс в моем случае не обязательно, поэтому не вникал почему так.
А вообще пришел к выводу что лучше использовать bind.
еще переодически встречал в поисковиках что какая то проблема с зоной local, но о чем конкретно речь там не смотрел.

Источник

Record of the UNIX Wars

It began as a personal voyage through the strange world of systems, network, and storage administration. Original stops were in the usual (Linux/Windows/Unix/OSX/Cisco/Brocade/Juniper) stations, but later on more were added. Please don’t tip the delivery boy. This was never planned to be the ultimate authoritative source of knowledge, but more like quick notes and thoughts to help me remember how to do something. If you learn something by reading this, don’t blame me!

Monday, March 17, 2014

generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information ()

This will be a quick post about something that was biting my ass these last few days and what was the real cause. After you read it, you are welcome to laugh at my expense. Go ahead! I deserve it!

I was working in a kerberos/ldap (linux) server and needed to debug the connection to a given client. The ldap connection uses TLS, GnuTLS specifically since the two machines were ubuntu servers, which means we also had to worry about certs. And since kerberos is in the picture, we need to configure for that. To help in solving other issues, which I should comment about later (at least those were clever problems not like this one), I was running slapd in debug mode,

and that did help solve the other issue I had. Some of you will notice I am also running ldaps (port 636), which I really do not need since TLS should take care of the encryption thingie. But, I digress for this post, so let’s go back on topic. What I then noticed was some very problems with ldap. For instance, if I created a kerberos ticket and then tried to run ldapsearch, I would then get the following error:

Here is what the server sees:

Since I do not have many clever things to talk about and fill the space until the solution, how about if we talk about what some of those lines mean?

• IP=192.168.1.181:44610 (IP=0.0.0.0:389) : Client 192.168.1.181 is connecting from its port 44610 to my port 389.
• oid=1.3.6.1.4.1.1466.20037: Start TLS extended request (per rfc2830).
• BIND : anonymous if we are doing a SIMPLE bind. If we are however doing SASL bind, it is not used.
• tag=97: result from a client bind operation.

As you noticed, at least from reading the title of this post, the error line is this generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information () thingie. Here is where it annoyed me to no end: what minor code? It is supposed to put some kind of message between the parenthesis, like «No principal in keytab matches desired name» or «Ticket expired». Then I would be able to search online for something. Instead, zilch. I could not find a single entry where the minor code parenthesis thingie was empty. Not very helpful today are we?

Solution

So, what was wrong? Me. User error. Do you remember how I was running slapd? Do you also remember the part about kerberos? Well, in the /etc/default/slapd (that’ll be /etc/sysconfig/ldap for you RedHat/CentOS/Fedora folks) I have defined

which means ldap knows then where the keytab containing the ldap service principal hides. Can you see where this is going? No? Let’s look again at how I am running slapd, shall we?

As you can see, I did not pass a KRB5_KTNAME to slapd. As soon as I fed that to slapd, all was once again well in the Land of Ooo.

Источник

Nov 15 16:10:21 vm7.dpnet.nethesis.it sssd[3194]: ; TSIG error with server: tsig verify failure
Nov 15 16:10:21 vm7.dpnet.nethesis.it sssd[3194]: update failed: SERVFAIL
Nov 15 16:10:21 vm7.dpnet.nethesis.it sssd[3194]: ; TSIG error with server: tsig verify failure
Nov 15 16:10:21 vm7.dpnet.nethesis.it sssd[3194]: update failed: SERVFAIL
Nov 15 16:10:21 vm7.dpnet.nethesis.it sssd[3194]: ; TSIG error with server: tsig verify failure
Nov 15 16:10:21 vm7.dpnet.nethesis.it sssd[3194]: update failed: SERVFAIL
Nov 15 16:10:21 vm7.dpnet.nethesis.it sssd[3194]: ; TSIG error with server: tsig verify failure
Nov 15 16:10:21 vm7.dpnet.nethesis.it sssd[3194]: update failed: SERVFAIL
Nov 15 16:10:21 vm7.dpnet.nethesis.it sssd[3194]: tkey query failed: GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more information, Minor = Server not found in Kerberos database.
Nov 15 16:10:21 vm7.dpnet.nethesis.it sssd[3194]: tkey query failed: GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more information, Minor = Server not found in Kerberos database.
Nov 15 16:10:21 vm7.dpnet.nethesis.it sssd[3194]: tkey query failed: GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more information, Minor = Server not found in Kerberos database.

Nov 15 15:35:49 nsdc-vm5.dpnet.nethesis.it samba[307]: Kerberos: TGS-REQ VM7$@DPNET.NETHESIS.IT from ipv4:192.168.122.7:54492 for DNS/localhost@DPNET.NETHESIS.IT [renewable]
Nov 15 15:35:49 nsdc-vm5.dpnet.nethesis.it samba[307]: Kerberos: Server not found in database: DNS/localhost@DPNET.NETHESIS.IT: no such entry found in hdb
Nov 15 15:35:49 nsdc-vm5.dpnet.nethesis.it samba[307]: Kerberos: Failed building TGS-REP to ipv4:192.168.122.7:54492
Nov 15 15:35:49 nsdc-vm5.dpnet.nethesis.it samba[307]: Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
Nov 15 15:35:49 nsdc-vm5.dpnet.nethesis.it samba[307]: single_terminate: reason[kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED]
Nov 15 15:35:49 nsdc-vm5.dpnet.nethesis.it samba[307]: Kerberos: TGS-REQ VM7$@DPNET.NETHESIS.IT from ipv4:192.168.122.7:54494 for DNS/localhost@DPNET.NETHESIS.IT [canonicalize, renewable]
Nov 15 15:35:49 nsdc-vm5.dpnet.nethesis.it samba[307]: Kerberos: Server not found in database: DNS/localhost@DPNET.NETHESIS.IT: no such entry found in hdb
Nov 15 15:35:49 nsdc-vm5.dpnet.nethesis.it samba[307]: Kerberos: Failed building TGS-REP to ipv4:192.168.122.7:54494
Nov 15 15:35:49 nsdc-vm5.dpnet.nethesis.it samba[307]: Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
Nov 15 15:35:49 nsdc-vm5.dpnet.nethesis.it samba[307]: single_terminate: reason[kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED]
Nov 15 15:35:49 nsdc-vm5.dpnet.nethesis.it samba[307]: Kerberos: TGS-REQ VM7$@DPNET.NETHESIS.IT from ipv4:192.168.122.7:54496 for DNS/localhost@DPNET.NETHESIS.IT [renewable]
Nov 15 15:35:49 nsdc-vm5.dpnet.nethesis.it samba[307]: Kerberos: Server not found in database: DNS/localhost@DPNET.NETHESIS.IT: no such entry found in hdb
Nov 15 15:35:49 nsdc-vm5.dpnet.nethesis.it samba[307]: Kerberos: Failed building TGS-REP to ipv4:192.168.122.7:54496
Nov 15 15:35:49 nsdc-vm5.dpnet.nethesis.it samba[307]: Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
Nov 15 15:35:49 nsdc-vm5.dpnet.nethesis.it samba[307]: single_terminate: reason[kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED]

I followed the document https://docs.aws.amazon.com/directoryservice/latest/admin-guide/join_linux_instance.html

Everything was working fine, but suddenly started to fails.

I decided clean all and start again. (I delete all and start again)

root@cthulhu:~# cat /etc/krb5.conf
[libdefaults]
        default_realm = EXAMPLE.COM
        rdns = false

root@cthulhu:~# cat /etc/sssd/sssd.conf
[sssd]
domains = example.com
config_file_version = 2
services = nss, pam

[domain/example.com]
ad_domain = example.com
krb5_realm = EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad

root@cthulhu:~# realm join -U Admin example.com --verbose
.
.
.

 * /usr/sbin/update-rc.d sssd enable
 * /usr/sbin/service sssd restart
 * Successfully enrolled machine in realm

The instance is now joined to the AD. Time is sync in both computers.

Lets try !!!

We can reach the AD…

root@cthulhu:~# id icalvete@example.com
uid=863401142(icalvete@example.com) gid=863400513(domain users@example.com) groups=863400513(domain users@example.com),863401137(aws delegated add workstations to domain users@example.com)

But we can`t get login.

root@cthulhu:~# kinit -V icalvete@example.com
Using default cache: /tmp/krb5cc_0
Using principal: icalvete@example.com
Password for icalvete@example.com:
kinit: Password incorrect while getting initial credentials

$ ssh example3
icalvete@example.com@54.54.54.54's password:
Permission denied, please try again.

Logs show these…

/var/log/syslog

Nov 11 16:33:31 cthulhu [sssd[krb5_child[2818]: Preauthentication failed

/var/log/auth.log

Nov 11 16:38:44 cthulhu sshd[3063]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=80.28.150.160  user=icalvete@example.com
Nov 11 16:38:44 cthulhu sshd[3063]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=80.28.150.160 user=icalvete@example.com
Nov 11 16:38:44 cthulhu sshd[3063]: pam_sss(sshd:auth): received for user icalvete@example.com: 17 (Failure setting user credentials)
Nov 11 16:38:44 cthulhu sshd[3062]: Received disconnect from 112.85.42.71 port 31633:11:  [preauth]
Nov 11 16:38:44 cthulhu sshd[3062]: Disconnected from 112.85.42.71 port 31633 [preauth]
Nov 11 16:38:47 cthulhu sshd[3063]: Failed password for icalvete@example.com from 80.80.80.80 port 60620 ssh2

Sometimes, one try works. This is really weird.

I restart sssd restart logs shows…

Nov 11 16:50:24 cthulhu systemd[1]: Stopping System Security Services Daemon...
Nov 11 16:50:24 cthulhu sssd[3396]: Shutting down
Nov 11 16:50:24 cthulhu sssd[3395]: Shutting down
Nov 11 16:50:24 cthulhu sssd[be[3384]: Shutting down
Nov 11 16:50:24 cthulhu systemd[1]: Stopped System Security Services Daemon.
Nov 11 16:50:24 cthulhu systemd[1]: Starting System Security Services Daemon...
Nov 11 16:50:24 cthulhu kernel: kauditd_printk_skb: 625 callbacks suppressed
Nov 11 16:50:24 cthulhu kernel: audit: type=1400 audit(1605113424.178:2226): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/etc/sssd/conf.d/" pid=3437 comm="sssd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Nov 11 16:50:24 cthulhu kernel: audit: type=1400 audit(1605113424.178:2227): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/usr/share/sssd/cfg_rules.ini" pid=3437 comm="sssd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Nov 11 16:50:24 cthulhu sssd[3437]: Starting up
Nov 11 16:50:24 cthulhu sssd[be[3455]: Starting up
Nov 11 16:50:24 cthulhu kernel: audit: type=1400 audit(1605113424.210:2228): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/etc/gss/mech.d/" pid=3455 comm="sssd_be" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Nov 11 16:50:24 cthulhu sssd[3464]: Starting up
Nov 11 16:50:24 cthulhu kernel: audit: type=1400 audit(1605113424.234:2229): apparmor="ALLOWED" operation="file_lock" profile="/usr/sbin/sssd" name="/var/lib/sss/mc/passwd" pid=3464 comm="sssd_nss" requested_mask="k" denied_mask="k" fsuid=0 ouid=0
Nov 11 16:50:24 cthulhu kernel: audit: type=1400 audit(1605113424.238:2230): apparmor="ALLOWED" operation="file_lock" profile="/usr/sbin/sssd" name="/var/lib/sss/mc/passwd" pid=3464 comm="sssd_nss" requested_mask="k" denied_mask="k" fsuid=0 ouid=0
Nov 11 16:50:24 cthulhu sssd[3465]: Starting up
Nov 11 16:50:24 cthulhu kernel: audit: type=1400 audit(1605113424.250:2231): apparmor="ALLOWED" operation="file_lock" profile="/usr/sbin/sssd" name="/var/lib/sss/mc/group" pid=3464 comm="sssd_nss" requested_mask="k" denied_mask="k" fsuid=0 ouid=0
Nov 11 16:50:24 cthulhu kernel: audit: type=1400 audit(1605113424.250:2232): apparmor="ALLOWED" operation="file_lock" profile="/usr/sbin/sssd" name="/var/lib/sss/mc/group" pid=3464 comm="sssd_nss" requested_mask="k" denied_mask="k" fsuid=0 ouid=0
Nov 11 16:50:24 cthulhu kernel: audit: type=1400 audit(1605113424.258:2233): apparmor="ALLOWED" operation="file_lock" profile="/usr/sbin/sssd" name="/var/lib/sss/mc/initgroups" pid=3464 comm="sssd_nss" requested_mask="k" denied_mask="k" fsuid=0 ouid=0
Nov 11 16:50:24 cthulhu kernel: audit: type=1400 audit(1605113424.258:2234): apparmor="ALLOWED" operation="file_lock" profile="/usr/sbin/sssd" name="/var/lib/sss/mc/initgroups" pid=3464 comm="sssd_nss" requested_mask="k" denied_mask="k" fsuid=0 ouid=0
Nov 11 16:50:24 cthulhu systemd[1]: Started System Security Services Daemon.
Nov 11 16:50:24 cthulhu kernel: audit: type=1400 audit(1605113424.266:2235): apparmor="ALLOWED" operation="capable" profile="/usr/sbin/sssd" pid=3437 comm="sssd" capability=12  capname="net_admin"
Nov 11 16:50:24 cthulhu systemd-resolved[785]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
Nov 11 16:50:24 cthulhu sssd[3437]: tkey query failed: GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more information, Minor = Server not found in Kerberos database.
Nov 11 16:50:24 cthulhu systemd-resolved[785]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
Nov 11 16:50:24 cthulhu sssd[3437]: tkey query failed: GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more information, Minor = Server not found in Kerberos database.
Nov 11 16:50:24 cthulhu systemd-resolved[785]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
Nov 11 16:50:24 cthulhu sssd[3437]: tkey query failed: GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more information, Minor = Server not found in Kerberos database.
Nov 11 16:50:24 cthulhu systemd-resolved[785]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
Nov 11 16:50:24 cthulhu sssd[3437]: tkey query failed: GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more information, Minor = Server not found in Kerberos database.
Nov 11 16:50:24 cthulhu sssd[3437]: response to SOA query was unsuccessful
Nov 11 16:50:24 cthulhu sssd[3437]: ; TSIG error with server: tsig verify failure
Nov 11 16:50:24 cthulhu sssd[3437]: update failed: REFUSED
Nov 11 16:50:24 cthulhu sssd[3437]: ; TSIG error with server: tsig verify failure
Nov 11 16:50:24 cthulhu sssd[3437]: update failed: REFUSED

It seems that the only thing doesn’t work is authentication.

I can work with users normaly like this…

root@cthulhu:~# su - icalvete@example.com
icalvete@example.com@cthulhu:~$