EFS recovery agents

[Guest]

I've been fighting with EFS on windows 2000, and I have a question regarding
recovery agents. I have set my domain account as one of the recovery agents
on our domain controller's default domain policy, and it would seem like that
would be enough for me to log in and open encrypted files on a domain
computer. However, I had to export the file recovery certificate from the
domain controller itself in order to get the 'private key', and import it on
the client computer with the encrypted files before I was able to access
them. But my question is, when I go to any other computer, domain or
non-domain, and import that same certificate and key, I am not able to open
those same encrypted files over the network. It says access denied. Is this
normal, and if not, what could be causing the problem? And does this mean
that if I move the disk with the encrypted data to another computer, I will
not be able to access the data with my recovery agent account?

 

[Roger Abell [MVP]]

It sounds like you need to read some more in the EFS guidance docs.
Keep in mind the docs are now up-rev'd for Windows 2003 Server
and there are some significant difference from what was possible when
on a Windows 2000 environment.
Defining an account as DRA in policy is only part of making that DRA
able to decrypt. The private key also needs to be imported into the
account - something you did not mention until you say you found you
needed to do this on a machine where you were trying to use the DRA.
Decrypting files over the network is one of the things differing between
W2k and W2k3. When decryption fails, or NTFS access checks fail,
one gets the same visual popup about access denied - something to
keep in mind when troubleshooting. For remote decryption there are
a number of factors involved: is your domain profile roaming, is the
remote machine trusted for delegation, etc. Read the docs.
However, one really does not want to, or should not want to do that.
If the data is worthy of EFS protection, then why in the world would
one want to remote decrypt and send over the wire in the clear ???
Again, check the W2k vs W2k3 ways of doing this.
One does not need to take the disk to move the files to a point for
decryption. A more normal, safe way is to use ntbackup to bundle
up the files and that the backup to a secure machine where use of
the DRA is allowed, unpack the backup, get the files in the clear,
rebundle and give (sneakernet) back.
The normal practice is to have a special account that is DRA, one
not allowed to be used other than upon DRA action need, one that
is closely monitored and allowed only to be used at specific machine.
Sometimes the private key is not even kept online in the private
cert store of the DRA account, requiring a load on need for use.
EFS usage represents the highest level of privacy you can give to
your user base with what come with Window environment.
Setting standards as just mentioned helps to keep it that way.

 

[Guest]

Thank you for your reply. I did indeed notice that almost all the
documentation on EFS, both official and unofficial, referred to its use on XP
or 2003 systems, and it was difficult to find anything directly referring to
Windows 2000.

Let me clarify exactly what we're trying to do. We have a server that uses
Altiris Recovery Solution to back up our other servers and the data they
store. We are putting a second machine at a remote location (that is still on
our network), to which we will synchronize the Altiris backup data, to serve
as offsite storage should our backup server fail. We would like to use EFS to
secure the data on the remote system in case someone should decide to steal
the computer itself, since it unfortunately will have to double as a user
workstation - unbeknownst to said users, of course... ;-) So after
discussing it, the questions we still have are:

1. The synchronization will be a batch file running as a scheduled job on
the Altiris server, which will copy all modified Altiris files to the remote
system overnight. Am I correct in assuming that the user that will have EFS
rights to those files will be whatever user the batch file runs as? And how
do things change if that user is a domain user?

2. If, instead, the EFS rights are given to the local administrator, does
that mean that ANY computer's local administrator can open those files, or
only local administrators of other domain computers, or is there some other
criteria? (When we ran the batch file as the Altiris server local admin, we
found that the remote computer local admin could open the files without any
special certificate imports.)

3. If we for some reason needed to take the drives out of the remote
computer and put them in another machine (if, say, the remote computer
failed), will we be able to just import the correct certificate and private
key and open the files on the new system?

Sorry this is so long, but I wanted to be sure to provide plenty of
information... thanks for your help!

Andy

 

[Roger Abell [MVP]]

I have inlined some information . . .

Thank you for your reply. I did indeed notice that almost all the
documentation on EFS, both official and unofficial, referred to its use on
XP
or 2003 systems, and it was difficult to find anything directly referring
to
Windows 2000.

Let me clarify exactly what we're trying to do. We have a server that uses
Altiris Recovery Solution to back up our other servers and the data they
store. We are putting a second machine at a remote location (that is still
on
our network), to which we will synchronize the Altiris backup data, to
serve
as offsite storage should our backup server fail. We would like to use EFS
to
secure the data on the remote system in case someone should decide to
steal
the computer itself, since it unfortunately will have to double as a user
workstation - unbeknownst to said users, of course... ;-) So after
discussing it, the questions we still have are:

Have you looked into using IPsec to encrypt the network traffic during
these backups ?

1. The synchronization will be a batch file running as a scheduled job on
the Altiris server, which will copy all modified Altiris files to the
remote
system overnight. Am I correct in assuming that the user that will have
EFS
rights to those files will be whatever user the batch file runs as? And
how
do things change if that user is a domain user?

Yes you are correct. The EFS encryption will be what is appropriate
for the account running the process that causes files to be written to
the area designated to have files EFS encrypted. It does not really
matter, as far as how EFS work, whether the account is local or domain.
What local or domain may however change is where (all) that account's
EFS cert/key might exist in storage.

2. If, instead, the EFS rights are given to the local administrator, does
that mean that ANY computer's local administrator can open those files, or
only local administrators of other domain computers, or is there some
other
criteria? (When we ran the batch file as the Altiris server local admin,
we
found that the remote computer local admin could open the files without
any
special certificate imports.)

I do not understand. One does not give EFS rights.
You may be considering something that is outside of the featureset here.
The account the causes a file to be stored with EFS encryption is the
one that causes it to be stored, or the account the triggers encryption
is the one that does it. Sounds dumb to say, but it is that simple.

3. If we for some reason needed to take the drives out of the remote
computer and put them in another machine (if, say, the remote computer
failed), will we be able to just import the correct certificate and
private
key and open the files on the new system?

If you have safely exported and saved the cert/key on non-degrading
media, and you remember the password to use to import again, then
if you import that key into the same Windows version you would be
able to access the files if those files have been moved correctly (i.e. in
a way sensitive to EFS, like with ntbackup - some third-party copy
utilities clobber the bit indicating that the file is encrypted - test what
you plan to use). I have warned about "the same Windows version"
since XP and later use improved algorithms compared to Windows
2000 - so mixing W2k and XP or W2k3 with them all in their default
config does not work, and changing the defaults is ill-advised as it
lowers XP/W2k3 to the level of W2k.