Re: EFS - Encryption and User Migration

• Previous message: Steven L Umbach: "Re: Limited Security Loacation list"
• In reply to: Damon Birrell: "Re: EFS - Encryption and User Migration"
• Next in thread: Gerry Hickman: "Re: EFS - Encryption and User Migration"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Tue, 15 Mar 2005 21:37:05 -0600

Your migration may work as it is but it really should be tested out on a
sample group of users/computers. I know ADMT has a test mode. The EFS
certificate/private key is stored in the user's profile so if you are
correctly migrating the user's profiles EFS "may" work. I have not tried
exactly what you are doing myself however to share a real life experience.
The RA would be an option for file recovery if for some reason the user
migration was a problems. Of course clear text backups are the failsafe
option. As far as importing a user's certificate in an automated way keep in
mind that there are really two parts to a users certificate - the public key
and the private key. Certificate as commonly refereed to is the public key.
To export/import a users certificate/private key, a password protected .pfx
file needs to be created and then the password needs to be used to
open/import the .pfx file but like I said this is all included in the user's
profile and hopefully will work as part of a proper migration. You can not
however simply restore a user's profile to a new computer to gain access to
the user's EFS files though there are recovery programs that can give the
user access as long as the user's password for that profile is known. ---
Steve

"Damon Birrell" <sopdamon.nospam@adsl.on.net> wrote in message
news:eZmGs3PKFHA.2396@TK2MSFTNGP12.phx.gbl...
> Gentlemen, thank you very much for your input. I have been sick for
> several
> days so haven't been able to contribute. I am pleasantly surprised with
> the
> feedback so far. I had a few comments to add:
>
> 1) Encryption is not an option. It is a clearly defined security
> requirement
> for this law enforcement agency and we have no option but to maintain it's
> implementation.
> 2) We do have an RA configured for the forest that houses both domains - I
> should have mentioned this detail last time!
> 3) We do know which files are encrypted - "My Documents" and everything
> underneath for all user profiles on the laptops.
> 4) My original proposed process was to export the users private key while
> in
> the old domain, migrate the user and then import it again. I am by no
> means
> strong with encryption principles but I would expect that if a user
> encrypted data on two different domain machines their private key on each
> machine would be unique. So this method wouldn't work?
>
> From what it sounds like we don't have a lot of options. Either we:
>
> 1) Get the users to unencrypt their data for the duration of the migration
> component of the project and only migrate the users once confirmed their
> data is unencrypted and backed up. This may not be acceptable to the
> customer but is the safest (procedurally) route. The ones we miss we can
> use
> the RA to recover the data. (safe but time consuming and requires customer
> effort)
>
> 2) Perform an RA recovery on every laptop to recover everyone's data after
> the migration (yuck, reactive, need to remove any traces of RA after
> recovery)
>
> 3) Perform some interim automated step with certificates / private keys to
> get people over the line on a just-in-time basis (yuck, risky). Use RA to
> resolve any issues that are not caught by the process.
>
> 4) Some other option I am unaware of.
>
> Just for the record, can someone please provide the syntax to import a
> users
> private key from a file onto a new workstation using certutil, certmgr or
> a
> rundll crypt.dll command? I really doubt I would use this method but I
> couldn't get any of these to work without requiring user input and it's
> bothering me :-)
>
>
> "Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
> news:uN2cNKmJFHA.1456@TK2MSFTNGP10.phx.gbl...
>> You can create a Recovery Agent for domain computer which is part of
>> Group
>> Policy computer configuration. Once you define that RA for all or a group
> of
>> domain computers that RA will be able to decrypt EFS files that are
> created,
>> modified, or opened as soon as that RA becomes effective on the domain
>> computers. EFS files that were created before the RA was defined will not
> be
>> able to be updated with the RA until they are at least opened. You can
>> use
>> the utility efsinfo to find out exactly what, if any, RA are associated
> with
>> an EFS file. Since it is "computer configuration" it will apply whether
> the
>> user that logs on is a domain user or a local user. Windows 2000
> computers
>> require a RA but XP Pro does not. For a domain user [not local XP Pro
>> user
>> however] , you can also reset the users password in AD Users and
>> Computers
>> and then logon as that user and access their EFS files as long as the
> user's
>> EFS private key exists on the computer in the user's profile. --- Steve
>>
>>
>> "Gerry Hickman" <gerry666uk@yahoo.co.uk> wrote in message
>> news:%23csFVubJFHA.532@TK2MSFTNGP12.phx.gbl...
>> > Hi Steve,
>> >
>> > Good to know about disabling it, but that's not exactly what I'd call
>> > "managing it centrally":)
>> >
>> > The central recovery agent sounds more interesting. Are you saying you
> can
>> > get all encrypted data from all laptops regardless of who logged in
> (both
>> > local and domain).
>> >
>> > Steven L Umbach wrote:
>> >
>> >> Hi Gerry.
>> >>
>> >> I agree that EFS can be a real problem but it can be managed
>> >> centrally.
>> >> You can either disable it totally for all or select domain computers
> and
>> >> you can also enforce that all or select domain computers use a central
>> >> recovery agent. In this particular situation with a migration I agree
>> >> that plain text backups is the best way to insure that data is not
>> >> st. --- Steve
>> >>
>> >>
>> >> "Gerry Hickman" <gerry666uk@yahoo.co.uk> wrote in message
>> >> news:e0oNJ6OJFHA.3356@TK2MSFTNGP12.phx.gbl...
>> >>
>> >>>Hi Damon,
>> >>>
>> >>>It's probably not the answer you want, but my way of dealing with EFS
> is
>> >>>to ban all users from using it - end of story.
>> >>>
>> >>>In my view, it was badly thought to allow simply allow it to be
>> >>>enabled
>> >>>by a "tick box" in the GUI, making it user specifig and having no
> central
>> >>>control mechanism.
>> >>>
>> >>>One option with the laptops, would be to simply unencrypt EVERY file
>> >>>on
>> >>>the laptop, then do what you want to do, then re-encrypt if you want.
>> >>>
>> >>>I'd tell users of any such laptops to make sure everything they care
>> >>>about is backed up. If they don't have a backup system, they should
>> >>>not
>> >>>be allowed to have laptops in the first place.
>> >>>
>> >>>One thing I can help with, is finding encrypted files; this is great
>> >>>if
>> >>>you only have 30 rogue files among 20,000 on a laptop, but in your
>> >>>case
>> >>>it's pointless because you've already said ALL files are encrypted!
>> >>>
>> >>>Damon Birrell wrote:
>> >>>
>> >>>
>> >>>>Hi
>> >>>>
>> >>>>Apologies for the cross post, I believe these queries have relevance
> in
>> >>>>several groups. I am working for a large Police organisation and we
> are
>> >>>>planning a migration using ADMT2. Scenario is this:
>> >>>>
>> >>>>1) Two domains in same forest (intraforest migration)
>> >>>>2) One domain is uplifted NT4 to W2K3 domain in W2k3 native mode,
>> >>>>call
>> >>>>it SOURCE domain
>> >>>>3) Other domain is W2K3 Domain in W2k3 native mode, call it TARGET
>> >>>>domain
>> >>>>4) SOURCE holds user accounts and groups
>> >>>>5) TARGET holds machine accounts
>> >>>>6) All workstations and servers have already joined TARGET domain
>> >>>>7) Users login to the SOURCE domain
>> >>>>8) All laptops have the logged on user's My Documents folder
>> >>>>encrypted
>> >>>>using the CIPHER command upon logon either through a local machine
>> >>>>script or network login script depending upon their logonserver.
>> >>>>9) We wish to migrate the user accounts to the TARGET domain with the
>> >>>>intention of decommissioning the SOURCE domain.
>> >>>>
>> >>>>My understanding is that Encyption will pose a problem, even with
>> >>>>SIDHistory and once I get the formal test environment running I
>> >>>>expect
>> >>>>to observe that users who are migrated from SOURCE to TARGET will not
> be
>> >>>>able to access their previously encrypted files.
>> >>>>
>> >>>>QUESTION 1: Is this above statement correct?
>> >>>>
>> >>>>We are in a situation where we have a lot of users with laptops who
> may
>> >>>>or may not be connected at the network for long periods of time. We
> also
>> >>>>have a requirement to maintain security (i.e. encryption) until just
>> >>>>before the user is migrated. We are yet to determine the order in
> which
>> >>>>we are migrating users but I am confident that we will NOT be able to
>> >>>>determine which users are laptop users, and if they have logged onto
>> >>>>multiple laptops and encrypted data, we have no real way of knowing
>> >>>>this. Since users may not be on the network during the time we
>> >>>>migrate
>> >>>>them, reversing the CIPHER command in the loogn scripts etc is not
> going
>> >>>>to catch all cases. e.g. one user who has logged onto multiple
> laptops.
>> >>>>
>> >>>>QUESTION 2: What is the best means of circumventing data loss in
>> >>>>these
>> >>>>circumstances? I figured that we are probably going to have to
>> >>>>perform
>> >>>>data recovery as the norm. I had several lines of thought a to how to
>> >>>>attack this problem, including a certificate export/import as part of
> an
>> >>>>automated script process. Will this approach actually work and if so,
>> >>>>what are the pre-requisites for allowing such a data recovery to take
>> >>>>place? (i.e. Domain recovery agent requirements, user certifcate
>> >>>>requirements, etc). I expect that the following process may be a
> posible
>> >>>>solution, if it works:
>> >>>>
>> >>>>Rough Algorithm:
>> >>>>
>> >>>>If machine is a laptop
>> >>>> Determine if user has been migrated or not via central log
>> >>>> If Not Migrated
>> >>>> Export users certificate (CER/PFX) using CIPHER /r and store
> on
>> >>>> secured file share
>> >>>> Update a central log that user has not been migrated but cert
>> >>>> has been backed up
>> >>>> Flag user to list of users who can be migrated
>> >>>> If migrated
>> >>>> Import users certificate (somehow, automatically without
> wizards
>> >>>> appearing or requiring user input)
>> >>>> End If
>> >>>>
>> >>>> II have scripted the "IF not migrated" part but struggled to get the
>> >>>> syntax using certutil, certmgr and rundll crypt.dll commands to
>> >>>> automate the import process of a certificate from a file. I guess I
>> >>>> need to know if it will even work before I continue...
>> >>>>
>> >>>>Anyone got any ideas?
>> >>>>
>> >>>>Regards,
>> >>>>Damon
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>--
>> >>>Gerry Hickman (London UK)
>> >>
>> >>
>> >>
>> >
>> >
>> > --
>> > Gerry Hickman (London UK)
>>
>>
>
>

• Previous message: Steven L Umbach: "Re: Limited Security Loacation list"
• In reply to: Damon Birrell: "Re: EFS - Encryption and User Migration"
• Next in thread: Gerry Hickman: "Re: EFS - Encryption and User Migration"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]