LDAP-UX Client Services B.04.15 with Microsoft Windows Active Directory Server Administrator's Guide (edition 8)

6. Enter set maxpagesize to <size>, where the <size> is the maximum number of
search objects that you want the Active Directory to return for a search, and then press the
Enter key.
7. Enter set maxqueryduration to <time>, where the <time> is the maximum number
of seconds to wait for a search request to complete, and then press the Enter key.
8. Enter show values then press the Enter key. This verifies the new values are set correctly.
9. Enter Commit Changes, and then press the Enter key.
10. Enter quit then press the Enter key to quit ldap policies.
11. Enter quit then press the Enter key to quit ntdsutil.
Search Filter
If enumeration requests cannot be avoided, consider the use of customized search descriptors
for each of your name services. Customized search descriptors can improve enumeration cases
because it limits the search only to the paths (containers) where the required data resides.
For example, if your default search DN is set to your domain root DC=cup, DC=hp, DC=com,
you can improve performance if you change the search base DN to search user and group
information toCN=Users, DC=cup, DC=hp, DC=com for the passwd and group services.
Client Daemon Performance
Compared to previous networked name service systems, LDAP directory servers support a
number of new features. And the general purpose nature of LDAP allows it to support a variety
of applications, beyond those just used by a networked OS. Although directory servers have
excellent performance and scalability, the addition of these features, such as security, means that
directory applications will benefit from a design that considers performance requirements. In
order to maximize of the number of HP-UX clients that can be supported by an LDAP directory
server, and also improve client response, the ldapclientd daemon supports both data caching
and persistent network connections. Their use, benefits and side-effects are described below.
ldapclientd Caching
Caching LDAP data locally allows for much greater response time for name service operations.
Caching means that data that has been recently retrieved from the directory server will be
retrieved from a local store, instead of the directory server. Caching greatly reduces both directory
server load and network usage. For example, when a user logs into the system, the OS typically
needs to enquire about his/her account several times in the login process. This occurs as the OS
identifies the user, gathers account information and authenticates the user. And further requests
often occur as the account starts up new applications once a session is established. With caching,
generally only one or two LDAP operations are required.
Caching is also critical to support certain types of applications that make frequent demands on
the name service system, either because they are malfunctioning or need this specific type of
information frequently.
ldapclientd also supports what is known as a negative cache. This type of cache is used to store
meta-data about non-existent information. For example, if an application requests information
about an account that does not exist, the directory server will not return an entry, and that
negative result will be stored in a cache. Intuitively this type of cache would seem to be
un-necessary. However, applications exist that may perform these operations frequently, either
on purpose or because they are malfunctioning. For example, if a file is created with a group ID
that does not exist, every time a user displays information about this file, using the ls command,
a request to the directory server will be generated.
The ldapclientd daemon currently supports caching of passwd, group, netgroup and automount
map information. ldapclientd also maintains a cache which maps user's accounts to LDAP DNs.
144 Administering LDAP-UX Client Services