Migrating files from one domain to another

  • 86 Views
  • Last Post 25 September 2015
RedPlumpTomato posted this 25 September 2015

Hi all,
I was wondering if ADMT would help with me a particular migration that I need to perform this month.
We have a file server in domain1 and a new fileserver in domain 2. There is a trust between domains.
folders in domain1 would have groups assigned for permission.
i want to be able to migrate (copy) these files /folders  to the new fileserver in domain2 and assign the new group to the folders.
Example:
on fileserver 1
Folder: Test
Group with Read/Write: \domain1\accounting
folder would be copied too fileserver 2
folder: test
group with read/write: \domain2\account
(groups are the same name in both domains. I've already imported all groups from domain1 to domain2.
I was thinking to migrate the files first (preserving permissions) and than using ADMT to change the permissions using a mapfile.
Any thoughts on thsi? We have about 2 million files to migrate.. If this is successful, we will have another 40 million objects to migrate after...

Order By: Standard | Newest | Votes
barkills posted this 25 September 2015

That should work.



 

Since you’ll be using the Security Translation Wizard, be aware that it will only deploy the ADMT agent to computers in the same domain.



 

Depending on what you’ve already done, that may mean you need to install ADMT on another computer (in the destination domain) and point it at the ADMT database

you already created.

 

There are two ways you can get the group mapping to happen. You can provide a mapping file or you can do a group migration. Lots of folks tend to incorrectly

think that if you do the group migration it means you will be using sidHistory—but that’s not actually true. SidHistory is just an option of the ADMT group migration operation—you need not use it. There are upsides and downsides of doing the group migration—I

tend to use it because then I don’t have to keep supplying a mapping file (or generate one) on each subsequent reACL/migration. The biggest potential downside is that there might be information on the origin group which you don’t want on the destination group,

but for almost all cases, there are easy ways to mitigate that.

 

One other thing to mention is that you should consider whether you’ll be running the Security Translation Wizard in Add mode or Replace

mode. With Add mode, it adds a “dual” ACE so you have an entry from each domain in the ACLs. With Replace mode, it converts the existing ACE to be the one in the destination domain. Add mode is nice if you haven’t yet gotten all the users to switch domains,

but it also means more work later to re-run the wizard in Remove mode.


 

show

RedPlumpTomato posted this 25 September 2015

Hi Brian ,
Thank you very much for this explanation. I'll test and report back my progress. 
On Sep 25, 2015, at 11:45 AM, Brian Arkills <barkills@xxxxxxxxxxxxxxxx> wrote:
















That should work.



 

Since you’ll be using the Security Translation Wizard, be aware that it will only deploy the ADMT agent to computers in the same domain.



 

Depending on what you’ve already done, that may mean you need to install ADMT on another computer (in the destination domain) and point it at the ADMT database

you already created.

 

There are two ways you can get the group mapping to happen. You can provide a mapping file or you can do a group migration. Lots of folks tend to incorrectly

think that if you do the group migration it means you will be using sidHistory—but that’s not actually true. SidHistory is just an option of the ADMT group migration operation—you need not use it. There are upsides and downsides of doing the group migration—I

tend to use it because then I don’t have to keep supplying a mapping file (or generate one) on each subsequent reACL/migration. The biggest potential downside is that there might be information on the origin group which you don’t want on the destination group,

but for almost all cases, there are easy ways to mitigate that.

 

One other thing to mention is that you should consider whether you’ll be running the Security Translation Wizard in Add mode or Replace

mode. With Add mode, it adds a “dual” ACE so you have an entry from each domain in the ACLs. With Replace mode, it converts the existing ACE to be the one in the destination domain. Add mode is nice if you haven’t yet gotten all the users to switch domains,

but it also means more work later to re-run the wizard in Remove mode.


 

show

RedPlumpTomato posted this 25 September 2015

Brian,
I do have a concern. I've done group migration without using ADMT. I simply exported the groups from the original domain into the new domain without issue. Therefore, I currently don't have an ADMT database. Will I still be able to use the Security Translation Wizard to modify the files that have already been migrated to the new file server?


show

barkills posted this 25 September 2015

Sure. Both of the ways I mentioned will still work.



 

With the mapping file, at the time it runs the security translation wizard, the ADMT agent will do the SID lookups from both domains so it knows what values to

find and what values to use. If you were deploying many agents, that’d be pretty inefficient, but that’s not your scenario.



 

With the ADMT group migration, it’s doing that SID lookup operation once and storing it in the ADMT database. The ADMT agent can then query the database for each

SID it encounters and figure out what is the replacement value. If you have other future migration/reACLing scenarios involving these two domains that you haven’t mentioned, then doing this is definitely recommended as it’ll benefit those future scenarios.

 

show

RedPlumpTomato posted this 25 September 2015

Excellent.  And if I don't want to use SID info , i can simply use a mapping file to replace the groups on all folders.   I hope I'm understanding this correctly.  :)
On Sep 25, 2015, at 1:05 PM, Brian Arkills <barkills@xxxxxxxxxxxxxxxx> wrote:
















