Resource Processing

The facts as presented

• Source user objects migrated in target domain with sidhistory
• Source user objects were deleted
• Source group objects were copied in target domain with sidhistory
• Most of the resource have been migrated on file servers in target domain
• Most of those resources have domain local groups(source domain groups) applied on ACL
• Target domain global groups (containing target domain user objects) are nested inside domain local groups(source domain groups)

Questions from the facts

• Were the source domain local groups migrated to the target with membership?
• Was the data migrated source server to target server? I
• If the above is Yes,were the permissions migrated as is or translated in flight? 
• Or Was the server migrated from the source to the target with the resources?  

My assumptions

• All Source groups type and scope were migrated to the target domain with sidhistory AND membership. Is this true? 

This sentence "Target domain global groups (containing target domain user objects) are nested inside domain local groups(source domain groups)", tells me that Target global groups are member of source domain local groups. Is that true? What about the Target domain local groups that were migrated from the source with sidhistory and membership? 

1. While resource processing, do I need to remove global groups(target domain) from domain local groups(source domain) and append it on resource ACL? 
2. Resource process to append or replace is only applicable on resource ACL?
3. Is this mandatory to add target users to source groups in resource processing? 
4. Can I perform both (add target users keeping source users intact) as well as (replace source users with target users) in source groups?
5. Since groups are copied and membership of those groups are also populated with target users which were already migrated, as an alternative is this possible to apply/add target groups on security descriptors(SD) instead of adding target users to source groups?
6. Can I also run ADPW against target domain? If yes, then what are possible scenarios where ADPW should be used against target domain?
7. What are other tasks for performing resource processing as per my above mentioned situation?

1. I am not sure I really understand this question. You don't need to manually do anything. A Resource Processing task will read the ACEs in the ACLs and replace or append the mapped SID. Resource processing tasks don't know anything about group membership. 

2. Resource process are applicable to all securable resource types. 

3. No, it has no bearing on resource processing at all. Again, resource processing only knows what is in the mapping data and what it is processing. 

4. This question is really two questions. Resource Update manager's resource processing tasks process OS securable resources. ADPW processing tasks process Active Directory securable resources. How you process the OS resources, replace or append, has no impact on the AD resource you are processing. 

5. Adding anything to the source groups should only have an impact for source joined servers with source domain local group secured resources. Target domain joined servers secured by source domain local groups will resolve to the target copy of the source domain local group via sidhistory. 

6. Sure, but I have yet to see from your descriptions as to why you would need to. 

• Were source objects members of target groups prior to the migration? If Yes, Yes, you need process the groups with ADPW. 
• Were source objects granted permission to any AD objects? If Yes, Yes, you need process the objects with ADPW. 
• Did you migrate the security descriptors using Merge or Replace? If Yes, Yes, you need process the security descriptors with ADPW. 
• Did you want to remove SidHistory from some objects? If Yes, Yes, you need process the security descriptors with ADPW. 
  

7. This is a little too open ended a question. Every migration should resource process EVERY security descriptor to append/cleanup or replace the source sids with the target sids. After those tasks have been completed, sid history should be removed. 

Were the source domain local groups migrated to the target with membership? Yes(some of them are now global group in target domain with membership)
Was the data migrated source server to target server? Yes
If the above is Yes,were the permissions migrated as is or translated in flight? Only resources with ACL intact/as-is were migrated
Or Was the server migrated from the source to the target with the resources?

This sentence "Target domain global groups (containing target domain user objects) are nested inside domain local groups(source domain groups)", tells me that Target global groups are member of source domain local groups. Is that true? - yes it's true

What about the Target domain local groups that were migrated from the source with sidhistory and membership? - Some of target domain local groups are migrated with sidhistory and membership and as I said above some of them are now global group in target domain with membership.

==================================================================================================================================

Jeff Shahan

Please answer with explanation on below mentioned queries.

Q1- What are those AD securable resources and how do I determine on which AD securable resources need to be processed? What exactly I have to do / how do I process resource processing on AD securable resources and security descriptors? Can I also resource process append or replace on AD security descriptors? How do I determine whether I need to append or replace on those AD resources?

Q2- How do I resource process on "Target domain global groups (containing target domain user objects) are nested inside domain local groups(source domain groups)"? What exactly do I need to do with this?

You know that those two questions are really 7 questions? 

Q1-5
What are those AD securable resources?
ntSecurityDescriptor (the permssions tab of an object), group membership 

How do I determine on which AD securable resources need to be processed?
Did you migrate the Security Descriptor? Merge or Replace? 

What exactly I have to do / how do I process resource processing on AD securable resources and security descriptors?
What you need to do is read the documentation. This beyond the scope I am willing to write https://support.quest.com/technical-documents/migration-manager-for-ad/8.15/resource-processing-guide

Can I also resource process append or replace on AD security descriptors?
Yes, you can append or replace. https://support.quest.com/technical-documents/migration-manager-for-ad/8.15/resource-processing-guide

How do I determine whether I need to append or replace on those AD resources?
This depends on your migration state. Are you finished migrating?

Q6-7
How do I resource process on "Target domain global groups (containing target domain user objects) are nested inside domain local groups(source domain groups)"?
ADPW can process trusting group membership, but this "source local groups" is what this is mixed up. If the resource is on a target server, the resources are secured with source domain local groups, and those source domain local groups were migrated to the target with sidhistory, the source domain local group are doing nothing. It is the target group with the sidhsitory that is actually controlling access. 

What exactly do I need to do with this?
From what I see from this thread you are missing, it that resource processing on the files and folders on the target host. The Resource Update Manager (RUM) handle that. 

Jeff Shahan

Let me rephrase. Resources in the source domain had been migrated to target domain. Domain Local groups (which were applied on source domain resource ACL) had also been migrated from source domain to target domain. Those source domain local groups are now global groups in target domain having sid of source domain local group in sidhistory attribute of migrated global group. This migrated global group is nested in source domain local group.

So according to you, source domain local group is doing nothing. But what about if user in source domain member of source domain local group wants to access resource? So do I need to remove global group from source domain local group and append on resource ACL for resource process? How does RUM handles this? Please suggest what should I do?

Jeff Shahan

Let me rephrase. Resources in the source domain had been migrated to target domain. Domain Local groups (which were applied on source domain resource ACL) had also been migrated from source domain to target domain. Those source domain local groups are now global groups in target domain having sid of source domain local group in sidhistory attribute of migrated global group. This migrated global group is nested in source domain local group.

So according to you, source domain local group is doing nothing. But what about if user in source domain member of source domain local group wants to access resource? So do I need to remove global group from source domain local group and append on resource ACL for resource process? How does RUM handles this? Please suggest what should I do?