Hi,
is there a way to disable OpenLDAP checking entries for existence of STRUCTURAL objectclasses?
I know it's illegal per standard to have either no or multiple objectclasses of STRUCTURAL type on an entry. Unfortunately in the enterprise world it is very common that you have to deal with existing data which is even beyond your control. Our LDAP is full of such 'bad' records, making imports into OpenLDAP fail for 50% of our entries. I'm trying to present OpenLDAP as an alternative to the commercial LDAP software my company is currently running but I need to come up with a solution to this in order to convince our managers and engineering. Competition such as Oracle Unified Dir have an option to selectively disable this type of checking. Is there a way to do it in OpenLDAP via config? If no, would it be rather easy or hard to add that to the code myself ? I once made a similar patch but it had to be applied in a single location within the source only.
Thanks Best regards Markus
--On Wednesday, January 8, 2020 3:25 PM +0000 Markus.Storm@t-systems.com wrote:
is there a way to disable OpenLDAP checking entries for existence of STRUCTURAL objectclasses?
No. This is a hard requirement. The best option would be to fix the bad data in your upstream system.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 1/8/20 7:07 PM, Quanah Gibson-Mount wrote:
--On Wednesday, January 8, 2020 3:25 PM +0000 Markus.Storm@t-systems.com wrote:
is there a way to disable OpenLDAP checking entries for existence of STRUCTURAL objectclasses?
No. This is a hard requirement. The best option would be to fix the bad data in your upstream system.
One possibility to fix this: Define a new STRUCTURAL object class derived from different other STRUCTURAL object classes.
E.g. in Æ-DIR I'm using this to provide hybrid posixGroup entries serving RFC 2307 and RFC 2307bis groups:
( 1.3.6.1.4.1.5427.1.389.100.6.1 NAME 'aeGroup' DESC 'AE-DIR: Group entry' SUP ( groupOfEntries $ posixGroup $ groupOfURLs $ aeObject ) STRUCTURAL MUST description MAY ( aeMemberZone $ aeDept $ aeLocation ) )
This works because unlike other LDAP directory servers OpenLDAP supports multiple class inheritance.
Ciao, Michael.
Thanks Michael for that idea. But that would mean to assign that new group to every entry that has 2 structural objectclasses today, wouldn't it? So it would require me to change the upstream data e.g. replace posixGroup by aeGroup and remove groupOfURLs (to stick with your example) and the application as there's applications to search for e.g. &(objectclass=posixGroup)(objectclass=groupOfURLs). And I would need to fix future entries on the fly (rwm module in replication??)
Guess that won't work out, possibly still easier to work around this in the source code. Any opinions on that from people to know the source better than I do ?
Best regards Markus
-----Original Message----- From: Michael Ströder michael@stroeder.com Sent: Thursday, January 9, 2020 9:56 AM To: Storm, Markus Markus.Storm@t-systems.com; openldap- technical@openldap.org Subject: Re: structural objectclass checking
On 1/8/20 7:07 PM, Quanah Gibson-Mount wrote:
--On Wednesday, January 8, 2020 3:25 PM +0000 Markus.Storm@t-systems.com wrote:
is there a way to disable OpenLDAP checking entries for existence of STRUCTURAL objectclasses?
No. This is a hard requirement. The best option would be to fix the bad data in your upstream system.
One possibility to fix this: Define a new STRUCTURAL object class derived from different other STRUCTURAL object classes.
E.g. in Æ-DIR I'm using this to provide hybrid posixGroup entries serving RFC 2307 and RFC 2307bis groups:
( 1.3.6.1.4.1.5427.1.389.100.6.1 NAME 'aeGroup' DESC 'AE-DIR: Group entry' SUP ( groupOfEntries $ posixGroup $ groupOfURLs $ aeObject ) STRUCTURAL MUST description MAY ( aeMemberZone $ aeDept $ aeLocation ) )
This works because unlike other LDAP directory servers OpenLDAP supports multiple class inheritance.
Ciao, Michael.
Markus.Storm@t-systems.com wrote:
Thanks Michael for that idea. But that would mean to assign that new group to every entry that has 2 structural objectclasses today, wouldn't it?
New objectclass, not new group.
So it would require me to change the upstream data e.g. replace posixGroup by aeGroup and remove groupOfURLs
No need to remove groupOfURLs.
(to stick with your example) and the application as there's applications to search for e.g. &(objectclass=posixGroup)(objectclass=groupOfURLs).
No need to change applications, since the new objectclass would satisfy both of those filters.
And I would need to fix future entries on the fly (rwm module in replication??)
Guess that won't work out, possibly still easier to work around this in the source code. Any opinions on that from people to know the source better than I do ?
Best regards Markus
-----Original Message----- From: Michael Ströder michael@stroeder.com Sent: Thursday, January 9, 2020 9:56 AM To: Storm, Markus Markus.Storm@t-systems.com; openldap- technical@openldap.org Subject: Re: structural objectclass checking
On 1/8/20 7:07 PM, Quanah Gibson-Mount wrote:
--On Wednesday, January 8, 2020 3:25 PM +0000 Markus.Storm@t-systems.com wrote:
is there a way to disable OpenLDAP checking entries for existence of STRUCTURAL objectclasses?
No. This is a hard requirement. The best option would be to fix the bad data in your upstream system.
One possibility to fix this: Define a new STRUCTURAL object class derived from different other STRUCTURAL object classes.
E.g. in Æ-DIR I'm using this to provide hybrid posixGroup entries serving RFC 2307 and RFC 2307bis groups:
( 1.3.6.1.4.1.5427.1.389.100.6.1 NAME 'aeGroup' DESC 'AE-DIR: Group entry' SUP ( groupOfEntries $ posixGroup $ groupOfURLs $ aeObject ) STRUCTURAL MUST description MAY ( aeMemberZone $ aeDept $ aeLocation ) )
This works because unlike other LDAP directory servers OpenLDAP supports multiple class inheritance.
Ciao, Michael.
On 1/9/20 4:35 PM, Markus.Storm@t-systems.com wrote:
Define a new STRUCTURAL object class derived from different other STRUCTURAL object classes.
But that would mean to assign that new group to every entry that has 2 structural objectclasses today, wouldn't it?
Yes. But since you have to do an export/import anyway it's not a big deal to create a simple LDIF filter script to add such a custom object class.
So it would require me to change the upstream data e.g. replace posixGroup by aeGroup and remove groupOfURLs (to stick with your example) and the application as there's applications to search for e.g. &(objectclass=posixGroup)(objectclass=groupOfURLs).
I don't exactly understand what you mean.
When using object class inheritance every filter for a SUP object class also matches.
You can play with Æ-DIR's demo which has a public LDAP(S) port and test how searching the group entries work:
https://www.ae-dir.com/demo.html
And I would need to fix future entries on the fly (rwm module in replication??)
Using slapo-rwm would not work.
Guess that won't work out, possibly still easier to work around this in the source code.
If you want to implement C code you could implement custom overlays and do whatever you want.
Ciao, Michael.
Markus,
You might review the objectclass definitions for your data. There is no issue with multiple STRUCTURAL objectclasses on the same object as long as they are part of the same hierarchy e.g.
dn: uid=user,ou=people,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: customizedObjectClassBasedOnInetOrgPerson . . .
There might also be the opportunity to convert some structural classes to auxiliary.
From: openldap-technical openldap-technical-bounces@openldap.org On Behalf Of Markus.Storm@t-systems.com Sent: Wednesday, January 8, 2020 8:25 AM To: openldap-technical@openldap.org Subject: structural objectclass checking
Hi,
is there a way to disable OpenLDAP checking entries for existence of STRUCTURAL objectclasses?
I know it's illegal per standard to have either no or multiple objectclasses of STRUCTURAL type on an entry. Unfortunately in the enterprise world it is very common that you have to deal with existing data which is even beyond your control. Our LDAP is full of such 'bad' records, making imports into OpenLDAP fail for 50% of our entries. I'm trying to present OpenLDAP as an alternative to the commercial LDAP software my company is currently running but I need to come up with a solution to this in order to convince our managers and engineering. Competition such as Oracle Unified Dir have an option to selectively disable this type of checking. Is there a way to do it in OpenLDAP via config? If no, would it be rather easy or hard to add that to the code myself ? I once made a similar patch but it had to be applied in a single location within the source only.
Thanks Best regards Markus
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
openldap-technical@openldap.org
-
Howard Chu -
Markus.Storm＠t-systems.com -
Michael Ströder -
Quanah Gibson-Mount -
Vandenburgh, Steve Y