The problem
Trying to attach to a network share on a Samba server from Windows Server 2019 as the SYSTEM account results in The password is invalid for \\server\share then a prompt for a new one. Expected result is The command completed successfully.
When I try to connect to the share, the log for the machine on the Samba server shows:
get_user_from_kerberos_info: Username DOMAIN\COMPUTER$ is invalid on this system
So the question is: why? How can I allow a member server to authenticate a computer account?
Background
I have recently reconfigured a Samba server (v4.5.16) and joined it to a Samba-powered Active Directory domain at 2008 R2 functional level. I've set up a share using Windows ACLs, giving Read & Execute NTFS permissions to Authenticated Users and Domain Computers and Everyone Full Control on the share. Browsing and net useing tests fine with a regular user account on a Windows 2019 box. All fine and dandy.
BUT! Since this share holds installation files for software deployment via Group Policy objects (GPOs,) it also needs to be accessible to machine accounts (e.g. COMPUTER$) But it's apparently not, despite also giving Everyone Read permissions. I'm testing with
psexec -i -s cmd.exe
net use \\server\share /user:%computername%$
...and that's when I see the problem.
I also enabled Windows Installer logging which just says the source (\\server\share\path\to\installer) is invalid.
Before this, everything was fine (software deployed successfully at startup) with older Windows machines (2003-2008) as the share had Guest access enabled, but Windows 10+ and 2016+ no longer allow this by default. (I did test allowing it too, but that only resulted in the same password prompt.)
FWIW, the Samba domain member hosting this share is set up to use the ad idmap back-end with the RFC2307 option. As a result, I tried adding a uidNumber to the computer account in the domain but that had no effect.
I'm at my wits' end here, having spent the better part of two days searching, testing, cursing, etc. so I now humbly seek the collective wisdom of ServerFault.
Thank you for your time and attention!
First off, I apologize for not putting this in a comment, but I don't have enough reputation to do so.
To clarify on your original post - when you say:
Does this mean you tried adding a uidNumber to the Samba box's computer account, or to the computer account that was trying to authenticate to the share?
The reason I ask, is that I think it may not even be necessary to create the COMPUTER$ account on the Samba box. I can't say for sure with machine accounts, but I had to get a Managed Service Account that SQL was using to be able to authenticate against a Samba share (running v4.8.5, also using the AD backend, with schema_mode rfc2307), and all I had to do was add the uidNumber attribute for the MSA in AD to get it working. Once I did this, I could see in the logs that it changed from saying
to:
And just like that, my
BACKUP DATABASEjob from SQL (running as the MSA) to that share started working.Since MSAs are treated just like computer accounts when it comes to authentication and the like, I wouldn't be surprised if the same fix (just assigning a valid uidNumber to your client computer account that you want to be able to access the share as, making sure the assigned number falls in your defined range for that domain) would work for this scenario as well (in fact I'd be very surprised if it didn't work).
Finally figured it out! With this error, one simply needs to create a user called COMPUTER$ on the Samba box. Since I'm using the AD back-end for idmap, I also had to manually set a uidNumber in AD on the COMPUTER$ account, and specify that same uid when I created the UNIX user, e.g.
adduser --force-badname "COMPUTER$" --uid 999000Now to figure out how to make Samba do this automatically when a new user attempts to authenticate to Samba...