- We have several service accounts (AD) that need to use a limited set of credentials.
- These service accounts run scripts (PowerShell & Python), etc on different servers, requiring these credentials. These servers all run different versions of Windows Server (2012 – 2016)
Currently the credentials are stored clear text, which is gaping security hole that needs to be fixed.
As we are a Microsoft shop, I initially wanted to opt for DPAPI, but this becomes unwieldy when multiple servers and accounts are used (as you have to store each credential in each combination of vault/server).
The second option was to store the credentials encrypted, on a SMB file share, with NTFS security to limit the accessibility to only the service accounts. The credentials would be encrypted with a certificate, which would be stored in the LocalMachine certificate store of each server. To access a specific credential, the service account would decrypt the file using the certificate.
This seemed like an OK approach:
- Servers only need to be provisioned with the same certificate (public key is sufficient).
- Only administrators can access the LocalMachine Certificate Store
- The credentials are encrypted and stored in a share secured by NTFS permissions.
I then came across a similar implementation as a PowerShell module: PowerShell Credential Vault. The major difference, as far as I can see, is that it stores a randomly generated key, encrypts the credentials (password only) using this key, and then encrypts the key using the certificate. The credentials and the encrypted key are stored together in an XML file.
Is there any advantage over just using the certificate to encrypt the credentials?