It’s worth noting this down as I don’t think it’s documented by openldap and every now and then it confuses me.
It’s easiest to illustrate with an example…
proxyattrset 0 uid gidNumber
proxyattrset 1 memberUid gidNumber
proxytemplate (&(objectClass=)(uid=)) 0 600 600
proxytemplate (&(objectClass=)(cn=)) 1 600 600
When setting up the templates and attrsets like this, you might expect all of the following queries to be cacheable:
ldapsearch -x "(&(objectClass=posixAccount)(uid=toby))" uid gidNumber
ldapsearch -x "(&(objectClass=posixAccount)(uid=toby))" uid
ldapsearch -x "(&(objectClass=posixAccount)(uid=toby))" gidNumber
ldapsearch -x "(&(objectClass=posixGroup)(cn=staff))" memberUid gidNumber
ldapsearch -x "(&(objectClass=posixGroup)(cn=staff))" memberUid
ldapsearch -x "(&(objectClass=posixGroup)(cn=staff))" gidNumber
But they’re not – all of them, except the last one, work. The pattern that seems to be followed here, and in other tests, is that if the list of attributes requested in the query is wholly contained in a previously defined attrset then it won’t work.
It seems there are two ways around this:
- If possible, make your template use an attrset which is defined earlier. This is what I did previously for a required attrset/template which only had one attr –
gidNumber
– it only worked if I made the template use a previous attrset which also containedgidNumber
. The obvious drawback here is that you may be requesting/caching large numbers of attributes that you don’t want. - Change the ordering of your attribute sets. This would seem to be the preferred solution, but won’t always be possible