Problem with VDS: Receiving attribute schema fails

[bastian_hickl]

Hello,

we are using the VDS with two data sources, both are databases with the scope to a single table.

One table contains company addresses while the other one contains data of persons.

If we use one virtual tree and only one node for e.g. the company data source we receive the attribute schema of this table by viewing it with external LDAP browsers like LDAP Admin. So this works for both data sources used in single mode (single data source and single virtual tree).

When we configure another virtual tree for the other data source (persons) as well as another user (only one user per tree) to connect to each tree by different username and password, we only receive the schema of the data source which is selected in the first tree.

Here are a few information about what's happening when we using LDAP Browser LDP.EXE to get the schema.

We used LDP.EXE because it is showing the schema naming context right after binding.

Connecting to LDAP Browser with the corresponding user of tree1 (tree1,o=db,*):

Schema naming context schows up: cn=schema,o=db

Accessing the schema works fine and we receive all attributes.

There is all ok.

Connectiong to LDAP Browser with the corresponding user of tree2 (tree2,o=db2,*):

Schema naming context: cn=schema,o=db

Accessing this schema returns: Server error: Couldn't perform DN to Data source mapping

Shouldn't be the schema of this binding cn=schema,o=db2?

This is even the correct path in the tree2.

Yes, the schemas of both tables are different, but we need to access them.

Is there any possibility or do we have any logical issue here?

Do you have any idea how this could work?

Maybe there is an even better solution where we only need one tree and one single user - that would be even more perfect

Thank you in advance.

Kind regards,

Bastian

[former_member2987 · Accepted solution]

Bastian,

I'm a little confused about what you want to do.

If you want to receive information from both tables, you'll need to set up a Join which is described in this document. Otherwise, you'll need to do two separate calls to your Virtual Directory instance and manipulate them separately.

Hope this helps!

Regards,

Matt

[bastian_hickl · Accepted solution]

Hi Matt,

thank you for your reply and your advice to join the tables - even if this isn't what we aim for.

Our business case is not to join the tables we just want to read the data with third party tools via LDAP. Some tools seem to need a vaild schema to handle the data they receive otherwise they cannot proceed further.

This is the only reason why we try to get the schema of both tables using one instance of the VDS.

If I am right, as you said, this isn't possible with one instance.

On the other hand that means there would be two VDS configurations, one for table person and one for table company. So there would be two connections...this won't make us happy - at least this was the feedback I've got.

As a workaround we make a replica of the VDS using OpenLDAP and let the third party tools connect to this directory.

You may have an idea to optimize this solution by using only the VDS.

...and thank you for so long.

Kind regards,

Bastian

[former_member2987 · Accepted solution]

Bastian,

You should be able to do this.

Just to be clear, you have two tables in separate databases that you need to represent in VDS as different containers or the same container (slightly more complex)

Just so I can model it correctly, what kind of data is it? (e.g. Users and Offices)

Let me see if I can build it over the weekend and I'll write up a quick blog on it.

Matt

[bastian_hickl · Accepted solution]

Hi Matt,

sounds great!

Yes we have two tables but they exist in the same database.

There are user data (HCM) in one table and company data with street address, tax number, etc.in the other one.

As I described earlier we got the data of both tabels in VDS and we are able to read the tables's data with an LDAP Browser, but we can't read the schema of both tables.

A blog would be wunderful

Regards,

Bastian

[former_member2987 · Accepted solution]

Oh good, same database, that makes life easier.

Matt

[former_member2987 · Accepted solution]

Hi Bastian,

So I took a look at this and it was much easier than I thought.

Using the Sample Data included with IDM, I was able to do this as follows:

1. Create a Database source pointing to table 1.

2. Create another Database source pointing to table 2

3. Create Static nodes to create the OUs for each

4. Create Dynamic nodes for each source, one per OU

That should do it.  Your application can now query for the data you need by directing the search to the appropriate OU.

If you'd still like a blog on this, let me know.

Matt

[bastian_hickl · Accepted solution]

Hi Matt,

thank you for your efforts.

Are you also able to get the schema for each table by using a LDAP Browser - for example LDAP Admin (or any other tool)?

Regards,

Bastian

[former_member2987 · Accepted solution]

Yep, tested it with Apache and Softerra.

[former_member2987 · Accepted solution]

PM me, and I'll send you the configuration.