Aaron, thanks very much for your suggestion. I understand the key concept here is "subordinate", in order to glue the meta database into another superior naming context.
I was able to create a LDIF database, containing a baseDN, which was superior to the subordinate META database. The vendor application appears to accept this LDIF database now, as it can verify the existence of the baseDN. My next hurdle will be to get it authorize users based on group membership within the underlying Active Directories. But I think that may be beyond the scope of this forum. Thanks again for your help. Bryce -----Original Message----- From: Aaron Richton [mailto:[email protected]] Sent: December 20, 2012 03:20 PM To: Bryce Powell Cc: [email protected] Subject: Re: META database root DN : no such object On Thu, 20 Dec 2012, Bryce Powell wrote: > ?When a search with base "dc=foo,dc=com" is attempted, if the scope is > "base" it fails with "no such object"; in fact, the common root > of the two targets (prior to massaging) does not exist.? The vendor > won?t change their code to skip the verification, and recommended I > use Microsoft?s ADAM instead of OpenLDAP. I would prefer to leverage > OpenLDAP, so does anyone have any recommendations as to what I could do? > Thanks, Bryce You're quoting from "scenario 2a" from the man page, which envisions dc=a,dc=foo,dc=com and dc=b,dc=foo,dc=com; your desire is to serve some data at dc=foo,dc=com. So you have to make that exist (obviously). You'll need a data store to place your "dc=foo,dc=com" data, and you'll need to "attach" dc=a,dc=foo,dc=com and dc=b,dc=foo,dc=com. So basically... database meta # maybe ldap or even relay in some installations subordinate suffix "dc=a,dc=foo,dc=com" uri "ldap://a.foo.com/dc=a,dc=foo,dc=com"; database meta subordinate suffix "dc=b,dc=foo,dc=com" uri "ldap://b.foo.com/dc=a,dc=foo,dc=com"; database mdb # or hdb or bdb or even ldif or..... suffix "dc=foo,dc=com" So then dc=a and dc=b live over the wire, and dc=foo,dc=com can be filled with Whatever You Want. Like, say, your base-scope data at dc=foo,dc=com. You'll almost certainly want to set up some careful ACLs and make sure, in particular, that nobody writes any dc=a/dc=b data to the on-disk database. Without trying it, I don't think it would cause a failure per se, but it would cause a very confused LDAP admin (quite undesirable)! (As for "dc=c" data on-disk, that's up to you and your site.)
