Encrypting Remote Files with EFS

Archived from groups: microsoft.public.security,microsoft.public.windows.server.security,microsoft.public.windowsxp.security_admin (More info?)

We are in the midst of deploying EFS to protect specific folders on laptop
hard drives. We want EFS used only for that purpose—locally; as such, we
do not want users to have the ability to encrypt files that are residing
on file servers. According to my understanding of EFS, which seems to be
confirmed by the quote below from Windows help, users shouldn't be able to
do so unless we specifically enable file server(s) to be trusted for
delegation in AD.

"In a domain environment, remote encryption is not enabled by default. To
enable encryption for a specific computer, your network administrator can
make that computer trusted for delegation. For more information, consult
your network administrator.�

However, some of our servers are allowing files to be encrypted and
decrypted remotely—and these servers are *not* marked as trusted for
delegation in AD. Further, the user that encrypted the file can scoot
over to another PC, log in as themselves, and access the file—and we have
no CA infrastructure in place; these are locally-generated EFS
certificates that do not chain back past the local client machine. The
certificate thumbprints in the personal store for the user account on the
two PCs do not match, yet they can access the file just the same, while
other user accounts cannot.

I'm thoroughly confused by this behavior, and would appreciate any experts
chiming in and cluing me in as to why 1) some servers are allowing remote
encryption, while others are not, and 2) why locally-generated EFS certs
are behaving this way.

Our environment:

-Windows 2000 native-mode domain

-All DCs are Win2k, file servers are a 2k/2003 mix

-Clients are 2000/XP; the OS of the client/server doesn't seem to matter—
some 2k3 servers allow remote encryption, some don't, and some 2000
servers allow, while others don't.

Thanks,

