At home last week, I started doing some preparations for upgrading my home server from Windows Server 2012 R2 to Windows Server 2016. This server was originally installed using Windows Server 2012 R2 Essentials and since, I have performed a Standard edition, edition upgrade on the machine which means that the host has ADDS, ADCS, NPS and some other roles installed as part of the original Essentials server installation. We all know that unbinding ADDS and ADCS can be a bit of a bore which is why nobody in the age of virtualization should be installing ADDS and ADCS on a single server together but that’s by the by.
When I started looking at decommissioning the ADCS role, I noticed that an EFS certificate had been issued to my domain user account. I’ve never knowingly used EFS but the presence of a certificate for that purpose lead me to believe there may be some files out there so I started looking.
EFS was a technology that appeared circa Windows XP to allow users to encrypt files before BitLocker was a thing. It was a nice idea but it was troubled and flawed in that it was enabled by default and users could self-encrypt files without IT having implemented the proper tools to allow them to recover the files when disaster struck.
At home last week, I started doing some preparations for upgrading my home server from Windows Server 2012 R2 to Windows Server 2016. This server was originally installed using Windows Server 2012 R2 Essentials and since, I have performed a Standard edition, edition upgrade on the machine which means that the host has ADDS, ADCS, NPS and some other roles installed as part of the original Essentials server installation. We all know that unbinding ADDS and ADCS can be a bit of a bore which is why nobody in the age of virtualization should be installing ADDS and ADCS on a single server together but that’s by the by.
When I started looking at decommissioning the ADCS role, I noticed that an EFS certificate had been issued to my domain user account. I’ve never knowingly used EFS but the presence of a certificate for that purpose lead me to believe there may be some files out there so I started looking.
EFS was a technology that appeared circa Windows XP to allow users to encrypt files before BitLocker was a thing. It was a nice idea but it was troubled and flawed in that it was enabled by default and users could self-encrypt files without IT having implemented the proper tools to allow them to recover the files when disaster struck.
Disable EFS via Group Policy
First and foremost, we want to prevent any new EFS encrypted files from appearing. This is easily done with Group Policy and is a setting that could and possibly even should be included in a baseline GPO for clients and servers (the setting is a Computer Configuration setting) but don’t put it in the Default Domain Policy as modifying this with additional settings isn’t best practice.
In the GPMC, open the GPO that you plan to include the setting in and navigate to Computer Configuration > Security Settings > Public Key Policies. Once in the PKI node, right-click on the Encrypting File System folder in the navigation area on the left.
In the EFS Properties, set the File Encryption using Encrypting File System (EFS) option to Don’t allow. This will disable the ability for users to use EFS.
Finding EFS Encrypted Files
This is the part I was primarily concerned about as where would the files be exactly given I’ve never knowingly used EFS. Luckily, there is a few switches in the cipher utility that can do all the heavy lifting for us. If you are an admin of a file server, you can run this centrally or if users have local files, you could configure this as a logon script for the users and output the results to a network share as .txt files which you can review at a later time.
cipher.exe /u /n /h <SearchPath> > <ResultsFile>
This nice simple command once modified with your path to search and the output file name will generate a list of all of the EFS encrypted files in that path. The search is recursive so will include sub-directories too. You can simply point this as your drive root and let is find everything. By adding the /n switch to the command, it prevents cipher from triggering an update on the file which means that it will not try to use or renew the EFS certificate on the file. This is ideal for running the command centrally as an admin where you may not have permissions currently to access the files but only traverse directory permissions.
Decrypting EFS Encrypted Files
This is the more complicated part. To be able to decrypt the files, you need to be in possession of a valid certificate that matches that used to encrypt the files. If your PKI was correctly configured for EFS and you have a Data Recovery Agent certificate then this is the master key that will allow you to unlock any EFS encrypted files. If you don’t have this then the only option is to have the files encrypted from the user side. If the users don’t have those certificates any more either then I’m sorry to say that there’s nothing that can be done except hope you have a backup of the files prior to them being encrypted. The key for the Data Recovery Agent (DRA) is embedded into EFS certificates so retro-adding a DRA isn’t an option.
Assuming you have the relevant certificates needed, the following command will attempt to decrypt all files in the specified path. Again, you could run this as a logon script for the user and set it up to traverse their home drives or redirected folders to decrypt all of their own files.
cipher.exe /d /s <FilePath>