Windows Services and network printers

[tshad]

We are setting up a Windows Service that will need to have access to some
network printers.

The printers will be set up on the server and have access from the server,
but does the Windows Server need to have Network permission to print to the
printers or is the fact that the server has access enough? Or can it use
the LocalSystem or LocalService Account to access the networked printers.

Thanks,

Tom

 

[Larry Smith]

We are setting up a Windows Service that will need to have access to some

network printers.

The printers will be set up on the server and have access from the server,
but does the Windows Server need to have Network permission to print to
the printers or is the fact that the server has access enough? Or can it
use the LocalSystem or LocalService Account to access the networked
printers.

Your explanation isn't clear enough I'm not sure what you're setup is
exactly. Is your service running on the same machine as the "network"
printer for instance or is this "network" printer on another machine (that
your service needs to access). In the general case, if a client on machine A
(a service or anyone else) tries to access a shared resource on machine B
(printers in this case), then a network logon session is created on machine
B representing that client. The identity associated with that session
determines what can be accessed. If the identity has permission to access
the share then there's no problem for client A. The nuts and bolts of all
this are more detailed of course so you need to understand authentication
among other things. For starters, read a couple of my previous posts on the
subject in general. I found a couple of old links to them here:

http://www.ureader.com/msg/16591694.aspx (search for "Larry Smith" and read
the explanation just above)
http://www.eggheadcafe.com/conversation.aspx?messageid=34259950&threadid=34224226

These are detailed enough to get you started but consult the following book
for full details (mentioned in each of the above links - consult chapter 8
in particular which you need to fully understand to prevent potential
problems):

http://www.amazon.com/Programming-Windows-Security-DevelopMentor-Keith/dp/0201604426

 

[Larry Smith]

We are setting up a Windows Service that will need to have access to some

network printers.

The printers will be set up on the server and have access from the server,
but does the Windows Server need to have Network permission to print to
the printers or is the fact that the server has access enough? Or can it
use the LocalSystem or LocalService Account to access the networked
printers.

Your explanation isn't clear enough I'm not sure what you're setup is
exactly. Is your service running on the same machine as the "network"
printer for instance or is this "network" printer on another machine (that
your service needs to access). In the general case, if a client on machine A
(a service or anyone else) tries to access a shared resource on machine B
(printers in this case), then a network logon session is created on machine
B representing that client. The identity associated with that session
determines what can be accessed. If the identity has permission to access
the share then there's no problem for client A. The nuts and bolts of all
this are more detailed of course so you need to understand authentication
among other things. For starters, read a couple of my previous posts on the
subject in general. I found a couple of old links to them here:

http://www.ureader.com/msg/16591694.aspx (search for "Larry Smith" and read
the explanation just above)
http://www.eggheadcafe.com/conversation.aspx?messageid=34259950&threadid=34224226

These are detailed enough to get you started but consult the following book
for full details (mentioned in each of the above links - consult chapter 8
in particular which you need to fully understand to prevent potential
problems):

http://www.amazon.com/Programming-Windows-Security-DevelopMentor-Keith/dp/0201604426

 

[tshad]

Your explanation isn't clear enough I'm not sure what you're setup is
exactly. Is your service running on the same machine as the "network"
printer for instance or is this "network" printer on another machine (that
your service needs to access). In the general case, if a client on machine
A (a service or anyone else) tries to access a shared resource on machine
B (printers in this case), then a network logon session is created on
machine B representing that client. The identity associated with that
session determines what can be accessed. If the identity has permission to
access the share then there's no problem for client A.

My setup is that I have a windows service that is watching a folder waiting
for some files to show up.

When they do, it will then print them to a networked printer. They may or
may not be connected to another computer. They may just be networkable
printers that are only connected to the Lan.

From what you are saying, I may have to set up the windows server with
Network Service and not LocalSystem. I wasn't sure if because the Server
could access the printers, the Windows Service could as well.

Thanks,

Tom

 

[tshad]

Your explanation isn't clear enough I'm not sure what you're setup is
exactly. Is your service running on the same machine as the "network"
printer for instance or is this "network" printer on another machine (that
your service needs to access). In the general case, if a client on machine
A (a service or anyone else) tries to access a shared resource on machine
B (printers in this case), then a network logon session is created on
machine B representing that client. The identity associated with that
session determines what can be accessed. If the identity has permission to
access the share then there's no problem for client A.

