EFS Certificate Issue

[Eric Skibicki]

Hello All,

I have a couple win2k3 servers up, both are domain controllers in a the
same forest (sc), and one of them (debbie) is running a certificate
authority (enterprise root). When I encrypt a file on a workstation, the
CA generates an EFS key, and uses that key on the local workstation.

The problem comes in when I try to encrypt a file on the other domain
controller via a mapped drive from the workstation. The user all of a
sudden generates a new key with himself as the issuer, and encrypts the file
that way.

Wanting to test something, I wrote a program that uses
AddUsersToEncryptedFile and EncryptFile to encrypt a file and add my test
user's AD/CA EFS key to that file. This was all done on the domain
controller that is hosting the share. When my test user attempts to open
that file (mind you it does have his CA EFS key attached (i can view the
properties, it is correct)) it gives an access denied....

Any ideas what is causing this behaviour?

Eric

 

[Drew Cooper [MSFT]]

Keys are stored in a user's profile. If the profile doesn't roam, neither
will the keys. And if there's no key available, EFS will request (or
generate) another keypair when encrypting a file.

 

[Eric Skibicki]

So my question has to be, what is the point of having the keys published to
active directory then?

Interesting scenario I tried last night... I encrypted a file on a remote
computer using the AD public key, I then tried opening the file on the
machine I know the AD key was generated on.. The user still couldnt read the
file...

Eric

Keys are stored in a user's profile. If the profile doesn't roam, neither
will the keys. And if there's no key available, EFS will request (or
generate) another keypair when encrypting a file.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

Hello All,

I have a couple win2k3 servers up, both are domain controllers in a the
same forest (sc), and one of them (debbie) is running a certificate
authority (enterprise root). When I encrypt a file on a workstation, the
CA generates an EFS key, and uses that key on the local workstation.

The problem comes in when I try to encrypt a file on the other domain
controller via a mapped drive from the workstation. The user all of a
sudden generates a new key with himself as the issuer, and encrypts the file
that way.

Wanting to test something, I wrote a program that uses
AddUsersToEncryptedFile and EncryptFile to encrypt a file and add my test
user's AD/CA EFS key to that file. This was all done on the domain
controller that is hosting the share. When my test user attempts to open
that file (mind you it does have his CA EFS key attached (i can view the
properties, it is correct)) it gives an access denied....

Any ideas what is causing this behaviour?

Eric

 

[Drew Cooper [MSFT]]

It's most useful for EFS certs when users have roaming profiles. Or for
sharing EFS files over WebDAV. Or for encrypting a file, adding another
user, using ntbackup to make a .bkf, then giving the .bkf to the other user.
In short - not often useful for EFS.
Publishing to the AD is something that makes more sense for, say, an S/MIME
cert.

- After you added the user, was the user's "thumbnail" (cute name for
"hash") on the file what you expected it to be?
- If you logged on to the remote server locally as that user and checked the
user's Personal cert store, was the matching cert there?
- If so, could you export the cert and its private key? (That's the
only way to tell if the private key is really there - don't trust the cert
UI - it really tells you "at some time earlier, I thought there was a
private key here").
- If so, when logged on as that user, could you open the file?

Another approach:
- What do you mean by "the AD key was generated on"? This might be the
source of the confusion. Are you expecting the key to be on the CA or on
the machine where the user requested a cert? (It will be on the latter.)

I hope one of those lines of questioning gets to the root of this. Please
let me know what you find.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

So my question has to be, what is the point of having the keys published to
active directory then?

Interesting scenario I tried last night... I encrypted a file on a remote
computer using the AD public key, I then tried opening the file on the
machine I know the AD key was generated on.. The user still couldnt read the
file...

Eric

Keys are stored in a user's profile. If the profile doesn't roam, neither
will the keys. And if there's no key available, EFS will request (or
generate) another keypair when encrypting a file.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

Hello All,

I have a couple win2k3 servers up, both are domain controllers in a the
same forest (sc), and one of them (debbie) is running a certificate
authority (enterprise root). When I encrypt a file on a workstation, the
CA generates an EFS key, and uses that key on the local workstation.

The problem comes in when I try to encrypt a file on the other domain
controller via a mapped drive from the workstation. The user all of a
sudden generates a new key with himself as the issuer, and encrypts

the
file

that way.

Wanting to test something, I wrote a program that uses
AddUsersToEncryptedFile and EncryptFile to encrypt a file and add my test
user's AD/CA EFS key to that file. This was all done on the domain
controller that is hosting the share. When my test user attempts to open
that file (mind you it does have his CA EFS key attached (i can view the
properties, it is correct)) it gives an access denied....

Any ideas what is causing this behaviour?

Eric

 

[Eric Skibicki]

Welp... After logging into the server as those users, and importing their CA
created EFS Cert to the user profile there, then making sure the same key
was reflected on the local machine that was doing the encryption, it appears
as though everything is working! Thanks much for the help with this
issue... I'd always thought EFS was a slightly more straight forward / easy
to use system... *shrug* It looks like I will be going with your
recommendation of roaming profiles...

