RE: Encrypting remote files with EFS

From: Zack Schiel (ZSchiel_at_blueandco.com)
Date: 05/24/05

  • Next message: Marc Fossi: "SecurityFocus Microsoft Newsletter #242"
    Date: Tue, 24 May 2005 13:17:56 -0500
    To: <AnthonyBlumfield@msn.com>, <focus-ms@securityfocus.com>
    
    

    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
    >
    >
    >
    >-----------------------------------------------------------------------

    ----
    >-----------------------------------------------------------------------
    ----
    >
    >
    ------------------------------------------------------------------------
    ---
    ------------------------------------------------------------------------
    ---
    ---------------------------------------------------------------------------
    ---------------------------------------------------------------------------
    

  • Next message: Marc Fossi: "SecurityFocus Microsoft Newsletter #242"

    Relevant Pages

    • Re: Encrypting remote files with EFS
      ... really don't have the 'trusted for delegation' attribute turned on. ... local EFS credentials as the domain user. ... If you really want to disable EFS on the file servers use a Group Policy ... encrypting files (or Encrypted Data Recovery Agent policy set to empty, ...
      (Focus-Microsoft)
    • RE: Encrypting remote files with EFS
      ... They really don't have trusted for delegation. ... Encrypting remote files with EFS ... If you really want to disable EFS on the file servers use a Group Policy ...
      (Focus-Microsoft)
    • Re: Encryption Across Network File Shares
      ... the user should be able to decrypt and work on the EFS files. ... for Delegation" and the user that is encrypting/decrypting will have to be ... certificate/private key into your domain account, by encrypting a file ...
      (microsoft.public.windowsxp.security_admin)
    • Re: Encryption Across Network File Shares
      ... The computer with the share that you want to contain EFS files and the ... certificate/private key into your domain account, by encrypting a file while ... "Rick Blake" wrote in message ...
      (microsoft.public.windowsxp.security_admin)
    • Re: EFS Certificate Needed
      ... Backup and save on non-degrading media the EFS DRA .pfx file ... Foe sure I will follow "Windows Recommendations". ... that recovery agent will only have ... Best practices for the Encrypting File System ...
      (microsoft.public.security)