Score:0

Microsoft's ADMT not migrating updated AD ACLs

in flag

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

cn flag
`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.
AUser avatar
in flag
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
cn flag
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.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.