Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | RE: Encrypting remote files with EFS |
|---|---|
| Date: | Tue, 24 May 2005 13:17:56 -0500 |
Anthony--thanks for the response. What we're trying to do here is actually the opposite. We *don't* want users to be able to encrypt files on remote servers, or to copy encrypted files to remote servers without decrypting the files first. This *appears* to be the way that Windows is supposed to behave with local profiles in use, no CA infrastructure in place, and file servers not trusted for delegation. However, we *are* able to do so on many of our servers. Can you give any insight as to why this might be? Thanks, -Zack- -----Original Message----- From: AnthonyBlumfield@msn.com [mailto:AnthonyBlumfield@msn.com] Sent: Saturday, May 21, 2005 9:51 PM To: focus-ms@securityfocus.com Subject: Re: Encrypting remote files with EFS In-Reply-To: <BC1AFC2B7BFC404FBE5E6E0A07C11DCFD86E10@carmel06.blueco.com> There is a configuration that will enable such behavior If your users are using roaming profiles and the server shares are web folders rather than file shares the following will happen: When the user copies a local file to the web folder it remains encrypted When the user accesses the file from another computer the certificate in his roaming profile is used to decrypt it. Thanks Anthony Blumfield [MSFT] Microsoft Corporation This posting is provided "AS IS" with no warranties, and confers no rights
Thread-Topic: Encrypting remote files with EFS Thread-Index: AcVV0A6JwsGHmcCsRPex6rsRutawHwAXuEvg From: "Zack Schiel" <ZSchiel@blueandco.com> To: "Bruce K. Marshall" <bkmlstsgohere@comcast.net> Cc: <focus-ms@securityfocus.com> X-OriginalArrivalTime: 11 May 2005 14:15:32.0001 (UTC)
FILETIME=[E417C110:01C55633]
They really don't have trusted for delegation. =20 Your postulation on why the files encrypt and are accessible from multiple machines seems correct--the users *do* have local profiles on the server after encrypting a file. This is a step in the right direction; the question now becomes *how* are they able to do this without the machine being trusted for delegation? Thanks for the help, -Z- -----Original Message----- From: Bruce K. Marshall [mailto:bkmlstsgohere@comcast.net]=20 Sent: Tuesday, May 10, 2005 9:21 PM To: Zack Schiel Cc: focus-ms@securityfocus.com Subject: Re: Encrypting remote files with EFS Zack, Strange. I can't explain how this would work if the AD computer
objects
really don't have the 'trusted for delegation' attribute turned on. If you=20 figure out why it still works, please let us know. The reason that the users can access the encrypted files from
multiple=20
computers is due to the fact that EFS is using a certificate and
private
key=20 stored on the file server for the encryption/decryption operations. If you=20 use efsinfo /u (or a similar tool) it should show you that the
encrypted
files have a different thumbprint than the certificates on their
local=20
computers. This is why the trusted for delegation attribute should
be=20
required; the server is actually creating a local profile and
generating
local EFS credentials as the domain user. If you really want to disable EFS on the file servers use a Group
Policy
with the Encrypting File System setting changed to disallow users
from=20
encrypting files (or Encrypted Data Recovery Agent policy set to
empty,=20
depending on your OS). Then apply the GPO to the OU containing only your=20 server computer objects. ---- Bruce K. Marshall - bmarshall@securityps.com Security PS - Kansas City ----- Original Message -----=20 From: "Zack Schiel" <ZSchiel@blueandco.com> To: "Bruce K. Marshall" <bkmlstsgohere@comcast.net> Cc: <focus-ms@securityfocus.com> Sent: Tuesday, May 10, 2005 5:54 PM Subject: RE: Encrypting remote files with EFS Yes, I have. They do have the encrypted attribute, and cannot be
opened
by other users. -Zack- -----Original Message----- From: Bruce K. Marshall [mailto:bkmlstsgohere@comcast.net] Sent: Tuesday, May 10, 2005 3:28 PM To: Zack Schiel Cc: focus-ms@securityfocus.com 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 -----=20 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-=20 -----------------------------------------------------------------------
----
-----------------------------------------------------------------------
----
------------------------------------------------------------------------ --- ------------------------------------------------------------------------ --- --------------------------------------------------------------------------- ---------------------------------------------------------------------------
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Encrypting remote files with EFS, AnthonyBlumfield |
|---|---|
| Next by Date: | SecurityFocus Microsoft Newsletter #242, Marc Fossi |
| Previous by Thread: | Re: Encrypting remote files with EFS, AnthonyBlumfield |
| Next by Thread: | SecurityFocus Microsoft Newsletter #240, Marc Fossi |
| Indexes: | [Date] [Thread] [Top] [All Lists] |