Nach UCS 4.2-2 (-3) Upgrade: System Fehlerdiagnose "Fehler traten auf bei der Ausführung von `kinit` oder `nsupdate`."

The_Preacher · November 28, 2017, 6:24pm

Hallo,

nachdem es unter starker Mithilfe des Kopano Support nun endlich gelungen ist, unser UCS-System auf 4.2-2 zu hieven, habe ich leider einige kritische Fehler, welche in der “System-Fehlerdiagnose” nun angezeigt werden. Es gibt einige in “samba-tool-dbcheck”, welche aber hauptsächlich auf sehr alte Überbleibsel des MS SBS 2011 zurückgehen.
Wesentlich mehr besorgt mich dies:

Kritisch: Überprüfe Kerberos authentifizierte DNS Updates

Fehler traten auf bei der Ausführung von `kinit` oder `nsupdate`. `nsupdate` Prüfung für die Domänne domain.local ist fehlgeschlagen. `kinit` für den Principal dns-ucs mit der Password Tabelle /var/lib/samba/private/dns.keytab ist fehlgeschlagen.

Hierzu finde ich im Forum nur Hilfestellung bei DC-Backup, nicht aber für den DC-Master. Welche Schritte kann ich unternehmen, um das Problem zu diagnostizieren und ggf. zu beheben?

VG,
TP

ulf.kosack · November 28, 2017, 6:58pm

Hallo,

das hatte ich nach dem Update auch. Siehe https://help.univention.com/t/resolved-univention-ldap-auth-is-critical-on-ucs-master/7192.Ich musste einmal das Passwort des Master-DC ändern und dann manuellem Trigger in alle Applikationen verteilen. Danach war die Fehlermeldung weg.

Vg
Ulf

The_Preacher · November 28, 2017, 8:01pm

Hallo,

das habe ich nun durchgeführt, leider ohne Erfolg. Die Fehlermeldung bleibt bestehen…

VG,
TP

ulf.kosack · November 29, 2017, 5:37am

Hast Du schon mal die Logs nach evtl. Fehlermeldungen durchsucht?

The_Preacher · December 6, 2017, 4:11pm

Hallo,

sorry - ich habe mal wieder wenig Zeit zum Debuggen, muss immer noch die eineinhalb Tage UCS 4.2-2 Upgrade aufholen…

Die Logs geben nur genau die Fehlermeldung wieder - warum der Trust nicht funktioniert erschließt sich mir nicht. Vor allem, da auch das manuelle Setzen des Keys nichts bewirkt, obwohl ich den Key abgeglichen habe und dieser hunderprozentig übereinstimmt…

VG,
TP

Moritz_Bunkus · December 12, 2017, 12:19pm

Moin,

das Problem sollten Sie fixen können, indem Sie die Credentials auf dem DC Master neu in eine Keytab exportieren und diese auf dem betroffenen System dann ersetzen. Ich schreibe das Folgende allgemein für die SItuation, dass der betroffene Host nicht der DC Master sondern ein anderer Server ist. Bei Ihnen ist nur der DC Master betroffen; daher sind bei Ihnen natürlich alle Befehle auf dem DC Master auszuführen.

Auf dem betroffenen System ein Backup der Datei /var/lib/samba/private/dns.keytab anlegen
Auf dem DC Master die nötigen Principals exportieren
Auf dem betroffenen Host die Keytab ersetzen
Erneut testen lassen

Auf der Shell sieht das so aus (mein Beispielhost heißt backup2, ersetzen Sie das jeweils an den drei Stellen durch den betroffenen Servernamen — bei Ihnen also ucs):

# Auf betroffenem Host:
cp /var/lib/samba/private/dns.keytab /var/lib/samba/private/dns.keytab.$(date '+%Y%m%d%H%M%S')
# Auf DC Master:
samba-tool domain exportkeytab dns.keytab.new --principal DNS/backup2.$(ucr get domainname)
samba-tool domain exportkeytab dns.keytab.new --principal dns-backup2@$(ucr get kerberos/realm)
scp dns.keytab.new root@backup2:/var/lib/samba/private/

