Заден план

Имам Windows 7 VM с два потребителски акаунта (condor_usr1 и condor_usr2), който се използва за компилиране на изходен код. Акаунтите condor_usr[1|2] са членове на групата администратори. Имам главна виртуална машина на HTCondor, която периодично получава задачи и присвоява всяка задача да се изпълнява на един от акаунтите condor_usr[1|2]. Услугата condor на Win7 VM работи като акаунт на локалната система, но изпълняваните задачи всъщност се изпълняват като акаунт condor_usr[1|2].

Имам ново изискване да подпиша компилирания изпълним файл. Импортирах сертификата с частен ключ в хранилището на текущ потребител\личен ключ в хранилището на сертификати на Windows.

проблем

Ако съм влязъл в Win7 VM (напр. чрез отдалечен работен плот) като един от акаунтите condor_usr, тогава компилациите, работещи като този акаунт, ще подпишат успешно изпълнимия файл, но компилациите, работещи като другия акаунт, няма да успеят да подпишат изпълнимия файл. Например, ако съм влязъл като condor_usr2, тогава компилациите, изпълнявани под condor_usr2, ще се подпишат успешно, а компилациите, работещи под condor_usr1, няма да успеят да се подпишат. Ако изляза, и двата акаунта не успяват да се подпишат.

Конкретната грешка, която получавам е:

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.

Включих някои журнали за проверка и намерих следния журнал, който се появи едновременно с неуспешно подписване.

Цел

Подпишете компилирания изпълним файл успешно, независимо от кой акаунт се изпълнява компилирането и без да се изисква потребител да е влязъл.

Какво разбрах досега

• Кодът/проектът, който се компилира, е решение на Visual Studio 2017.
• Методът за подписване е подписване на манифест ClickOnce (опция в проекта VS2017).
• Когато се стартира задание за компилиране, заданието влиза като condor_usr[1|2] с помощта на тип влизане 2 (интерактивно влизане). https://ss64.com/nt/syntax-logon-types.html

Неща, които съм пробвал

Освен ако не е отбелязано друго, тези действия нямаха ефект и бяха отменени.

• Добавяне на condor_usr акаунти към групата криптографски оператори.
• 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
• Използване на PsExec -h make.bat за получаване на повишен токен на акаунта. https://docs.microsoft.com/en-us/sysinternals/downloads/psexec
• Смятам, че контролът на потребителските акаунти (UAC) може да пречи на системния акаунт и/или акаунта condor_usr да получи достъп до хранилището на сертификати (или частни ключове в хранилището на сертификати), но UAC вече е деактивиран на Win7 VM.
• Поставих оригиналния .pfx файл със сертификат в решението VS2017 и го насочих вместо сертификата в хранилището на ключове. Това нямаше ефект, което ме кара да вярвам, че проблемът е някакъв вид разрешение за подписване, а не (или може би в допълнение към) чисто разрешения около действителното хранилище на сертификати.
• Опитах да стартирам задание, докато бях влязъл през отдалечен работен плот, и след това излязох от сесията на отдалечения работен плот (действително излизане, а не прекъсване на връзката), преди заданието да стигне до частта за подписване. Неуспешно подписване.