First, I can only speak to 2k3...I would suspect that Win2k functions
similarly, but since I no longer use Win2k, I can say for sure.
Users can encrypt files if they have "FULL CONTROL". The encryption
is based on user id, not workstation. So if UserA encrypted the file
on a file server, UserA can read that file on any workstation (even
workstations outside of the domain) as long as they have authenticated
to the resource via the user id that encrypted the file. In Win2k3
you can also specify multiple users to be able to decrypt the files.
If another user id tries to access the file (even Domain Admin -
unless they are Recovery Agents) they will get access denied...even if
they have rights to the file.
I suggest you read the following whitepaper(s) on EFS:
http://www.microsoft.com/technet/security/topics/cryptographyetc/efs.ms
px
And
http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/cryptfs.ms
px
If you don't want used encrypting files, you can disable encryption
via Group Policy (or individual reg hacks). The second paper talks
more about that.
I hope that helps...good luck. Working with EFS can be a huge
challenge...but is a great security feature.
John
----- Original Message -----
From: "Bruce K. Marshall" <bkmlstsgohere@comcast.net>
Date: Tuesday, May 10, 2005 4:28 pm
Subject: Re: Encrypting remote files with EFS
Zack,
My suspicion would be that the files on the suspect servers are
not actually
encrypted. The behavior is not consistent with my experience or
expectations.
Have you verified that the encrypted attribute is still set on
files while
on the server?
----
Bruce K. Marshall - bmarshall@securityps.com
Security PS - Kansas City
----- Original Message -----
From: "Zack Schiel" <ZSchiel@blueandco.com>
To: <focus-ms@securityfocus.com>
Sent: Tuesday, May 10, 2005 9:03 AM
Subject: Encrypting remote files with EFS
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-
-------------------------------------------------------------------
--------
-------------------------------------------------------------------
--------
-------------------------------------------------------------------
--------
-------------------------------------------------------------------
--------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
