none
Minimum permissions needed for ADMT 3.2 when doing an Interforest migration with SID History

    Question

  • Hi

    I am preparing for an Interforest migration using ADMT 3.2. I have it all configured both in a test lab and in production. In the target domain I have administrative credentials (Domain Admin) but in the source domain I only have Full Control Permissions on the OU structure I am going to migrate.

    In my test lab, I am only able to migrate users and groups with SID History if the migration account has administrative credentials (Domain Admin) in both source and target domain. If the migration account has Administrative credentials (Domain Admin) in target domain and full controll permission on the OU structure in the source domain I get the following error in ADMT 3.2 when I select to Migrate with SIDs, "Could not verify auditing and TcpipClientSupport on domains. Will not be able migrate Sid's. Access is denied."

    I have read about the permission requirement in the ADMT Migration Guide page 49-53 and it states that you need Domain Admin credentials in both source and target domain but I was wondering if there is any way to delegate the required permission without being added to the Domain Admins group in the source domain?

    Kind regards

    Flagzz

    Tuesday, August 30, 2011 12:21 PM

Answers

  • Hi,

    AFAIK, that is not possible. You need domain admins. Because diffrent domain means there is a security boundary.

    That is hard coded by MS.


    Best regards Biswajit Biswas Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. MCP 2003,MCSA 2003, MCSA:M 2003, CCNA, MCTS, Enterprise Admin
    • Marked as answer by Flagzz Tuesday, August 30, 2011 5:59 PM
    Tuesday, August 30, 2011 1:10 PM
  • Here are permission details from ADMT user guide. I don’t believe you can delete the permission in the source domain.  The ADMT account needs to read domain, auditing configuration etc 

    Migration object

    Credentials necessary in source domain

    Credentials necessary in target domain

    User/managed service account/group without SID history

    Delegated Read all user information permission on the user OU or group OU and domain administrator credential

    Delegated Create, delete, and manage user accounts, Create, delete, and manage groups, and Modify the membership of a group for the user OU or the group OU and local administrator on the computer where ADMT is installed

    User/managed service account/group with SID history

    Delegated Read all user information permission on the user OU or group OU and domain administrator credential

    Delegated permission on the user OU or the group OU, extended permission to migrate SID history, and local administrator on the computer on which ADMT is installed

     


    Santhosh Sivarajan | MCTS, MCSE (W2K3/W2K/NT4), MCSA (W2K3/W2K/MSG), CCNA, Network+| Houston, TX
    Blogs - http://blogs.sivarajan.com/

    FaceBook Twitter LinkedIn

    This posting is provided AS IS with no warranties,and confers no rights
    • Marked as answer by Flagzz Tuesday, August 30, 2011 5:59 PM
    Tuesday, August 30, 2011 2:41 PM

All replies

  • Hi,

    AFAIK, that is not possible. You need domain admins. Because diffrent domain means there is a security boundary.

    That is hard coded by MS.


    Best regards Biswajit Biswas Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. MCP 2003,MCSA 2003, MCSA:M 2003, CCNA, MCTS, Enterprise Admin
    • Marked as answer by Flagzz Tuesday, August 30, 2011 5:59 PM
    Tuesday, August 30, 2011 1:10 PM
  • Here are permission details from ADMT user guide. I don’t believe you can delete the permission in the source domain.  The ADMT account needs to read domain, auditing configuration etc 

    Migration object

    Credentials necessary in source domain

    Credentials necessary in target domain

    User/managed service account/group without SID history

    Delegated Read all user information permission on the user OU or group OU and domain administrator credential

    Delegated Create, delete, and manage user accounts, Create, delete, and manage groups, and Modify the membership of a group for the user OU or the group OU and local administrator on the computer where ADMT is installed

    User/managed service account/group with SID history

    Delegated Read all user information permission on the user OU or group OU and domain administrator credential

    Delegated permission on the user OU or the group OU, extended permission to migrate SID history, and local administrator on the computer on which ADMT is installed

     


    Santhosh Sivarajan | MCTS, MCSE (W2K3/W2K/NT4), MCSA (W2K3/W2K/MSG), CCNA, Network+| Houston, TX
    Blogs - http://blogs.sivarajan.com/

    FaceBook Twitter LinkedIn

    This posting is provided AS IS with no warranties,and confers no rights
    • Marked as answer by Flagzz Tuesday, August 30, 2011 5:59 PM
    Tuesday, August 30, 2011 2:41 PM
  • Hi Biswajit and Santhosh

    Thanks for your replies. Yeah I know about the requirements being Domain Admin in the source domain but I have a hard time convincing the people in the source domain that I (ADMT) require Domain Admin permissions.

    So I guess I was hoping for a kind og a miracle :)

    Kind regards

    Flagzz

    Tuesday, August 30, 2011 5:58 PM
  • HI,

      I'm in the same boat how did you go with  this?

    Thursday, March 15, 2012 7:39 PM
  • I might be crazy, but I think I just got this working *without* adding them to domain admins in the source domain.  Essentially the same changes are made to both domains.

    In the target domain I created a group called GRP_Delegated_Account_Migration and put my admin_migrate account in there.

    Permissions:

    Source Domain

    • Full add/remove user objects and full read/write all user object properties just to TARGET\GRP_Delegated_Account_Migration for all account OU's that I wanted them to migrate accounts *from*.
    • Delegated Migrate SID history on the base domain object in the source domain

    Target Domain

    • Full add/remove user objects and full read/write all user object properties just to TARGET\GRP_Delegated_Account_Migration for all account OU's that I wanted them to migrate accounts *to*.
    • Delegated Migrate SID history on the base domain object in the target domain

    I verified that the sidHistory had their old SID after migration.

    Matt




    • Edited by m_a_tt Monday, September 24, 2012 9:25 PM
    Monday, September 24, 2012 8:43 PM
  • I might be crazy, but I think I just got this working *without* adding them to domain admins in the source domain.  Essentially the same changes are made to both domains.

    In the target domain I created a group called GRP_Delegated_Account_Migration and put my admin_migrate account in there.

    Permissions:

    Source Domain

    • Full add/remove user objects and full read/write all user object properties just to TARGET\GRP_Delegated_Account_Migration for all account OU's that I wanted them to migrate accounts *from*.
    • Delegated Migrate SID history on the base domain object in the source domain

    Target Domain

    • Full add/remove user objects and full read/write all user object properties just to TARGET\GRP_Delegated_Account_Migration for all account OU's that I wanted them to migrate accounts *to*.
    • Delegated Migrate SID history on the base domain object in the target domain

    I verified that the sidHistory had their old SID after migration.

    Matt




    Hi Matt,

    Do you think or did this really work? I have the same problem here and convincing people to get domain admin is a true problem. If the account requires admin credentials in the server where ADMT is installed AND full access to the specific OU's, then this is much easier to get.

    Tuesday, October 30, 2012 12:24 PM
  • It did work.  I just said I *think* in case I inadvertently missed something.  Usually MS will give you a workaround for these types of things but they seem so clear that "DA is required" I thought I must have done something wrong.  We were able to migrate without giving out DA using the delegated perms described above.  This allowed a helpdesk level person a few time zones away (with appropriate screenshots) to move a lot of users which saved our local staff a lot of time.  As always, test in a lab, but those delegations worked for me.
    • Edited by m_a_tt Tuesday, July 16, 2013 9:14 PM more info
    Tuesday, July 16, 2013 9:13 PM