简体   繁体   English

Samba 4.13.17 因 Kerberos 错误而中断域登录

[英]Samba 4.13.17 breaks domain login with Kerberos errors

I have two Ubuntu 20.04 LTS servers which updated Samba to version 4.13.17 last night.我有两个 Ubuntu 20.04 LTS 服务器昨晚将 Samba 更新到版本 4.13.17。 This morning users were not able to login from a some Windows 10 PC's.今天早上,用户无法从 Windows 10 台 PC 登录。 The same user could login from another Windows10 PC.同一用户可以从另一台 Windows10 PC 登录。

The Event log on the affected PC's give a Kerberos error (translated with Google Translate).受影响 PC 上的事件日志给出 Kerberos 错误(使用谷歌翻译)。

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.我尝试在 VM 中进行全新的 Windows 10 安装,直到我应用最新的 Windows 更新后它才有效。 Then it gave the same Kerberos error.然后它给出了相同的 Kerberos 错误。

Edit: Just to add the content of /et/krb5.conf编辑:只是添加 /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 Edit2:昨天晚上还有一些更新

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.起初,2 个测试虚拟机在将它们从域中删除后工作,删除机器帐户并将它们重新加入到域中。 It even worked after a reboot.它甚至在重新启动后工作。 But minutes later I had the same problem again.但是几分钟后我又遇到了同样的问题。

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.更新 20230127:Ubuntu 今天发布了 samba 2:4.13.17~dfsg-0ubuntu1.20.04.5 source package in Ubuntu,它恢复了 samba 2:4.13.17~dfsg-0ubuntu1.24.04.04.5 中的所有安全漏洞修复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:对于带有 Samba 4.13.17 的 Ubuntu 20.04,似乎只有一种方法可以解决登录问题:

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.修改本地安全策略 -> 本地策略 -> 安全选项 -> 网络安全:“配置 Kerberos 允许的加密类型”只勾选 DES_CBC_CRC、DES_CBC_MD5 和 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.您可以通过 GPO 配置它,但只有当与 AD 的连接再次工作时才会应用 GPO。 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:您还可以应用以下注册表项:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters]
"SupportedEncryptionTypes"=dword:00000007

Here are some more informations:以下是更多信息:

https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1993934https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1993934

https://bugzilla.samba.org/show_bug.cgi?id=15197 https://bugzilla.samba.org/show_bug.cgi?id=15197

https://launchpad.net/ubuntu/+source/samba/2:4.13.17~dfsg-0ubuntu1.20.04.5 https://launchpad.net/ubuntu/+source/samba/2:4.13.17~dfsg-0ubuntu1.20.04.5

Downgrade samba to previous version (4.11.6), as workaround without any configuration changes, works.将 samba 降级到以前的版本 (4.11.6),因为没有任何配置更改的解决方法有效。 Now clients can log on to domain.现在客户端可以登录域了。

A new samba update fixed the problem by reverting the previous security fixes.新的 samba 更新通过恢复以前的安全修复解决了这个问题。

https://ubuntu.com/security/notices/USN-5822-2 https://ubuntu.com/security/notices/USN-5822-2

We also experienced the same issue on a VM with a DC.我们在带有 DC 的 VM 上也遇到了同样的问题。 We switched back to a backup from November 2022. After leaving and rejoining the domain, clients worked again.我们从 2022 年 11 月开始切换回备份。离开并重新加入域后,客户再次工作。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM