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.
Here's how to reproduce the problem. Meta LDAP server is listening on a socket /var/run/slapd/slapd (configuration at end), providing dc=meta. AD is dc=ad,dc=org,dc=uk.
After startup:
ldapsearch -H ldapi://%2Fvar%2Frun%2Fslapd%2Fldapi-meta -x -D "cn=administrator,dc=meta" -b dc=meta -w secret sAMAccountName=user1
<nothing returned>
Try again with cn:
ldapsearch -H ldapi://%2Fvar%2Frun%2Fslapd%2Fldapi-meta -x -D "cn=administrator,dc=meta" -b dc=meta -w secret cn=user1
<AD record returned successfully>
After this, the original search on sAMAccountName or any other attribute will also be successful.
Debug output from slapd shows an incorrect filter on objectClass with the original failed search:
==> rewrite_context_apply [depth=1] string='ou=ad.org.uk,dc=meta' ==> rewrite_rule_apply rule='((.+),)?ou=ad.org.uk,[ ]?dc=meta$' string='ou=ad.org.uk,dc=meta' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'dc=ad,dc=org,dc=uk'} ==> rewrite_context_apply [depth=1] string='(!(objectClass=*))' ==> rewrite_context_apply [depth=1] res={0,'NULL'} ldap_search_ext put_filter: "(!(objectClass=*))" put_filter: NOT put_filter_list "(objectClass=*)" put_filter: "(objectClass=*)" put_filter: simple put_simple_filter: "objectClass=*" ldap_send_initial_request ldap_send_server_request
A successful search with cn shows the following:
==> rewrite_context_apply [depth=1] string='ou=ad.org.uk,dc=meta' ==> rewrite_rule_apply rule='((.+),)?ou=ad.org.uk,[ ]?dc=meta$' string='ou=ad.org.uk,dc=meta' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'dc=ad,dc=org,dc=uk'} ==> rewrite_context_apply [depth=1] string='(cn=user1)' ==> rewrite_context_apply [depth=1] res={0,'NULL'} ldap_search_ext put_filter: "(cn=user1)" put_filter: simple put_simple_filter: "cn=user1" ldap_send_initial_request ldap_send_server_request
Here's the minimal slapd.conf file:
include /etc/openldap/schema/core.schema
modulepath /usr/lib/openldap/modules moduleload back_meta.so
argsfile /var/run/slapd/slapd.args pidfile /var/run/slapd/slapd.pid
################################################################# # # Meta DB config # # dc=meta # #################################################################
database meta suffix dc=meta rootdn cn=administrator,dc=meta rootpw secret
uri ldap://ad.org.uk:3268/ou=ad.org.uk,dc=meta suffixmassage "ou=ad.org.uk,dc=meta" "dc=ad,dc=org,dc=uk" lastmod off
idassert-bind bindmethod=simple binddn="cn=adldap,dc=ad,dc=org,dc=uk credentials="password" flags=non-prescriptive
idassert-authzFrom "dn.exact:cn=administrator,dc=meta"
Thanks for any help offered.
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.
On 06/12/2011 16:24, masarati@aero.polimi.it wrote:
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.
[snip]
For this reason, if one knows a proxy needs to be used in some specific form, its schema must be defined accordingly.
Ok, understood, thanks for the explanation.
My next problem therefore is to obtain a usable schema for the AD. I've extracted the schema directly from our AD and cleaned it up so that OpenLDAP is (almost) happy, but it doesn't support some of the syntaxes. The documentation suggests I can't easily add the required syntaxes to OpenLDAP either.
So for now I've worked around the issue by performing a search as soon as the meta LDAP server has started.
Just wondering though if anyone out there has created a suitable MS schema that OpenLDAP is happy to use?
openldap-technical@openldap.org