Since yesterday I haven't been able to generate strong name keys using sn.exe or through Visual Studio which also uses sn.exe.
When attempting to generate a key file the following cimmand is executed
sn - k "key file.snk"
sn.exe then responds with
Failed to generate a strong name key pair -- Access is denied.
After repeating this process while running Process Monitor I now know that the locations to which sn.exe is denied access all reside within the following directory
\ProgramData\Microsoft\Crypto\RSA\MachineKeys
Querying the permissions of this folder reveals that the Everyone and Administrators groups have no rights and the NETWORK SERVICE account has Full Control.
Yesterday, I installed SourceGear Fortress which does use the NETWORK SERVICE account, however that is the only sicnificant change to the system prior to the issue occuring.
Is it normal for Everyone and Administrators to have no rights to the RSA key store?
After restoring Read and Write permissions to my user account for the MachineKeys directory I was again able to generate keys
Related
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.
I have a running Windows server image on EC2.
I created an additional administrator login and have been using it login using RDP. Unfortunately I've lost the PEM file for the "Administrator" account and I've also disabled it for "safety"
Since I have access to the instance through an alternative administrative account I'm trying to figure out a few things:
Do need the "Administator" account PEM file in future?
If I get Amazon to generate a new PEM file using the same name that I currently have, how do I replace the "Administrator" key pair for the instance?
I've searched all over and can't find an answer on how to replace the key pair or add an additional key pair to a running "Windows" instance
Everything talks about shutting down and creating an new instance. I cannot shut down this server, so that must be a way to replace the key pair for the "Administrator" account.
I can't even find where Windows stores the key pair in a Windows server.
When an instance is first launched from one of the Amazon-supplied Windows AMIs, some code on the instance generates a random Administrator password. This password is then encrypted with the selected Keypair and passed back to AWS (you can actually see it in the System Log).
When you wish to first login to the instance, you will need to use the PEM to decrypt the Administrator password. You can then login to the Windows instance using that password.
It is recommended that you immediately change the Administrator password or connect the instance to Active Directory -- basically, follow your standard company security practices.
If you remember the password, you will not require the PEM file again. In fact, if you change the password, then even having the PEM will not facilitate access because it will only decrypt the original password, not the current password.
Bottom line: Ignore the PEM file. You still have administrative access to the instance, so you don't even need the Administrator account anymore. If you wish to use the Administrator account, simply use your existing administrative login to reactive it and set the password. There is no reason to panic and, actually, no reason to do anything.
I'm writing a Windows Service that occasionally queries data in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles, to detect if the system has changed network (e.g. it's a laptop and they connect to a new Wifi Hotspot).
The Service must run as a LocalService account, so has no administration privileges, however the read permissions on this particular key and its subkeys are for Administrators ony, so the LocalService account is not able to read them.
I'd like to manually add read permissions for my Service to the key, but ONLY for that one Service. I could grant the "Local Service" account read privileges, but this would allow all LocalService Services to read the key, which I do not want. Is there any way of doing this, maybe creating a user account for a single application?
Vista added Service Isolation and it can assign a service SID to the process. You can then add this SID to the ACL of the registry key.
I am importing X509 from PKCS #12 file (using PFXImportCertStore Cryptographic API) in Computer's Personal Store.
Problem:
Any process running under "Local Service" account or any non-admin account can not access privates key (restricted to Admin user by Windows).
How to give access to private keys of a certificate to non-admin users and local service?
Note:
Since multiple process use certificates, I preferred using Computers store instead user's store.
This is a tricky one with some pitfalls. I had the same problem and was close to despair, when I finally found the remark which saved me in this post
I succeeded to do this for a local service running under the Network Service account.
First, there is the option to grant other users access to the private key of a certificate in the MS certificate store. Already this I'd classify as druid knowledge: this option is available in the context menu (right click the certificate), but only if the certificate resides in the localMachine\Personal store. There, in the entry All tasks, you will find the sub entry Manage Private Keys. This is not available in other stores, not even in the CurrentUser\Personal store.
This entry opens a dialog which allows you to add access rights to the certificate for other users. Here, the next hurdle waits for you: the default setting is to search for users in the domain, not on the local machine. The desired user may not be found, unless you change the search filter.
To this result I came very fast by googling, but it did not help. I could get the service to run, but only if I changed the service user to the logon account, which is not what I wanted (this leads, btw, to a workaround: create a local user account for services and import the certificate from within that user account. You can then place the certificate in almost any store and it will work fine)
This is where the post cited above comes in, the last hurdle for me: the procedure described above seems to work only if you import the certificate into the certificate store from within the MMC snapin. Select the store localMachine\Personal and use the context menu to import the certificate in question. (I chose to make the private key exportable, this may or may not be relevant here). If you import the certificate by double clicking on it in the file system, it will be imported into some store in the Current User location. I used to do this and then move it into the localMachine\Personal folder and changed the access right -- this did never work for me. Only after importing it from within localMachine\Personal in the MMC certificate snap-in it worked immediately...
(Also note that you have to place the certificate into a store which can be found by the service user. Your current user stores usually does not allow this, so localMachine is the better choice, anyway)
I don't know whether you can move the certificate around afterwards, but that's easy to check in the system..
Hopefully a simple one.
If I run powershell on my XP machine and run:
PS> get-childitem \\networkdrive\$share\folder\file.ext
the command successfully completes and returns the information I am looking for.
If I run the same command from team city it error with an Object-Not-Found. (The team city server and agent are running on the same machine that succeeds with the command)
I'm presuming that this is because Windows Services (what the agent is running as) cannot access network drives.
Does anyone have a simple workaround for this?
The problem is not that team city is running as an Windows Service. The problem is that the account used for that service do not have access to the network share.
There are two solutions to the problem:
1) Change the account of the service to an account which have access to the network share.
Open Services-> Find the team city services
Right click-> Properties -> Go to the Log On tab
Put in the name and password of an account with access
2) Grant the currently used account (most likely the Network Service Account) access to the share.
Use the above steps to figure out which account Team City is running under
On the share Grant access to that account
If it is the Network Service or System account, you need to add the Computer as an account instead of a user. So make sure you pick Computer as object type in the Add dialog.