Background
I inherited a group of Windows Server 2019 servers recently. The setup is...not ideal. They are all part of a workgroup, myworkgroup
, but there's no domain involved. Each has their own local administrator account, theadmin
. All of the local theadmin
accounts have the same password. One server has a shared folder enabled.
The general layout looks something like:
- ServerA
- File Share:
C:\Shared
(name: "Shared") - Local admin:
ServerA\theadmin
(same password, e.g.redactedpw1234
)
- File Share:
- ServerB
- Local admin:
ServerB\theadmin
(same password, e.g.redactedpw1234
)
- Local admin:
- ServerC
- Local admin:
ServerC\theadmin
(same password, e.g.redactedpw1234
)
- Local admin:
- ServerQA
- Local admin:
ServerQA\theadmin
(same password, e.g.redactedpw1234
)
- Local admin:
The challenge
At some point -- difficult to pinpoint exactly when -- the ServerQA theadmin
account is now able to read from \\ServerA\Shared
, but is unable to modify or delete files (saw an issue with a scheduled task running as this account, and then verified via Windows explorer while logged in as that account).
ServerB's and ServerC's theadmin
account don't seem to have that problem. When signed in on the local theadmin
account on those two machines, I can look at \\ServerA\Shared
and modify/create/delete files as expected.
So my challenge can be summed up as:
- ✅
ServerB
,ServerC
, andServerQA
appear to have the same config - ✅
ServerB
can access\\ServerA\Share
in windows explorer and create/modify files - ✅
ServerC
can access\\ServerA\Share
in windows explorer and create/modify files - ❌
ServerQA
can read\\ServerA\Share
in windows explorer but receives a permission error when attempting to create or modify files.
Things I've Tried
- Restarting the
ServerQA
server Get-SmbConnection
on all servers.- The setup pattern appears to be the same on ServerB, ServerC, and ServerQA - The user is listed as
[TheMachine]\theadmin
in each case, and the credential is the same. So they're all using their localtheadmin
credentials. - The dialect is
3.1.1
for all machines.
- The setup pattern appears to be the same on ServerB, ServerC, and ServerQA - The user is listed as
Get-SmbMultichannelConnection
appears to show the same patfor all of them.Interface index [The Ethernet1 index for the server], RSS: True, RDMA: False
- Tried to remove and re-establish the share
- On ServerQA,
net use /delete \\ServerA\Shared
- On ServerA,
Get-SmbSession
and thenClose-SmbSession
to close any sessions for that machine - On ServerQA,
net use \\ServerA\Shared /user:ServerQA\theadmin redactedpw1234
to re-establish - On ServerQA,
net use
andGet-SmbConnection
to confirm that things are set up as expected
- On ServerQA,
- Ran
whoami /all
on all servers and verified that the local accounts are all in the same local groups. - Checked the SMBClient and SMBServer event logs on the respective servers. Nothing stands out.
- Checked the registry. All servers have the same values in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
- Though I could be missing somewhere else I should be looking?
Get-SmbClientConfiguration
returns the same exact result on all servers- Installed the NTFSSecurity powershell module and ran
Get-NTFSEffectiveAccess -Path \\ServerA\Shared
from all servers. All returned the result. - On
ServerA
, ranicacls "C:\Shared"
. This returned ServerA\theadmin as having access, but none of the other machine's specific admin accounts. So I'm assuming this isn't as relevant. - On
ServerA
, ranGet-SmbShareAccess -Name "Shared"
. TheServerA\theadmin
user was in the results but none of the other machines'theadmin
users are mentioned specifically. - Ran
secedit /export /cfg c:\Windows\temp\secpol.cfg
onServerB
andServerQA
and compared results. There are differences under privileges, but as far as I can tell they seem to reflect local SIDs. I'm less familiar with this though. - On each server, ran
gpresult /h
and compared the HTML files. As far as I can tell, there are no differences. - Per a great answer attempt below, I checked the
ServerQA
server's registry to see ifHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy
was set to1
as it should be. Unfortunately, it already is.
Question
Given all of the above, how can I determine what the difference is between the access from ServerQA
vs ServerB
or ServerC
in this situation? Are there any additional tools I should be considering? Is there a common troubleshooting point I'm missing to determine the difference between servers? I'm at a loss.
Update -- getting closer?
After restarting ServerA
(that hosts the file share), and ServerQA
(the problematic client), the symptoms seemed to go away for about 10 minutes. I was able to modify files and see the scheduled tasks running as expected and modifying files. Then the symptoms returned without any action on my part, and have remained that way.