question

brajkishorSingh-1326 avatar image
0 Votes"
brajkishorSingh-1326 asked GaryReynolds commented

unable to get/retrive membership info in cross domain scenerio

Hello
We are experience issue with membership info not retrieving within cross domain environment
let me explain more about it:-
for exam-user1 reside in domain A & its part of some more security group. When we trying to search user from Domain B unable to get complete membership info of user1,Only i can see user is part of domain user only

Note-Transitive trust (Forest wise) already setup
All groups created in domain A & have the type Global /security
Issue with few of user only rest users residing into same OU & we can see the membership info from domain B

azure-active-directorywindows-active-directory
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

GaryReynolds avatar image
0 Votes"
GaryReynolds answered GaryReynolds commented

Hi @brajkishorSingh-1326

Yes this is expected behaviour, if you are viewing the user's membership with ADUC. The membership of a user is stored in the memberof attribute, as DN based on the domain A name context. When domain B try to resolve the members it will pass the DN to the domain B to be resolved. However, while you have a trust, this doesn't provide an LDAP referral, so the domain B domain controllers will not be able to resolve the DN and will return the following error:

 Error: (0x0A) A referral was returned from the server, Server Error: 0000202B: RefErr: DSID-03100838, data 0, 1 access points
     ref 1: 'w2k12.local', Ext Error: (8235) A referral was returned from the server.
    
 Referral: ldap://w2k12.local/DC=w2k12,dc=local

So the membership can't be displayed. The reason why the domain users is displayed, is because this is the primary group, which stored in primaryGroupID attribute, and this is stored as a RID (part of the SID) which can be resolved by the SIDtoName API, as it will use the trust to resolve the name.

Gary.

· 4
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Hi @GaryReynolds-8098 Thanks for your response Appreciate your help

We have replicate the same scenario on our testing environment & we can get the user membership in cross domain scenario. Would you pls test this with your testing environment if possible might be we will get more clarity

Does cross domain delegation will work here ?
For exam-IF we can provide delegation on OU wise or Domain wise for some of the users does this work ?

I can get the members info with below command from Domain A to domain B but not from ADUC

Get-ADUser -Identity username -Properties * -server domainname |select-object memberof

Regards

0 Votes 0 ·

Hi,

Yes the get-aduser command will work, as it doesn't try to process the the values in the memberof attribute, the same would be true if you use LDP or another ldap client to read the attribute. ADUC however do additional processing of the returned values to provide more meaningful information for the user, probably using an ASQ query or something similar to get display name / canonical name, etc. and it this processing that fails with the referral error I mentioned above. The AD property dialog in NetTools uses the same processing logic and it fails the same way.

Gary.

0 Votes 0 ·

Thanks Gary for your input

Would liketo inform you issue has been resolved after providing cross domain delegation with parameter "Read group membership"

Thanks

0 Votes 0 ·
Show more comments
LimitlessTechnology-2700 avatar image
0 Votes"
LimitlessTechnology-2700 answered GaryReynolds commented

Hello BrajkishorSingh,

Thank you for your question and reaching out.

In order to retrieve all groups user belongs to you have to query one Global Catalog in each domain of the entire forest for the user's membership (user's tokenGroups attribute will return you nested groups as well), then remove duplicated groups.

Be aware that Active Directory cannot return more than 5K values of a single attribute in one query. If a user belongs to more than 10K groups, then AD will return you only first 5K. You have to use technique called range retrieval to query for membership in that case.

You won't be able to search for group members in a different forest by using the memberOf property because it's just not set when you add a user to a domain local group that belongs to another forest.

Instead, AD creates an object of type ForeignSecurityPrincipal in the domain of the group that has the target user's SID as its CN. Then the DN of that object gets added to the group's members property.



--If the reply is helpful, please Upvote and Accept as answer--

· 2
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thanks for your input

Would like to inform you issue has been resolved after providing cross domain delegation with parameter "Read group membership"

Thanks


0 Votes 0 ·

Hi @LimitlessTechnology-2700 ,

A couple of comments about the details provided:

In order to retrieve all groups user belongs to you have to query one Global Catalog in each domain of the entire forest for the user's membership (user's tokenGroups attribute will return you nested groups as well), then remove duplicated groups.

The TokenGroup attribute is not replicated to the GC. You have to queries the user object in the user's domain context to read the TokenGroup attribute. The TokenGroup attribute contains the SIDs of all the groups that the user is a member of, this includes the SIDs of the groups from trusted domains via the ForeignSecurityPrincipals.

Be aware that Active Directory cannot return more than 5K values of a single attribute in one query. If a user belongs to more than 10K groups, then AD will return you only first 5K. You have to use technique called range retrieval to query for membership in that case.

The 5000 is not a fixed limit, it's defined by the MavValRange value in the lDAPAdminLimits attributes of the Query Policy object. I believe 5000 was the default for W2008, however, it appears that this has now been reduced to 1500 in later versions. Most range aware AD\LDAP client hide this functionality and display the members as a continuous list.

Gary.


0 Votes 0 ·