Recovery Agent in XP-Pro huh

Discussion in 'other software & services' started by AAP, Dec 26, 2003.

Thread Status:
Not open for further replies.
  1. AAP

    AAP Registered Member

    Jul 30, 2003
    Hello,To all

    First i hope all had a great Christmas
    now i just happen to see someone post
    that WinXP Pro has this Recovery Agent

    but how do i find it & how do i use it i
    looked for it & all i got was this here
    There is no policy defined o_O

    so could someone please tell me how
    do i get this to work i would like to get
    the Private Key from the Recovery Agent

    Thank you


    The best to you & family stay safe my friend

    Good luck :D
  2. AAP

    AAP Registered Member

    Jul 30, 2003
    Hello,To all

    Well if anyone needs this info have a
    look at this like some great info & pics :D

    Good luck :D
  3. bigc73542

    bigc73542 Retired Moderator

    Sep 21, 2003
    SW. Oklahoma

    check this from microsoft
    Data Recovery and Data Recovery Agents

    You can use Local Policy on stand-alone computers to designate one or more users, typically Administrator accounts, as data recovery agents. These DRAs are issued recovery certificates with public and private keys that are used for EFS data recovery operations.

    The default design for the EFS recovery policy is different in Windows XP Professional than it was in Windows 2000 Professional. Stand-alone computers do not have a default DRA, but Microsoft strongly recommends that all environments have at least one designated DRA.

    In a Windows 2000 environment, if an administrator attempts to configure an EFS recovery policy with no recovery agent certificates, EFS is automatically disabled. In a Windows XP Professional environment, the same action enables users to encrypt files without a DRA. In a mixed environment an empty EFS recovery policy turns off EFS on Windows 2000 computers, but only eliminates the requirement for a DRA on Windows XP Professional computers.

    When a domain user logs on at a domain computer that is within the scope of the EFS recovery policy, all DRA certificates are cached in the computer's certificate store. This means that EFS on every domain computer can easily access and use the DRA's public key (or multiple public keys if multiple DRAs are designated). On computers where an EFS recovery policy is in effect, every encrypted file contains at least one data recovery field, in which the file's FEK is encrypted by using the DRA's public key and stored. By using the associated private key, any designated DRA can decrypt any encrypted file within the scope of the EFS recovery policy.

    The private key for a DRA must be located on the computer where recovery operations are to be conducted.

    Because each DRA has a distinct private key that can decrypt a file's FEK, data recovery discloses only the encrypted data, not the private keys of any user other than the DRA. A private key for recovery cannot decrypt the DDF. If there are multiple recovery agent accounts, each private key for recovery decrypts only its own DRF and no other. Thus, there is no danger that an unauthorized recovery agent account can access information from the file that enables access to other files.

    It is best not to encrypt files when you are logged on with a DRA account. The effectiveness of EFS recovery is compromised if a file's creator is both the user and the recovery agent.

    For more information about encrypted file recovery, see Windows XP Professional Help and Support Center.

    For more information about how to change EFS recovery policy for the local computer, see Windows XP Professional Help and Support Center and "Configuring Data Recovery Policy in a Stand-Alone Environment" later in this chapter.
    Data Recovery Implementation Considerations

    When designating DRAs for your files, it is important to keep the following considerations in mind:
    Files are more secure, but less recoverable, if only one person can decrypt them. If you choose not to designate any DRAs, be sure that user profiles are backed up regularly. The user's private key, without which the file cannot be decrypted, is stored in the user profile. Additionally, because users can have multiple profiles on multiple computers or might have a roaming profile, be sure that all profiles are being backed up. This is especially true for notebook computers. If the user logs on with a local account and encrypts a file, the private key for that transaction is contained in the user profile for the local account, not the user's domain account profile.

    The most effective way for users to ensure access to encrypted files is to export their EFS certificates and private keys. For more information about exporting EFS certificates and keys, see "Exporting and Importing EFS and DRA Certificates and Private Keys" later in this chapter.
    Files are less secure, but more recoverable, if more than one person can decrypt them. If you want the ability to recover encrypted files, designate one or more DRAs by using the EFS recovery policy.
    For more flexible EFS recovery management, consider issuing EFS recovery certificates to designated recovery agent accounts, in addition to the default Administrator account. Also, legal or corporate policy might require that the recovery agent account be different from the domain Administrator account. You can also configure EFS recovery policy for portable computers to use the same recovery agent certificates, whether the computers are connected to domains or are operated as stand-alone computers.
    EFS is normally used to encrypt user data files. Application files (for example, .exe, .dll, .ini files) are rarely encrypted. If computers are configured to use System Restore as part of recovery policy, application files are saved at restore points. These files can then be restored to return the system to a previous state. If application files that System Restore is monitoring are encrypted, it is important to note the following expected results of restoration:
    If you decrypt a previously encrypted monitored file or folder, and then restore to a point before the file or folder was decrypted, the restored file or folder remains decrypted. If you undo the restore, the file or folder remains decrypted.
    If you encrypt a monitored file, and then restore to a point before the monitored file was encrypted, the restored file is unencrypted. If you undo the restore, the file remains unencrypted.
    If you modify a monitored file that is encrypted for multiple users, and then restore to a point before the modification occurred, the file will be accessible only to the first user who modified the file after the restore point was created. If you undo the restore, only the user who ran the restore will be able to access the file. The filter will back up the file during restore in the context of the user who is running the restore operation.
    If you delete a monitored encrypted file and then restore to a point before the deletion, the deleted file is restored with its encryption attributes intact. If you undo the restore, the file is again deleted.
    If you encrypt a directory and then restore to a point before it was encrypted, the directory remains encrypted. Monitored files created in this directory after the restore point are encrypted, but they will be deleted by a restore. Monitored files moved into this directory retain the encryption status from the directory in which they were created. After the restore, monitored files will be moved back to their original directory and retain the encryption status from that directory. If you undo the restore, the directory remains encrypted, and files are returned.
    If you modify an encrypted directory (for example, change its name) and then restore to a point before the modification, the modification is lost, but the directory remains encrypted. If you undo the restore, the modification returns and the directory remains encrypted.
    If you delete a directory that is encrypted and then restore to a point before it was deleted, the directory retains its encryption status. If you undo the restore, the directory is again deleted.

    If you encrypt application files, consider these recommendations:
    The best practice is to place these files in a partition/drive that is excluded from System Restore protection. This reduces the risk of restoring files to a pre-encrypted state.
    If you choose to encrypt application files and use System Restore on the partition/drive storing the files, turn off System Restore (losing all previous restore points), complete the encryption settings, and then turn System Restore back on. This ensures that the files cannot be reverted to a pre-encrypted state.

    To configure System Restore
    On the System Tools menu, click System Restore.
    Select System Restore Settings, and configure the options as appropriate for your environment.

    You must be an administrator to configure System Restore
Thread Status:
Not open for further replies.