-Zack-
4 answers Last reply
More about encrypting remote files
  1. Archived from groups: microsoft.public.security,microsoft.public.windows.server.security,microsoft.public.windowsxp.security_admin (More info?)

    The user encrypting on one, logging on to another and being able to decrypt
    sounds about right, as these are "domain" profiles, so as they move from
    machine to machine, the same domain profile would be loaded to the
    PC/laptop - I'll assume these are roaming profiles? Maybe not?

    As far as the cert footprint, which one are you comparing, the "public" or
    "private" cert - the "public" one should be different, as the are different
    machines, but the "private" cert should be identical.

    For the rest, some of the other experts will need assist, as why some do and
    some don't, I agree with you, if none are trusted, then it shouldn't allow
    none.

    --

    Star Fleet Admiral Q @ your Service!

    http://www.google.com
    Google is your "Friend"

    "Zack" <None@none.com> wrote in message
    news:op.sqkb2nspobdjke@zschielxp.blueco.com...
    > We are in the midst of deploying EFS to protect specific folders on laptop
    > hard drives. We want EFS used only for that purpose-locally; as such, we
    > do not want users to have the ability to encrypt files that are residing
    > on file servers. According to my understanding of EFS, which seems to be
    > confirmed by the quote below from Windows help, users shouldn't be able to
    > do so unless we specifically enable file server(s) to be trusted for
    > delegation in AD.
    >
    > "In a domain environment, remote encryption is not enabled by default. To
    > enable encryption for a specific computer, your network administrator can
    > make that computer trusted for delegation. For more information, consult
    > your network administrator."
    >
    > However, some of our servers are allowing files to be encrypted and
    > decrypted remotely-and these servers are *not* marked as trusted for
    > delegation in AD. Further, the user that encrypted the file can scoot
    > over to another PC, log in as themselves, and access the file-and we have
    > no CA infrastructure in place; these are locally-generated EFS
    > certificates that do not chain back past the local client machine. The
    > certificate thumbprints in the personal store for the user account on the
    > two PCs do not match, yet they can access the file just the same, while
    > other user accounts cannot.
    >
    > I'm thoroughly confused by this behavior, and would appreciate any experts
    > chiming in and cluing me in as to why 1) some servers are allowing remote
    > encryption, while others are not, and 2) why locally-generated EFS certs
    > are behaving this way.
    >
    > Our environment:
    >
    > -Windows 2000 native-mode domain
    >
    > -All DCs are Win2k, file servers are a 2k/2003 mix
    >
    > -Clients are 2000/XP; the OS of the client/server doesn't seem to matter-
    > some 2k3 servers allow remote encryption, some don't, and some 2000
    > servers allow, while others don't.
    >
    > Thanks,
    >
    > -Zack-
  2. Archived from groups: microsoft.public.security,microsoft.public.windows.server.security,microsoft.public.windowsxp.security_admin (More info?)

    Hi Zack,

    Ah well, I played around with EFS a bit and got some small input for
    you:

    if you encrypt a file on your local client hdd windows will create a
    local zertificate (A) you need to access this file.

    if the same domain user encrypts a file on some other local comps hdd
    it will create a new local zertifacte (B) there, too, to encrypt the
    file.

    if you encrypt a file on a domain server hdd, the server will create a
    domain zertifacte (C) to encrypt the file.

    if you now attach the hdd of the first local to the second comp, you
    will not be able to decrypt the file (unless you export the (A) first
    and import it to the second comp) since the local zertificate (B) will
    be used.

    but if you try to access the file on the server hdd windows will use
    the server based zertificate (C) and can decrypt it just fine.


    I dont like this behaviour as well. I in my case do not want the server
    to store data and zertificates in one place, I'd rather like the zert
    to reside on the client only, so when someone steals my server they got
    no chance of accessing the data on the hdd. Well, but thats just me...

    cu,
    Sam
  3. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.security_admin,microsoft.public.windows.server.security (More info?)

    Zack, were the servers at one time trusted for delegation? If so, you will
    need to reboot the machines to clear EFS cache. EFS will cache up to 100
    users' certificates (for performance). Users who had previously encrypted on
    the servers would still be able to do so until the cache is cleared.

    If the servers were never trusted for delegation, please give a few more
    details. Exactly which client OSes (XPsp1, XPsp2, W2Ksp4, etc.) are able to
    access which non-TFD servers (W2Ksp4, WS2003, WS2003sp1, etc.).

    Thanks.
    Pat
    --
    This posting is provided "AS IS" with no warranties, and confers no rights.


    "Zack" wrote:

    > We are in the midst of deploying EFS to protect specific folders on laptop
    > hard drives. We want EFS used only for that purpose—locally; as such, we
    > do not want users to have the ability to encrypt files that are residing
    > on file servers. According to my understanding of EFS, which seems to be
    > confirmed by the quote below from Windows help, users shouldn’t be able to
    > do so unless we specifically enable file server(s) to be trusted for
    > delegation in AD.
    >
    > “In a domain environment, remote encryption is not enabled by default. To
    > enable encryption for a specific computer, your network administrator can
    > make that computer trusted for delegation. For more information, consult
    > your network administrator.�
    >
    > However, some of our servers are allowing files to be encrypted and
    > decrypted remotely—and these servers are *not* marked as trusted for
    > delegation in AD. Further, the user that encrypted the file can scoot
    > over to another PC, log in as themselves, and access the file—and we have
    > no CA infrastructure in place; these are locally-generated EFS
    > certificates that do not chain back past the local client machine. The
    > certificate thumbprints in the personal store for the user account on the
    > two PCs do not match, yet they can access the file just the same, while
    > other user accounts cannot.
    >
    > I’m thoroughly confused by this behavior, and would appreciate any experts
    > chiming in and cluing me in as to why 1) some servers are allowing remote
    > encryption, while others are not, and 2) why locally-generated EFS certs
    > are behaving this way.
    >
    > Our environment:
    >
    > -Windows 2000 native-mode domain
    >
    > -All DCs are Win2k, file servers are a 2k/2003 mix
    >
    > -Clients are 2000/XP; the OS of the client/server doesn’t seem to matter—
    > some 2k3 servers allow remote encryption, some don’t, and some 2000
    > servers allow, while others don’t.
    >
    > Thanks,
    >
    > -Zack-
    >
  4. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.security_admin,microsoft.public.windows.server.security (More info?)

    Just to clarify, only the servers would need to be rebooted.

    Thanks.
    Pat
    --
    This posting is provided "AS IS" with no warranties, and confers no rights.


    "Pat Hoffer [MSFT]" wrote:

    > Zack, were the servers at one time trusted for delegation? If so, you will
    > need to reboot the machines to clear EFS cache. EFS will cache up to 100
    > users' certificates (for performance). Users who had previously encrypted on
    > the servers would still be able to do so until the cache is cleared.
    >
    > If the servers were never trusted for delegation, please give a few more
    > details. Exactly which client OSes (XPsp1, XPsp2, W2Ksp4, etc.) are able to
    > access which non-TFD servers (W2Ksp4, WS2003, WS2003sp1, etc.).
    >
    > Thanks.
    > Pat
    > --
    > This posting is provided "AS IS" with no warranties, and confers no rights.
    >
    >
    > "Zack" wrote:
    >
    > > We are in the midst of deploying EFS to protect specific folders on laptop
    > > hard drives. We want EFS used only for that purpose—locally; as such, we
    > > do not want users to have the ability to encrypt files that are residing
    > > on file servers. According to my understanding of EFS, which seems to be
    > > confirmed by the quote below from Windows help, users shouldn’t be able to
    > > do so unless we specifically enable file server(s) to be trusted for
    > > delegation in AD.
    > >
    > > “In a domain environment, remote encryption is not enabled by default. To
    > > enable encryption for a specific computer, your network administrator can
    > > make that computer trusted for delegation. For more information, consult
    > > your network administrator.�
    > >
    > > However, some of our servers are allowing files to be encrypted and
    > > decrypted remotely—and these servers are *not* marked as trusted for
    > > delegation in AD. Further, the user that encrypted the file can scoot
    > > over to another PC, log in as themselves, and access the file—and we have
    > > no CA infrastructure in place; these are locally-generated EFS
    > > certificates that do not chain back past the local client machine. The
    > > certificate thumbprints in the personal store for the user account on the
    > > two PCs do not match, yet they can access the file just the same, while
    > > other user accounts cannot.
    > >
    > > I’m thoroughly confused by this behavior, and would appreciate any experts
    > > chiming in and cluing me in as to why 1) some servers are allowing remote
    > > encryption, while others are not, and 2) why locally-generated EFS certs
    > > are behaving this way.
    > >
    > > Our environment:
    > >
    > > -Windows 2000 native-mode domain
    > >
    > > -All DCs are Win2k, file servers are a 2k/2003 mix
    > >
    > > -Clients are 2000/XP; the OS of the client/server doesn’t seem to matter—
    > > some 2k3 servers allow remote encryption, some don’t, and some 2000
    > > servers allow, while others don’t.
    > >
    > > Thanks,
    > >
    > > -Zack-
    > >
Ask a new question

Read More

Security Microsoft Servers Windows XP