I have an application vendor that attempts schema validation incorrectly and fails. This failure prevents us from being able to configure the application to connect to our OpenLDAP implementation. I have identified the issue and have a case open with the software vendor to get it fixed. The failing application is part of a suite that must deploy to production very soon in order to meet regulatory requirements and avoid very costly fines. The application vendor is not obligated in any way to meet our deadlines and has indicated that they will not be able to provide a code fix in time. We have a work around that allows us to manage user accounts locally within the application suite itself. If we are forced to take this approach when this application is implemented we will not be able to cost effectively switch back to LDAP once the vendor fixes the code. I'm in a very tough spot where I'm trying to avoid this. To get past the broken schema validation I need cn=Subschema to appear as cn=schema. I've tried everything I can think of (short of tweaking the source) and every approach I've tried has one little technical detail that prevents it from working. Anyone have any ideas I could use? At this point I'm even considering a replica that uses modified source but I have no experience with the OpenLDAP source and would need hints as to how much effort this is and where to make the code changes.
Any ideas or assistance would be greatly appreciated. -Jon C. Kidder American Electric Power Middleware Services 614-716-4970
