Speed up your Active Directory LDAP searches with one simple change

What is LDAP?

Lightweight Directory Access Protocol (LDAP) is a standard protocol for accessing and managing directory information over a network. In NAS environments, LDAP is used to store user and group identity information that is leveraged in security and access controls on files and folders.

NetApp ONTAP can act as an LDAP client, where UNIX user and group lookups are performed when authentication into NAS shares is required, such as when a Windows user needs to be mapped to a UNIX user or when NFSv4.1 user authentication happens.

For more information about multiprotocol NAS access in ONTAP, see:
https://www.netapp.com/media/27436-tr-4887.pdf

For details on configuring Active Directory LDAP with ONTAP, see:
https://www.netapp.com/pdf.html?item=/media/19423-tr-4835.pdf

How LDAP searches work in ONTAP

ONTAP performs a standard LDAP query when looking up a user name, leveraging attribute search fields specified in the LDAP client schema on the storage virtual machine (SVM).

For instance, if a Windows user (say, johnb) attempts to access an SMB share in ONTAP, a Windows -> UNIX name mapping is attempted, where ONTAP will try to find a UNIX user with the same name as the Windows user (johnb). If the SVM is configured to act as an LDAP client, then an LDAP search for the user is attempted using the following LDAP search filter:

(&(objectClass=User)(uid=johnb)

If a search query takes longer than the LDAP timeout, then the query fails and access will be denied. The default timeout is 3 seconds and the maximum allowed timeout is 10 seconds. In large LDAP environments with many user and group objects, it’s possible that the queries exceed the default timeout value and fail. While it is possible to increase the default LDAP query timeout value, that only is a partial fix – queries that take even 3 seconds are generally too slow and will generate user tickets for slow access to the NAS.

Diagnosing slow LDAP queries

The easiest way to diagnose slow LDAP queries is to use a packet capture to see the timing of when a request is sent vs. when it is responded to. First, we’d need to issue an LDAP search from ONTAP that simulates what a user access attempt would do. That can be done with the following command:

::> set advanced; access-check authentication translate -node [node1] -vserver [SVM] -unix-user-name [username]

Alternately, you can use getXXbyYY to perform this lookup and even specify to bypass the cache:

::*> getxxbyyy getpwbyname -node [node1] -vserver [SVM] -username [username] -use-cache false

In a packet capture, we can filter on LDAP as a protocol and see the time delta between the searchRequest and the searchResEntry. In the below, we can see that the time delta is around .0018 seconds, which is really fast, since the LDAP server only has a handful of users.

In Wireshark, you can get a summary of time deltas with Tools -> Statistics -> Service Response Time and select LDAP.

This gives the following window:

When I create 20K new users in the LDAP server, that search response time increases a bit (from .0018 to .35, or nearly 194x):

When more objects are present in the directory, or the AD server has heavier load, or the network has excess latency, those queries can get even longer.

Interestingly, other queries, such as a uidNumber search for the same user, take much less time to complete:

So why is that?

LDAP searchFlags and indexing

In AD LDAP, some attributes are indexed in the directory, which allows faster searches for those attributes, as they don’t need to be found by crawling the entire directory. Instead, they are in a smaller section of the database and returned faster in queries.

By default, the uidNumber attribute is indexed, while the uid attribute is not. That is why the above example had such a difference in search times.

The attributes have a value called searchFlags, where indexing is set (or not set). In the case of uidNumber, the flag is set to 0x1 (INDEX). This can be seen via ADSI Edit.

The uid attribute has a searchFlag of 0x8, which is PRESERVE_ON_DELETE:

Other LDAP attributes specific to UNIX identities in AD that have index set include:

• Common Name (CN)
• gidNumber

To speed up LDAP queries for UID values, all that’s needed is adding 1 to the searchFlags value to add indexing. That means the value becomes 9 instead of 8.

Once that’s done, the queries will return in the same amount of time as the other indexed queries.

Cloud impact

If you are using an ONTAP version in the cloud (such as Amazon FSxN, Cloud Volumes ONTAP, Azure NetApp Files, etc), the uid attribute change will improve those implementation lookup speeds as well and can help mitigate the impact of AD environments that reside on-prem or over latent networks.

Other methods to speed up LDAP queries

If it’s not possible to set the uid value to be indexed in LDAP, there are alternate ways to speed up LDAP queries. These apply only to ONTAP and cloud versions that allow CLI configuration (such as Amazon FSxN). As a service versions of ONTAP (such as ANF or Google Cloud NetApp Volumes) don’t allow these configuration options currently.

1. Use a custom LDAP schema to change -uid-attribute to cn (which is indexed) instead of uid
   • Custom LDAP schemas can be applied to change which attributes are looked up by ONTAP in searches. TR-4835 shows how to create a new custom schema.
2. Modify the LDAP client configuration to include user and group DN filters
   • By specifying the user and group DNs (instead of simply using the base DN), the searches can target the location where the user and group objects reside. If you have multiple OUs where users and groups reside, you can specify multiple DNs in the configuration by separating the DNs with a semicolon (;).

Hopefully these simple steps can help your LDAP configuration perform even better.

If you have questions or comments, leave them below!