Re: EFS - Encryption and User Migration

• Previous message: James Fabulous: "Certificate Templates and Auto-Enrollment"
• In reply to: Steven L Umbach: "Re: EFS - Encryption and User Migration"
• Next in thread: Al Dunbar [MS-MVP]: "Re: EFS - Encryption and User Migration"
• Reply: Al Dunbar [MS-MVP]: "Re: EFS - Encryption and User Migration"
• Reply: Gerry Hickman: "Re: EFS - Encryption and User Migration"
• Reply: Steven L Umbach: "Re: EFS - Encryption and User Migration"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Tue, 15 Mar 2005 12:25:48 +1100

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: James Fabulous: "Certificate Templates and Auto-Enrollment"
• In reply to: Steven L Umbach: "Re: EFS - Encryption and User Migration"
• Next in thread: Al Dunbar [MS-MVP]: "Re: EFS - Encryption and User Migration"
• Reply: Al Dunbar [MS-MVP]: "Re: EFS - Encryption and User Migration"
• Reply: Gerry Hickman: "Re: EFS - Encryption and User Migration"
• Reply: Steven L Umbach: "Re: EFS - Encryption and User Migration"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]