Hi Michael,
NSS results must not be dependent on the backend database a directory service uses.
I activated connection logging and here's the proof that NSS is not the culprit.
Searches initiated by NSS are identical and exactly this behavior can also be seen when using ldapsearch from command line with parameters from the log:
# running 'getent passwd' with hdb backend:
Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128
Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0
Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 RESULT tag=97 err=0 text=
Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH base="ou=account,dc=its,dc=scom" scope=1 deref=3 filter="(objectClass=posixAccount)"
Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos description objectClass
Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=656 text=
Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 fd=13 closed (connection lost)
# running 'getent passwd' with mdb backend:
Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128
Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0
Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 RESULT tag=97 err=0 text=
Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH base="ou=account,dc=its,dc=scom" scope=1 deref=3 filter="(objectClass=posixAccount)"
Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos description objectClass
Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SEARCH RESULT tag=101 err=0 text=
Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 fd=13 closed (connection lost)
I suspect that aliases are not handled the same way in hdb and mdb as I am using aliases here and deref=3 in both searches, example:
dn: uid=joe,ou=Account,dc=its,dc=scom
objectClass: alias
objectClass: extensibleObject
uid: joe
aliasedObjectName: uid=joe,ou=Person,dc=its,dc=scom
structuralObjectClass: alias
When using hdb, the alias is dereferenced correctly (nentries=656), when using mdb it seems not to be dereferenced at all (nentries=0).
Maybe there's a parameter around for mdb which I couldn't find in the docs