Thanks again,
Eric

It's most useful for EFS certs when users have roaming profiles. Or for
sharing EFS files over WebDAV. Or for encrypting a file, adding another
user, using ntbackup to make a .bkf, then giving the .bkf to the other user.
In short - not often useful for EFS.
Publishing to the AD is something that makes more sense for, say, an S/MIME
cert.

- After you added the user, was the user's "thumbnail" (cute name for
"hash") on the file what you expected it to be?
- If you logged on to the remote server locally as that user and checked the
user's Personal cert store, was the matching cert there?
- If so, could you export the cert and its private key? (That's the
only way to tell if the private key is really there - don't trust the cert
UI - it really tells you "at some time earlier, I thought there was a
private key here").
- If so, when logged on as that user, could you open the file?

Another approach:
- What do you mean by "the AD key was generated on"? This might be the
source of the confusion. Are you expecting the key to be on the CA or on
the machine where the user requested a cert? (It will be on the latter.)

I hope one of those lines of questioning gets to the root of this. Please
let me know what you find.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

So my question has to be, what is the point of having the keys published to
active directory then?

Interesting scenario I tried last night... I encrypted a file on a remote
computer using the AD public key, I then tried opening the file on the
machine I know the AD key was generated on.. The user still couldnt read the
file...

Eric

Keys are stored in a user's profile. If the profile doesn't roam, neither
will the keys. And if there's no key available, EFS will request (or
generate) another keypair when encrypting a file.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.


Hello All,

I have a couple win2k3 servers up, both are domain controllers in

a
the

same forest (sc), and one of them (debbie) is running a certificate
authority (enterprise root). When I encrypt a file on a

workstation,
the

CA generates an EFS key, and uses that key on the local workstation.

The problem comes in when I try to encrypt a file on the other domain
controller via a mapped drive from the workstation. The user all of a
sudden generates a new key with himself as the issuer, and encrypts the
file
that way.

Wanting to test something, I wrote a program that uses
AddUsersToEncryptedFile and EncryptFile to encrypt a file and add my test
user's AD/CA EFS key to that file. This was all done on the domain
controller that is hosting the share. When my test user attempts to open
that file (mind you it does have his CA EFS key attached (i can view the
properties, it is correct)) it gives an access denied....

Any ideas what is causing this behaviour?

Eric

 

[Drew Cooper [MSFT]]

EFS is as straightforward as we could make it. The scenario you present is
one of the ones that the current released implementations don't handle well.
And those of us that have worked on it understand the limitations - you're
not the only one who's had problems with this. The hope is that in the
future we can make EFS over SMB both more secure (still encrypted on the
wire, get rid of the delegation requirements) and easier to use (whatever
EFS cert is found in the AD is most likely the user's current one).

Roaming profiles aren't a perfect solution either. Or, rather, they come
with their own problems. The one that bothers me most personally is that
when profiles are written back to the server, the last writer wins - no
merging. This has bitten me before when I've been logged onto multiple
machines simultaneously.

I'm not sure how much help I was, but I'm glad you got it figured out.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

Welp... After logging into the server as those users, and importing their CA
created EFS Cert to the user profile there, then making sure the same key
was reflected on the local machine that was doing the encryption, it appears
as though everything is working! Thanks much for the help with this
issue... I'd always thought EFS was a slightly more straight forward / easy
to use system... *shrug* It looks like I will be going with your
recommendation of roaming profiles...

Thanks again,
Eric

It's most useful for EFS certs when users have roaming profiles. Or for
sharing EFS files over WebDAV. Or for encrypting a file, adding another
user, using ntbackup to make a .bkf, then giving the .bkf to the other user.
In short - not often useful for EFS.
Publishing to the AD is something that makes more sense for, say, an S/MIME
cert.

- After you added the user, was the user's "thumbnail" (cute name for
"hash") on the file what you expected it to be?
- If you logged on to the remote server locally as that user and checked the
user's Personal cert store, was the matching cert there?
- If so, could you export the cert and its private key? (That's the
only way to tell if the private key is really there - don't trust the cert
UI - it really tells you "at some time earlier, I thought there was a
private key here").
- If so, when logged on as that user, could you open the file?

Another approach:
- What do you mean by "the AD key was generated on"? This might be the
source of the confusion. Are you expecting the key to be on the CA or on
the machine where the user requested a cert? (It will be on the latter.)

I hope one of those lines of questioning gets to the root of this. Please
let me know what you find.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

So my question has to be, what is the point of having the keys

published
to

active directory then?

Interesting scenario I tried last night... I encrypted a file on a remote
computer using the AD public key, I then tried opening the file on the
machine I know the AD key was generated on.. The user still couldnt

read
the

file...

Eric

Keys are stored in a user's profile. If the profile doesn't roam, neither
will the keys. And if there's no key available, EFS will request (or
generate) another keypair when encrypting a file.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no
rights.


Hello All,

I have a couple win2k3 servers up, both are domain controllers

in

a

of

a encrypts
the view
the