I have a need to access an RSA private key from a Windows service running under the NT AUTHORITY\SYSTEM account. I'm able to install the private key on the server, and then make use of that key when running as the user that installed the key. However, the key does not seem to be available from the Windows service. Do I need a machine-level key here (which I understand increases the risk of compromise), or is there a way I can install a key specifically intended for use by the SYSTEM account?
You can do start->run->mmc, load the Certificates snap-in and then choose "Service account" to manage the certificates for a specific service. I am not sure if you can do this for the SYSTEM account. Is this a requirement or are you able to run your service as a custom least privilege account?
Related
We have a bunch of Windows server applications that currently handle secrets as follows; our apps are in C#.
We store them in settings files in code
We store them encrypted, using a certificate
The servers have this certificate with the private key, so they can decrypt the secret
We're looking at implementing Hashicorp Vault. It seems easy enough to simply replace the encrypt-store-decrypt with storing the secret in Vault in the KV engine, and just grabbing it in our apps - that takes that certificate out of the picture entirely. Since we're on-prem, I'll need to figure out our auth method.
We have different apps running on different machines, and it's somewhat dynamic (not as much as an autoscaling scenario, but not permanent - so we can't just assign servers to roles one time and depend on Kerberos auth).
I'm unsure how to make AppRole work in our scenario. We don't have one of the example "trusted platforms" or "trusted entities", there's no Nomad, Chef, Terraform, etc. We have Windows machines, in a domain, and we have a homegrown orchestrator that could be queried to say "This machine name runs these apps", so maybe there's something that can be done there?
Am I in "write your own auth plugin" territory, to speak to our homegrown orchestrator?
Edit - someone on Reddit suggested that this is a simple solution if our apps are all 1-to-1 with the Windows domain account they run under, because then we can just use kerb authentication. That's not currently the way we're architected, but we've got to solve this somehow, and that might do it nicely.
2nd edit - replaced "services" with "apps", since most of our services aren't actually running as Windows services, just processes. The launcher is a Windows service but the individual processes it launches are not.
How about Group Managed Service Accounts?
https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview
Essentially you created one "trusted platform" (to your key vault service).
Your service can still has its own identity but delegation to the gMSA when you want to retrieve the secrets.
For future visibility, here's what we landed on:
TLS certificate authentication. Using Vault, we issue a handful of certs, each will correspond to a security policy/profile, so that any machine that holds that certificate will be able to authenticate and retrieve the secrets they should have access to.
Kerberos ended up being a dead-end for two reasons. The vault.exe agent (which is part of this use case) can't use the native Windows Kerberos SSPI, so we'd have to manage and distribute keytab files. Also, if we used machine authentication, it would blow up our client count (we're using the cloud-hosted HCP Vault, where pricing is partially based on client count).
Custom plugins can't be loaded into the HCP, of course
Azure won't work, it requires Managed Identities which you can't assign to on-prem machines. Otherwise this might have been a great fit
in the past, we used VSTS build agents, running with domain accounts on on-prem build machines. In such scenario, certificates could be stored into the domain accounts personal store (manually, by logging in once with this account). So a later build could get the certificates by thumbprint for signing e.g. a manifest.
Now, the agents run with "Network Service", because we no longer have a local domain (all moved to Azure AD). All works, except the retrieval of certificates from the store. I already used the mmc snap-in to connect to the service (VSTSAgent), and installed certificates to this personal store, but still the build fails with "Error MSB3323: Unable to find manifest signing certificate in the certificate store.".
If I log-on to the machine and run from within VS, all works well, but of course here I am using a different account (with a different personal store), but this at least tells me that solution & projects are fine. And the pipelines are OK as well, because they still work OK on the "old" build-machines that use a domain account.
So, if anyone has an idea or can point me to some information on how to use the VSTSAgent running as "Network Service" together with signing (from the certificate store), that highly appreciated.
Many thanks, Sebastian
We have Windows Server 2012 R2 with installed Certification Authority role.
There we have certificate templates.
I want to get certificate from this server of specific template into specific container automatically by autoenrollment.
Now I automatically get certificate into personal store by group policy and autoenrollment.
But I want to get certificate into the specific store (for example, custom SCCM or SMS) automatically by autoenrollment.
We are using Java Kerberos authentication to connect to our SQL Server DB from Linux. Here we had used the prinicipal name and the password to generate a keytab file on the Linux system. Currently the connectivity works fine.
But there has been an additional requirement to use expiring passwords, which expire every 3 months. In our other applications we use an API called CyberArk which retrieves the password from a vault and Ops team need not bother about changing the password on the application server located on the Linux system.
Does anyone have any experience on using Kerberos in such an enironment? We are basically looking at avoiding to regenerate the keytab file every time the password expires.
I don't think you can avoid to regenerate the keytab file in the event of password change or expiring. What you can do, however, is to make it painless to generate the keytab file on the Linux server. this require the Linux server joining the Active Directory, using RHEL native tool realm or Centrify software.
RHEL tool document is here https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/realmd-domain
For Centrify user, https://community.centrify.com/t5/Centrify-Express/Replace-SSH-Keys-with-Kerberos-Keytabs/td-p/10112
I have a .PXF file used to strongly name several of our .NET assemblies. VS2010/MSBUILD seems to expect this to be in the personal container for the user account running VS2010/MSBUILD. This is all just fine and dandy when working in an interactive user account, but when atempting an automated build via TFS 2010 on the build agent the account used by the build agent (by default) is NT-AUTHORITY/NetworkService.
Since I cannot log in an interacive session as NetworkService I cant just install the PFX from an interactive sessions shell.
So can anyone tell me how I install a PFX certificate in the personal cert store of the NetworkService account?
Answer Courtesey of Richard Reposed from serverfault
You need to open the Network Service certificate store, and add it.
To open the store:
From Start | Run: mmc.exe
File | Add/Remove Snapins and select Certificates then Add.
When prompted for the type of account select Service Account
Select local/remote computer as required
Select any service that's running as Network Service
("Remote Procedure Call (RPC)" run as Network Service by default)
Finish the wizard and OK to close the add/remove dialog.
On the applicable catrgory right click and select add tasks to find the import etc. operations.