1

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!

1

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:

As a result, I tried adding a uidNumber to the computer account in the domain but that had no effect.

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

Username DOMAIN\MSA$ is invalid on this system

to:

Successful AuthZ: [SMB2,krb5] user [DOMAIN]\[MSA$]...

And just like that, my BACKUP DATABASE job 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).

1
  • It's been awhile (sorry for the delay!) but I think I added a uidNumber to the computer account trying to authenticate to the share. At least, such accounts currently have uidNumbers in my AD. And my Samba share box doesn't have a COMPUTER$ account in /etc/passwd, so I must have arrived at the same result you did, adding uidNumbers to the connecting computers' accounts. – Sean P. Jul 2 '20 at 16:50
0

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 999000

Now to figure out how to make Samba do this automatically when a new user attempts to authenticate to Samba...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.