Though I haven't personally tested, I have good reason to believe that the above stated AT COMMAND solution will work for XP, 2000 and Server 2003. Per my and Bryant's testing, we've identified that the same approach does not work with Vista or Windows Server 2008 -- most probably due to added security and the /interactive switch being deprecated.
However, I came across this article which demonstrates the use of PSTools from SysInternals (which was acquired by Microsoft in July, 2006.) I launched the command line via the following and suddenly I was running under the Local Admin Account like magic:
psexec -i -s cmd.exe
PSTools works well. It's a lightweight, well-documented set of tools which provides an appropriate solution to my problem.
Many thanks to those who offered help.
Since there is so much confusion about functionality of standard service accounts, I'll try to give a quick run down.
First the actual accounts:
LocalService account (preferred)
A limited service account that is very similar to Network Service and meant to run standard least-privileged services. However, unlike Network Service it accesses the network as an Anonymous user.
- Name:
NT AUTHORITY\LocalService
- the account has no password (any password information you provide is ignored)
- HKCU represents the LocalService user account
- has minimal privileges on the local computer
- presents anonymous credentials on the network
- SID: S-1-5-19
- has its own profile under the HKEY_USERS registry key (
HKEY_USERS\S-1-5-19
)
NetworkService account
Limited service account that is meant to run standard privileged services. This account is far more limited than Local System (or even Administrator) but still has the right to access the network as the machine (see caveat above).
NT AUTHORITY\NetworkService
- the account has no password (any password information you provide is ignored)
- HKCU represents the NetworkService user account
- has minimal privileges on the local computer
- presents the computer's credentials (e.g.
MANGO$
) to remote servers
- SID: S-1-5-20
- has its own profile under the HKEY_USERS registry key (
HKEY_USERS\S-1-5-20
)
- If trying to schedule a task using it, enter
NETWORK SERVICE
into the Select User or Group dialog
LocalSystem account (dangerous, don't use!)
Completely trusted account, more so than the administrator account. There is nothing on a single box that this account cannot do, and it has the right to access the network as the machine (this requires Active Directory and granting the machine account permissions to something)
- Name:
.\LocalSystem
(can also use LocalSystem
or ComputerName\LocalSystem
)
- the account has no password (any password information you provide is ignored)
- SID: S-1-5-18
- does not have any profile of its own (
HKCU
represents the default user)
- has extensive privileges on the local computer
- presents the computer's credentials (e.g.
MANGO$
) to remote servers
Above when talking about accessing the network, this refers solely to SPNEGO (Negotiate), NTLM and Kerberos and not to any other authentication mechanism. For example, processing running as LocalService
can still access the internet.
The general issue with running as a standard out of the box account is that if you modify any of the default permissions you're expanding the set of things everything running as that account can do. So if you grant DBO to a database, not only can your service running as Local Service or Network Service access that database but everything else running as those accounts can too. If every developer does this the computer will have a service account that has permissions to do practically anything (more specifically the superset of all of the different additional privileges granted to that account).
It is always preferable from a security perspective to run as your own service account that has precisely the permissions you need to do what your service does and nothing else. However, the cost of this approach is setting up your service account, and managing the password. It's a balancing act that each application needs to manage.
In your specific case, the issue that you are probably seeing is that the the DCOM or COM+ activation is limited to a given set of accounts. In Windows XP SP2, Windows Server 2003, and above the Activation permission was restricted significantly. You should use the Component Services MMC snapin to examine your specific COM object and see the activation permissions. If you're not accessing anything on the network as the machine account you should seriously consider using Local Service (not Local System which is basically the operating system).
In Windows Server 2003 you cannot run a scheduled task as
NT_AUTHORITY\LocalService
(aka the Local Service account), or
NT AUTHORITY\NetworkService
(aka the Network Service account).
That capability only was added with Task Scheduler 2.0, which only exists in Windows Vista/Windows Server 2008 and newer.
A service running as NetworkService
presents the machine credentials on the network. This means that if your computer was called mango
, it would present as the machine account MANGO$
:
Best Answer
This is a very good question and sadly many developers don't ask enough questions about IIS/ASP.NET security in the context of being a web developer and setting up IIS. So here goes....
To cover the identities listed:
IIS_IUSRS:
This is analogous to the old IIS6
IIS_WPG
group. It's a built-in group with it's security configured such that any member of this group can act as an application pool identity.IUSR:
This account is analogous to the old
IUSR_<MACHINE_NAME>
local account that was the default anonymous user for IIS5 and IIS6 websites (i.e. the one configured via the Directory Security tab of a site's properties).For more information about
IIS_IUSRS
andIUSR
see:DefaultAppPool:
If an application pool is configured to run using the Application Pool Identity feature then a "synthesised" account called
IIS AppPool\<pool name>
will be created on the fly to used as the pool identity. In this case there will be a synthesised account calledIIS AppPool\DefaultAppPool
created for the life time of the pool. If you delete the pool then this account will no longer exist. When applying permissions to files and folders these must be added usingIIS AppPool\<pool name>
. You also won't see these pool accounts in your computers User Manager. See the following for more information:ASP.NET v4.0:
-This will be the Application Pool Identity for the ASP.NET v4.0 Application Pool. See
DefaultAppPool
above.NETWORK SERVICE:
-The
NETWORK SERVICE
account is a built-in identity introduced on Windows 2003.NETWORK SERVICE
is a low privileged account under which you can run your application pools and websites. A website running in a Windows 2003 pool can still impersonate the site's anonymous account (IUSR_ or whatever you configured as the anonymous identity).In ASP.NET prior to Windows 2008 you could have ASP.NET execute requests under the Application Pool account (usually
NETWORK SERVICE
). Alternatively you could configure ASP.NET to impersonate the site's anonymous account via the<identity impersonate="true" />
setting inweb.config
file locally (if that setting is locked then it would need to be done by an admin in themachine.config
file).Setting
<identity impersonate="true">
is common in shared hosting environments where shared application pools are used (in conjunction with partial trust settings to prevent unwinding of the impersonated account).In IIS7.x/ASP.NET impersonation control is now configured via the Authentication configuration feature of a site. So you can configure to run as the pool identity,
IUSR
or a specific custom anonymous account.LOCAL SERVICE:
The
LOCAL SERVICE
account is a built-in account used by the service control manager. It has a minimum set of privileges on the local computer. It has a fairly limited scope of use:LOCAL SYSTEM:
You didn't ask about this one but I'm adding for completeness. This is a local built-in account. It has fairly extensive privileges and trust. You should never configure a website or application pool to run under this identity.
In Practice:
In practice the preferred approach to securing a website (if the site gets its own application pool - which is the default for a new site in IIS7's MMC) is to run under
Application Pool Identity
. This means setting the site's Identity in its Application Pool's Advanced Settings toApplication Pool Identity
:In the website you should then configure the Authentication feature:
Right click and edit the Anonymous Authentication entry:
Ensure that "Application pool identity" is selected:
When you come to apply file and folder permissions you grant the Application Pool identity whatever rights are required. For example if you are granting the application pool identity for the
ASP.NET v4.0
pool permissions then you can either do this via Explorer:Click the "Check Names" button:
Or you can do this using the
ICACLS.EXE
utility:...or...if you site's application pool is called
BobsCatPicBlog
then:I hope this helps clear things up.
Update:
I just bumped into this excellent answer from 2009 which contains a bunch of useful information, well worth a read: