Resource Processing

Hello,

Post inter-forest migration, source user objects migrated in target domain along with sidhistory and those source user objects were deleted. Source group objects were copied in target domain along 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).

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? Resource process to append or replace is only applicable on resource ACL?

2. Is this mandatory to add target users to source groups in resource processing? Can I perform both (add target users keeping source users intact) as well as (replace source users with target users) in source groups
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?

3. Can I also run ADPW against target domain? If yes, then what are possible scenarios where ADPW should be used against target domain?

4. What are other tasks for performing resource processing as per my above mentioned situation?

Thanks & Regards,
Shawn Douglas

Parents
  • 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.

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

    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 replacehttps://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. 

  • 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?

  • What if resources are located on source domain. "Domain Local" groups of source domain are applied on resource ACL. Those source domain local groups had been migrated from source domain to target domain using Sid History and scope of the source domain group had been changed from domain local group (in source domain) to Global group (in target domain) meaning that now global group in target domain having Sid of source domain local group in Sid History attribute.

    Then does it also mean that  the source domain local group are doing nothing. It is the target group with the Sid history that is actually controlling access.

    Please reply.

  • Here's what happens when you "convert" a Domain Local group to Global.

    As you can see, Bob and Joe have dropped out of the membership.

    As to your comment about the Domain Local group "doing nothing" - it depends on who you are as Bob and Joe will still need it to retain access to the resource.  It also depends on where the server resides.  Once you move it to the target domain, that source domain local group will no longer be recognized.

    There is an interesting article here that discusses the challenges associated with changing group scope:

    https://activedirectoryfaq.com/2016/09/domain-migration-access-denied-group-type-change/


  • Thank you  for the explanation. I have follow-up query based upon real world situation.

    Resource had been migrated on target domain server. The resources are secured with source domain local groups and those source domain local groups were migrated to the target domain with sidhistory. So as per our discussions, the source domain local group will no longer be recognized. Here is the interesting part:

    Q1) I see that few users (source domain) are still member of those source domain local group. So if source domain local group is not recognized, do those users have access on resource?

    What if the resources resources are secured with source Global or source universal groups and those groups were migrated to the target domain with sidhistory. 

    Q2) Then will those source global or source universal groups be recognized? If those users (source domain) are still member of those source global or source universal group, do those users have access on resource?

    Please answer and explain specific to questions.

Reply
  • Thank you  for the explanation. I have follow-up query based upon real world situation.

    Resource had been migrated on target domain server. The resources are secured with source domain local groups and those source domain local groups were migrated to the target domain with sidhistory. So as per our discussions, the source domain local group will no longer be recognized. Here is the interesting part:

    Q1) I see that few users (source domain) are still member of those source domain local group. So if source domain local group is not recognized, do those users have access on resource?

    What if the resources resources are secured with source Global or source universal groups and those groups were migrated to the target domain with sidhistory. 

    Q2) Then will those source global or source universal groups be recognized? If those users (source domain) are still member of those source global or source universal group, do those users have access on resource?

    Please answer and explain specific to questions.

Children
  • I think it's helpful to take a look at what you should be seeing in your NTFS ACLs and how to interpret it.

    (Be sure to click the image to see it more clearly.)

    Below are two possible views of the same list of ACEs on a folder on a server that has been re-ACL'd with QMM and moved to the target domain.

    View 1 is a more conceptual view of the state of the ACLs that helps you understand what ACEs are present after re-ACL'ing.

    View 2 is the most likely what you will actually see because it includes the visual "translation" of source domain objects into target domain objects.  Though very confusing, this occurs when groups are migrated with their SIDHistory and is supposed to be the effect of Microsoft trying to do you a favor (the underlying SIDs in the ACLs are still those of the source objects).

  • Frankly speaking, I'm not able to understand. You're right, it's very confusing. I just look forward to your straight answer of my original questions.

  • I don't understand why you are so concerned about whether the original groups are doing anything or not. 

    You have told us that you have moved the server to the target domain so this tells me that you intend to manage all of your resource access there.

    The point of using the QMM tool in the first place is to have it

    1) Create target equivalents of all source groups that you use in file system ACLs.  Of course, you have to tell it what these are.

    2) Using a RUM processing job, update the ACLs to contain target equivalents of your source groups wherever possible.

    Performing the above steps will allow you to perform all of your access management in the target domain only - which based on your above noted decision to move your server to the target domain, appears to be your goal.

    Finally, to answer your question, regardless of source group type/scope, if you have used QMM to create an equivalent group in your target domain and performed re-ACL'ing, the members of the target equivalent group should have access.

    Have you migrated your groups and re-permissioned your servers or not?

  • Groups have been migrated along with sidhistory but re-ACL is not done. That's why I need to know whether members of source group applied on resource ACL will be able to access resources(target domain) or not if source domain local group is not recognized. What if those source group scope is global or universal.

  • OK - then proceed with your re-ACL and then, if you think something is not right or you have questions about what you are seeing in the ACLs, please post a screen cap of sample folder ACL along with some annotations like what I did above.  That is what this Forum is for.  To answer questions about using the QMM tool and the results you are seeing.