Re: EFS and Delegation

From: Guillaume (Guillaume_at_discussions.microsoft.com)
Date: 06/10/05 

Date: Fri, 10 Jun 2005 10:25:01 -0700

Response inline.

"Steven L Umbach" wrote:

> I have never tried that myself as a way to prevent a user from creating EFS
> files on a share and I wonder if the changes have not been replicated to all
> the necessary domain controllers or the information is being cached on the
> server or once the user has the certificate on the server disabling his
> account to not be able to be trusted for delegation does no longer matter.
Only one DC in the domain , one CA, and stations (everything tested on
Virtual Server).

> What you might try is to create a test user that has his account configured
> so that it can not be trusted for delegation right off the bat and then see
> if that new test user can encrypt a file via EFS on the server share. If
> that works try deleting an existing user profile on the server for a user
> and then have them try to encrypt a file via EFS on the share. The user
> profile is where the EFS certificate/private key is located. --- Steve
>
Let me develop on the test:
- created a share directly on the DC
- created two user accounts from scratch: user1 with "sensitive account..."
cleared, one with "sensitive account..." cleared
- both accounts retrieved EFS v2 Certificates through auto-enrollment
- did NOT copy profiles to the DC
- acces the share from a station, logged on as user1, then user2
- each time, I was able to create a file and encrypt it remotely. Of course,
as profiles were not copied to the server, this one created the profiles
locally, and auto-emitted EFS certificates (basic EFS v1 cetificates that are
the only one that can be emitted when needed are disabled on the CA), which
is perfectly OK as it's supposed to behave this way.
So the problem is really that no matter your clear or check the box "account
is sensitive...", you can still encrypt/decrypt on the server as long as this
one has EFS permitted. If you dont't have any profile on the server, it will
create one for you and generate the needed certificate/private key.

You solutions to disable EFS directly on the server works vey well btw.

Guillaume.

Relevant Pages

  • Re: remote DEcryption problem
    ... > 1)- Where is the shared folder located, i.e., on a domain ... If just a server, you have to ... This will provide a central store for all EFS ... >>encrypt file on the server by a domain client. ...
    (microsoft.public.win2000.security)
  • Re: EFS network folders
    ... EFS was introduced to prevent abuse from unauthorized access to stolen hard ... So I thought that enabling EFS on a folder would encrypt contents making ... >> folder on server, from the workstation, to encrypted status. ...
    (microsoft.public.win2000.security)
  • Re: EFS and Delegation
    ... Well that is interesting and does not correlate with the EFS documentation ... same results with a brand new account. ... glad you were at least able to EFS disable on that server. ... > - did NOT copy profiles to the DC ...
    (microsoft.public.windows.server.security)
  • RE: EFS Event ID: 6203 on Windows Server 2003
    ... Were the same certificates/keys that were used to encrypt the transferred ... encrypted the users' files with different certs/keys from the current server. ... We are using roaming user profiles. ... > The error only occurs on accessing files that were transferd to the file ...
    (microsoft.public.windowsxp.security_admin)
  • Re: EFS and multiple users
    ... Let say I encrypt a file on my PC. ... Now I have to copy it to the server ... Files will usually inherit parent folder settings (permissions, EFS ...
    (microsoft.public.win2000.security)