Multiple Search Bases
Starting with SSSD 1.7.0, the System Security Services Daemon now has the ability to search for users, groups and netgroups in multiple search bases. Some LDAP deployments divide groups into different trees so that individual clients can receive different “views” of a group. (This is especially useful for some application software that restricts access to hard-coded group names. In these cases, you can install the same application in different configurations by providing different views of that group).
In SSSD 1.7.0, we extended the ldap_search_base (and ldap_[user|group|netgroup]_search_base) options so that they will now take three pieces of information instead of one (the base itself). Search bases are specified by the pseudocode regular expression:
<base_dn>?<search_scope>?<search_filter>
The search filter can be either an empty string (indicating that no special filtering should be done) or it can be a valid LDAP search filter, which will be ANDed with the standard search filters SSSD uses internally.
“But that’s only one search base, you say!”. And you would be correct. You can add additional search bases by inserting another ‘?’ after the search filter of the preceding base.
For backwards-compatibility, a single search base can be specified simply by base_dn, which will be treated as
<base_dn>?subtree?
Paged lookups
For performance reasons, many LDAP servers limit the number of records that can be retrieved by an LDAP search at one time. Beginning with SSSD 1.6.0, the System Security Services Daemon can now perform paged searches to retrieve responses containing more entries than this limit. This is particularly useful for deployments with large group memberships or those with large numbers of users and groups with enumeration enabled.
SSSD now provides an option ldap_page_size that specifies how many records to request for each individual lookup. The default was set to 1000 records (chosen as it was the lowest common default value of OpenLDAP, 389 DS and Active Directory). However, if your LDAP server has been tuned to have a higher or lower value for this limit, you may wish to update this value to match.
As a general rule, you will want this page size to match the limit on the server, for maximum performance. A larger page size will mean fewer round-trips across the wire to LDAP.
Password Changes and Read-Only Replicas
Due to its use of the openldap client libraries, SSSD has a limitation when it comes to performing password changes. Normally, the way that a read-only replica will be set up is that it will be configured to return a referral to a read-write master LDAP server when a password-change attempt occurs. The client is expected to process this referral and then open a new connection to the read-write master.
Unfortunately, due to an open bug in the OpenLDAP client libraries (which SSSD uses internally for much of its LDAP communication), this referral is not processed correctly. As we’ve not had much traction with the OpenLDAP developers in fixing this bug, SSSD has implemented a workaround. We provide a new option ldap_chpass_uri (valid when using chpass_provider = ldap). It’s semantics are identical to that of ldap_uri, except that it will only be used when a password-change is implemented. This option allows the system administrator to specify a list of read-write servers against which the password-change should occur. The ldap_uri option can remain pointed at the read-only replicas for performance, without compromising the ability to perform password changes on the client.
Stephen Gallagher's Open-Source Blog 