Alex's picture

Hello all,

I've been running a Samba domain for nearly a year and have connected all Windows 10 home PCs to it successfully, along with one TrueNAS SCALE instance.

Today I upgraded one of the PCs from Windows 10 to Windows 11. After rebooting, I can no longer log into that PC using a domain account. I can only log in using its local administrator account.

Everything seems fine on that machine (I can access the network and I can use RSAT to connect to the domain controller and browser users).

Is Samba capable of driving Windows 11 clients? What can I do to investigate the issue?

When I try to log in, nothing is written to the logs in /var/log/samba, so there is no "error" logged on the DC side. On the Windows side I simply get a the message "the username or password is incorrect". So I do not have much to go on.

What can I do to investigate the source of this problem?

Jeremy Davis's picture

I'm a full time Linux user so beyond basic release testing, I have limited experience with Samba, but a quick google suggests that due to a recent Windows update, the authentication process has changed. Apparently to support "Windows11 version 22H2" you need Samba v4.16+. Our current v16.x Domain Controller only has Samba v4.9.5. So I assume that's the issue. FWIW, I'm pretty sure this is the issue you're hitting (on Ubuntu bug tracker, but applies to Debian too - Ubuntu is a Debian derivative).

We've had a raft of issues with the current v17.x major update release and it is way behind schedule, but the default Samba version in Debian Bullseye (what v17.x is based on) still only has Samba v4.13.13. Although I do note that Samba v4.16.6 is in bullseye-backports.

So until we produce an updated appliance, with a newer version of Samba, the only really viable path for you is to do a Debian style "in place" upgrade. There is also a thread another user posted a while ago that might be generally relevant? It actually covers upgrading from a Debian 9/Stretch base -> Debian 10/Buster, but the general idea should still apply (just that you'll be going from Debian 10/Buster -> Debian 11/Bullseye instead).

Assuming that you are running your DC in a VM, I urge you to create a snapshot and a backup of your server before doing anything. At least then, worst case scenario you'll be sure you can get back to where are right now. If possible, I also strongly encourage you to leave the existing server as is (so the existing Win10 machines can continue working as they are until you're done). Hopefully you can launch a new VM from a snapshot?

Once you have upgraded to a Debian 11/Bullseye base, then you'll need to enable Debian backports. Then you should be able to upgrade Samba to v4.16.x.

That's probably a lot to take in, especially if you aren't super confident with Linux. But I'm more than happy to provide any assistance if you hit issues and/or have questions. The more info you can provide (e.g. commands run, explicit error messages, etc) the easier it will be for me to assist.

Jeremy Davis's picture

FYI, I just found a third party repo that provides newer Samba packages. Please do not consider this an endorsement or suggestion that you should use it. I have no knowledge of who this is, how security conscious they are nor how well the repo is maintained. So use it at your own risk - but please report back on your experience if you do try it.

Having said that, unfortunately it doesn't appear to provide Samba v4.16 for Debian 10/Buster (only v4.15). So even if you were to use that, it still requires an upgrade to Debian 11/Bullseye base and doesn't provide any advantage over using official Debian backport install. So I can't recommend using it.

One other thing that has a occurred to me is that depending on the AD schema version your existing setup uses, you may need to manually upgrade the "AD Functional Level". Please see the Samba wiki's "Raising the Functional Levels" page for more info.

Jeremy Davis's picture

I'm back again with another bit of info. It appears that there is a workaround that can be applied to Samba config to support newer Windows 11 builds with older (i.e.

I'm a little loathe to publish it here as it appears likely there are security implications. It's not clear to me how much risk might be involved, and ultimately it probably depends on your specific usage scenario and the risk level you are comfortable with. So until we have more understanding of the implications, I don't want to tacitly give any inferred endorsement. So with that disclaimer out of the way, apparently the below setting will workaround the issue:

"Local Security Policy" >> "Local Policies" >> "Security Options" >> "Network security": Configure encryption types allowed for Kerberos - Check only DES_CBC_CRC and DES_CBC_MD5

I assume that you do that via RSAT (from one of your still working Win10 machines), but I'm not 100% sure...

Alex's picture

I genuinely appreciate this treasure trove of information!

I actually run my DC in an LXC container in Proxmox. I am curious about updating in-place, just to confirm that this is indeed the issue, so I hope to have time to try that this weekend. (Will of course back up the DC before I try).

I also took a backup of the Windows 10 VM before I upgraded it. Therefore I can (at worst) roll back to Windows 10 very easily.

I think I will even try the security policy hack just out of curiosity.

I will report back here when I've had time to try all this, but thank you again for sharing all this information and knowledge.

Alex's picture

Just wanted to update that I tried the security policy hack and was able to log in. So this is definitely the issue affecting me. Since I am not comfortable with using it, I will try the Samba upgrade instead...

Jeremy Davis's picture

I'm really glad that my thoughts were of value to you. It certainly does sound like that's the exact issue.

Please be aware though, that once you get the updated backported Samba, you won't get auto security updates for it (or any other backported package). You'll need to manually check for and install updated package as they become available.

Also, I'd like to thank you tons for reporting this issue. The timing is awesome as I hope to get onto the Domain Controller update soon. Now that I am aware of this issue, I'll keep this in mind. Because of the implications of installing from backports, I think I might ship it with the default Samba version, but make it easy to upgrade if needed. My rationale for planning to go that way is that's the only way I can ensure users are aware of the implications.

Add new comment