Trying to set a local account to run the service would fail with
LsaLookupNames() complaining that the name could not be looked up.
Thanks Allen Vailliencourt.
Jump through a few hoops to make the Windows service control panel to
localise service ObjectNames if they are set to LocalSystem,
LocalService or NetworkService.
Those aren't the canonical names of the accounts as returned by
LsaLookupSids() so attempting to call ChangeServiceConfig() with a
username of, eg, NetworkService will fail, even though writing
NetworkService directly to the registry would work. Calling
ChangeServiceConfig() with a username of "NT Authority\Network Service"
will work, since that's the canonical name returned by LsaLookupSids()
but it won't be localised in the control panel.
The solution is to write "NT Authority\NetworkService" to the registry
and it will appear correctly.
At this point I'm not sure whether to label it a bug or a feature that
"nssm get <service> ObjectName" will return the actual value in the
registry and not the localised name.
Thanks Marco Certelli.
Certain well-known accounts can be used to start a service without
entering a password.
"LocalSystem" is the default value of ObjectName in the registry. It is
not a real account but is an alias for the "NT Authority\System"
account.
"NT Authority\Local Service" has minimal local and no network
privileges.
"NT Authority\Network Service" has minimal local and network privileges.
NSSM now recognises these well-known accounts and will accept them as
ObjectName parameters without complaining that no password was enter.
With the exception of LocalSystem, each can be specified without the "NT
Authority" pseudo-domain prefix.
Iain Patterson