SearchRequest in RootDSE

I have to following function to query users from an AD server:

public List<LDAPUserDTO> getUsersWithPaging(String filter)
{
    List<LDAPUserDTO> userList = new ArrayList<>();

    try(LDAPConnection connection = new LDAPConnection(config.getHost(),config.getPort(),config.getUsername(),config.getPassword()))
    {
        SearchRequest searchRequest = new SearchRequest("", SearchScope.SUB,filter, null);          
        ASN1OctetString resumeCookie = null;
        while (true)
        {
            searchRequest.setControls(
                    new SimplePagedResultsControl(100, resumeCookie));
            SearchResult searchResult = connection.search(searchRequest);
            for (SearchResultEntry e : searchResult.getSearchEntries())
            {
                LDAPUserDTO tmp = new LDAPUserDTO();
                tmp.distinguishedName = e.getAttributeValue("distinguishedName");
                tmp.name = e.getAttributeValue("name");
                userList.add(tmp);
            }

            LDAPTestUtils.assertHasControl(searchResult,
                    SimplePagedResultsControl.PAGED_RESULTS_OID);
            SimplePagedResultsControl responseControl =
                    SimplePagedResultsControl.get(searchResult);
            if (responseControl.moreResultsToReturn())
            {
                resumeCookie = responseControl.getCookie();
            }
            else
            {
                break;
            }
        }       
        return userList;
    } catch (LDAPException e) {
        logger.error(e.getExceptionMessage());
        return null;
    }


}

However, this breaks when I try to search on the RootDSE.

What I've tried so far:

baseDN = null
baseDN = "";
baseDN = RootDSE.getRootDSE(connection).getDN()
baseDN = "RootDSE"

All resulting in various exceptions or empty results:

Caused by: LDAPSDKUsageException(message='A null object was provided where a non-null object is required (non-null index 0). 

2020-04-01 10:42:22,902 ERROR [de.dbz.service.LDAPService] (default task-1272) LDAPException(resultCode=32 (no such object), numEntries=0, numReferences=0, diagnosticMessage='0000208D: NameErr: DSID-03100213, problem 2001 (NO_OBJECT), data 0, best match of:
    ''
 ', ldapSDKVersion=4.0.12, revision=aaefc59e0e6d110bf3a8e8a029adb776f6d2ce28')

So, I really spend a lot of time with this. It is possible to kind of query the RootDSE, but it's not that straight forward as someone might think.

I mainly used WireShark to see what the guys at Softerra are doing with their LDAP Browser.

Turns out I wasn't that far away:

As you can see, the baseObject is empty here. Also, there is one additional Control with the OID LDAP_SERVER_SEARCH_OPTIONS_OID and the ASN.1 String 308400000003020102.

So what does this 308400000003020102 more readable: 30 84 00 00 00 03 02 01 02 actually do?

First of all, we decode this into something, we can read - in this case, this would be the int 2.

In binary, this gives us: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0

As we know from the documentation, we have the following notation:

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30    | 31    |
|---|---|---|---|---|---|---|---|---|----|----|----|----|----|----|----|----|----|----|----|----|----|----|----|----|----|----|----|----|-------|-------|
| x | x | x | x | x | x | x | x | x | x  | x  | x  | x  | x  | x  | x  | x  | x  | x  | x  | x  | x  | x  | x  | x  | x  | x  | x  | x  | SSFPR | SSFDS |

or we just take the int values from the documentation:

• 1 = SSFDS -> SERVER_SEARCH_FLAG_DOMAIN_SCOPE
• 2 = SSFPR -> SERVER_SEARCH_FLAG_PHANTOM_ROOT

So, in my example, we have SSFPR which is defined as follows:

For AD DS, instructs the server to search all NC replicas except application NC replicas that are subordinate to the search base, even if the search base is not instantiated on the server. For AD LDS, the behavior is the same except that it also includes application NC replicas in the search. For AD DS and AD LDS, this will cause the search to be executed over all NC replicas (except for application NCs on AD DS DCs) held on the DC that are subordinate to the search base. This enables search bases such as the empty string, which would cause the server to search all of the NC replicas (except for application NCs on AD DS DCs) that it holds.

NC stands for Naming Context and those are stored as Operational Attribute in the RootDSE with the name namingContexts.

The other value, SSFDS does the following:

Prevents continuation references from being generated when the search results are returned. This performs the same function as the LDAP_SERVER_DOMAIN_SCOPE_OID control.

So, someone might ask why I even do this. As it turns out, I got a customer with several sub DCs under one DC. If I tell the search to handle referrals, the execution time is pretty high and too long - therefore this wasn't really an option for me. But when I turn it off, I wasn't getting all the results when I was defining the BaseDN to be the group whose members I wanted to retrieve.

Searching via the RootDSE option in Softerra's LDAP Browser was way faster and returned the results in less then one second.

I personally don't have any clue why this is way faster - but the ActiveDirectory without any interface of tool from Microsoft is kind of black magic for me anyway. But to be frank, that's not really my area of expertise.

In the end, I ended up with the following Java code:

SearchRequest searchRequest = new SearchRequest("", SearchScope.SUB, filter, null); 
[...]
Control globalSearch = new Control("1.2.840.113556.1.4.1340", true, new ASN1OctetString(Hex.decode("308400000003020102")));

searchRequest.setControls(new SimplePagedResultsControl(100, resumeCookie, true),globalSearch);
[...]

The used Hex.decode() is the following: org.bouncycastle.util.encoders.Hex.

A huge thanks to the guys at Softerra which more or less put my journey into the abyss of the AD to an end.