EFS Event ID: 6203 on Windows Server 2003

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Has anyone ever seen the event ID 6203 of source EFS.
Full description:
EFS does not support encryption over network sessions established using the
NTLM protocol.
This event is logged on the server everytime i try to access an encrypted
file from my windows xp SP1 workstation. Even if i just klick on the file in
the explorer.
Afterwards i got an access denied error while opening or decrypt the file.
Any comments?
 
Your machines are not in a domain environment. EFS provides "remote access"
to encrypted files only if the computers are managed under an Active
Directory. That's because the computer that is the "server" must be enabled
for delegation and this can only be done through AD. For
standalone/workgroup machines, you can only access encrypted files locally,
on the box.

For further information, see the "Delegated Server Mode" section at
http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/cryptfs.mspx#EJAA

Additional information is at
http://www.microsoft.com/resources/...windows/xp/all/reskit/en-us/prnb_efs_awzg.asp

Thanks.
Pat
 
Pat,
thanks for your response,
our machines are all members of a single Windows 2000 domain.
The file server is a member server. We are using roaming user profiles.
The server is marked as "trusted for delegation" in AD.
EFS is only used by the system admins for testing purposes.
I proofed the user efs certificates and the corresponding private keys,
everything seems to be ok, private keys are present. After more research I
found out the following:
The error only occurs on accessing files that were transferd to the file
server from our old file server by using backup and restore with Veritas
Backup Exec.
The old file server was a domain controller, which in the meantime has been
demoted and switched off.

Thanks
Mike
 
Were the same certificates/keys that were used to encrypt the transferred
files also used to encrypt the new files? Since these are roaming profiles,
I would expect both servers would have had access to the same profile data
(where the certs/keys are stored); but if not, the former server might have
encrypted the users' files with different certs/keys from the current server.
Compare the thumbprints on transferred and new files. (You can do this in
the Properties UI on the files.)

Thanks.
Pat
 
There are different certs used, but all certs and private keys are present in
my profile as I see in MMC snap in "Certificates" of current user.
 
If the older certs/keys are still showing up in the roaming profiles, the new
file server should have also used those same certs/keys from the
profiles--rather than creating new certs/keys for the profiles. (You may
want to investigate why the new server was unable to get the existing profile
data.) Since the new file server is using the newer certs/keys, it will be
unable to decrypt the older files for remote users; however, if you log on
locally to the server with your roaming profile that contains both sets of
certs/keys, you should be able to locally access the older files. If you can
decrypt them locally and then re-encrypt them remotely, the certs/keys for
the old/new files should match.

To do the above for multiple users, you'll need to use the File Recovery
certificate from your EFS policy to decrypt the files. That cert/key will
give you access to everyone's files. When the users re-encrypt them
remotely, the new server will use their current certs/keys.

Thanks.
Pat
 
Back
Top