Windows 22H2 repeatedly says “wrong username and password” trying to login Active Directory user

Print Friendly, PDF & Email

I recently had to troubleshoot an issue where a new Surface Pro 9 for an employee of an existing company. IT staff unboxed the device and began the initial set up, including Windows 11 22H2 Pro. Initially, the machine joined to the domain, but upon reboot, after joining the domain, absolutely nothing would let us log in to the domain. We tried normal users, domain Administrators, and in the end we had to go back to local users to continue troubleshooting.

We didn’t believe there was a problem with the Domain Controller because all of the other computers in the building are behaving fine. Why just this one brand new computer? In the end, we realized it was because Windows 22H2 (Windows 10 or 11) doesn’t like a Linux-based SAMBA Active Directory server.

UPDATE 2: This changes the whole article! I thought I had a nice, easy work-around, but unfortunately this problem is much larger than I ever thought.

According to this thread on Github, Microsoft is aware of the issue, but claims that, and I directly quote, “this is not our problem.” As it turns out, this is Windows 11 AND Windows 10 22H2 working as intended. They have admitted that they are aware this is causing widespread problems, and purportedly have ‘resolved the bug’ in Windows 11 Insider build 25247.

But if you’re not about to run Windows 11 insider builds in your production environment, the good news is that SAMBA has been fixed in Debian, and Ubuntu 22.10.x. If you’re using Ubuntu LTS, the fix has been released as of December 7th, 2022; approximately 1530 EST. It has been committed and is now released for the Jammy, Focal, and Bionic branches (if you’re an Ubuntu user, you probably already understand what those things mean). Simply run a quick sudo apt update and see if several SAMBA utilities are in the list, then run a sudo apt upgrade to install them!

Despite my best efforts and the solution I originally proposed below, the best answer is just to check your package repository for any SAMBA updates available. Whether it’s version 4.16 or backported some of the features of 4.16.x, you should be in good shape.

UPDATE 1: If the information I have provided below does not apply to you, this may be a more widespread issue with Windows 11 22H2 than I initially realized, as Microsoft has noted issues with joining a domain in an official “known issues” post. Back to the original post below.

Well, bear with me because this is still a developing issue, but it seems that Windows 11 22H2 (and potentially Windows 10 22H2, though I haven’t had a chance to test it yet) requires kerberos authentication over SMB2. If you have a modern version of Windows Server, this probably is not an issue for you. HOWEVER, where I work, we’re actually using an Ubuntu Linux based Samba Active Directory Domain Controller!

Even then, back in March, Samba released an update which basically saw this issue coming and updated the default configuration so that this should not be an issue. Unfortunately, this environment is a machine shop where a lot of legacy factory machines connect to file shares and the boxes under the hood are still literally Windows XP computers, which can only use SMB one.

So back in March, this particular environment modified their SMB config on the linux server by going in to /etc/samba/cmb.conf and adding a line that for:

client min protocol = NT1

But that, our case, is what CAUSES THE PROBLEM. With that line in there, Windows 11 22H2 will not authenticate with the domain controller. I believe the SOLUTION is that line must be adjusted to:

client min protocol = SMB2

If that line doesn’t exist for you, yet, it should be underneath the “[global]” heading inside the .conf file.

Or potentially just have the line removed altogether, as updated versions of this software are looking for SMB2 by default. In this particular situation, though, this is going to break a lot of the file-shares that the machine shop needs to run. At this time, our best workaround is going to be creating a new, distinct shared folder for those old machine shop computers to connect to for filesharing purposes, and then change the Domain Controller’s configuration so that the minimum accepted protocol is SMB2. In the long run, this is going to make the entire environment more secure and will be MUCH better for the Domain Controller. But right now, there is a bit of headache for everyone, as remapping network drives on devices which aren’t necessarily joined to the domain itself is never as simple as it sounds!

There may be tweaks that can be made at the Windows level so that people with Linux based AD DC’s don’t have to modify their configs (I tried some of the advice from reddit user “/u/I_Searched_Google” in this thread, but to no avail) but so far I haven’t had any luck. But all the credit in the world goes to that Redditor for helping me at least understand the issue that I was experiencing and, hopefully, coming up with a solution that helps a few people.