Re: EFS Certificate Issue
From: Drew Cooper [MSFT] (dcoop_at_online.microsoft.com)
Date: Thu, 4 Mar 2004 17:31:13 -0800
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
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. "Eric Skibicki" <firstname.lastname@example.org> wrote in message news:%23X2WOEkAEHA.3308@TK2MSFTNGP10.phx.gbl... > > 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 > > > "Drew Cooper [MSFT]" <email@example.com> wrote in message > news:u3xXY$iAEHA.3220@TK2MSFTNGP10.phx.gbl... > > 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. > > > > > > "Eric Skibicki" <firstname.lastname@example.org> wrote in message > > news:eYgb%235fAEHA.3804@TK2MSFTNGP09.phx.gbl... > > > 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 > > > > > > "Drew Cooper [MSFT]" <email@example.com> wrote in message > > > news:OsoPDBZAEHA.132@TK2MSFTNGP10.phx.gbl... > > > > 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. > > > > > > > > > > > > "Eric Skibicki" <firstname.lastname@example.org> wrote in message > > > > news:uTlo%23fWAEHA.email@example.com... > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >