Any way to prevent an administrator from changing a user password?

New Contributor

Hi all, I'm looking for some advice.


We have a Windows server which contains some high security files that almost nobody in the organization should be able to open.


To store those files, we setup a special account, created a directory which only that account has access to, encrypted that directory with EFS under that account, archived the EFS keys to a USB key to be put  in a safe deposit box, and deleted them from the server.


However, I believe that a regular domain administrator can just change the password on the account, login under that account, and get access to all those files.   Am I wrong?


If I am not wrong, then how do we prevent that?  Is there any way to prevent domain admins from having the ability to change passwords ?  We need domain admins to have access to that server for

regular maintenance issues, performing upgrades of server applications, etc.


Thanks for your advice,


6 Replies
Any Admin account will have full administrative access to everything on the computer. That is why it is an administrator account. If there is absolutely no way for you to set it up so that you are admin and all others are Standard Users, and you have ability to make radical changes, maybe keep your data in a password protected VeraCrypt volume.

you can also create a Virtual disk (VHDX) using the Disk management and then encrypt it via Bitlocker, store the password and key on a USB/Smart card etc and save the password file somewhere else.

these are the Only ways you can achieve what you're looking for.
Thanks for your suggestion.

In fact the configuration is a bit more complicated... I avoided giving the whole setup because I didnt want to over-complicate the question and get no replies.

But it looks like I'll need to describe the setup better because unfortunately (I think) it precludes using something like veracrypt.

The files are accessed by a service running on the server. The service gets requests for files from users, decides if the user has the rights for the file, and if yes provides access to the file to the user. So actually the EFS storage is encrypted under the user a account which is used as the logon account for the service. We want to prevent an administrator (or somebody who gets the administrator password) from changing the password on the secure account and logging in and getting access to the full library of files.

So I dont think Veracrypt is a viable option because I dont think Veracrypt can be setup to provide access only for the specific account/service. If you have an idea of how this could work then I would love to hear it.

Otherwise if you have any other ideas then I will appreciate your input.

I really wonder how very secure sites like military or secret services handle this... I'm surprised there is no way to somehow limit access of an administrator to specific file or changes to an account. I expected they would at least need a system of requiring one person to initiate a change and a second person to approve it...
Military or secret services May use more secure ways than Built-in Windows security protocols that are closed-source and only Microsoft knows how secure or vulnerable they are. (which is good for most of the organizations and users in the world.)

Anyway, maybe I would try creating a separate domain environment where the Administrator in the first environment wouldn't have Any access in the 2nd environment, then I would create some sort of special trust between the two environments (could be forests/domains/trees) and make my service work. I don't know the specifics but just a thought that I would try, hopefully someone else will suggest a better way :)

Good luck!
best response confirmed by Rahul Mittal (ODSP) (Microsoft)

@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:


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.

Bravo, me ha servido de mucha ayuda.@dretzer 



Vielen Dank für diese ausführliche Überlegungen, da ich auch bei uns im Unternehmen den Daten- und Serverschutz überprüfen muss. Zum Teil habe ich mir die gleichen Überlegungen gestellt, und der Firma vorgeschlagen die Domänen-Administator Konten auf so wenig wie möglich Admins zu vergeben (max.2), alles über Gruppenmitgliedschaften zu steuern, und auch lieber unsichere Clients wie XP oder win7 in eigene Bereiche auszulagern, bis die Umstellung auf win10 abgeschlossen ist.

Admin Gruppen gibt es zum Glück genug beim ADDS, um auch anderen Admins genug Rechte geben zu können.