|
If the unit is this strongly separated from the rest of your forest
and you have little dependencies on apps, this should be a fairly easy /
straight forward migration. You should be able to achieve all steps with ADMT: The re-ACLing (= security translation) is actually a very straight
forward process – this is how I would go at it: 1.
Create some test accounts in source domain that you put into group
used by the users to be migrated a. Log on
to a few test clients in source domain so as to create user source domain profiles
(make some changes so that you can differentiate the profile from a default
profile) 2.
Migrate the units groups and users, but leave the users in the
target domain disabled (except for some of the test-users) a. Users still
logon to source domain 3.
With the trusts between source and target still in place, migrate
the resources (servers) a. Users
still logon to source domain and access resources across trust, using SIDs from
source domain 4.
Perform 1st security translation on all resources (servers) a. Choose to
ADD permissions b. Users
still logon to source domain and access resources across trust, using SIDs from
source domain c. Logon to
a test computer in target domain with some of your test-accounts and check they
also have access to servers (now using SIDs from target domain) d. If
everything works, you are ready for activation of the target user accounts –
ideally the next two steps would be coordinated that you only enable the users
whose workstations you are migrating at the time (but often difficult to match
user to workstation…) 5.
Perform security translation AND profile updates on all workstations
in unit – again, use ADD permissions a. I
personally prefer to do this prior to enabling the users and prior to migrating
the computers – this way this step can be performed in the “background”
without any direct impact on the users b. This also
allows you (or them) to monitor how well they can reach their clients, check
access issues etc. c. Ensure that
the computer updates – especially profile updates – have worked by using
some of your test accounts on clients in the source domain: let them logon with
the target domain’s account => they should at this point get the same user
profile as before AND have access to the target servers 6.
Once a critical mass of computers has been updated, you are ready
to enable your users in the target domain 7.
Now migrate the computers to target domain (those, where security
translation has already been performed successfully) a. At this
time there will be an impact to the users, since machines need to be rebooted –
which is why you should communicate these activities to your users prior to
performing this step b. After the
computer migration, ADMT will have changed the default logon domain to the
target domain c. Users
will now logon to the target domain and access resources with the new SIDs d. Add extra
time for troubleshooting and fixing access issues… 8.
After all computers have been migrated, and all users of the unit
logon to the target domain, you are ready to do the cleanup steps a. Cut the
trusts between the domains (if this is what you want to achieve) b. Perform another
security translation on all resources (servers and workstations) in the target
domain => this time choose the REPLACE option 9.
Done – enjoy some champagne… /Guido From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Kamlesh Parmar Appreciate the quick response, I was able to migrate groups, users without sIDhistory to
target. I also tried using clonepr.vbs, it also asks for admin
rights on source. And reading further, it made it clear that, can't populate
sIDhistory through legitimate APIs without having admin rights on source
domain. So, now my hopes are based on security translation at each
and every to be migrated resource. I will read up about PES service, so that if possible
passwords also can be migrated without admin rights. In this case, no AD dependant app like exchange comes into
picture. :-) this is more of completely independent unit with their own
groups, users and computers contained within one OU. So group membership related
stuff won't be problematic. (at least it seems on initial inspection) Anyway to make 2nd approach you mentioned more systematic
and less painless? subinacl? ADMT security translation wizard? Thanks once again for your response, -- Kamlesh On 7/27/06, Grillenmeier, Guido
<[EMAIL PROTECTED]>
wrote: you can migrate most objects from the source even without admin
rights to them - the default auth. user already has plenty of permissions to
read most attributes you would care to migrate. You could still setup passwords migration without giving
them domain admin privs to your source domain - you would install the PES
server for them instead on one of your DCs (you'd need to exchange the PES key
ofcourse). Migrating SID history on the other hand, requires admin privs on
the source domain => while you can delegate SIDhistory migration to the
target, I've always complained that you can't delegate it on the source.
Full control on the respective Users OU in your source domain is not enough. But if they do their part right (i.e. reacl all their resources in a two
step approach 1st add new acls prior to "activating" the target
accounts, 2nd remove old acls after all users use the new accounts), they
don't really need SIDhistory and can spare themselves from having to clean it
up later. You'll still have the same challenges with apps as you always do
and if you also use exchange, then migrating their mailboxes is a totally
different story. Another special challenge in your scenario is group
migration => depending on how your security model is setup, they may very
likel need to migrate groups that don't "belong" to them, but that
they need to have access to their resources (and allowing to re-acl them). This
doesn't mean that they need to migrate the members that don't belong to
"their" unit, but they do need read permissions on most of your
groups (which most users have by default anyways...). /Guido From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
] On Behalf Of Kamlesh Parmar Hi Guys, We have a peculiar requirement, that one of the small group
of around 300 users will be parting from corporate AD and will be setting up
there own forest. We will be using ADMT 3.0 for migration. source DFL & FFL : windows 2000 native Target DFL & FFL : Windows 2003 Two way trust between domains. We would be giving FULL control rights over those
300 users and their computers account to new admins of new forest. also, they are added to local admins of those computers to
be migrated. They have domain admins rights in Target domain. We don't want to add them into administrators group on
source domains (i.e. corporate AD) Is it possible to migrate, users,groups and computers? What will break, in migration? I can think of, we will not be installing PES as a result
so, NO password migration. anything else? Thanking you in advance, Kamlesh
|
- RE: [ActiveDir] Migration without domain admin rights ... Grillenmeier, Guido
- Re: [ActiveDir] Migration without domain admin ri... Kamlesh Parmar
