Incomplete results when querying Active Directory for group members in a situation with trust relationships

Question

We are attempting to query Active Directory for a list of all machines that are members of a group, along with information like OperatingSystem attributes. We can't get results for every member of the group.

Environment details:

Multiple domain controllers, running Windows Server 2003 and 2008 R2.
Multiple domains, with a trust relationship between domains.
Running the AD queries from a Windows Server 2008 R2 machine.
The account querying AD is "a local admin account, member of the domain, with admin privs on that server."
We've been informed that some machines "are members of the group via a trust relationship."

Our current test group, "Group-99", has two machines: FOO10 and FOO11.

When we query for group members, we receive the expected result, a list of all machines in the group:

PS > dsquery group -name "Group-99" | dsget group -members

"CN=FOO10,OU=Domain Controllers,DC=activedirdev,DC=widgetco,DC=com"
"CN=FOO11,OU=Portland,OU=Domain Controllers,DC=activedirdev,DC=widgetco,DC=com"

We then query for DNSHostName and OperatingSystem, but can only receive results for one of the two machines:

PS > dsquery * -filter "(&(objectClass=Computer)(objectCategory=Computer)(sAMAccountName=FOO11$))" -attr sAMAccountName operatingSystem
sAMAccountName    operatingSystem
FOO11$            Windows Server 2008 R2 Standard

PS > dsquery * -filter "(&(objectClass=Computer)(objectCategory=Computer)(sAMAccountName=FOO10$))" -attr sAMAccountName operatingSystem
PS >

None of us are Active Directory wizards so we are unsure where the problem lies. Adjusting the Active Directory setup is not possible.

Can you help us figure out how to get the information we need, or if it's even possible to get it?

Follow-up clarification: Our perfect result would be a way to issue one query that will return results for all group members, no matter what domain they are on. Something like:

PS > dsquery (stuff)
CN        operatingSystem
FOO10     Windows Server 2008 R2 Standard
FOO11     Windows Server 2003

Well, are you sure that's actually its SAMaccountname? It might be different from the CN for some reason... can't hurt to check. — HopelessN00b, Feb 21 '14 at 21:39
A great idea, but unfortunately we've tried querying it other ways (e.g. using memberOf) and have the same issue. — Ale Exc, Feb 21 '14 at 22:59
@What about using the search in a GUI like ADSIedit or ADUC? — HopelessN00b, Feb 22 '14 at 05:11

score 0 · Accepted Answer · answered Feb 21 '14 at 22:21

0

The object you are querying looks like it exists in another domain. When you run DSQuery without specifying the server or domain you want to contact, you will automatically bind to the domain you logged into. This object may be in another domain.

To get the missing object, try

dsquery * -filter "(&(objectClass=Computer)(objectCategory=Computer)(sAMAccountName=FOO10$))" -attr sAMAccountName operatingSystem -d activedirdev.widgetco.com

Ref: http://technet.microsoft.com/en-us/library/cc754232.aspx

answered Feb 21 '14 at 22:21

Ryan Newington

358
1
6

Thanks! Do we need to explicitly bind to each domain controller, then, rather than relying on referrals and the trust relationship? We tried using -r to chase referrals while bound to Portland, but that didn't turn up FOO10. – Ale Exc Feb 21 '14 at 23:06
-r isnt working because there are no referrals to chase in this example. You are asking for an object called FOO10$ in the domain you are bound to. If you specify the full DN of the object (in a domain naming context that is foreign to this domain) then that's when a referral event can take place. – Ryan Newington Feb 21 '14 at 23:52
To test if referrals are working: dsquery * "CN=FOO10,OU=Domain Controllers,DC=activedirdev,DC=widgetco,DC=com" -r -attr sAMAccountName operatingSystem – Ryan Newington Feb 22 '14 at 00:02
Thanks! I think we had a misunderstanding of what referral chasing encompassed. We've switched to explicitly specifying the domain. – Ale Exc Mar 05 '14 at 18:11

score 0 · Answer 2 · answered Feb 21 '14 at 22:40

As already noted by HopelessN00b, having a commonName of FOO10 does not necessarily mean that the sAMAccountName is FOO10$ (although it's very likely).

The find out whether this is the case, retrieve the object directly instead of searching for it:

dsget computer "CN=FOO10,OU=Domain Controllers,DC=activedirdev,DC=widgetco,DC=com" -samid

Incomplete results when querying Active Directory for group members in a situation with trust relationships

2 Answers2