In that panel you should therefore make sure that your service is entered
Are you talking about just adding this to the name so it stands out?
No. These are the literal names that need to be entered in the ACL editor.
Other variations might not be accepted possibly depending on what version
of the OS you're using perhaps ("LocalSystem" for instance won't be accepted
on XP so you need to enter "System"). Other acceptable variations may be
possible however but it's immaterial. The names don't really matter since
they represent the same account. Note that different locations in Windows
may accept the other variations however (perhaps the "Services" panel for
instance - maybe someone at MSFT should start enforcing a consistent naming
convention).
When you say "System" account - what account are you talking about? Are
you talking about the LocalSystem account?
Yes. The account name you actually enter is "System" however (in the ACL
editor anyway)
On my other system, I just set up "LocalSystem" in my project. When I
right click my service from the Services window from "My Computer"/manage
and go to the Log On tab, I have the "This Account" selected and an
account name in it such as (e-mail address removed) with a password
which the user has set up networking permissions for. In that case, we
are not printing to network printer. In this case we are.
All that does is tell the system which account to launch the service under.
This refers to its "security context". Read on.
I don't have the program set up as Network Service, but I assume that when
I select "This Account" instead of "Local System account" that I am
setting up a Network Service account (could be wrong here).
No. "Network Service" is the name of an actual account that's built into
Windows. You can enter any account you want here including the "Network
Service" account (the "System" account itself has its own radio button on
this panel however). The three accounts we've been discussing are what most
people use. The "LabelPrinter" account you referred to above isn't normal
although it's permitted (but probably unsuitable though - the other three
are the norm). Just enter "NT AUTHORITY\NetworkService" if that's what you
want (no password required - note the different naming convention here
compared to the ACL editor but I won't get into the details).
When you say it takes on the computer's credentials - what does that mean.
It's basic Windows security. Every program runs with an identity, AKA
"credentials", "security context", etc. (there are various synonymns). The
simple story is that when you log on, every program you launch does so under
your logon identity. If you try to access any resource on your system (a
file or whatever), you're allowed to do so only if that resource permits
your identity to access it. Each resource has a DACL associated with it
(Discretionary Access Control List) which is basically just a list of who
can access that resource and in what way (read, write, whatever). Whenever
any program tries to access a given resource, the system simply checks the
identity of the program's currently running thread against the DACL for that
resources. If the DACL allows that identity to access the resource in the
way that's being requested (write access for instance), then all's well.
Otherwise you get "access denied" errors. The very same program however
would work just fine when running with the identity of a user that does have
the required rights (if you log on as that user instead). Now, when a
service is running, it's doing so under the account you specify in the
services control panel. That's what the "Log On" tab is for. The service
starts under the account you specify and can therefore access resources as
just described. Its security context is now that account however (which is
different than the account of the user who's currently logged on to Windows
itself). Note that these security contexts are also referred to as logon
sessions. Again, this is the simple story but read on.
Now, when you access a resource on another machine, usually by accessing
some share that was set up on that machine (shared folder, printer, etc.), a
"logon session" is created on that machine to represent the remote (client)
user. As described above then, that logon session can then access any
resource it's permittted to access via the resource's DACL (the printer's
DACL in this case). Who's identity is used for this logon session however?
By default it's the identity of the currently running thread back on the
client machine. This now gets into a deeper area however because the server
needs to authenticate this user. For the subject of this discusssion, if the
"System" account or "Network Service" account on the client machine is
trying to access the shared resource, its identity will be
"DomainName\MachineName", assuming your network is running a Windows domain
which is likely in most companies. This refers to the client machine's
account on the domain controller itself (since every computer in the domain
has such an account). This account represents each machine itself but it's
no different than any other domain acccount (your own included). So, the
server where the shared resource is (printer in this case) will now
authenticate "DomainName\MachineName" and create a logon session for that
user, even though this "user" is really a machine and not a human. The
"System" or "Network Service" accounts on the client machine can therefore
print on the server machine (via the share) so long as
"DomainName\MachineName" is in the share's DACL on the server (well, this is
still a simplification since there's actually security at the "share" level
which doesn't really involve DACLs but that's another topic). So, the answer
to your question "when you say it takes on the computer's credentials - what
does that mean" should now be reasonably clear. The "computer's credentials"
refers to the client computers' credentials, i.e., the security context of
the "DomainName\MachineName" account which the logon session will be running
under on the server where the shared resource is located (when that shared
resource is being accessed from a service running under the "System" or
"Network Service" account on the client machine).
I thought we could not use a Local System account if accessing the network
and that a specific account would have to be set up. This would make
sense since this would run without anyone actually be logged in. Right?
You may have explained this later, but I just want to make sure.
The "Local System" account (AKA "System" account) can access the network as
just previously described. In your case however, if the client machine is
accessing a network printer that's not attached to another machine running
Windows (the printer is just another piece of hardware on the network but it
knows nothing about Windows), then so long as the "System" account is
included in the DACL of that printer on the host machine (the machine where
"System" itself is running), it should be able to print to it. You need to
confirm this of course but I'm unaware of any reason why it shouldn't work.
Is this both, Local Service and Local System?
"Local Service" only. "Local System" (or just "System") has credentials as
previously described (in a Windows domain only - if there's no domain then
it has no network credentials either)
So if I am dealing with a networked printer (no pc involved), I could do
this with only Local Service or Local System as long as I have it defined
in the "Add Printers" program with "Everyone" as a group and "Print"
permissions. Or if Everyone is not there, I would have to set up service
as "This Account" with a user and password and that User would have to be
in the "Add Printers" Security tab under "Group or user names" with
"Print" permission (or a Group that has this user in it would need to be
there with "Print" permissions).
Yes. Under "This Account" however you can enter "Network Service"
or "Local Service" which is what you should almost certainly do (unless your
service requires full rights to the machine for other purposes in which case
you may need to check the "Local System account" radio button instead, since
this account has full rights on your machine).
Except that you can't access the Network at all with "Local Service",
right?
Wrong. You can still access the network but you'll have no credentials. This
only matters if you're contacting another Windows machine however . If so
then this account isn't normally suitable (it's not intended for this).