Anschließend testen Sie das auf dem betroffenen Host manuell mit folgendem Befehl, der im Erfolgsfall keinen Fehler liefert (auch wieder backup2 durch ucs ersetzen):

kinit -t /var/lib/samba/private/dns.keytab dns-backup2

Nun sollte auch der Testfall in der Systemdiagnose wieder OK sein.

Gruß
mosu

The_Preacher · December 12, 2017, 2:06pm

Hallo,
danke für die Anleitung!

Ich hatte dies laut einen HowTo von Univention schon ähnlich (scp durch cp ersetzt, da in meinem Fall überflüssig) durchgeführt, allerdings leider bereits damals wie auch jetzt ohne Erfolg:

root@ucs:~# cp /var/lib/samba/private/dns.keytab /var/lib/samba/private/dns.keytab.$(date '+%Y%m%d%H%M%S')
root@ucs:~#
root@ucs:~# samba-tool domain exportkeytab dns.keytab.new --principal DNS/ucs.$(ucr get domainname)
Export one principal to dns.keytab.new
root@ucs:~#
root@ucs:~# samba-tool domain exportkeytab dns.keytab.new --principal dns-ucs@$(ucr get kerberos/realm)
Export one principal to dns.keytab.new
root@ucs:~#
root@ucs:~# scp dns.keytab.new root@ucs:/var/lib/samba/private/
Password:
dns.keytab.new                                                                                         100%  408     0.4KB/s   00:00
root@ucs:~#
root@ucs:~# kinit -t /var/lib/samba/private/dns.keytab dns-ucs
kinit: krb5_get_init_creds: No PKINIT PA found
root@ucs:~#

Die Überprüfung schlägt natürlich nach wie vor fehl, “No PKINIT PA found” ist vermutlich nicht so günstig…!

VG,
TP

Moritz_Bunkus · December 12, 2017, 2:15pm

Ups, das ist natürlich Quark, weil die Zieldatei dann dns.keytab.new heißt, obwohl die dns.keytab heißen muss. Also scp dns.keytab.new /var/lib/samba/private/dns.keytab

The_Preacher · December 12, 2017, 2:22pm

Ja klar, hätte mir auch auffallen müssen. Bewirkt aber nach wie vor nix:

root@ucs:~# cp /var/lib/samba/private/dns.keytab /var/lib/samba/private/dns.keytab.$(date '+%Y%m%d%H%M%S')
root@ucs:~#
root@ucs:~# samba-tool domain exportkeytab dns.keytab.new --principal DNS/ucs.$(ucr get domainname)
Export one principal to dns.keytab.new
root@ucs:~#
root@ucs:~# samba-tool domain exportkeytab dns.keytab.new --principal dns-ucs@$(ucr get kerberos/realm)
Export one principal to dns.keytab.new
root@ucs:~#
root@ucs:~# scp dns.keytab.new root@ucs:/var/lib/samba/private/dns.keytab
Password:
dns.keytab.new                                               100%  408     0.4KB/s   00:00
root@ucs:~#
root@ucs:~# kinit -t /var/lib/samba/private/dns.keytab dns-ucs
kinit: krb5_get_init_creds: No PKINIT PA found
root@ucs:~#
root@ucs:~# cd /var/lib/samba/private/
root@ucs:/var/lib/samba/private# ls -als
...
   4 -rw-------  1 root root     408 Dez 12 15:18 dns.keytab
   4 -rw-------  1 root root     732 Dez 12 15:18 dns.keytab.20171212151819
   4 -rw-------  1 root root     408 Dez 12 14:22 dns.keytab.new
   4 -rw-------  1 root root    1745 Nov 28 11:00 dns_update_cache
   4 -rw-------  1 root root    3183 Jän 16  2017 dns_update_list
