Hi,
I have a meta DB pointing to an Active Directory backend. This is used by SASL for authentication.
The meta DB does not contain a schema definition for the AD.
I've configured SASL to lookup sAMAccountName in AD, but this always fails until a lookup against the meta DB has first been performed against an attribute that the meta DB does understand (e.g. cn). Once that's been done, the system is rock solid and can be searched on any attribute.
Looking at the debug output it seems that any initial search does not honour the specified filter unless the attribute being searched for is defined in the schema, but after one successful search, the LDAP server is happy to search for these attributes.
I can work around this by doing a dummy search when the LDAP server starts, but I'd like to understand the cause of the problem properly.
Any suggestions as to the cause of this? I'm using 2.4.20 on SLES 11.
This is the intended behavior. Slapd needs attributes to be defined in the schema in order to accept them in filters (because it needs to be able to check the validity of the filter with respect to the attribute, the value and the matching rule. Until an attribute is known in the schema, when used in a filter it causes the filter to evaluate to invalid. As soon as the proxy knows about the existence of an attribute (e.g. because it is returned by the remote server it is proxying, it records a fake definition for that attribute (one as liberal as possible), in order to extend the usability of that attribute by the frontend. The rationale is that if an unknown attribute is contained in a client's filter, it may be the consequence of a typo, of a misconfiguration or other types of errors, while if it is returned by a (supposedly trusted, since it's proxied) remote server, it ought to be somehow valid, although nothing is known about it. For this reason, if one knows a proxy needs to be used in some specific form, its schema must be defined accordingly.
p.