ADPW usage question

Hello Support Team,

I've general question related to usage of ADPW tool. 

Question: If resource is secured with Source Domain Local groups only && Resource Server (Source domain) has been moved to Target domain, then do I still need to process Source Domain Local groups using ADPW in order to add the Target objects to the Source Domain Local groups?

Please answer and explain.

  • Have patience. We have full time jobs and this is not it. We also have lives. 

  • To recap, the Server with the resources secured with source domain local groups has been moved to the target domain, do you need to update the membership of the source domain local groups? 

    NO. 

    Forgetting about migration for a minute. 

    1. If you were to change the domain membership of a server using source domain local groups to secure the resource, to the target domain, all domain local groups with display as SIDS for the resources. 
    2. If you created matching named domain local groups in the target domain, they will still be displayed as sids on the resources. (This is the same as Migration without sidhistory)
    3. Now if you migrate the source domain local groups sids to the target domain Sidhistory, the groups would display as the target domain local group because of Sidhistory. 
    4. Now move it back to the source domain and all permissions now resolve as the source domain local groups.

    So ADPW has several functions. 

    • Updated Permissions Local Group Membership
    • Remove Sid History

    support.quest.com/.../11

    This is from the next page of the documentation

    Generally, if you want the new users to have the same level of access as the old users after Active Directory migration, you need to run Active Directory Processing Wizard (ADPW) in all domains where the old users had specifically configured access rights. This is as good as obligatory in most Active Directory migrations, at least for the initial transition period.

    The following are examples of activities that you may need to perform in ADPW to restore users' resource access levels:

    Add target users to source groups
    This is the most common operation for ADPW.

    So in your case, the server has been moved to the target domain, the source domain local groups no longer control access to the target joined server. 

  • Thank you for providing the details. 

    1- If you were to change the domain membership of a server using source domain local groups to secure the resource, to the target domain, all domain local groups with display as SIDS for the resources.

    Comment:  What if source domain controllers still present in source domain in co-existence scenario, then I think if groups in ACL will resolve to name of source domain local group. It will show unresolvable Sid only if actual Source domain local group is removed from source domain OR source domain decommissioned or source domain turned off. 

    2- If you created matching named domain local groups in the target domain, they will still be displayed as sids on the resources. (This is the same as Migration without sidhistory)

    Comment: Since domain portion of Target domain local group is different from domain portion of source domain local group, it should resolve to nsame of soure domain local group in ACL (same condition as mentioned above).

    3- Now if you migrate the source domain local groups sids to the target domain Sidhistory, the groups would display as the target domain local group because of Sidhistory.

    Comment: It will show Target domain local group in ACL only if migration is completed and source domain controllers are turned off.  Then all migrated users have still have access.

    4- Now move it back to the source domain and all permissions now resolve as the source domain local groups.

    Comment: Groups in ACL will resolved to actual name of source domain local group, because source domain local group still exist in source domain as original source object (as they don't have sidhistory).

    Kindly answer and explain specific to my comments.

    Thanks,

    Ryan

  • My explanation were with a one-way trust. Source is trusting, target being trusted. This is the standard minimum trust for a migration functionality when migrating Sid history. The trust would have to be a two-way for your comment to #1 to be true. Comment #2 is 1/2 correct, the reason why it does not resolve to the target same name group. But with a one-way trust the sid would not resolve to the source. Comment #3 is wrong, it will resolve to target group with the sidhistory value that matches. A two-way trust or one-way trust with the target being trusting and the source being trusted. Comment #4 is mostly right,  sidhistory plays no role is the resolution of the Sid to name in this example.

  • Standard minimum trust for a migration functionality when migrating Sid history. 

    Question: Are you talking about 1 way forest trust or 1 way external trust?

    Now if you migrate the source domain local groups sids to the target domain Sidhistory, the groups would display as the target domain local group because of Sidhistory.

    Follow-up on your comment. This is interesting

    Question: In my environment, both source domain and target domain exist with 2 way trust. Resources are secured with only Source domain local groups. Source domain local groups migrated to target domain along with sidhistory. Scope of Migrated group is "Global Group" in target domain. Server has also been moved from source domain to target domain.

    But when I checked resource ACL in target domain, it still shows source domain local group name instead of target equivalent migrated global group name. They why it does does not resolve to target group because of sidhistory?

    What is the reason? Please explain. 

  • Standard minimum trust for a migration functionality when migrating Sid history. 

    Question: Are you talking about 1 way forest trust or 1 way external trust?

    This questions makes no sense. There is no difference between the two as it relates to this, in this context. 

    Question: In my environment, both source domain and target domain exist with 2 way trust. Resources are secured with only Source domain local groups. Source domain local groups migrated to target domain along with sidhistory. Scope of Migrated group is "Global Group" in target domain. Server has also been moved from source domain to target domain.

    But when I checked resource ACL in target domain, it still shows source domain local group name instead of target equivalent migrated global group name. They why it does does not resolve to target group because of sidhistory?

    It depends on what host you are checking the permissions from. If it is a source joined host, they will resolve to the source. If it is from the servers console hosting the file share, it will resolve to the target. Permissions management sid resolution is tied to the host and domain membership of that host that you are viewing the permission from. It is always best to view these from the console of the host and not from a remote host. 

    Forgetting about migration for a minute. 

    1. If you were to change the domain membership of a server using source domain local groups to secure the resource, to the target domain, all domain local groups with display as SIDS for the resources. 
    2. If you created matching named domain local groups in the target domain, they will still be displayed as sids on the resources. (This is the same as Migration without sidhistory)
    3. Now if you migrate the source domain local groups sids to the target domain Sidhistory, the groups would display as the target domain local group because of Sidhistory. 
    4. Now move it back to the source domain and all permissions now resolve as the source domain local groups.

    This will be a demo of the above

    There is a source and target domain. There is a one-way trust. Source2010 is trusting of Target2016

    The permissions on the source joined member server (this server is named membersever)

    Now the permissions to the same folder after the server has been moved to the target domain. Notice that the SIDs do not resolve? They do not resolve because there is NOT a trust this direction. 

    If we migrate the users and groups to the target with sid history, still with the same one way trust and we look at the permission on the target joined member server sales data folder, we see the following

     

  • Thank you for your response.

    In my environment, all resources hosted on NAS devices(Source Domain) were moved to Isilon NAS (Target Domain). Post migration of resources, source NAS devices were decommissioned. However, there is CNAME record of source NAS devices added in DNS which points to target NAS. So I can access resources (share/folder) by using UNC to \\Source-NAS-server\Share as well as \\Target-NAS-server\Share from target domain joined member server (2012 R2).

    • It should be able to resolve to target equivalent migrated Global Groups names if I'm accessing from target domain joined remote host whether accessing via RDP or via Console (Host / Server) OR via UNC to target domain joined server hosting the file share. Correct? Please confirm.
    • But in both cases, I see only source domain local groups name instead of target equivalent migrated global groups name in resource ACL. They why it does does not resolve to target group because of sidhistory in spite of "accessing via UNC from Target Domain joined remote member server"?

    Please explain and provide reason.

    Question: So Sid resolution to Security name depends on : Direction of Trust as well as domain membership of the host  from where permission is checked? does it also depend on domain membership of servers where resource is hosted? How does Sid resolution to Security Principal name works if Server membership has been changed from source domain to target domain? Please explain.

    Looking forward to prompt reply.

  • Former Member
    0 Former Member over 3 years ago in reply to wagner ryan my

    Good day,  I'd recommend at this point that if this issue is still ongoing with one of our products, to open a support ticket. this way a support engineer can assist you by taking a deeper look than possible in the community. especially avoiding to divulge any specifics about your work environment and in a more timely and expedite manner https://support.quest.com/contact-support 

    Our engineers will be waiting for your request. 

    Thank you

  • Former Member

    This is not something which is impacting my production environment. I don't think it requires to open support ticket. I have submitted valid question related to understanding the post migration state of servers. If my question is technically explained then I'm good to go.