Sure. Both of the ways I mentioned will still work.



 

With the mapping file, at the time it runs the security translation wizard, the ADMT agent will do the SID lookups from both domains so it knows what values to

find and what values to use. If you were deploying many agents, that’d be pretty inefficient, but that’s not your scenario.



 

With the ADMT group migration, it’s doing that SID lookup operation once and storing it in the ADMT database. The ADMT agent can then query the database for each

SID it encounters and figure out what is the replacement value. If you have other future migration/reACLing scenarios involving these two domains that you haven’t mentioned, then doing this is definitely recommended as it’ll benefit those future scenarios.

 

show

barkills posted this 25 September 2015

ADMT will be dealing with SIDs regardless of what you do. Under the covers all your files (and all other resources) have an ACL which consists of SIDs that corresponds

to the “nice” names you see for users and groups. ADMT is managing the SID to “nice” name business for you, just as Windows does that for you in its UI.



 

So you can’t get away from the fact that conceptually beneath the covers SIDs are being used. And that’s a good thing. That’s what ensures that you can rename

a user or group and access isn’t lost because of the rename.

 

One decision you have is whether or not you use sidHistory. That’s where you append another SID on a user or group so that Windows will give you access to any

resources of either that SID or the one assigned by default

to that user/group. Using sidhistory is a fine solution when you’ve got a messy migration or you need a higher assurance that access won’t break during your migration activities. But there is some “technical debt” that comes with it, because you really should

remove the sidHistory at some point. So using sidHistory equates to delaying the point of “testing” whether you got the reACLing right until later. For your scenario, using sidHistory makes very little sense to me—and you’ll find that there are quite a few

folks that feel that it never makes sense. I wouldn’t go quite that far, but I think there is a good point here to consider carefully.

J



 

 

show

RedPlumpTomato posted this 25 September 2015

I think the main issue is that I may be looking at this from the wrong perspective.. I was checking out screenshots of the Security Translation Wizard here: https://blog.thesysadmins.co.uk/admt-series-10-security-translation-wizard-local-profiles.html
But, I don't see any option to specify which files I'm going to work with.  It looks like I just specify source domain , target domain, and choose "Files and Folders" but, I don't see where I can actually choose the files.


show

barkills posted this 25 September 2015

Yes, the ADMT agent scans all files on the target computer for the SIDs of the users/groups you’ve specified, not just some of the files.

 

If you want more selective reACLing, check out subinacl.exe or SetACL. They work a bit differently, but you can likely get what you want out of them.

 

show

RedPlumpTomato posted this 25 September 2015

Again , much appreciated Brian.  I will play with these options and report back. 
On Sep 25, 2015, at 3:04 PM, Brian Arkills <barkills@xxxxxxxxxxxxxxxx> wrote:
















Yes, the ADMT agent scans all files on the target computer for the SIDs of the users/groups you’ve specified, not just some of the files.

 

If you want more selective reACLing, check out subinacl.exe or SetACL. They work a bit differently, but you can likely get what you want out of them.

 

show

Close