When troubleshooting authentication, certificate enrollment or often quite any other system issue, it is usually necessary to do the tests under exactly the same identity as is running the problematic system component. Every user account can have very different settings which affect Kerberos authentication or certificate enrollment or any other permission and user rights settings.
For example, if your troublemaker runs under SYSTEM account, you must run the troubleshooting tools under SYSTEM account. If the problems appears under Network Service, run your tests under its identity as well. Even such close accounts as SYSTEM and Network Service have certain differences. Apart from being member of Administrators group in case of SYSTEM, the account also has NTLM authentication disabled by default and is willing to use Kerberos only, while Network Service may fall back to NTLM if necessary. Local Service virtual account is also similar to Network Service, but although it can access network, it cannot make use of its machine's identity and will do so anonymously.
Even if you run services under a domain user account, there are many crumb settings that make huge differences when somethings goes wrong. There are many options such as various Kerberos delegation types and settings, Kerberos AES or DES encryption settings, service principal names (SPNs), group membership, logon workstations or account expiration, LDAP account permissions (affected for example by the AdminSDHolder feature) and others.
One of every troubleshooter's commandement is thus to run his/her tools under the same identity that shows the error.
How to run a command line under nearly any identity?
As long as you can start command line (CMD) interactively under your problematic account, you can later start any other tool you need, even those which display GUI, from the command line.
The builtin RUNAS command can be used to log on arbitrary domain or local user account. Although it is kind of limited and cannot start anything under SYSTEM or other virtual accounts. We go for PSEXEC instead. You can download PSEXEC utility from Microsoft's own site at live.sysinternals.com (don't be afraid, it has always been digitally signed by Microsoft), or from here http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx.
To run command line under SYSTEM account:
To run command line under Network Service account:
psexec -d -i -u "NT Authority\Network Service" cmd.exe
psexec -d -i -u "NT Authority\NetworkService" cmd.exe
To run command line under Local Service account:
psexec -d -i -u "NT Authority\Local Service" cmd.exe
psexec -d -i -u "NT Authority\LocalService" cmd.exe
To run command line under NT SERVICE virtual service identity or IIS APPPOOL virtual application pool identity
Unfortunatelly, not even PSEXEC does have this functionality. I personally doubt it is possible to achieve at all. So in case you need to troubleshoot any local issues, you are lost here. But in case the the service or app pool tries to access a network resource, you can make do with Network Service account again. From network perspective, they are the same. Up to my knowledge, NT SERVICE and IIS APPPOOL virtual accounts differ from Network Service only locally on the computer where they are running.
Note about PSEXEC insecurity when starting programs over network
Although PSEXEC documentation says, that the tool sends user passwords over network unencrypted, it does not have any risk locally. When you start command line locally, no passwords are transmitted over network and thus you are safe.
You are still safe, even if you used PSEXEC to start a program locally under a domain user account, which requires prior authentication on a DC. Although such operation requires some network access in the form of user authentication, it uses normal Kerberos or NTLM authentication to verify user's credentials. Both methods are encrypted when packets get sent over network.
The only case of clear password sending over network would occure, if you started a program on a remote computer under a different user identity than the one under which you are running PSEXEC on your local machine.