1256 -rw-------  1 root root 1286144 Aug 20  2014 hklm.ldb
1572 -rw-------  1 root root 1609728 Nov  7 08:17 idmap.ldb
   4 -rw-r--r--  1 root root     578 Nov 28 11:44 krb5.conf
   4 -rw-------  1 root root      93 Aug 20  2014 krb5.conf.debian
   0 srwxrwxrwx  1 root root       0 Dez  6 16:22 ldapi
   4 drwxr-x---  2 root root    4096 Dez  6 16:22 ldap_priv
   4 drwx------  2 root root    4096 Dez 12 15:19 msg.sock
   4 -r--r--r--  1 root root     222 Aug 20  2014 named.conf.update
   4 -rw-------  1 root root     696 Dez  6 16:22 netlogon_creds_cli.tdb
1256 -rw-------  1 root root 1286144 Aug 20  2014 privilege.ldb
   4 -rw-------  1 root root     696 Aug 20  2014 randseed.tdb
4152 -rw-------  1 root root 4251648 Feb 19  2015 sam.ldb
   4 drwx------  2 root root    4096 Dez 12 03:00 sam.ldb.d
  12 -rw-------  1 root root   12288 Dez 12 15:17 schannel_store.tdb
   4 -rw-------  1 root root    1062 Aug 20  2014 secrets.keytab
1256 -rw-------  1 root root 1286144 Nov 28 20:59 secrets.ldb
 416 -rw-------  1 root root  425984 Nov 28 20:59 secrets.tdb
1256 -rw-------  1 root root 1286144 Aug 20  2014 share.ldb
   4 drwxr-xr-x  3 root root    4096 Aug 20  2014 smbd.tmp
   4 -rw-------  1 root root     955 Aug 20  2014 spn_update_list
   4 drwx------  2 root root    4096 Aug 20  2014 tls
1256 -rw-------  1 root root 1286144 Aug 20  2014 wins_config.ldb
root@ucs:/var/lib/samba/private#

Moritz_Bunkus · December 12, 2017, 2:51pm

OK, die Fehlermeldung ist auch eine, die mir nichts sagt. Sie können an der Stelle versuchen, den zugehörigen User zu entfernen, ihn neu anzulegen und anschließend die Kerberos-Keytab neu zu exportieren. Konkret:

udm users/user delete --dn=uid=dns-$(hostname),cn=users,$(ucr get ldap/base)
# warten bis S4-Connector synchronisiert hat
/usr/share/univention-samba4/scripts/create_spn_account.sh --samaccountname "dns-$(hostname)" --serviceprincipalname "DNS/$(hostname).$(ucr get domainname)" --privatekeytab dns.keytab
# warten bis S4-Connector synchronisiert hat
/usr/share/univention-s4-connector/resync_object_from_s4.py "cn=dns-$(hostname),cn=users,$(ucr get samba4/ldap/base)"
# warten bis S4-Connector synchronisiert hat
keytab=/var/lib/samba/private/dns.keytab
mv $keytab $keytab.$(date '+%Y%m%d%H%M%S')
samba-tool domain exportkeytab $keytab "--principal=DNS/$(hostname).$(ucr get domainname)"
samba-tool domain exportkeytab $keytab "--principal=dns-$(hostname)@$(ucr get kerberos/realm)"

Anschließend erneut testen mit kinit -t $keytab dns-$(hostname).

Bitte bei den Punkten »warten bis…« unbedingt geduldig sein und die nachfolgenen Schritte nicht zu bald anschließen.

Kommt beim kinit dann als Fehlermeldung “password incorrect”, so wurden Schritte zu schnell durchgeführt. In dem Fall einfach noch mal die Principals exportieren, also die Schritte ab mv $keytab ….

Gruß
mosu

The_Preacher · December 12, 2017, 7:16pm

Hallelujah!
Das war es!
Vielen, vielen Dank Herr Bunkus!

Moritz_Bunkus · December 13, 2017, 7:57am

Ja cool! Freut mich selber sehr, dass die Prozedur das Problem beheben konnte. Gern geschehen.