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.batto obtain the account's elevated token. https://docs.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.
