73

How do you grant access to network resources to the LocalSystem (NT AUTHORITY\SYSTEM) account?

Background

When accessing the network, the LocalSystem account acts as the computer on the network:

LocalSystem Account

The LocalSystem account is a predefined local account used by the service control manager.

...and acts as the computer on the network.

Or to say the same thing again: The LocalSystem account acts as the computer on the network:

When a service runs under the LocalSystem account on a computer that is a domain member, the service has whatever network access is granted to the computer account, or to any groups of which the computer account is a member.

How does one grant a "computer" access to a shared folder and files?

Note:

Computer accounts typically have few privileges and do not belong to groups.

So how would i grant a computer access to one of my shares; considering that "Everyone" already has access?

Note: workgroup

| Account        | Presents credentials |
|----------------|----------------------|
| LocalSystem    | Machine$             |
| LocalService   | Anonymous            |
| NetworkService | Machine$             |
Ian Boyd
  • 5,131
  • 14
  • 57
  • 79
  • This question is slightly related to the earlier [question related to enabling anonymous access to a share](http://serverfault.com/q/51635/191799) - at least it seems it can be solved with an anonymously accessible share. – CodeFox Aug 26 '15 at 14:09

4 Answers4

67

In a domain environment, you can grant access rights to computer accounts; this applies to processes running on those computers as LocalSystem or NetworkService (but not LocalService, which presents anonymous credentials on the network) when they connect to remote systems.

So, if you have a computer called MANGO, you'll have an Active Directory computer account called MANGO$, which you can grant permissions to.

enter image description here

Note: You can't do any of this in a workgroup environment; this applies only to domains.

Massimo
  • 68,714
  • 56
  • 196
  • 319
  • 6
    +1 and accepted. **But:** LocalService *can* access the network, it just "presents anonymous credentials on the network" (http://msdn.microsoft.com/en-us/library/ms684188(VS.85).aspx) – Ian Boyd Apr 27 '10 at 02:12
  • 1
    Just to mention, having spent a not inconsiderable amount of time trying to get this to work for multiple domains I don't think it's possible. i.e. \\DOMAIN2\MANGO$ doesn't appear to grant access. – BennyB Jul 09 '13 at 13:31
  • This only works if the domains are in a trust relationship; otherwise, you're correct, it doesn't work. – Massimo Jul 09 '13 at 15:06
  • I thought everyday groups includes authenticated users as well as local_service and local_system account? – kakacii May 22 '17 at 03:42
  • Note that `LocalSystem` can also access anything that any other process can. It can thus steal credentials of logged-on users. – Demi Sep 12 '18 at 19:44
  • Related to @IanBoyd 's first comment, granting "Anonymous Logon" permission to a folder still does not allow LOCALSYSTEM to access it. This is relevant, in my case, to attempting to move/migrate Hyper-V VMs from a workgroup host onto a domain-joined host. Hyper-V operations are run as LOCALSYSTEM, which is probably a big part of the reason that live migrations are only supported on a domain. – Thomas Oct 31 '18 at 19:04
4

It's useful to note that computer accounts also fall under Authenticated Users. So you don't have to grant individual computerName$ accounts on your network resource, you can cover all your computers by granting rights to Authenticated Users, if that's your desired scenario.

You can also use YourDomain\Domain Computers

Sandra
  • 261
  • 1
  • 9
  • The OP was a workgroup, so this won't work for the question as asked. – mfinni Apr 29 '20 at 19:29
  • On the other hand, [stackexchange is a combination of Wikipedia meets reddit](https://blog.codinghorror.com/introducing-stackoverflow-com/), and this is [useful](https://meta.stackoverflow.com/a/371355/12597) information to have on this wiki entry. – Ian Boyd May 01 '20 at 13:29
3

You don't. If you need a service to connect to remote files or other network services, then you want to have the service run as a named account, and on the remote machine, assign rights to that named account.

It would really be best if you full explain what you're trying to do - that way you'll get the best answers.

mfinni
  • 35,711
  • 3
  • 50
  • 86
  • 8
    Totally incorrect. You can grant permissions to machine accounts (and thus to services running as them) exactly the same way you can grant them to user accounts. There are of course scenarios where this might not be the best solution, but it's perfectly doable. – Massimo Apr 26 '10 at 15:21
  • @Massimo: mfinni is not saying that you can't technically do it, but that you dont want to do it--It is best practice to run the service as a named account. – Josh Brower Apr 26 '10 at 16:54
  • 1
    The answer looked exactly like that, this is the reason for my downvote; also, the original poster seem to know quite well the difference between an user account and a computer one, so answering his question with "don't do that" just didn't seem right to me. – Massimo Apr 26 '10 at 17:01
  • Also, downvoting *my* answer (which **is** technically correct, as opposed to mfinni's one) is not exactly fair. – Massimo Apr 26 '10 at 17:04
  • 1
    Besides, there are very legitimate scenarios where granting permissions to machine accounts would be needed. Just think about computer startup scripts, or GPO software deployment, or services which just want to run as LocalSystem and you can't do anything about that. I'm not saying this is a best practice or "the" right solution, of course; but if someone asks "how to do this?" I think "don't do it" is definitely not a correct answer. – Massimo Apr 26 '10 at 17:14
  • Massimo - the OP specified that this is a workgroup, so there is no domain. Thus, RemoteServer A wouldn't know the difference between the machine account for Machine B and Machine BadGuy. You're right, that my answer was not technically correct, but I think that it was the best answer for what we know from the OP. – mfinni Apr 26 '10 at 18:44
  • 1
    In a workgroup environment, you can't assign rights on MachineB to an user account defined on MachineA... besides, he was asked specifically how to assign rights to a *maschine* account, so that's what I answered to; and I also said that this was not possible without a domain. – Massimo Apr 26 '10 at 19:03
  • 2
    What i was trying to do is grant **SQL Server**, running as `LocalSystem`, access to a network share; and to do so without **a)** stopping the SQL Server service, **b)** creating a new account for SQL Server to login as, or **c)** changing what account SQL Server logs in as. Also, my reasons for asking the question are irrelevant. i phrased the question so people besides me could use the knowledge and apply it to their individual situations. Finally, while i am in this particular instance on a domain: any complete answer would include instructions for on a workgroup. – Ian Boyd Apr 27 '10 at 02:11
  • Massimo - if he's in a workgroup, he can make an account with an identical username and password on both machines, that will work as I described. – mfinni Apr 27 '10 at 03:12
  • 2
    Ian - if that's what you're after, it's usually a better idea to use the SQL Server Agent and its account, or use Integration Services. You can get more detail when you ask a detailed question, and it can still be very applicable to other readers' situations. – mfinni Apr 27 '10 at 03:16
-1

It is Simple:

Put the Machine´s AD Account into the local Admins Group and then this Machine (or its Local Admin Account) can fully Access the destination OVER the Network. Tested today, works fine.

womble
  • 95,029
  • 29
  • 173
  • 228
Frank Wolf
  • 1
  • 5
    While this is functional, it is NOT recommended or best practice. The `Local System` account is called local for a reason. If you want something to have network access, the service or otherwise should be changed to run as another user. This would be like granting the `guest` account on a machine administrator access. It would work, but that defeats the purpose of what it was built for. – Cory Knutson Aug 28 '18 at 13:41