Pierangelo Masarati [masarati@aero.polimi.it] kirjoitti:
Petteri Heinonen wrote:
Pierangelo Masarati [masarati@aero.polimi.it] wrote:
Petteri Heinonen wrote:
Hi, I've setup a translucent proxy. Now, I have tried to do some
test > searches. For example this works ok:
ldapsearch -x -W -D "cn=admin,dc=company,dc=com" -b >
"OU=Users,OU=Department,DC=company,DC=com" "(givenName=Myname)"
Search is proxied through proxy to the actual server, and correct
result > is returned. However, if I try this:
ldapsearch -x -W -D "cn=admin,dc=company,dc=com" -b >
"OU=Users,OU=Department,DC=company,DC=com" "(objectClass=User)"
I get no results. I have monitored the traffic between proxy and
backend > server, and the query is not even sent there. In OpenLDAP log there is:
Jul 27 15:51:00 ldaptr01 slapd[17772]: begin get_filter
Jul 27 15:51:00 ldaptr01 slapd[17772]: EQUALITY Jul 27 15:51:00 ldaptr01 slapd[17772]: get_ava: illegal value for >
attributeType objectClass
Jul 27 15:51:00 ldaptr01 slapd[17772]: end get_filter 0
What would be the problem here?
The objectClass "User" is not defined in the proxy's schema?
p.
That's correct. But in translucent overlay's documentation, there is:
"Note: The Translucent Proxy overlay will disable schema checking in the local database, so that an entry consisting of overlay attributes need not adhere to the complete schema."
But it seems that schema checking is still in affect when doing searches. Is there a way to disable local schema checking altogether? Or do I have to build some dummy schema so that OpenLDAP is aware about objectClasses I want to search for?
What happens is that you use unknown schema items in the *filter*, which requires it to be known in order to apply appropriate matching rules and so. The schema relaxation in the documentation refers to enforcing adherence with allowed and required attributes of an objectclass, and with stored objectclasses complying with structural inheritance relationship. Schema items need to be known anyway.
p.
Ok, thanks for the clarification. I guess that my goal to have an Active Directory proxied properly is not going to happen. I would need a complete AD schema for OpenLDAP, and that's probably now available anywhere.
Ok, thanks for the clarification. I guess that my goal to have an Active Directory proxied properly is not going to happen. I would need a complete AD schema for OpenLDAP, and that's probably now available anywhere.
Well, this may not be entirely true, although I'm not 100% sure this works as intended in your case. In fact, slapd is relatively picky about knowing a definition of entities it needs to use. In your case, the objectClass you're using in the filter, and any attribute you may use in a filter. However, as soon as data whose definition is not known are returned by a proxy, slapd can live with them under the assumption they won't be used for anything special. So if you search an entry
dn: cn=Some Name,dc=some,dc=org objectClass: fancyObject cn: Some Name fancyAttr: fancy stuff
using the objectClass or fancyAttr in the filter, they need to be known by slapd; however, if you just search for anything below dc=some,dc=org, and that entry is returned by the proxy, slapd will record fancyObject and fancyAttr for future reference, although in a non-persistent manner (the next time you start slapd you'll need it to learn again about their existence).
p.
openldap-technical@openldap.org
-
masaratiļ¼ aero.polimi.it -
Petteri Heinonen