Background

I have a Windows 7 VM with two user accounts (condor_usr1 and condor_usr2) that is used for source code compiling. The condor_usr[1|2] accounts are members of the administrators group. I have an HTCondor master VM that periodically receives jobs and assigns each job to run on one of the condor_usr[1|2] accounts. The condor service on the Win7 VM runs as the local system account, but jobs being executed actually run as the condor_usr[1|2] account.

I have a new requirement to sign the compiled executable. I've imported the certificate with private key into the Current User\Personal key store in the Windows Certificate store.

Problem

If I'm logged into the Win7 VM (e.g. via remote desktop) as one of the condor_usr accounts, then compiles running as that account will successfully sign the executable, but compiles running as the other account will fail to sign the executable. For example, if I'm logged in as condor_usr2, then compiles running under condor_usr2 will sign successfully and compiles running under condor_usr1 will fail to sign. If I log out, both accounts fail to sign.

The specific error I receive is:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets(264,9): error MSB3482: An error occurred while signing: The system cannot find the file specified.

Turned on some audit logging and found the following log that occurred at the same time as a signing failure.

Goal

Sign the compiled executable successfully regardless of which account the compile is running as and without requiring a user to be logged in.

What I've Figured Out So Far

• The code/project being compiled is a Visual Studio 2017 solution.
• The signing method is ClickOnce manifest signing (an option in the VS2017 project).
• When a compile job is started, the job logs in as condor_usr[1|2] using logon type 2 (interactive logon). https://ss64.com/nt/syntax-logon-types.html

Things I've Tried

Unless otherwise noted, these actions had no effect and were reverted.

• Adding the condor_usr accounts to the Cryptographic Operators group.
• Importing the certificate w/ private key to the Local Computer\Personal key store.
  • Granting the Network Service account full control to the certificate/private key. https://community.dynamics.com/nav/b/technicaltipsandtricksfordynamicsnav/posts/how-to-grant-access-to-the-certificate-s-private-key-to-the-service-account-for-microsoft-dynamics-nav-server
• Using PsExec -h make.bat to obtain the account's elevated token. https://learn.microsoft.com/en-us/sysinternals/downloads/psexec
• I considered that User Account Control (UAC) may be preventing the system account and/or condor_usr account from accessing the certificate store (or private keys in the cert store), but UAC is already disabled on the Win7 VM.
• I placed the original .pfx certificate file in the VS2017 solution and targeted it instead of the certificate in the key store. This had no effect, which leads me to believe that the issue is some sort of signing permission rather than (or perhaps in addition to) purely permissions around the actual certificate store.
• I tried starting a job while logged in via remote desktop, and then logging out of the remote desktop session (actual logout, not disconnect) before the job got to the signing portion. Signing failed.

Make sure all the accounts involved in the process has the "Logon as service" rights by ensuring they are present in the local policy "Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Log on as a service". Note that this change becomes effective the next time the owner of the account(s) logs on.

Try running the HTCondor service directly as "condor_usr1" instead of the "Local System" account.