2

I have a web site that hits a fileshare on our network and uses the computer (webserver$), not a user account, to authenticate as the website runs as Network Service. I thought I could create a local account on the web server and runas to test hitting the file share, but that didn't work (access denied hitting \Server). The website is hitting the share, but it seems like subfolders are not consistently granted permission; this is what I'm testing.

This is related as it covers setting up access. How to grant network access to LocalSystem account?

I'd thought this was my solution, but I've tried as System, NetworkService, and LocalService and none of them can access the share.

How can I test this authentication from the web server?


UPDATE 20180613

A sub-folder didn't have the web server's access/permission applied and this is resolved, but for my own knowledge, I would still like to know how to test a file share+subfolder access with the permission granted by computername$. It's easy if it is a user account because I can specify a username/password, but I can't seem to find the right way to manually test if the access is granted to a computer instead of a user.

UnhandledExcepSean
  • 151
  • 1
  • 7
  • If the website is hitting the share correctly and the subfolder permissions are not granted consistently, authentication is working flawless. You can see 'active connections' in the file sharing tools. – bjoster Jun 13 '18 at 13:27

2 Answers2

0

Essentially, you have to become NT AUTHORITY\SYSTEM. There are a variety of ways to do that, but the easiest is probably PsExec. From an elevated cmd prompt, use the following to open a new cmd prompt as the system account.

psexec -s -i cmd

From there, verify who you are with whoami and proceed to test however you want.

Ryan Bolger
  • 16,472
  • 3
  • 40
  • 59
  • This isn't it, I had tried this yesterday (refer to the "I'd thought this was my solution" paragraph) BUT I was just testing again and I think I found my issue. I'll post it as an answer. – UnhandledExcepSean Jun 13 '18 at 17:34
0

So, my underlying issue was that a folder didn't have permission to the web server.

But the failure in manually testing it was this. What I was doing:

  1. Open a command window
  2. cd
  3. psexec -s -i cmd
  4. In the new command window, whoami. Shows NT Authority\System
  5. in the new command window, type start \\servername
  6. Server opens in Explorer. Access to share denied when double clicking it.


What I did today worked when I tried it again differently:

  1. Open a command window
  2. cd
  3. psexec -s -i cmd
  4. In the new command window, whoami. Shows NT Authority\System
  5. in the new command window, type dir \\servername\share
  6. all of the sub-folders are shown on screen

So, the underlying problem was that I expected the START/Explorer to run under the account in the second command window and I couldn't readily determine what account Explorer was running under.

UnhandledExcepSean
  • 151
  • 1
  • 7