[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: META database root DN : no such object
- To: Aaron Richton <richton@nbcs.rutgers.edu>
- Subject: RE: META database root DN : no such object
- From: Bryce Powell <Bryce.Powell@telus.com>
- Date: Fri, 21 Dec 2012 14:24:10 -0700
- Accept-language: en-US
- Acceptlanguage: en-US
- Cc: "openldap-technical@openldap.org" <openldap-technical@openldap.org>
- Content-language: en-US
- Domainkey-signature: s=orkaan.nssi; d=telus.com; c=nofws; q=dns; h=X-IronPort-Anti-Spam-Filtered: X-IronPort-Anti-Spam-Result:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:acceptlanguage:Content-Type: Content-Transfer-Encoding:MIME-Version; b=X+yCyZnUgLsdywficvNBsM4uBP4jEldV0ZOru1+l2ojLTGXUCZrALiTR 3tXu2WMQnQmsXaDhI2aSa+IrfjCDLt7OmppZcgZrSa71JKZ/JPophRdhQ 8GNJYMS4SCaQKYImJ4YyS4Bj26Fvw13dpfeRVmW4i3vEAnZ9+lYrm5XZt k=;
- Thread-index: Ac3fwX3fUYT1C+7hQ+WHWPWZ4zYySw==
- Thread-topic: META database root DN : no such object
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:richton@nbcs.rutgers.edu]
Sent: December 20, 2012 03:20 PM
To: Bryce Powell
Cc: openldap-technical@openldap.org
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.)