Hi,

I have two forests and I created a bi-directional forest trust. In order to prepare for admt I tried to add some user from the one forest A to a domain-local security group forest B. That seems to be working, as the user is listed in the Groups "members" UI in forest B.

But if you go to the user object in forest A the Group Membership is not listed, and you can also not see that when checking the memberof property. whoami /Groups also does not Show the Group Membership. For a Domain admin in forest A, that is also a member of the builtin/Administrators in forest B, that results in "you must be a member of Domain admins", and permission is denied if you tried to migrate SID, even if you grant migrate SID history explicitely.

So I have two problems
why cant I find the Group in the memberof? (when checking via GUI or get-adprincipalgroupmembership)
Is there any way to migrate the SIDHistory if you are unable to put the account to builtin/Administrators?

What did I miss? Please help .

Thanks in advance,

Martin 

• Edited by Gudel, Martin Friday, August 28, 2015 7:24 AM

Hi Jedi,

thanks for your response. I wonder for that proposal as a foreign security principal is unable to be added to an universal group - so it's not possible to put a user from a trusted domain as a member to an universal group
( see also https://technet.microsoft.com/en-us/library/cc755692(v=ws.10).aspx )

While saying that, of course, the user is a member of the Builtin/Administrators group of the forest root domain, as mentioned before. I think that's the recommended way as also told by your first TechNet cite.

Any ideas?

Regards,

Martin

 

The information below was taken from the link below:

http://www.microsoft.com/en-us/download/details.aspx?id=19188

You can not migrate accounts, groups, etc. that are builtin. The SIDs that are being migrated must be unique.

To protect your system against the problem of open sets when you restructure Active Directory domains within a forest, migrate groups before you migrate the user accounts that are members of those groups. If you migrate groups simultaneously with migrating users, you might not migrate nested groups, which creates an open set.

In addition, follow these guidelines for migrating groups:

• Migrate universal groups first, followed by global groups.
• Migrate domain local groups when you migrate the resources (domain controllers and member servers) on which they are used to assign permissions.
• You can choose to migrate computer local groups when you migrate the computer later in the restructure process.

Migrate universal groups, without migrating users who are members of these groups at the same time, from the source domain to the target domain. Migrating universal groups without the users helps to protect against the problem of open sets. The security identifier (SID) history allows group members to continue to have access to resources based on universal group membership. When you migrate universal groups to the target domain, they cease to exist in the source domain.

Note

If you are migrating a small number of universal groups, you can migrate universal groups at the same time that you migrate global groups.

You can migrate universal groups by using the Active Directory Migration Tool (ADMT) snap-in, the ADMT command-line option, or a script.

To preserve the memberships of global groups, you must migrate global groups before you migrate users.