My setup is that I have a windows service that is watching a folder waiting
for some files to show up.

When they do, it will then print them to a networked printer. They may or
may not be connected to another computer. They may just be networkable
printers that are only connected to the Lan.

From what you are saying, I may have to set up the windows server with
Network Service and not LocalSystem. I wasn't sure if because the Server
could access the printers, the Windows Service could as well.

Thanks,

Tom

 

[Larry Smith]

My setup is that I have a windows service that is watching a folder

waiting for some files to show up.

When they do, it will then print them to a networked printer. They may or
may not be connected to another computer. They may just be networkable
printers that are only connected to the Lan.

From what you are saying, I may have to set up the windows server with
Network Service and not LocalSystem. I wasn't sure if because the Server
could access the printers, the Windows Service could as well.

While experimentation is always required to confirm a theory, you should be
able connect to your network printer using any of the service accounts. This
is based on how things normally work though I've never tried this particular
scenario (what follows is sound though). First, I'm assuming the printer is
already setup for access on this machine even though it's a standalone
printer on your LAN (with its own IP address). I'm also assuming there are
no firewall issues on your machine or the printer itself if it supports it.
It may allow you to block clients based on their IP or MAC addresses for all
I know. This would then apply to your entire machine and not some specific
account (service or otherwise). To access the printer from a service you
need to provide "Print" rights to the service just like you would any other
user account (a service is no different). If you bring up the ACL editor for
your printer (Control Panel -> Printers and Faxes -> Right-click target
printer - > Properties - > Security tab), the "Print" permission checkbox
should be checked in the "Permissions for <whoever>" panel seen in the
bottom half of the dialog (check "Allow"). This applies to the currently
selected group or user in the "Group or user names" panel seen in top-half
of the dialog. In that panel you should therefore make sure that your
service is entered either directly (by adding the name "System", "Network
Service" or "Local Service"), or indirectly (e.g., "Everyone",
"Authenticated Users", some other group that contains your service account,
or even "Administrators" since the "System" account always has that SID in
its token, assuming you're using the "System" account). That should give
your service access to the printer in theory. Note that on the network
itself, the "System" account and "Network Service" account normally take on
the identity of the computer's credentials when accessing another machine.
This assumes the machine is a member of a Windows domain since it has no
network credentials otherwise. In a Windows domain however, the network
credentials are "DomainName\ComputerName" where "DomainName" is the name of
the domain and "ComputerName" is the NetBIOS name of the machine. The "Local
Service" account OTOH has no network credentials, i.e., it's anonymous on
the network (a NULL network session is therefore created when accessing
other machines - read the links cited in my last post and the book I
recommended). In your case however, none of this should matter if you're
only accessing a network printer (one plugged directly into the network with
its own IP address opposed to a shared printer on another Windows machine).
At least, I'm not aware of any issues where these credentials will matter
since your machine is accessing the printer directly on the LAN (i.e., your
printer knows nothing about Windows credentials and AFAIK, the Windows
domain running your network shouldn't get involved here). If you're
accessing a printer connected to another Windows machine however then the
above explanation no longer applies. Instead, you'll do that by accessing a
network share so now sharing and authentication issues do come into play on
the print server itself.. IOW, you're now accessing the printer via its
share name on the client machine so when doing this under the "System" or
"Network Service" accounts, the share must provide access to
"DomainName\ComputerName" on the print server (assuming there's a Windows
domain running, otherwise you''ll have no credentials at all which is always
the case with "Local Service" even when a domain is present - you can still
access the printer however if the share allows anonmyous users). Read my
last post including the links I provided and the recommended book for
further details.

 

[Larry Smith]

My setup is that I have a windows service that is watching a folder

waiting for some files to show up.

When they do, it will then print them to a networked printer. They may or
may not be connected to another computer. They may just be networkable
printers that are only connected to the Lan.

From what you are saying, I may have to set up the windows server with
Network Service and not LocalSystem. I wasn't sure if because the Server
could access the printers, the Windows Service could as well.

While experimentation is always required to confirm a theory, you should be
able connect to your network printer using any of the service accounts. This
is based on how things normally work though I've never tried this particular
scenario (what follows is sound though). First, I'm assuming the printer is
already setup for access on this machine even though it's a standalone
printer on your LAN (with its own IP address). I'm also assuming there are
no firewall issues on your machine or the printer itself if it supports it.
It may allow you to block clients based on their IP or MAC addresses for all
I know. This would then apply to your entire machine and not some specific
account (service or otherwise). To access the printer from a service you
need to provide "Print" rights to the service just like you would any other
user account (a service is no different). If you bring up the ACL editor for
your printer (Control Panel -> Printers and Faxes -> Right-click target
printer - > Properties - > Security tab), the "Print" permission checkbox
should be checked in the "Permissions for <whoever>" panel seen in the
bottom half of the dialog (check "Allow"). This applies to the currently
selected group or user in the "Group or user names" panel seen in top-half
of the dialog. In that panel you should therefore make sure that your
service is entered either directly (by adding the name "System", "Network
Service" or "Local Service"), or indirectly (e.g., "Everyone",
"Authenticated Users", some other group that contains your service account,
or even "Administrators" since the "System" account always has that SID in
its token, assuming you're using the "System" account). That should give
your service access to the printer in theory. Note that on the network
itself, the "System" account and "Network Service" account normally take on
the identity of the computer's credentials when accessing another machine.
This assumes the machine is a member of a Windows domain since it has no
network credentials otherwise. In a Windows domain however, the network
credentials are "DomainName\ComputerName" where "DomainName" is the name of
the domain and "ComputerName" is the NetBIOS name of the machine. The "Local
Service" account OTOH has no network credentials, i.e., it's anonymous on
the network (a NULL network session is therefore created when accessing
other machines - read the links cited in my last post and the book I
recommended). In your case however, none of this should matter if you're
only accessing a network printer (one plugged directly into the network with
its own IP address opposed to a shared printer on another Windows machine).
At least, I'm not aware of any issues where these credentials will matter
since your machine is accessing the printer directly on the LAN (i.e., your
printer knows nothing about Windows credentials and AFAIK, the Windows
domain running your network shouldn't get involved here). If you're
accessing a printer connected to another Windows machine however then the
above explanation no longer applies. Instead, you'll do that by accessing a
network share so now sharing and authentication issues do come into play on
the print server itself.. IOW, you're now accessing the printer via its
share name on the client machine so when doing this under the "System" or
"Network Service" accounts, the share must provide access to
"DomainName\ComputerName" on the print server (assuming there's a Windows
domain running, otherwise you''ll have no credentials at all which is always
the case with "Local Service" even when a domain is present - you can still
access the printer however if the share allows anonmyous users). Read my
last post including the links I provided and the recommended book for
further details.

 

[tshad]

While experimentation is always required to confirm a theory, you should
be able connect to your network printer using any of the service accounts.
This is based on how things normally work though I've never tried this
particular scenario (what follows is sound though). First, I'm assuming
the printer is already setup for access on this machine even though it's a
standalone printer on your LAN (with its own IP address). I'm also
assuming there are no firewall issues on your machine or the printer
itself if it supports it. It may allow you to block clients based on their
IP or MAC addresses for all I know. This would then apply to your entire
machine and not some specific account (service or otherwise). To access
the printer from a service you need to provide "Print" rights to the
service just like you would any other user account (a service is no
different). If you bring up the ACL editor for your printer (Control
Panel -> Printers and Faxes -> Right-click target printer - > Properties -
"Permissions for <whoever>" panel seen in the bottom half of the dialog
(check "Allow"). This applies to the currently selected group or user in
the "Group or user names" panel seen in top-half of the dialog.

In that panel you should therefore make sure that your service is entered
either directly (by adding the name "System", "Network Service" or "Local
Service"),

Are you talking about just adding this to the name so it stands out?

or indirectly (e.g., "Everyone", "Authenticated Users", some other group
that contains your service account, or even "Administrators" since the
"System" account always has that SID in its token, assuming you're using
the "System" account).

When you say "System" account - what account are you talking about? Are you
talking about the LocalSystem account?

That should give your service access to the printer in theory. Note that
on the network itself, the "System" account and "Network Service" account
normally take on the identity of the computer's credentials when accessing
another machine.

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.

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).

When you say it takes on the computer's credentials - what does that mean.
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.

This assumes the machine is a member of a Windows domain since it has no
network credentials otherwise. In a Windows domain however, the network
credentials are "DomainName\ComputerName" where "DomainName" is the name
of the domain and "ComputerName" is the NetBIOS name of the machine. The
"Local Service" account OTOH has no network credentials, i.e., it's
anonymous on the network (a NULL network session is therefore created when
accessing other machines - read the links cited in my last post and the
book I recommended).

Is this both, Local Service and Local System?

(I will look at the links as well).

In your case however, none of this should matter if you're only accessing
a network printer (one plugged directly into the network with its own IP
address opposed to a shared printer on another Windows machine). At least,
I'm not aware of any issues where these credentials will matter since your
machine is accessing the printer directly on the LAN (i.e., your printer
knows nothing about Windows credentials and AFAIK, the Windows domain
running your network shouldn't get involved here).

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).

If you're accessing a printer connected to another Windows machine however
then the above explanation no longer applies. Instead, you'll do that by
accessing a network share so now sharing and authentication issues do come
into play on the print server itself.. IOW, you're now accessing the
printer via its share name on the client machine so when doing this under
the "System" or "Network Service" accounts, the share must provide access
to "DomainName\ComputerName" on the print server (assuming there's a
Windows domain running, otherwise you''ll have no credentials at all which
is always the case with "Local Service" even when a domain is present -
you can still access the printer however if the share allows anonmyous
users).

Except that you can't access the Network at all with "Local Service", right?

Thanks,

Tom

 

[tshad]

While experimentation is always required to confirm a theory, you should
be able connect to your network printer using any of the service accounts.
This is based on how things normally work though I've never tried this
particular scenario (what follows is sound though). First, I'm assuming
the printer is already setup for access on this machine even though it's a
standalone printer on your LAN (with its own IP address). I'm also
assuming there are no firewall issues on your machine or the printer
itself if it supports it. It may allow you to block clients based on their
IP or MAC addresses for all I know. This would then apply to your entire
machine and not some specific account (service or otherwise). To access
the printer from a service you need to provide "Print" rights to the
service just like you would any other user account (a service is no
different). If you bring up the ACL editor for your printer (Control
Panel -> Printers and Faxes -> Right-click target printer - > Properties -
"Permissions for <whoever>" panel seen in the bottom half of the dialog
(check "Allow"). This applies to the currently selected group or user in
the "Group or user names" panel seen in top-half of the dialog.

In that panel you should therefore make sure that your service is entered
either directly (by adding the name "System", "Network Service" or "Local
Service"),

Are you talking about just adding this to the name so it stands out?

or indirectly (e.g., "Everyone", "Authenticated Users", some other group
that contains your service account, or even "Administrators" since the
"System" account always has that SID in its token, assuming you're using
the "System" account).

When you say "System" account - what account are you talking about? Are you
talking about the LocalSystem account?

That should give your service access to the printer in theory. Note that
on the network itself, the "System" account and "Network Service" account
normally take on the identity of the computer's credentials when accessing
another machine.

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.

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).

When you say it takes on the computer's credentials - what does that mean.
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.

This assumes the machine is a member of a Windows domain since it has no
network credentials otherwise. In a Windows domain however, the network
credentials are "DomainName\ComputerName" where "DomainName" is the name
of the domain and "ComputerName" is the NetBIOS name of the machine. The
"Local Service" account OTOH has no network credentials, i.e., it's
anonymous on the network (a NULL network session is therefore created when
accessing other machines - read the links cited in my last post and the
book I recommended).

Is this both, Local Service and Local System?

(I will look at the links as well).

In your case however, none of this should matter if you're only accessing
a network printer (one plugged directly into the network with its own IP
address opposed to a shared printer on another Windows machine). At least,
I'm not aware of any issues where these credentials will matter since your
machine is accessing the printer directly on the LAN (i.e., your printer
knows nothing about Windows credentials and AFAIK, the Windows domain
running your network shouldn't get involved here).

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).

If you're accessing a printer connected to another Windows machine however
then the above explanation no longer applies. Instead, you'll do that by
accessing a network share so now sharing and authentication issues do come
into play on the print server itself.. IOW, you're now accessing the
printer via its share name on the client machine so when doing this under
the "System" or "Network Service" accounts, the share must provide access
to "DomainName\ComputerName" on the print server (assuming there's a
Windows domain running, otherwise you''ll have no credentials at all which
is always the case with "Local Service" even when a domain is present -
you can still access the printer however if the share allows anonmyous
users).

Except that you can't access the Network at all with "Local Service", right?

Thanks,

Tom

 

[Larry Smith]

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).

 

[Larry Smith]

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).