@lewinr You don't need to prevent a password reset. EFS encrypts files with a private key that is stored and encrypted with the users accounts password. If someone resets the password of the user account, access to this private key will be lost and EFS encrypted files cannot be decrypted.
Your method already protects against administrative accounts.
That being said, for high security you have to think about other attack scenarios that could potentially be a breach: stealing the password (key logger for example) or stealing the hash and cracking the password would be the first two that come to mind. Both can be done from someone that has administrative privileges on the mentioned server.
To protect against this kind of attacks you have different options:
- To protect against stealing the hash, make sure you use domain accounts only and implement credential guard.
- To protect against key logging, implement application white listing with device guard policies which can be implemented in a way so that not even an administrator can circumvent them
- To better protect the encryption key make sure you use a custom EFS-Certificate template which stores the private key inside a TPM or Smartcard which automatically gets you multi-factor for your encryption key
- Implement Smartcard-Logon only for sensitive accounts
- Implement a Multi-Tier administrative model with just-in-time administration and least-privilege-administration
- Implement central logging and make sure that any access to sensitive files or usage of sensitive privileges gets logged and reviewed
To sum it up for your service-account case:
- Make sure the server in question has a TPM-Chip
- Create a custom certificate template for EFS that uses at least RSA2048 or higher (take a look at elliptic curve cryptography as well) and uses the platform crypto provider (this will protect the private key with the TPM)
- Deploy this certificate for your service account user and make sure the account has a strong password
- Encrypt using this account/certificate. Make sure no other Privat-Key is silently added to the encrypted files
- Implement extensive auditing, for example with this framework: https://github.com/palantir/windows-event-forwarding
The following is just for information and will not necessarily help you with your special case (service account needs access):
Additionally you can use Bitlocker instead of EFS to protect sensitive data. Use a separate Data-Volume (physical or virtual disk, depending on the server) and encrypt this volume with Bitlocker. Make sure the only KeyProtector for this volume is a Smartcard certificate. Only the person owning the physical Smartcard can mount this volume and the private-key never touches the server. This way not even an administrator can access the encrypted volume without first stealing the physical Smartcard AND getting the PIN.
In both cases (EFS and Bitlocker) you have to double-check that no additional protectors are present. If some Administrator already implemented EFS-Recovery in the domain, you will always have an additional Recovery-Certificate placed on all EFS-encrypted files and the person with access to this recovery certificate can decrypt all EFS-encrypted files inside the domain. You can check this in the advanced properties -> details of an encrypted file.
Same goes for Bitlocker. Domain policies could be implemented that will place additional Keyprotectors on your Bitlocker-Volumes. Especially Bitlocker-Recovery-Certificates and Recovery Passwords which get sent to ADDS for storage would be a problem.
If you set up everything correctly, it is practically impossible for any administrative account to get access to your encrypted data.
Of course there is much more to this whole topic than can be written in a single post. This information should get you started in a good direction though. If you really have such high-value data in your company, and you don't have the expertise to implement high-security configurations, I recommend outsourcing this to a company with lots of experience in this field.
It is much to easy to misunderstand technologies or overlook something important. But if all you need is to lock out some normal admins from accessing specific files, you should be able to do so with the information above.
