I have two Ubuntu 20.04 LTS servers which updated Samba to version 4.13.17 last night. This morning users were not able to login from a some Windows 10 PC’s. The same user could login from another Windows10 PC.
The Event log on the affected PC’s give a Kerberos error (translated with Google Translate).
The Kerberos client received a KRB_AP_ERR_MODIFIED error from server "dd-02a$". The target name used was DD-02A$. This indicates that the target server was unable to decrypt the token provided by the client. This can occur when the target server principal name (SPN) is not registered with the account that the target service is using. Make sure the target SPN is only registered with the account used by the server. This error can also occur if the password for the target service account does not match the password that is configured in the Kerberos KDC (Key Distribution Center) for the target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified and the target domain (DD.LAN) is different from the client domain (DD.LAN), check if there are server accounts with the same name in these two domains, or use the fully qualified name to identify the server to identify.
There must be some setting on the working PC’s which I need to apply to the others, but what could it be? I googled for hours this morning already without success.
I tried with a fresh Windows 10 installation in a VM and it worked until I applied the latest Windows Updates. Then it gave the same Kerberos error.
Edit: Just to add the content of /et/krb5.conf
[libdefaults]
; default_realm = ATHENA.MIT.EDU
default_realm = DD.LAN
; for Windows 2008 with AES
default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
Edit2: yesterday evening there were a few more updates
libkrb5-3:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), libgssapi-krb5-2:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), bind9-dnsutils:amd64 (1:9.16.1-0ubuntu2.11, 1:9.16.1-0ubuntu2.12), bind9-host:amd64 (1:9.16.1-0ubuntu2.11, 1:9.16.1-0ubuntu2.12), dnsutils:amd64 (1:9.16.1-0ubuntu2.11, 1:9.16.1-0ubuntu2.12), libkdb5-9:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), libk5crypto3:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), krb5-locales:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), krb5-user:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), libkadm5srv-mit11:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), libkrb5support0:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), libgssrpc4:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), bind9-utils:amd64 (1:9.16.1-0ubuntu2.11, 1:9.16.1-0ubuntu2.12), bind9:amd64 (1:9.16.1-0ubuntu2.11, 1:9.16.1-0ubuntu2.12), libkadm5clnt-mit11:amd64 (1.17-6ubuntu4.1, 1.17-6ubuntu4.2), bind9-libs:amd64 (1:9.16.1-0ubuntu2.11, 1:9.16.1-0ubuntu2.12)
At first the 2 test VMs worked after removing them from the domain, deleting the machine accounts and re-joining them to the domain. It even worked after a reboot. But minutes later I had the same problem again.
4
Answers
A new samba update fixed the problem by reverting the previous security fixes.
https://ubuntu.com/security/notices/USN-5822-2
Downgrade samba to previous version (4.11.6), as workaround without any configuration changes, works. Now clients can log on to domain.
We have the same issue here.
Update 20230127:
Ubuntu published today samba 2:4.13.17~dfsg-0ubuntu1.20.04.5 source package in Ubuntu, which revert all security bug fixes from samba 2:4.13.17~dfsg-0ubuntu1.20.04.4. With this update the login works without the workaround below.
For Ubuntu 20.04 with Samba 4.13.17 there seems to be only a workaround to solve the login problem:
Modifying the Local Security Policy -> Local Policies -> Security Options -> Network security: "Configure encryption types allowed for Kerberos" Check only DES_CBC_CRC, DES_CBC_MD5 and RC4_HMAC_MD5.
This worked for us to login again.
You can configure this via GPO but the GPO will only be applied if the connection to the AD works again. So you need first a local account on the affected computer, modify the security settings and reboot the system.
You can also apply the following registry entry:
Here are some more informations:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1993934
https://bugzilla.samba.org/show_bug.cgi?id=15197
https://launchpad.net/ubuntu/+source/samba/2:4.13.17~dfsg-0ubuntu1.20.04.5
We also experienced the same issue on a VM with a DC. We switched back to a backup from November 2022. After leaving and rejoining the domain, clients worked again.