Showing results for 
Search instead for 
Did you mean: 

Exposing Directory Server cn=config through a proxy server

UnboundID PedroT
0 Kudos


4.x to 5.x


Use Case 

If you want to search the cn=config branch of a Directory Server via a Proxy Server, the Proxy Server, which has it's own cn=config branch, will try and process this operation locally instead of passing it through to the Directory Server cn=config backend.  In order to allow searches to pass through the Proxy Server you need to create a new subtree view in the Proxy Server and then add some connection and request criteria around it so that only operations from certain clients for the cn=config branch will be passed through to the Directory Server.


The use case that this was built around was were a client application needed to read the details of the user assigned password policy.  By default the application did not have access to this information so a number of config changes on both the Directory and Proxy Server had to be made.  The following article describes these changes.


Use Case 

 Application uses an account to proxy-auth as other accounts in the system to do various tasks.  The below example shows these two entries and the configuration changes required for this to work.

Here is the system accounts used (abbreviated):

Proxy Auth Account:
dn: uid=idsvcUser,ou=systems,dc=example,dc=com
uid: idsvUser
ds-privilege-name: proxied-auth

Account to be used:
dn: uid=itUser,ou=systems,dc=example,dc=com
uid: idsvUser2
ds-privilege-name: config-read

In the above entries the idsvcUser account is the one that is authenticating to the directory server and submitting the search request for the password policy information as the itUser.  The itUser must have the config-read privilege add to it's account.

Search Operation:

bin/ldapsearch -D "uid=idsvcUser,ou=systems,dc=example,dc=com" -w 
password -p 1389 --proxyas "dn: uid=itUser,ou=systems,dc=example,dc=com"
-b "cn=Default Password Policy,cn=Password Policies,cn=config" objectclass=*


Directory Server Configuration Changes

In order for the above accounts to have access to the cn=config branch we need to modify and existing Global ACI and then add a new one. 

  1. First replace the Global ACI that allows the cn=Proxy User account to proxy across all backends and add the idscvUser account to the list of accounts that can do this.  The new ACI should look as follows:
    (targetattr="*")(version 3.0; acl "Proxy User Access"; allow(proxy) 
    userdn="ldap:///cn=Proxy User,cn=Root DNs,cn=config || 
    ldap:///uid=idsvUser,ou=systems,dc=example,dc=com ";)

  2. Next you need to add a new Global ACI that allows the itUser to read information from cn=config.  This ACI should look as follows:

    (version 3.0; acl "Read and Search on cn=config"; allow (read,search) 

    Proxy Server Configuration Changes While the ACI's are enough to allow this if the operations are sent directly to the Directory Server, once they are passed through the Proxy Server, the operation will fail as it will process the search locally.  To fix this we need to a new sub-tree view to the configuration of the proxy server to allow these searches to pass through for certain clients.
    Here are the steps to do that:


  1. First we need create a new load balancing algorithm (or you can use an existing one).  You can list the servers in your topology in place of what I have listed here but the names must match the external servers configured in the proxy.
    dsconfig create-load-balancing-algorithm 
    --algorithm-name ds_config_LoadBalancer 
    --type failover --set enabled:true 
    --set backend-server: 
    --set backend-server:
  2. Next you need a request processor that is for this specific operations that will direct operations for cn=config to the directory servers.
    dsconfig create-request-processor --processor-name
    ds_config_RequestProcessor --type proxying 
    --set load-balancing-algorithm:ds_config_LoadBalancer

  3. The next configuration object is the Subtree View which exposes the cn=config backend from the directory servers to the clients of the proxy server.
    dsconfig create-subtree-view 
    --view-name ds_config_VIEW 
    --set base-dn:cn=config 
    --set request-processor:ds_config_RequestProcessor
  4. You need to restrict however who can see the information in cn=config since you cannot direct all searches for cn=config to the directory server since then some proxy tools won't work properly.  In this case we will restrict this new subtree view to only users that are based in the "ou=systems,dc=example,dc=com" branch. 
    dsconfig create-connection-criteria
     --criteria-name ds_config_ConnectionCriteria 
    --type simple 
    --set included-user-base-dn:ou=systems,dc=example,dc=com
  5. The next configuration is the request criteria which will then restrict which types of requests are going to one routed to this new subtree view.  In this case we want to only route request for searches against the cn=config branch.  This combined with the connection-criteria above will scope which operations this targets.
    dsconfig create-request-criteria 
    --criteria-name ds_config_RequestCriteria 
    --type simple 
    --set included-target-entry-dn:cn=config --set connection-criteria:ds_config_ConnectionCriteria

  6. Finally we need to create the client connection policy that ties all of this together.  The key is also to make this have an evaluation order of 1 so that it is evaluated before the normal client connection policy is evaluated. 
    dsconfig create-client-connection-policy --policy-name ds_config_ClientConnnectionPolicy --set enabled:true 
    --set evaluation-order-index:1 
    --set subtree-view:ds_config_VIEW --set connection-criteria:ds_config_ConnectionCriteria 
    --set subtree-view:dc_example_dc_com-view

Now searches like the one listed above will pass through to the Directory Server and return the password policy information from the cn=config branch of one of the servers.