I'm working with two domains where **Domain1** has a one-way trust relationship with **Domain2**. This means that while **Domain2** trusts **Domain1**, **Domain1** does not trust **Domain2**. I have a situation where **Domain2**'s **builtinAdministrators** group contains some members from **Domain1**. However, since **Domain2** isn't trusted by **Domain1**, those members appear as foreign objects, which is causing issues when I try to use the command `Get-ADGroupMember` to retrieve the members of the Administrators group from **Domain2**. It throws an internal error instead.
Interestingly, I can access and see the members of the Administrators group from **Domain1** using the ADUC console without any issues, while **Domain2** shows the foreign security principal SIDs as expected due to the trust. I have admin credentials for both domains, so I'm wondering if there's a way to compile a list of those group members despite these trust limitations. Any insights would be greatly appreciated!
2 Answers
Absolutely, you can work around this issue! The error you're experiencing is due to how trusts and name resolution work. Since there's a one-way trust from **Domain1** to **Domain2**, **Domain2** can't automatically resolve those foreign security principals on its own when you use `Get-ADGroupMember` directly from it. Instead, try querying the raw `member` attribute of the group in **Domain2**. After that, pull the SIDs of these foreign objects and resolve them manually in **Domain1** using your admin credentials there. This way, you'll effectively bypass the trust issue!
Great advice! Just to add to that, when using PowerShell, you can use the `Get-ADDomain` command to identify your search base for querying the members based on their SID. Then, use `Get-ADObject` to extract their information in **Domain1**. Your approach should work well to compile the list you need!
Exactly! That method will allow you to see the details of those members effectively. Just make sure your scripts are well-structured to handle any errors or exceptions that might come up during the query.
That sounds like a solid plan! Just make sure to query the `member` attribute directly and handle the SIDs carefully; there’s a bit of scripting you’ll have to do, but I’m sure you can handle it!