How to detect and prevent circular references in Unboundid LDAP SDK for java?

Question

I am using Unboundid LDAP SDK for java to connect to AD & perform operations on AD.

I have nested assignments of group under group.

Like for eg:

Group-1 has member Group-2 .

Group-2 has member Group-3 .

Now it is possible that Group-3 has member Group-1 . This will lead to infinite loop due to circular reference.

Also, I have n level of depth in AD for nested members so I am not sure how can I detect circular reference while making a group member of another group.

I did some research on google in order to find solution, and came across this thing:

clientLoop (96) The clientLoop result code indicates that the client has detected some kind of loop while processing results from the server. It usually applies when the client is trying to follow a referral (or a search result reference) and encounters a referral URL that it has already tried to follow.

Loop_DETECT (54) The result code (54) that will be used if the server detects a chaining or alias loop.

Reference: https://docs.ldap.com/ldap-sdk/docs/javadoc/com/unboundid/ldap/sdk/ResultCode.html#LOOP_DETECT

So it means it is possible and there is a way within Unboundid ldap sdk to detect circular references. But I am not able to find an example code or solution to this yet.

How do I detect and prevent circular references in such cases using Unboundid LDAP SDK for java?

Note: This is NOT a duplicate of existing related questions because I seek an answer/solution in context of Unboundid ldap sdk only. Not in some powershell script. Other similar questions has no answer yet related to Unboundid ldap sdk .

Answer 1

You may want to try the (Active Directory specific solution) of using the function LDAP_MATCHING_RULE_IN_CHAIN if that suits your needs which avoids this altogether, see eg:

Is it safe to use 1.2.840.113556.1.4.1941 implementation in case of cyclic dependencies?

See for a complete example eg:

https://confluence.atlassian.com/crowdkb/active-directory-user-filter-does-not-search-nested-groups-715130424.html

This also avoids making several calls to Active Directory, which might be a performance benefit (also make sure to use cached connections which are not the default for an SSL/TLS connection).

If you also need to take other domains in a forest into account you may want to connect to the Global Catalog (plaintext over port 3268 or SSL/TLS over 3269)

The long magic number is an OIN from Microsoft (part of: https://ldapwiki.com/wiki/1.2.840.113556 ) which is the portable numeric representation of the function name: LDAP_MATCHING_RULE_IN_CHAIN. This function name may not be known to your software, but the OIN is what really is transferred over the wire to LDAP/Active Directory.