Access home drives and shares using migrated target domain account from source workstation & Resource process via Replace

Hello IT Engineers,

Q1: Does it make any difference if migrate target domain account (with sidhistory) try to access home drives and shares from source domain joined workstation? Does it have anything to do with domain membership of server where home drives and shares are hosted? Will there be any difference with regards to Sid/Sidhistory of users and groups if login from source domain joined workstation? Basically, what will be the difference between accessing home drives, shares from source domain joined workstation AND accessing home drives, shares from target domain joined workstation?

Q2: Do I still have to run cleanup processing job in RUM post resource process via "Replace"?

Looking forward to answer and explanation of above mentioned questions.

Thanks in advance!

Top Replies

  • You do know that there are three question marks in Q1? 

    Does it make any difference if migrate target domain account (with sidhistory) try to access home drives and shares from source domain joined workstation?

    Target user logged in to source joined workstation, accessing home drive and shared resources? Depends where serve is joined that hosts the home drive and other shares. If the server is a source member the trust and EnableSIDhistory/Quarantine settings matter. if the server is a member of the target, it does not. 

    Does it have anything to do with domain membership of server where home drives and shares are hosted?


    Yes, see above

    Will there be any difference with regards to Sid/Sidhistory of users and groups if login from source domain joined workstation?


    It is more about the resource hosting server domain membership and the trust. 

    Basically, what will be the difference between accessing home drives, shares from source domain joined workstation AND accessing home drives, shares from target domain joined workstation?

    It is all about the membership of the resource hosting server, the related trust and trust settings.. The ability to logon to e source joined workstation as the target means you have the right direction for a one-way trust to support sidhistory access to source joined servers. If access is not working, you have an issue with the trust and EnableSIDhistory/Quarantine settings of the trust. 

    Do I still have to run cleanup processing job in RUM post resource process via "Replace"?

    You should ALWAYS update the permissions to the migrated target objects. How you do it, Append today, Clean up tomorrow or just a replace tomorrow is up to you. The end results are the same.

  • As I understand correctly, workstation domain membership criteria doesn't matter for target account. As long as there is trust relationship from source domain to target domain and sidhistory is enabled in trust settings, access to source domain joined resource server should be working for target domain account. Am I right?

    Source domain joined workstation tries to authenticate the target user to the source domain controller it has it's secure channel connected to. Since target user account is located in trusted domain, then source domain controller connects to the trusted domain controller it has a secure channel with. Finally, authentication took place in target domain. So it means trust is not only required for authentication and authorization traffic to flow but also it is required for using secure channel connected o trusted domain controller. 

    Q1: I mean that is if trust had been missing, then source domain controller would not have been able to connect to trusted domain controller. Am I right?

    Q2: What if there is one-way trust from source domain to target domain and source user tries to login on target domain joined workstation, then will target domain controller still be able to use secure channel to connect source domain controller?

    Q3: If answer of Q2 is yes, then does it mean that using secure channel does not depend on direction of trust? Does it also mean that is secure channel traffic for connecting to domain controller can flow regardless of trust direction?

    Q4: So if there is one-way trust from source domain to target domain and source user tries to login on target domain joined workstation, then trust and EnableSIDhistory/Quarantine settings does not matter as long as resource server is source domain joined. Am I right? Could you please explain the reason?

    Q5: So if there is one-way trust from source domain to target domain and target user tries to login on source domain joined workstation, you said then trust and EnableSIDhistory/Quarantine settings does not matter as long as resource server is target domain joined. Could you please explain the reason?

    Q6: As per the scenario, it also means that authentication traffic can flow regardless of trust direction. But authorization traffic is always opposite to trust direction. Am I right?

    Q7: As I understand correctly if I update permissions to the migrated target objects by replacing source object ACEs with migrated target ACEs, then there is no need to run cleanup processing job in RUM. Am I right?

    Looking forward to answer and explanation of above mentioned questions.

    Thanks in advance!

  • As I understand correctly, workstation domain membership criteria doesn't matter for target account. As long as there is trust relationship from source domain to target domain and sidhistory is enabled in trust settings, access to source domain joined resource server should be working for target domain account. Am I right?

    Workstation membership always maters, but this in uses case, the focus is on the the server hosting the resource, the access control list. 

    So it means trust is not only required for authentication and authorization traffic to flow but also it is required for using secure channel connected o trusted domain controller. 

    I would not state it this way as authentication and authorization is the WHAT and the trusts and secure channels is the HOW. You cant have the WHAT without the HOW. So it is just the trust allows for Authentication and Authorization (with or without sid history). 

    Q1: I mean that is if trust had been missing, then source domain controller would not have been able to connect to trusted domain controller. Am I right?

    You are correct. Authentication of a Target user to a source workstation would have failed. So there would be no authorization to the workstation and later to the resource. 

    Q2: What if there is one-way trust from source domain to target domain and source user tries to login on target domain joined workstation, then will target domain controller still be able to use secure channel to connect source domain controller?

    When talking trust, how you stated it is ambiguous, one-way trust from source domain to target domain. I have to assume since we are talking migration and Sid history that the trusting domain is the source and the trusted domain is the target. If that is the case and direction of the trust, then NO a source user can not authenticate to a target joined workstation. 

    When talking about trusts, a Trusted domain is where accounts can come from for authentication or authorization and the trusting domain is where they can be used. 

    Q3: If answer of Q2 is yes, then does it mean that using secure channel does not depend on direction of trust? Does it also mean that is secure channel traffic for connecting to domain controller can flow regardless of trust direction?

    It is no. Direction of the trust matters and the secure channels flow in that direction ONLY. 

    Q4: So if there is one-way trust from source domain to target domain and source user tries to login on target domain joined workstation, then trust and EnableSIDhistory/Quarantine settings does not matter as long as resource server is source domain joined. Am I right? Could you please explain the reason?

    See Q2 and Q3

    Q5: So if there is one-way trust from source domain to target domain and target user tries to login on source domain joined workstation, you said then trust and EnableSIDhistory/Quarantine settings does not matter as long as resource server is target domain joined. Could you please explain the reason?

    You misunderstand the context of that comment. Without the trust, a target user could not logon to a source workstation.  So the trust play a role there. It is the authentication and authorization of the target user accessing a resource on a target joined server. The trust and it's setting play no role for the target joined member servers ability to authenticate and authorize access to a hosted resource. 

    Q6: As per the scenario, it also means that authentication traffic can flow regardless of trust direction. But authorization traffic is always opposite to trust direction. Am I right?

    No, you are wrong, see Q2 and Q3

    Q7: As I understand correctly if I update permissions to the migrated target objects by replacing source object ACEs with migrated target ACEs, then there is no need to run cleanup processing job in RUM. Am I right?

    Yes, if you replace the source object access control entries with target access control entries you will not have any source access control entries to clean up. However timing matters, if you replace before the source users are migrated, they will lose access to the resources. This is why we normally append the target permission and clean it up at the end of the migration.  

  • Workstation membership always maters

    Could you please explain with examples when, where, why and how workstation membership matters?

  • Hi Jeff,

    Waiting for reply on my question.

  • How about you explain to be in detail why the domain the workstation is a member does not matter? 

    Everything play a role. So it depends what your focus is as to what pieces matter in this context.