Security Software

Hello,

We've run Sun DS v5.2 for a number of years and have nearly completed upgrading to [O]DSEE 6.3.1/7.0/11.1 with Directory Proxy Server (DPS) fronting the setup.

Our DPS is set up based on the documentation example using inferior/superior subtrees served from different data sources. It "mostly" works, but a few issues remain to be ironed out. I've been working on these for some weeks using various data view configurations, connection handlers, etc--but to no avail--and and I'm starting to run out of ideas.

The data and servers are divided into two major groups: a set of top-level systems presenting (example) naming context dc=a and another group serving subtree dc=b,dc=a. The split tree configuration is primarily for data and security partitioning.

I would like to present data from a common group of DPS instances while maintaining data partitioning between dc=a and dc=b,dc=a pools, and without resorting to a second set of proxies on a separate IP address. One requirement is to disallow subtree queries starting at dc=a (a common use case) from descending into dc=b,dc=a to avoid unnecessary load on subtree back ends, i.e. use excluded-subtrees.

A summary of the current configuration. Problems and questions below.

-----
dpconf set-server-prop ... data-view-automatic-routing-mode:limited

# dc=a : 'root data view' : defaultDataSourcePool
dpconf create-ldap-data-source dsA1 host1.mydomain:1389
...
dpconf attach-ldap-data-source defaultDataSourcePool dsA1 dsA2 ...
dpconf set-attached-ldap-data-source-prop defaultDataSourcePool dsA1 ...
dpconf set-ldap-data-view-prop 'root data view' \
excluded-subtrees:'""' \
excluded-subtrees:cn=config \
excluded-subtrees:cn=monitor \
excluded-subtrees:'cn=proxy manager' \
excluded-subtrees:dc=b,dc=a

# dc=b,dc=a : view-b : pool-b
dpconf create-ldap-data-source dsB1 hostX.mydomain:1389
...
dpconf create-ldap-data-source-pool pool-b
dpconf set-ldap-data-source-pool-prop pool-b \
enable-client-affinity:true \
client-affinity-policy:read-affinity-after-write
dpconf attach-ldap-data-source pool-b dsB1 dsB2 ...
dpconf set-attached-ldap-data-source-prop pool-b dsB1 ...
...

dpconf create-ldap-data-view view-b pool-b dc=b,dc=a
dpconf set-ldap-data-view-prop view-b excluded-subtrees:'""'
...
-----

Problem: On occasion a client bound to dc=b,dc=a will try to fetch the schema ( cn=schema ). With configuration above, the request is routed to top-level pool behind root data view. Because the client's dc=b,dc=a credentials do not exist on the top-level servers, so an error is thrown.

I've tried routing connections bound to dc=b,dc=a using a connection handler, but it doesn't seem to work properly (can't recall the exact problem now), e.g.

-----
dpconf create-connection-handler handler-b
dpconf set-connection-handler-prop handler-b \
bind-dn-filters:"(.*),dc=b,dc=a" \
data-view-routing-custom-list:view-b \
data-view-routing-policy:custom \
enable-data-view-affinity:true \
is-enabled:true ...
-----

I have not configured proxy authorization because it looks to require cross server pool accounts i.e. I'd have to create dc=b,dc=a accounts in the dc=a suffix.

I haven't configured pass-through authentication, as versions of the docs over time seem to have began to discourage its use.

Questions:

I'd like to route all requests bound to dc=b,dc=a to that pool, including queries to rootDSE ("") and cn=schema, i.e. I'd like the view(s) able to serve all three search bases.

I'd like to route all requests bound to dc=a to that pool, including queries to rootDSE ("") and cn=schema.

Anonymous connections can be routed normally: requests to dc=a go to that view, requests to dc=b,dc=a to that view and, say, anonymous requests on rootDSE ("") and cn=schema default to the top-level servers ( dc=a ).

I'd like namingContexts to contain dc=a and possibly (don't care) dc=b=dc=a. I do not want to present rootDSE ("") and cn=schema in namingContexts (I've observed this in some configurations).

Lastly, I'd like to find a configuration that requires (simple) bind to be done over a secure connection (SSL, TLS). I've seen a new ACI for a recent version of DS that would help, but we still have a few DS 5.2 servers in the replication topology, and I don't want to break those. One idea might be to write a connection handler that sends bound connections done over SSL/TLS ( is-ssl-mandatory ) to the proper view, with a subsequent handler that sends bound (i.e. insecure) connections to an empty data view.

How might I accomplish this? I've tried quite a few variations and this post is pretty long, does it make sense to break up the questions?

Thank you!
Tom.