Re: EFS - Encryption and User Migration
From: Al Dunbar [MS-MVP] (alan-no-drub-spam_at_hotmail.com)
Date: 03/09/05
- Next message: Steven L Umbach: "Re: Anonymous Acccess to File Share on Windows Server 2003"
- Previous message: Garry Lindsay: "Re: Windows Server 2003, SSL Certificate, Bad Request (Invalid Hostname)"
- In reply to: Damon Birrell: "EFS - Encryption and User Migration"
- Next in thread: Steven L Umbach: "Re: EFS - Encryption and User Migration"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 8 Mar 2005 21:19:48 -0700
"Damon Birrell" <sophdamon.nospam@adsl.on.net> wrote in message
news:ui88AfEJFHA.4028@tk2msftngp13.phx.gbl...
> 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?
That would certainly seem to apply to EFS. But don't take my word for it,
create a dummy user, setup the encryption, migrate the account to the other
domain, and see what happens.
> 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.
Yuk!
> 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
Perhaps. But I tend to be leary of using "automated scripts" to perform
irreversible conversions, especially when important, sensitive user data is
involved.
> 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).
Not my area of expertise, sorry...
> 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
What, just because ONE of the laptops containing his encrypted files has had
the certificate exported, you are sure his account is ready to be converted?
> If migrated
> Import users certificate (somehow, automatically without wizards
> appearing or requiring user input)
> End If
As I said above, I would be very concerned about the possibility of
something going wrong, like the user pulling the plug halfway through the
script, the power failing, or the remote connection being broken.
> 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?
Because of the importance and sensitivity of the data, I would convert your
process from the following:
- we need to migrate the users, and, while we are at it, we will try to
preserve their encrypted data.
to:
- we need to migrate the user's encrypted data, and, while we are at it will
have to migrate the user accounts as well.
I know little of your organization and the practicality of working things
this way, but my preference would be to advise the user community of the
need to convert their encrypted data to belong to accounts in the new
domain. I would then create the new accounts and issue them, but leave the
old ones intact. The users would be required to identify all of the
workstations containing their data, and make arrangements to bring the
systems in (or whatever else might work for you). They would logon with
their old accounts to access their encrypted data, save it without
encryption (should be isolated from unsecured networks at this point), log
in with the new account, and re-crypt it.
There might be a more direct way to do the actual conversion to the new
certificate (not my area of expertise), but I would think fewer gotcha's
would crop up later on if the process was carried out through the logon
script.
/Al
- Next message: Steven L Umbach: "Re: Anonymous Acccess to File Share on Windows Server 2003"
- Previous message: Garry Lindsay: "Re: Windows Server 2003, SSL Certificate, Bad Request (Invalid Hostname)"
- In reply to: Damon Birrell: "EFS - Encryption and User Migration"
- Next in thread: Steven L Umbach: "Re: EFS - Encryption and User Migration"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
