RE: Encrypting remote files with EFS

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

  • Next message: jbaskerville_at_cfl.rr.com: "Re: Encrypting remote files with EFS"
    Date: Wed, 11 May 2005 09:15:31 -0500
    To: "Bruce K. Marshall" <bkmlstsgohere@comcast.net>
    
    

    They really don't have trusted for delegation.

    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]
    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
    figure out why it still works, please let us know.

    The reason that the users can access the encrypted files from multiple
    computers is due to the fact that EFS is using a certificate and private
    key
    stored on the file server for the encryption/decryption operations. If
    you
    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
    computers. This is why the trusted for delegation attribute should be
    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
    encrypting files (or Encrypted Data Recovery Agent policy set to empty,
    depending on your OS). Then apply the GPO to the OU containing only
    your
    server computer objects.

    ----
    Bruce K. Marshall - bmarshall@securityps.com
    Security PS - Kansas City
    ----- Original Message ----- 
    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 ----- 
    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- 
    ---------------------------------------------------------------------------
    ---------------------------------------------------------------------------
    

  • Next message: jbaskerville_at_cfl.rr.com: "Re: Encrypting remote files with EFS"
  • Quantcast