Hi!
How does OpenLDAP behave when it encounters a search filter with an unknown objectClass? From what I've been able to gather, it translates the search filter into (?objectClass=value), thus yielding the rest of the search invalid. What can I do about this? Either just pass the search as it is, or remove it altogether?
The reason I'm asking about this is that I'm setting up OpenLDAP as a proxy for Active Directory. After months of researching I've discovered that the problem lays exactly here - OpenLDAP alters the search filter for object classes it knows nothing about.
Example:
(| (& (objectClass=group) (member=cn=username,ou=test,dc=example,dc=com) ) (& (objectClass=groupOfNames) (member=cn=username,ou=test,dc=example,dc=com) ) (& (objectClass=groupOfUniqueNames) (uniqueMember=cn=username,ou=test,dc=example,dc=com) ) (& (objectClass=accessGroup) (member=cn=username,ou=test,dc=example,dc=com) ) (& (objectClass=univentionGroup) (uniqueMember=cn=username,ou=test,dc=example,dc=com) ) )
Yields no entries. I've looked at the syslog (loglevel = 256) and I see that the last two clauses have been "translated" into "?objectClass=accessGroup" and "?objectClass=univentionGroup". But if I then remove the last two clauses, like so...
(| (& (objectClass=group) (member=cn=username,ou=test,dc=example,dc=com) ) (& (objectClass=groupOfNames) (member=cn=username,ou=test,dc=example,dc=com) ) (& (objectClass=groupOfUniqueNames) (uniqueMember=cn=username,ou=test,dc=example,dc=com) ) )
... then I get the entries I want back. Problem here is that I'm unable to alter the search filter, since this is generated by a 3rd-party app that I can't change, so I need to fix my OpenLDAP to let this stuff pass through.
Any idea?
- Marius
Hi!
How does OpenLDAP behave when it encounters a search filter with an unknown objectClass? From what I've been able to gather, it translates the search filter into (?objectClass=value), thus yielding the rest of the search invalid. What can I do about this? Either just pass the search as it is, or remove it altogether?
The reason I'm asking about this is that I'm setting up OpenLDAP as a proxy for Active Directory. After months of researching I've discovered that the problem lays exactly here - OpenLDAP alters the search filter for object classes it knows nothing about.
Example:
(| (& (objectClass=group) (member=cn=username,ou=test,dc=example,dc=com) ) (& (objectClass=groupOfNames) (member=cn=username,ou=test,dc=example,dc=com) ) (& (objectClass=groupOfUniqueNames) (uniqueMember=cn=username,ou=test,dc=example,dc=com) ) (& (objectClass=accessGroup) (member=cn=username,ou=test,dc=example,dc=com) ) (& (objectClass=univentionGroup) (uniqueMember=cn=username,ou=test,dc=example,dc=com) ) )
Yields no entries. I've looked at the syslog (loglevel = 256) and I see that the last two clauses have been "translated" into "?objectClass=accessGroup" and "?objectClass=univentionGroup". But if I then remove the last two clauses, like so...
(| (& (objectClass=group) (member=cn=username,ou=test,dc=example,dc=com) ) (& (objectClass=groupOfNames) (member=cn=username,ou=test,dc=example,dc=com) ) (& (objectClass=groupOfUniqueNames) (uniqueMember=cn=username,ou=test,dc=example,dc=com) ) )
... then I get the entries I want back. Problem here is that I'm unable to alter the search filter, since this is generated by a 3rd-party app that I can't change, so I need to fix my OpenLDAP to let this stuff pass through.
Any idea?
Define those objectclasses in slapd's schema, that's the wisest thing to do. I'd note that in recent releases the filter is passed thru as is even when unknown. Unfortunately, you don't state what version you're using.
p.
Den 24.08.2010 16:35, skrev masarati@aero.polimi.it:
Define those objectclasses in slapd's schema, that's the wisest thing to do. I'd note that in recent releases the filter is passed thru as is even when unknown. Unfortunately, you don't state what version you're using.
Sorry about that. I'm using the current in Debian - 2.4.11.
And for the schemas, see what I wrote in my previous post on the mailing list - I basically have no way of getting hold of the schema declarations.
- Marius
Den 24.08.2010 16:35, skrev masarati@aero.polimi.it:
Define those objectclasses in slapd's schema, that's the wisest thing to do. I'd note that in recent releases the filter is passed thru as is even when unknown. Unfortunately, you don't state what version you're using.
Sorry about that. I'm using the current in Debian - 2.4.11.
And for the schemas, see what I wrote in my previous post on the mailing list - I basically have no way of getting hold of the schema declarations.
As soon as the AD you're proxying knows about them, you can extract the schema from it. See the documentation of AD, I don't remember how it stores the schema (I'm afraid it does not work as illustrated in RFC4512, 4.4). Otherwise, if they're not known to AD as well, you won't get anything useful out of it, so the point is moot. In any case, your definition of those classes needs not be accurate, as soon as you only intend to proxy them. They basically need to be known.
p.
masarati@aero.polimi.it wrote:
Den 24.08.2010 16:35, skrev masarati@aero.polimi.it:
Define those objectclasses in slapd's schema, that's the wisest thing to do. I'd note that in recent releases the filter is passed thru as is even when unknown. Unfortunately, you don't state what version you're using.
Sorry about that. I'm using the current in Debian - 2.4.11.
And for the schemas, see what I wrote in my previous post on the mailing list - I basically have no way of getting hold of the schema declarations.
As soon as the AD you're proxying knows about them, you can extract the schema from it. See the documentation of AD, I don't remember how it stores the schema (I'm afraid it does not work as illustrated in RFC4512, 4.4).
Off course MS AD has a subschema subentry which can be located and read as with any other LDAPv3 compliant server.
In W2K there were some incompabilities regarding values for SYNTAX not being OIDs.
My web2ldap can be used to access AD and extract the few schema descriptions needed from the subschema subentry. You can do a (wild-card) search for OIDs and NAMEs.
Ciao, Michael.
On the 24th of August, at 15:20, Marius Flage wrote:
How does OpenLDAP behave when it encounters a search filter with an unknown objectClass? From what I've been able to gather, it translates the search filter into (?objectClass=value), thus yielding the rest of the search invalid. What can I do about this? Either just pass the search as it is, or remove it altogether?
I have of course come to another - better - conclusion now. OpenLDAP doesn't alter the search filters, instead it just "tags" them in the logfiles when it encounters some unknown object classes. But the underlaying problem is still the same - I get no entries back from OpenLDAP when I include the two unknown object classes in the search.
Some intensive googling has revealed that accessGroup is an object class from IBM's SecureWay Directory Server and that univentionGroup is from Univention Groups Directory Server [1].
I'm sure if I'm able to get hold of the schemas for these two directory servers, that I'll be able to make the search valid, but so far I've found nothing when searching on the respective sites - and don't get me started on IBM's webpages.
So what can I do then? As I said this is a 3rd party application (actually a Zope application that uses LDAPUserFolder), so it's not really feasible to start hacking at that to get this working. Is there a way to rewrite the object classes or maybe just get OpenLDAP to ignore the unknown object classes when searching? Or, even better, does anyone have the correct schema declarations laying around?
Hopefully my last email to the mailing list about this for now - the next entry is up to you! :)
- Marius
openldap-technical@openldap.org
-
Marius Flage -
masarati＠aero.polimi.it -
Michael Ströder