SSPR Helpdesk Search Efficiency
A key feature of NetIQ’s Self-Service Password Reset, also known as SSPR, is the Helpdesk module. This module allows authorized users to search and change passwords for other users among other things. The Helpdesk module can even be configured to contain multiple Helpdesk profiles that can grant different permissions or limitations on different groups of users to restrict which accounts a particular group can see or what activities a group can perform such as change password, unlock account, clear challenge data, and even delete account.
Regardless of whether or not your instance of SSPR uses a single Helpdesk profile or dozens, each Helpdesk profile (including the default) requires a “Helpdesk Search Filter” which is nothing more than an LDAP filter used to query for matching objects to display in the UI.
As you can see in this example, the LDAP filter is search for all objects with an objectClass equal to Person and at least one attribute match from the cn, workforceID, givenName, or sn values equal to the parameter entered on the Helpdesk look-up screen. This means that SSPR is doing 5 checks essentially to determine all objects that might meet the search criteria.
- objectClass=Person AND cn=<parameter>
- objectClass=Person AND workforceID=<parameter>
- objectClass=Person AND givenName=<parameter>
- objectClass=Person AND sn=<parameter>
The key thing to keep in mind is that SSPR does not iteratively build the results screen so that values dynamically appear as the searches take place. This is mainly due to how LDAP searches work. Even though the sample filter would return results that match any of the 4 combinations listed above, the way the search works is that it searches for all matches in a single query (much like a SQL query would) and then the total results are returned. And this is where the efficiency concerns come in.
If SSPR is pointed to a directory that has a large volume of objects, say 200k or more, then these complex, multi-valued attribute filters may take several seconds to fully perform any searches and return the results. Even if all of the attributes in the filter are indexed within your directory it may still require a few seconds for the query to complete.
Because SSPR leverages this “static” LDAP filter configuration versus a dynamic filter created on the fly by allowing users to choose which attribute(s) to search on, this means that planning how this LDAP filter is constructed is absolutely critical to maximizing SSPR’s performance.
For example, if you have attributes that contain the same information, such as, if your object CNs are firstName + lastName (or some similar construct) then there is little reason to include the givenName and sn attributes in the LDAP search filter. If your organization issues workforceIDs/employeeIDs but users rarely use or know them then it does little value to include that attribute in your search filter. The key is to keep your LDAP search filter as simple as possible with as few attributes as is needed to accomplish the overall goal; finding users with minimal key details.
It should also be worth pointing out that in addition to the LDAP search filter, you can also specify one or more LDAP search bases which limit what OU(s) your defined search filter is executed against.
It should go without saying that isolating any searches to only the container(s) where the data is expected to be found will further increase the efficiency of any searches. However, it should also be said that while you can specify multiple specific containers that the more containers specified, the higher number of times a search will have to be executed, so there is a tipping point where too many search bases will be less efficient than a more generic search base.
For most, a 3-5 second wait to look-up users may not be a big concern whereas for others that may be totally unacceptable, however, the groups that generally have the greatest concern for speed are those with the highest number of users which are the groups most likely to be impacted in this scenario. For smaller groups with a smaller user base the redundant search filter is less likely to make a noticable impact but as that user base grows the issue may begin to present itself and get worse as the numbers increase. For larger groups, the impact is seen immediately and will only continue to get worse until the filter is adjusted to minimize search fields and times.
The moral of the story: The key to making SSPR’s Helpdesk module work its best, construct the LDAP search filter with as few redundant attributes as possible, make sure those attributes are indexed in your directory, and limit your search scope by specifying as specific an LDAP search base as possible.