• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1163
  • Last Modified:

Using a domain EFS Recovery Agent

I have created (I think!) a recovery agent under the EFS policy on our Windows Server 2003 SBS server, but I am missing one small detail.  The policy is created, the certificate is created and I have assigned Recovery Agent rights to a newly created 'EFS Admin' user (domain admin rights).  Users of the domain are allowed to create EFS folders, but when I show the details for the encrypted files the Recovery Agent Name field is blank, meaning that I don't have a workable recovery policy.  I would expect the name EFS Admin to show up in this section, meaning that this user can also recover EFS protected documents (etc).  Any ideas guys?
0
-Juddy-
Asked:
-Juddy-
  • 6
  • 4
2 Solutions
 
ParanormasticCryptographic EngineerCommented:
This may be what you meant, but make sure you have it set in domain GPO:
computer config - windows settings - security settings - public key policies/encrypting file system
Properties:
Allow users to encrypt files using Encrypting File System (EFS) = Enabled
Certificates
Your EFS DRA cert should be listed here.

If your DRA cert was issued from a CA, then the root CA cert needs to be trusted.  If it was made using cipher /r then you will need to deploy that self-signed cert as another root (in addition to your CA root if you have one).

computer config - windows settings - security settings - public key policies/trusted root certification authorities
Make sure the appropriate cert shows up here.

Also, users should run 'gpupdate /force' first then reboot to apply the GPO.  This is applied to the computer container, so you must reboot.

Also, you might want to have a logon script run "cipher /u" to update all the encrypted files that user has access to, otherwise if they never touch it then iti will not get updated - note this needs to be for each EFS user on the box since userA cannot open userB's docs unless added as an extra user.  If this is a new rollout, then you may not need to do this.

Where you are looking and what you expect to see are correct - the dRA should be listed in the bottom half of that window.
0
 
ParanormasticCryptographic EngineerCommented:
Also, since I've seen this a few times, make sure you are deploying the cert file (.crt or .cer) and not the .pfx file which has the private key.  If you did, honestly I would just revoke that one and start with a new one since you just populated the private key everywhere, or just delete it and create a new one with cipher /r.  CA cert for the DRA is preferred.
0
 
-Juddy-Author Commented:
Let me answer these in point form, just for clarity:

EFS is enabled for all users.
EFS section of my Default Domain Security Setting does indeed show the DRA cert.
DRA cert was issued from the CA (it also shows up in 'issued certificates', how do I ensure the root CA cert is trusted?
The certificate was made by right clicking the EFS 'folder' in the default domain security settings and using the add/create data recovery agent.

Thanks!
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
-Juddy-Author Commented:
One more thing, on one test PC when I look at the details for a file in an EFS area it now shows the correct data recovery agent, which is nice.  Problem is though that when I logon to the PC as the DRA and attempt to open the file in the EFS area I get access is denied.  Should I (as the DRA) be able to open these files, or is there a recovery process which I'm missing?
0
 
ParanormasticCryptographic EngineerCommented:
To make sure the root CA cert is trusted, open MMC - Certificates snapin - add twice, once for user and once for local computer.  Check local computer first, but could have ended up in either (or both which is fine), look in the Trusted Root Certification Authorities store - expand that and select Certificates, then scroll through the list in the details pane.  If it is in the user but not computer area, you can click-n-drag it down to that area in the computer context so it is available to all users - however that would just be for that box.  If not in computer context then you need to check the domain GPO settings:
computer config - windows settings - security settings - public key policies/trusted root certification authorities

0
 
ParanormasticCryptographic EngineerCommented:
The DRA will still need to be granted rights to the file in order to access it - this is good security practice that the DRA does not normally have access so changing permissions can be logged.

Specifically, you need to be able to grant the DRA user account read permissions to open, or modify to change - although it is common to just do full control since permissions should be removed afterwards anyways.

Also, you will need to install the .pfx file so the private key for the DRA is on that box - GPO only distributes the public key with the cert.  After accessing or decrypting the file, you should delete the certificate from the DRA user's personal cert store.  You may want to just make a batch file on the flash drive or CD that you store the .pfx file on:
certutil -user -delstore My %cert serial number or thumbprint without spaces%

Alternatively, you can run certutil -user -viewdelstore My   and then select the cert from the list.

To make the .pfx, on the box you originally created the DRA cert on, log on as the DRA user and open certmgr.msc (certificate MMC - user context) and expand Personal - Certificates.  Locate the DRA cert and open it - verify on General tab it has the little key icon and message stating you have the private key, then go to Details tab and click Copy certificate button.  During the wizard, select to export the private key and also select to use strong protection (will make it require a password when accessing the private key).  Keep this locked up when not in use - I would suggest a sealed envelope signed over on the licked and factory seals, or duct tape around it and sign that, to make it tamper-evident (will show if someone else accessed it, and if so the DRA cert should be revoked and reissued).

Also, set a calendar reminder about 2 months ahead of expiration of the DRA cert so you can renew it and get the new one deployed well enough ahead of time.  It will auto renew at 6 weeks before expiry.  Just make sure to keep the old .pfx around for recovery since it will still be valid to decrypt, it just won't be able to be part of encrypting new files after expiration.  This will make it so you don't have to run 'cipher /u' to update the dra cert on all files, but you certainly can if you wish.
0
 
-Juddy-Author Commented:
Thanks for your response, I have been off sick so have only just seen it!  I'll give it a try today.
0
 
ParanormasticCryptographic EngineerCommented:
Everything turn out okay here, or still working on it?
0
 
-Juddy-Author Commented:
Firts day back, so I'll check into it today! Thanks.
0
 
ParanormasticCryptographic EngineerCommented:
Any updates?
0

Featured Post

[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

  • 6
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now