Strange behavior against AD server

["Full Name" <nuncestbibendum [at] excite.com>]

I am using nss-pam-ldapd 0.8.13 in a CentOS 7 system, to obtain user 
information from remote LDAP servers by means of the NSS framework. I am 
currently accessing three LDAP servers: one of them is an OpenLDAP server, 
whereas the other two are Active Directory 2016 servers, A and B. For the 
latter I have the following filters and mappings in my /etc/nslcd.conf file in 
the CentOS 7 system:

filter passwd 
(&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
map    passwd uid                         sAMAccountName
map    passwd homeDirectory    unixHomeDirectory
map    passwd gecos                   displayName
filter group  (objectClass=group)

The NSS framework is configured so that user information is searched for first 
in the local files, resorting to the LDAP server only when not found in those 
files - i.e. the /etc/nsswitch.conf file in the CentOS 7 system has the 
following entries:

passwd: files ldap
shadow: files ldap
group:  files ldap

The LDAP servers are used by the CentOS 7 system to retrieve user information 
alone, not for carrying out authentication. 

Things are working as expected against the OpenLDAP server. Things are also 
working properly against Active DIrectory server A. In this case, when I log 
into the CentOS 7 system over SSH as user U, the traces generated by the nslcd 
daemon (launched with the -d option) in this box reveal a number of LDAP data 
exchanges with A having to do with user U, and also some exchanges having to do 
with the groups that U belongs to, as configured in A. This is very similar to 
what I see when operating against the OpenLDAP server.

When the same operation is carried out against Active Directory server B, 
instead of A, the following is observed:

1. In the logging in process, after the authentication has succeeded, the nslcd 
traces in the CentOS 7 system reveal LDAP data exchanges to do with U, as 
before. However, they also show exchanges to do with other users defined in B 
alone. That is, such users are not a priori known by the CentOS 7 system. The 
problem is that there are hundreds of such users in B, which of course implies 
that the logging in process takes quite a long time - over 10 seconds - to 
complete, until getting to the CLI.

2. A similar phenomenon takes place when executing the 'ls -l' command from the 
/home directory in the CentOS 7 box. As a result, this operation is agonizingly 
slow, even when /home contains a small number of files. This does not happen 
when carrying out this operation when A is used in the NSS framework in the 
CentOS 7 box, rather than B.

Anybody got any ideas concerning what may be going on in the interaction with 
B? My knowledge of Active Directory is very meager and, at any rate, I don't 
have access to B. However, I can get in touch with those responsible for B, and 
suggest ways to solve this problem - if I knew what to suggest. 

Any pointers in this respect would be much appreciated.