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.

Stefano Trentini's picture

Thank you so much!!
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.

Hey @Alex were you able to try the in-place samba upgrade? I have a machine I am running into this same issue on, so I figured I would ask before I try it myself.

Or any update on the availability of the updated 17.x DC? Jeremy? :) I understand you're swamped, but figured I'd ask.

Jeremy Davis's picture

The updated Domain Controller will be ready soon. No firm ETA, but hopefully within the next week or 2.

However, I have set up a test Win11 VM and can 100% confirm that the default Samba version in Debian Bullseye (4.13) will not work with latest Win11. But the version in Bullseye backports (v4.17) definitely does work. The v17.x TurnKey Domain Controller will ship with the backports version installed.

Excellent thanks! Looking forward to it :)

Alex's picture


I'm looking forward to the release of the new domain controller!

I was just wondering: what is the best way to go about updating? I've never done it before.

I use Proxmox, so generally I take a backup before changing anything, but at the same time my go-to approach is to just  set something up from scratch and then ditch the old container. This is not really an upgrade, but a reinstallation/reconfiguration.

In this case, I need to preserve the domain data (user/computer accounts) so this approach won't work. I was therefore wondering what the best practice is to go about this.

I also wonder: how does one find out what version of the domain controller they are running? I am sure it is 16.2, but is  there some command/file I can check inside the running image to find out?

Thank you!


Jeremy Davis's picture

Generally the best way is to add the new server to your existing domain. Then remove the old server.

Obviously take a backup of your existing domain controllers before you start (if you don't already, then it's worth being aware that best practice is to have at least 2 domain controllers as members - online all the time). I'd add 2 new DCs to your existing AD domain, then remove both of the old ones (or the old one if you only have one). Personally, I'd suggest that (after removing them from the AD domain) you just power down the old server(s) and leave then around for at least a week or 2 (just in case).

Alex's picture

Thank you Jeremy, that makes a lot of sense! I was reading which are generic instructions, but having appliance-specific instructions always trumps generic approaches.

I will of course backup before touching anything, that is good advice and also why I love Linux (and Docker) containers: this flexibility to back up an image and not worry about "breaking" a system while working on it is amazing.

I look forward to the new container. In the meantime I'll add a second domain controller with the existing version, just to learn how that works on the Windows side. I actually have two machines running Proxmox anyway: one is my home lab (with pfsense, truenas, domain controller, syncthing, duplicati, etc). The other runs my two desktops with GPU passthrough but is quite powerful so an extra domain controller there will be negligible.

Thank you again for your excellent advice.

P.S. If you get to a stage where you have images that need beta-testers I'd be happy to oblige, as it is quite easy for me to keep my old DC instances around until it's "releasable" and revert back to them if needed.

Jeremy Davis's picture

Please let me know how you go.

As a complete aside, thanks for noting the page you were checking. I think that page should be toned down a little. Whilst we still don't technically support "Debian style" in place upgrade, it should generally work and I'll certainly give anyone "best effort" support if they try and have any problems. As much as possible, I want TurnKey users to use it how works best for them (i.e. I don't want us to railroad users any more than we need to). So I'm always happy to explore ways we can make in place upgrades work better for those who wish to use them. We've had many reports of successful Debian style upgrades.

But I digress...

Domain Controller is a very specific beast! I think it might be worth me sharing a bit more of my (somewhat limited) knowledge regarding AD domains.

Whilst backups are always a good thing, backups of domain controller data are a bit tricky and from my understanding, prone to corruption. At least technically it should be possible to safely dump the backend LDAP-like databases and restore them later. But I haven't found much info about that, not even in the Samba docs. I'm almost certain that it's possible, but as no one seems to do it and I'm not so vain to think that I'm the first to try. So I've always figured that there's probably a good reason why no one does that!

So generally what you are backing up is mostly config, rather than AD data. A snapshot is different, because that will include all the data. But I have minimal experience with restoring snapshots of AD DCs. I would expect it to work, but I imagine that there are corner cases where problems can occur.

My understanding is that the above is the context behind the advice to always run (at least) 2 AD DCs in your network. If you have 2 PVE nodes, perhaps consider running one DC on each host?

AFAIK if whichever one you use for DNS goes down, that will still break stuff (i.,e. DNS won't resolve). But you should be able to manually switch your DNS to the other AD member server and it should continue to "just work". IIRC you can set a fallback DNS in Windows, so perhaps if you make your second DC the backup DNS that might "just work"? Obviously the devil is in the detail. But once you have 2 DCs, then you could even test it yourself?!

Alex's picture

Hello Jeremy,

I've been able to upgrade to V17 using  replication among domain controllers.

I've replied to someone else here with the approach:

One issue I have found  that for whatever reason, you cannot create a domain controller called DC1 and join an existing domain. This has nothing to do with the V16 to V17 upgrade, it must be a bug in the setup script. To reproduced I did the following using V17 as a template ONLY (so V16 not involved at all).

  • Create a domain AD.SAMPLE.LAN with the controller named DC2
  • Create a domain controller and try to join the existing AD.SAMPLE.LAN domain
  • At the prompt "Set new unique hostname for this domain-controller." enter dc1
    • You get the error "Hostname matches default 'dc1'."
  • If you enter DC1 in all-caps the error does not occur with V17

I just wanted to let you know and also document this in the forums in case anyone else comes across this.

Jeremy Davis's picture

Sorry I missed this one previously. I saw your other comment though! :)

Thanks for reporting this.

It looks like I added that in a huge grab bag commit (for v16.1), and unfortunately I don't recall my rationale. Having said that, I can only assume I was trying to save some users from themselves, whilst inadvertently stopping a completely legitimate use case!

So I propose that I remove that test altogether. It means that you could inadvertently try to join with a hostname that already exists, but we're actually not checking for other hosts on the network so, you could do that anyway. And I imagine that Samba would fail to join to the domain if there is already a member with the same hostname.

What do you think?

PS I've pushed the code and opened a pull request if you're interested at all.

Alex's picture

I'm certain AD would not allow for a duplicate computer account, so given that it is a valid use case one should be able to do it. (just my 5 cents)

Jeremy Davis's picture

Yeah, that's what I reckon too. Thanks for your input.

Add new comment