0

Can someone please help me with the following

I set up a LAB consisting two single DC AD Forests (two separate AD forests) as I wanted to install and become familiar with Microsoft's ADMT (Active Directory Migration Tool), I downloaded the latest version 3.2

In the source forest I created and OU called Sales and created one user account and two group accounts under this OU.

I then performed a test migration of the Groups (to start with) and this worked as expected. The Groups appear in the target along with their SID History being populated, so good so far

Next, I assigned one of the groups under the sales OU some AD rights with the Sales OU. I gave the Group the 'write' and 'create child objects' rights to the Sales OU.

I then migrated the group for a second time. choosing the option to 'update user rights' and to 'migrate and merge conflicting objects' (as object already migrated once).

However this updated ACL in the Sales OU did not come across to the target Sales OU (in the target forest). I also tried it with a brand new account that was not migrated before and again although the account migrated OK, the accounts rights (specific ACEs listed in the source ACL for the Sales OU) do not get migrated to the target forest.

I can only assume this is because ADMT is not actually being asked to Migrate the Sales OU itself (and therein its ACL) but rather the object under it.

If that is the case? then this begs the question if I want to migrate AD ACLs (for example on OUs etc) to the new forest, would I have to do this with a PowerShell script for example?

I would be grateful for any help/advice on this please

Thanks CXMelga

Greg Askew
  • 34,339
  • 3
  • 52
  • 81
AUser
  • 1
  • `I can only assume this is because ADMT is not actually being asked to Migrate the Sales OU itself`. Should be easy to test. It seems logical that the tool will not search every object in the source domain for every principal to be migrated to determine if there are permissions. It copies permissions of objects to be migrated. – Greg Askew Apr 15 '22 at 11:06
  • Hello Gary, yes I think that must be it too as the ACL (NtSecurityDescriptor) is on the actual object (Sales OU in this case) and that is not being migrated as ADMT does not appear to migrate OUs from what I can see. I can sort this out with a PowerShell script. However whilst it is good practice to apply permissions at the OU level (delegated rights for example) so they are easy to find later (and therein audit/migrate) this does not have to be the case, there could be permissions all over the place. CXMelga – AUser Apr 15 '22 at 20:19
  • That's the next/default approach. Find ACL's that aren't inherited and apply them to matching OU's. PowerShell may work for small/medium organizations/infrastructures. – Greg Askew Apr 15 '22 at 20:22

0 Answers0