Re: EFS - Encryption and User Migration
From: Al Dunbar [MS-MVP] (alan-no-drub-spam_at_hotmail.com)
Date: 03/15/05
- Next message: Lanwench [MVP - Exchange]: "Re: Shared fax for Macintosh?"
- Previous message: Jeremy Church: "Re: Need to delete *.bak in all subdirectories."
- 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 ]
Date: Mon, 14 Mar 2005 21:10:06 -0700
"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.
Of course, but...
Why is this a requirement? Dumb question, the answer is to protect the
information against unauthorized access, while at the same time protecting
it from loss. But surely they realize that the data is encrypted while the
user is using it, do they not?
Even if you find a way to do the migration without turning encryption off,
you should probably be contacting their security specialists, who may
consider doing a threat risk assessment on the overall process. If they are
leaving all of the details up to a consultant, and you are doing this
migration through a logon script that needs to run against every user on
every workstation he has data on, there is a good chance that something will
be lost somewhere.
> 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)
This would be my choice (remember, I'm not an encryption expert either).
Doing it this way gives you better control/monitoring of the process, so you
will know when you are done.
But the choice should perhaps be up to the client - you might be surprised
what they say when you give them cost estimates for your time to do all of
the recoveries, along with the time the user has to wait.
> 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)
You don't see any potential security holes here?
> 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.
Well, I haven't quite wrapped my head around your whole process, but does
your domain migration of the user accounts have to delete the old one when
the new one has been created? Would there not be some method for them to
logon to their new accounts, but use the old ones to decrypt their data when
they run across data that is inaccessible?
/Al
> 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)
> >
> >
>
>
- Next message: Lanwench [MVP - Exchange]: "Re: Shared fax for Macintosh?"
- Previous message: Jeremy Church: "Re: Need to delete *.bak in all subdirectories."
- 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 ]
Relevant Pages
|
