bug with efs on server 2003

[Goldorak-Go]

Hi,
I can speek French or English.
My trouble is the following.

I want to use efs on my domain, so I'have created an efs self-signed
certificate for a recovery agent for the domain with the command Cipher /r.
This efs self-signed certificate is valid for 100 years.
I have imported this certificate in the policy of the domain and replicated
the policy with the "Active directory site and services" snap-in.

Now I want to encrypt a folder on a member server. Before doing that I have
just forced this server to apply the domain policy by typing the command
GPUPDATE /force and rebooted the server.

I have created a user wich is called "BABY" on the domain. This user will
serve to encrypt my folder.
So when I encrypt the folder a new certificate and a private key are created
for this user.

I don't want the private key to stay on the local server, so I have exported
the certificate and the private key together in a *.PFX file and I've ask to
delete the private key localy during this export.

Now there is only the certificate of the user "BABY" profile on the local
machine. The private key has been removed as expected.

My problem is the following: when I add a new file to the existing encrypted
directory, the user "BABY" get a new certificate and a new private key.
I try to think that this behaviour is not normal.
Can someone help me please ???

My infrastructure is based on Windows server 2003 R2 standard edition. I
have not updated the servers for the moment with any patches.

thanks a lot ....

 

[Brian Komar \(MVP\)]

Inline...

Hi,
I can speek French or English.
My trouble is the following.

I want to use efs on my domain, so I'have created an efs self-signed
certificate for a recovery agent for the domain with the command Cipher
/r.
This efs self-signed certificate is valid for 100 years.
I have imported this certificate in the policy of the domain and
replicated
the policy with the "Active directory site and services" snap-in.

Now I want to encrypt a folder on a member server. Before doing that I
have
just forced this server to apply the domain policy by typing the command
GPUPDATE /force and rebooted the server.

This is good, you have applied the recovery policy then.

I have created a user wich is called "BABY" on the domain. This user will
serve to encrypt my folder.
So when I encrypt the folder a new certificate and a private key are
created
for this user.

[bk] As expected. SInce you do not mention a PKI, I have to assume it is
self-signed.

I don't want the private key to stay on the local server, so I have
exported
the certificate and the private key together in a *.PFX file and I've ask
to
delete the private key localy during this export.

[bk] Big mistake. Since you have removed the certificate, the next
encryption attempt will generate a new certificate. Also, the user has lost
access to the previously encrypted file.

Now there is only the certificate of the user "BABY" profile on the local
machine. The private key has been removed as expected.

[bk] Mistake.,

My problem is the following: when I add a new file to the existing
encrypted
directory, the user "BABY" get a new certificate and a new private key.
I try to think that this behaviour is not normal.
Can someone help me please ???

[bk] This is expected. How did you expect EFS to protect the new FEK created
for the newly encrypted file.
Please read the whitepaper on how EFS works available at
www.microsoft.com/pki

 

[Goldorak-Go]

Hi Brian Komar!!!

Thank you for your response, but I 'm still thinking that something is going
wrong.

EFS use the public key to encrypt the FEK and the FEK encrypts the efs file.
EFS automatically obtains the user’s public key from the user’s X.509
version 3 file encryption certificate.
EFS never need the private key to encrypt data.
The private key is only needed to decrypt the FEK and then the efs file.

So if I export and delete the private key that is stored localy, and if I
let the corresponding certificate in place on this server then I must be able
to encrypt using the public key of this certificate.
And this is what is going wrong in my case.
Because the existing certificate is not used. In fact another certificate
and its private key is generated when I put a new file in the encrypted
folder.

Most of all, I tried the same procedure on a XP workstation and everything
is going well like I expected and I tried this several times.
But with my Windows server 2003 this is not the same.

anybody has an idea ???

 

[Brian Komar \(MVP\)]

sigh....

Hi Brian Komar!!!

Thank you for your response, but I 'm still thinking that something is
going
wrong. nope.

EFS use the public key to encrypt the FEK and the FEK encrypts the efs
file.
EFS automatically obtains the user’s public key from the user’s X.509
version 3 file encryption certificate.
EFS never need the private key to encrypt data.
The private key is only needed to decrypt the FEK and then the efs file.

So far, so true.

So if I export and delete the private key that is stored localy, and if I
let the corresponding certificate in place on this server then I must be
able
to encrypt using the public key of this certificate.
And this is what is going wrong in my case.

Nope, it also checks that you have the private key to be able to decrypt the
file.
You cannot open the file without the private key.

Because the existing certificate is not used. In fact another certificate
and its private key is generated when I put a new file in the encrypted
folder.

Yep, expected behavior.

Most of all, I tried the same procedure on a XP workstation and everything
is going well like I expected and I tried this several times.
But with my Windows server 2003 this is not the same.

You are going down a non-supported path. Do not delete the private key.

 

[Goldorak-Go]

Hi Brian,

Finally I think you are true because I destroyed everything to start once
again the same procedure on my windows XP and this time the result is similar
to my experience on windows server 2003.

So there is no bug.
Just a strange exception that makes me work for nothing.... mmmmMicrosoft.

Thanks for your help !!!

 

[Brian Komar \(MVP\)]

Actually, it was just you, not Microsoft.
They have documented exactly how things work.
Never delete the private key, it is a very bad design.
Brian