Sitting Exam this Saturday. EFS certificates and keys a prob

twiggytwiggy Member Posts: 6 ■□□□□□□□□□
Hi all,

First post, be gentle.
I am sitting the 70-271 this Saturday, i'm pretty happy with my preparation, been through the MS Press self paced, and Sybex study guide.
The only thing I am still having trouble on no matter how many times I do it, or read different articles on is EFS.
Set attribute at command line, sure. Set in folder properties - no problem. Understand effect of moving or copy on attribute - uhuh. Create a Recovery Agent - yes...
but heres the thing... I create a certificate using the private key of the user who is encrypting the files, or the computer that the files are encrypted on... then the certificate permits access to the resource? after it is imported - if something (?) happens to the private key - whatever that actually is.

So i suppose, I can do it, I just dont understand what is happening. I would feel better if i knew, if anyone could point me to a reference that could clear this up for me, i'm just not 100% on the private key and certificate process..

Many thanks in Advance

twiggy from oz


  • royalroyal Member Posts: 3,352 ■■■■□□□□□□
    Welcome to the site. Here is a good website that shows how to create a DRA, back up the DRA certificate, import the DRA certificate, and more. In the jist of it, when a user goes to encrypt something, a certificate is created on the fly. This certificate's Key Enhanced Usage is for Encrypting File System. The Key Enhanced Usage basically states what a certificates intended use is for, and in this scenario, it's for EFS. This certificate building process generates both a private and public key. When you encrypt a file, the File Encryption Key (FEK) is encrypted with both the user's public key as well as the DRA's public key. This allows both the user to decrypt the file or the DRA to decrypt the file with their own private key. This means, that if anything happens to the private key of the user, we can always use the DRA to decrypt that file. You might be thinking to yourself, what is this private/public key? Well, it's a pair of keys that have an association with each other. When you encrypt something with a public key, you'll need that private key to decrypt it due to the association.

    In Windows 2000, a DRA was assigned by default. Having a DRA in place was also a prerequisite of being allowed to take advantage of EFS. In Windows XP Pro (Home does not support EFS), the DRA was removed and no longer is a requirement to use EFS. In Server 2003, a DRA is automatically created for the Domain Administrator on your first Domain Controller and all clients are configured to use this DRA when they join the Domain. You will see the DRA certificate in the personal certificate store with a Key Enhanced Usage of File Recovery. The sole purpose of the DRA certificate is to decrypt files. In a Domain environment, you will often see that this certificate is highly protected. I've heard of a company of removing the Domain Admins security group from the Domain DRA, and adding a much smaller security group to be the Domain DRA. They then copy the certificate to a few different devices and lock them in a safe. Then, if a DRA is ever needed, that file is backed up onto a device, and taken to a secure workstation. That file is then placed on that recovery workstation, the safe is unlocked, and the File Recovery certificate is imported onto that desktop. The file is then decrypted and sent back to the other machine. Then the File Recovery certificate is deleted off that workstation. If another file is ever in need of decryption again, the process of backing up the file, obtaining the file recovery certificate from the safe, and imported onto a dedicated recovery workstation is redone.

    So hopefully this helps and gives you an example of a real world scenario where this can be used. Let us know if you have any other questions and good luck on your exam!
    “For success, attitude is equally as important as ability.” - Harry F. Banks
  • sprkymrksprkymrk Member Posts: 4,884 ■■■□□□□□□□
    Maybe this will help. The private key is stored on the computer when the user logs in. If you delete it, the file will be unreadable even to that user. Try this to see what happens:

    Create a folder on your C:\ called Encrypted, set the encryption attribute, then put a text file with some text in it in the folder.

    1. Click Start, click Run, type certmgr.msc
    2. In the console tree, click Personal>Certificates.
    3. In the details pane, right click the certificate that has Encrypting File System listed in the Intended Purposes column, go to All Tasks, and then click Export.
    4. In the Certificate Export Wizard, click Next, and then click Yes, export the private key.
    5. Under Export File Format, ensure that the Enable strong protection (requires IE 5.0, NT 4.0 SP4 or above) check box is selected, and then click Next.
    6. In Password, type a password to encrypt the private key you are exporting.
    7. Type a file name and path (for example use a floppy disk and export to a:\efs-yourname)
    8. Click Next, and then click Finish.

    Now delete the EFS certificate from the MMC.
    Try to read your encrypted file (can't remember if you need to logoff/on first).
    You should get an access denied.
    Now open up the certmgr.msc again, go to Personal>Certificates and then do an import from the Action>All Tasks menu and follow the prompts to import your EFS certificate again.
    Now you should be able to read the encrypted file again.
    All things are possible, only believe.
  • twiggytwiggy Member Posts: 6 ■□□□□□□□□□
    Thanks very much for your help guys, so you know - passed with an 883!

  • sprkymrksprkymrk Member Posts: 4,884 ■■■□□□□□□□
    twiggy wrote:
    Thanks very much for your help guys, so you know - passed with an 883!


    Nice job, great score! icon_thumright.gif
    All things are possible, only believe.
  • royalroyal Member Posts: 3,352 ■■■■□□□□□□
    “For success, attitude is equally as important as ability.” - Harry F. Banks
Sign In or Register to comment.