Squarespace’s all-in-one platform gives you everything you need to express yourself creatively online, whether it is with a domain, website, or online store. Get started with your free trial today, and when ready, take 10% off your first purchase with offer code 'EXPERTS'.
adding user in one domain to a group in a different domain in AD
We have two domains that were previously two different companies. I have been told by level 3 engineering that "a sufficient trust has been built". I was asked to put a user in what I will call domain ABC.COM into a group in domain XYZ.COM. I am logged into my workstation into domain XYZ.COM and have ADUC up. I can connect to domain ABC.COM and XYZ.COM, but when I call up a group I need in ABC.COM I cannot see the user I need in XYZ.COM. It is like I need to be at the FORREST level not the DOMAIN level. I know I am an ENTERPRISE and DOMAIN ADMIN. How can I verify if the proper trust is really built and how can I get up one level higher so I can add users in one domain to a group in the other? We are on FORREST LEVEL 2003
Asked:
Who is Participating?
Are you trying the add an XYZ user to a group in ABC domain ? What is the group type ?
http://www.shariqsheikh.com/blog/index.php/200909/group-nesting-reference-chart/
http://www.shariqsheikh.com/blog/index.php/200909/group-nesting-reference-chart/
If they were previously entirely separate then surely they are two entirely separate forests?
And if that is the case, the only type of group you can add users in the remote domain to is (Domain) Local.
Chris
Yup, when trying to make sense of the naming of "scopes" with regards to their nesting restrictions,,,take the scope as in where it can be ACL'd on a resource...the acceptance of different objects from trusted domain is different I try explaining somewhat in my blog.
Domain Local - Can accept trusted users but can only be ACL'd on a local resource.
Global Group - Can be ACL'd on a trusted resource but can't accept users from the trusted domain.
Domain Local - Can accept trusted users but can only be ACL'd on a local resource.
Global Group - Can be ACL'd on a trusted resource but can't accept users from the trusted domain.
Yes I verified they are two forests so I guess I am going to be limited to Domain locals.
Couldnt i build a doman local on domain abc then then add the Global groups in need ABC to that local group. Then make the user in XYZ a member of the domain local in ABC?
Couldnt i build a doman local on domain abc then then add the Global groups in need ABC to that local group. Then make the user in XYZ a member of the domain local in ABC?
I am sorry I didn't understand "Couldnt i build a doman local on domain abc then then add the Global groups in need ABC to that local group. Then make the user in XYZ a member of the domain local in ABC?"
What is your end goal ?
What is your end goal ?
Ok, as of now and all I have learned since this started. We have two domains ABC and XYZ. They were previous companies that merged. I did verify they are two different Forests that are trusted. I was told to pull user "smith" from doman XYZ and set her up in ABC. I first considered the migration tool, but was told the users in XYZ have so much bogus info in them I should start fresh. So I created "smith" in ABC. I now want to add ABC/smith to 3 global groups in XYZ. Then I will log her in and start configuring her applications and make adjustments as needed. So...will it be possible to create a Domain local group "trustgroup" in XYZ, add the 3 global groups in XYZ to it. Then add ABC/smith to "trustgroup" domain local that is in XYZ?...thanks for your patience
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
All Courses
From novice to tech pro — start learning today.
-
Course of the Month10 days, 17 hours left to enrollMonitoring and Operating a Private Cloud with System Center 2012 R2 273 lessons
You'd have to use a Local group to secure whatever resource, then add either Global groups or foreign security principals (aka ABC users) to that.
I wouldn't turn away from ADMT despite what they've said, it would have made this task a lot easier, even for one user at a time. This is because it can be told to write the SID for the user from XYZ into the SID History in ABC (as part of the migration). Then you can continue to control access using the account XYZ (courtesy of the matching SID / SID History) until you're ready to ditch XYZ entirely (and provided you disable SID filtering on the trust).
It makes the user-end of a migration a truck-load easier as well, ADMT can rewrite the user profile when you migrate a computer.
Chris