Problem:
A share (opsi_depot) on an Opsi depot server cannot be mounted by a Windows client. The opsi-client-agent gives an error message saying “Wrong password” and a password prompt always appears via the Windows Explorer. Two things are unusual: when accessing via the IP instead of the host name, everything works, and mounting via the Linux command line also works. So only the combination Windows together with the mount via the host name is problematic.
[2024/08/20 09:14:28.260144, 1] ../../source3/librpc/crypto/gse.c:713(gse_get_server_auth_token)
gss_accept_sec_context failed with [ Miscellaneous failure (see text): Failed to find cifs/slave-opsi.schein.me@SCHEIN.ME(kvno 27) in keytab MEMORY:c
ifs_srv_keytab (aes256-cts-hmac-sha1-96)]
[2024/08/20 09:14:28.260193, 1] ../../auth/gensec/spnego.c:1245(gensec_spnego_server_negTokenInit_step)
gensec_spnego_server_negTokenInit_step: gse_krb5: parsing NEG_TOKEN_INIT content failed (next[(null)]): NT_STATUS_LOGON_FAILURE
Investigation:
Sounds like a kerberos issue.
On the opsi server, the server password for Kerberos was somehow no longer correct, i.e. it could no longer pull a ticket as a server with its machine.secret, which it needs to communicate with the school server.
cp -r /var/log/samba /var/tmp/samba.0; smbcontrol all debug 11; sleep 1
smbclient //$(hostname -f)/opsi_depot -U pcpatch
cp -r /var/log/samba /var/tmp/samba.1; diff -Nuar /var/tmp/samba.0 /var/tmp/samba.1 > /var/tmp/diff02; smbcontrol all debug 0;
less /var/tmp/diff02
Solution:
Search for the old working password in /etc/machine.secret.old (try and error)
With the old working password you can use kpasswd with the machine-Account to set the new password from the actual /etc/machine.secret.
cat /etc/machine.secret; echo
kinit slave-opsi$
cat /etc/machine.secret.old
kinit slave-opsi$
kinit slave-opsi$
kinit slave-opsi$
kpasswd slave-opsi$
kinit slave-opsi$
ucr set server/password/interval=-1
/usr/lib/univention-server/server_password_change
ucr set server/password/interval=21