test

Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide

Sample Virtual Configurations

The following section provides two sample configurations. These configurations illustrate the main features of a virtual directory, and indicate how these features are configured.

Joining an LDAP Directory and a MySQL Database

The procedures in this section describe a sample virtual configuration that joins an LDAP directory and a MySQL database. The LDAP directory is the primary data source, that contains most of the user information. The mySQL database contains additional information about the users. The resulting configuration is illustrated in the following figure.

Figure 23–1 Sample Virtual Configuration

Figure shows join data view comprising LDAP data view and JDBC data view

You can use the sample data provided in install-path/ds6/ldif/Example.ldif to duplicate this example, or you can substitute the sample data with your own data.

This configuration can be broken into three sections:

For simplicity, all the commands in this section assume that the Directory Proxy Server is running on the local host in /local/dps. The commands also assume that the following environment variables have been set:

DIR_PROXY_PORT

1389

LDAP_ADMIN_PWF

pwd.txt, a file containing the administrator password.

DIRSERV_PORT

4389

LDAP_ADMIN_USER

cn=Directory Manager

Configuring and Testing the LDAP Data View

ProcedureTo Configure the LDAP Data View

Before You Begin

The tasks in this section assume the following information:

  1. Create an LDAP data source named myds1 for the Directory Server instance.


    % dpconf create-ldap-data-source myds1 host1:4389

  2. Enable the data source, and allow write operations to the data source.


    % dpconf set-ldap-data-source-prop myds1 is-enabled:true is-read-only:false

  3. Create an LDAP data source pool named myds1-pool.


    % dpconf create-ldap-data-source-pool myds1-pool

  4. Attach the LDAP data source to the LDAP data source pool.


    % dpconf attach-ldap-data-source myds1-pool myds1

  5. Specify that the data source should receive 100% of the bind, add, search, and modify operations from that data source pool.


    % dpconf set-attached-ldap-data-source-prop myds1-pool myds1 add-weight:100 \
 bind-weight:100 modify-weight:100 search-weight:100

  6. Create an LDAP data view for the data source pool, named myds1–view, with a base DN of dc=example,dc=com.


    % dpconf create-ldap-data-view myds1-view myds1-pool dc=example,dc=com

ProcedureTo Test the LDAP Data View

  1. As a user under dc=example,dc=com, search all entries in the LDAP data source to verify that you can read from the data view. 


    % ldapsearch -p 1389 -D "uid=kvaughan,ou=people,dc=example,dc=com" -w bribery \
 -b dc=example,dc=com "objectclass=*"
    Note –

    You must use the credentials of a user under dc=example,dc=com. If you want to use cn=Directory Manager, you must define a data view to handle that DN.

  2. As a user under dc=example,dc=com, modify the userPassword attribute to verify that you can write to the data view.


    % ldapmodify -p 1389 -D "uid=kvaughan,ou=people,dc=example,dc=com" -w bribery
dn: uid=kvaughan,ou=people,dc=example,dc=com
changetype: modify
replace: userPassword
userPassword: myNewPassword
    Note –

    A default ACI in Directory Server allows users to modify their own passwords.

Configuring and Testing the JDBC Data View

The following tasks assume that a mySQL database is installed, running and populated with data, and that the mySQL database has the following characteristics:

The following table describes the tables in the database, and their composite fields. You need this information to set up the JDBC data view.

mySQL Table 

Fields 

EMPLOYEE

ID, SURNAME,PASSWORD, TITLE, COUNTRY_ID

COUNTRY

ID, NAME

PHONE

USER_ID, NUMBER

ProcedureTo Configure the JDBC Data View

  1. Create a JDBC data source named mysql1 for the SQL database. 


    % dpconf create-jdbc-data-source -b sample_sql -B jdbc:mysql://host2.example.com:3306 \
 -J file:/net/host2.example/local/mysql/lib/jdbc.jar -S com.mysql.jdbc.Driver mysql1

  2. Specify the user name and password file for the SQL database.


    % dpconf set-jdbc-data-source-prop mysql1 db-pwd-file:sqlpwd.txt db-user:root

  3. Restart the proxy server.


    % dpadm restart /local/dps

  4. Enable the data source, and allow write operations to the data source.


    % dpconf set-jdbc-data-source-prop mysql1 is-enabled:true is-read-only:false

  5. Create a JDBC data source pool named mysql1–pool.


    % dpconf create-jdbc-data-source-pool mysql1-pool

  6. Attach the JDBC data source to the data source pool.


    % dpconf attach-jdbc-data-source mysql1-pool mysql1

  7. Create a JDBC data view for the data source pool, named myjdbc1–view, with a base DN of o=sql.


    % dpconf create-jdbc-data-view mysql1-view mysql1-pool o=sql

  8. Create a JDBC table for each table in the MySQL database.


    % dpconf create-jdbc-table employee1 EMPLOYEE
% dpconf create-jdbc-table country1 COUNTRY
% dpconf create-jdbc-table phone1 PHONE

    The name of the table in the SQL database is case sensitive. Make sure that you use the same case that is used in the SQL database.

  9. Create a JDBC attribute for each column in each table.

    Creating a JDBC attribute maps the MySQL column to an LDAP attribute.


    % dpconf add-jdbc-attr employee1 uid ID
% dpconf add-jdbc-attr employee1 sn SURNAME
% dpconf add-jdbc-attr employee1 userPassword PASSWORD
% dpconf add-jdbc-attr employee1 room ROOM
% dpconf add-jdbc-attr phone1 tel NUMBER
% dpconf add-jdbc-attr country1 country NAME

    It is not necessary to create JDBC attributes for the phone1 user_id and country1 id columns, because these columns are used only in the context of the MySQL database. They will not have a corresponding LDAP attribute.

  10. Create a JDBC object class for the LDAP person object class.

    In this step, the employee1 table is identified as the primary table, and the country1 and phone1 tables are identified as secondary tables. The creation of a JDBC object class also requires a DN. In this example, the DN is constructed from the uid attribute and the base DN of the data view.


    % dpconf create-jdbc-object-class mysql1-view person employee1 country1 phone1 uid

  11. Define the join rules between the primary table and the secondary tables.

    A join rule is defined on the secondary table and determines how data from that table is linked to data from the primary table.


    % dpconf set-jdbc-table-prop country1 filter-join-rule:'ID=${EMPLOYEE.COUNTRY_ID}'
% dpconf set-jdbc-table-prop phone1 filter-join-rule:'USER_ID=${EMPLOYEE.ID}'

  12. Specify the super class for the JDBC object class.

    The super class indicates the LDAP object class from which the JDBC object class inherits attributes.


    % dpconf set-jdbc-object-class-prop mysql1-view person super-class:top

ProcedureTo Create the Required ACIs

Before you can test the JDBC data view, you must enable write access to the data view by configuring ACIs. By default, write access to non-LDAP data views is denied. For the purposes of this example, it is sufficient to add one global ACI that allows users to modify their own passwords.

  1. As the Proxy Manager, add a pool of ACIs to the JDBC data source and add a global ACI that allows users to modify their own entries.


    % ldapmodify -p 1389 -D "cn=proxy manager" -w password
dn: cn=mysql1,cn=virtual access controls
changetype: add
objectclass: acisource
dpsaci: (targetattr="*") (target = "ldap:///o=sql") \
 (version 3.0; acl "enable all access for all users "; allow(all) \
userdn="ldap:///uid=kvaughan,o=sql";)
cn: mysql1

  2. Create a connection handler to handle connections to the o=sql domain.


    % dpconf create-connection-handler mysql1-handler

  3. Enable the connection handler and configure it to handle all binds from users in the o=sql domain.


    % dpconf set-connection-handler-prop mysql1-handler is-enabled:true \
 bind-dn-filters:"uid=.*,o=sql"

  4. Configure the connection handler to use the pool of ACIs added previously.


    % dpconf set-connection-handler-prop mysql1-handler aci-source:mysql1

ProcedureTo Test the JDBC Data View

  1. As a user under o=sql, search the JDBC data source to verify that you can read from the data view. 


    % ldapsearch -p 1389 -D "uid=kvaughan,o=sql" -w mypwd -b o=sql "objectclass=*"
    Note –

    You must use the credentials of a user under o=sql, or an anonymous bind.

  2. As a user under o=sql, modify the userPassword attribute to verify that you can write to the data view.


    % ldapmodify -p 1389 -D "uid=kvaughan,o=sql" -w mypwd
dn: uid=kvaughan,o=sql
changetype: modify
replace: userPassword
userPassword: myNewpwd

Creating and Testing the Join Data View

ProcedureTo Create the Join Data View

  1. Create a join data view named myjoin1–view.

    Specifying the LDAP data view as the primary data view, and the JDBC data view as the secondary data view.


    % dpconf create-join-data-view myjoin1-view myds1-view mysql1-view o=join

  2. Define a join rule on the secondary data view.

    The following join rule specifies that the uid attribute of entries from the secondary data view should match the uid attribute of entries from the primary data view.


    % dpconf set-jdbc-data-view-prop mysql1-view filter-join-rule:uid='${myds1-view.uid}'

  3. If the filter join rule is set on the join data view, you need to set a virtual transformation rule on the secondary data view to be able to add an entry on the join data view.


    dpconf add-virtual-transformation secondary-view-name \
write add-attr-value dn uid=\${uid}
    Note –

    Without setting this rule, addition of entries to join data view would not be possible.

  4. Define the set of attributes that can be read from and written to the primary data view through a join data view.


    % dpconf set-ldap-data-view-prop myds1-view viewable-attr:dn viewable-attr:cn \
 viewable-attr:sn viewable-attr:givenName viewable-attr:objectClass viewable-attr:ou \
 viewable-attr:l viewable-attr:uid viewable-attr:mail viewable-attr:telephoneNumber \
 viewable-attr:facsimileTelephoneNumber viewable-attr:roomNumber viewable-attr:userPassword
% dpconf set-ldap-data-view-prop myds1-view writable-attr:dn writable-attr:cn \
 writable-attr:sn writable-attr:givenName writable-attr:objectClass writable-attr:ou \
 writable-attr:l writable-attr:uid writable-attr:mail writable-attr:telephoneNumber \
 writable-attr:facsimileTelephoneNumber writable-attr:roomNumber writable-attr:userPassword

    These definitions apply only in the context of the join view. By default all attributes can be read and written if you access the LDAP data view directly.

  5. Define the set of attributes that can be read from and written to the secondary data view through a join data view.


    % dpconf set-jdbc-data-view-prop mysql1-view viewable-attr:dn viewable-attr:objectclass \
 viewable-attr:sn viewable-attr:room viewable-attr:userpassword viewable-attr:jobtitle \
 viewable-attr:country viewable-attr:tel
% dpconf set-jdbc-data-view-prop mysql1-view writable-attr:dn writable-attr:objectclass \
 writable-attr:sn writable-attr:room writable-attr:userpassword writable-attr:jobtitle \
 writable-attr:country writable-attr:tel

    These definitions apply only in the context of the join view. By default all attributes can be read and written if you access the JDBC data view directly.

ProcedureTo Create the Required ACIs

  1. As the proxy manager, add a global ACI that allows anonymous access to the join data view.


    % ldapmodify -p 1389 -D "cn=proxy manager" -w password
dn: cn=myjoin1,cn=virtual access controls
changetype: add
objectclass: acisource
dpsaci: (targetattr="*") (target = "ldap:///o=join") \
 (version 3.0; acl "anonymous_access"; allow(all) userdn="ldap:///anyone";)
cn: myjoin1

  2. Create a connection handler to handle connections to the o=join domain.


    % dpconf create-connection-handler myjoin1-handler

  3. Enable the connection handler and configure it to handle all binds from users under o=join.


    % dpconf set-connection-handler-prop myjoin1-handler is-enabled:true \
 bind-dn-filters:"uid=.*,ou=people,o=join"

  4. Configure the connection handler to use the pool of ACIs added previously.


    % dpconf set-connection-handler-prop myjoin1-handler aci-source:myjoin1

ProcedureTo Test the Join Data View

  1. As an anonymous user, search the join data view.

    In this step, we search Kirsten Vaughan's entry to see whether data from both join views is retrieved.


    % ldapsearch -p 1389 -b o=join "uid=kvaughan"

    Note that the returned entry includes the attributes from both the LDAP data view and the JDBC data view.

  2. As a user under o=join, modify the userPassword attribute to verify that you can write to the join data view.


    % ldapmodify -p 1389 -D "uid=kvaughan,ou=people,o=join" -w myNewPassword
dn: uid=kvaughan,ou=people,o=join
changetype: modify
replace: userPassword
userPassword: myPassword

Joining Multiple Disparate Data Sources

This configuration describes an organization, Example.com, whose specific directory service requirements are met by some of the features of a virtual directory.

Data Storage Scenario

Example.com stores organizational data in multiple disparate data sources. For legacy reasons, user data is spread across an LDAP directory, a flat LDIF file, and an SQL database. The HR department stores user data in an LDAP directory, with a base DN of o=example.com. The Payroll department stores data in an SQL database. Administrative data such as departments and building numbers is stored by the administration department in an LDIF file, with a base DN of dc=example,dc=com.

In addition, Example.com has acquired a company named Company22. Company 22 also stores its user data in an LDAP directory, with a base DN of dc=company22,dc=com.

The following diagram provides a high level view of how Example.com's user data is stored.

Figure 23–2 Data Storage In Disparate Sources

Figure shows how Example.com's user data is stored in disparate data sources

Client Application Requirements

Example.com has several LDAP client applications that require access to the data stored in the disparate data sources. The requirements of the client applications are not all the same. Different views of the data are required. In some cases, the clients require the data to be aggregated. In addition, some client applications require access to Company22's user data so that these new employees of Example.com can be administered along with the old employees.

The following diagram provides a high level view of Example.com's client application requirements.

Figure 23–3 Client Application Requirements

Figure shows the requirements of Example.com's LDAP applications

The following sections walk you through sufficient configuration Directory Proxy Server data views to meet the client application requirements described in this sample scenario. For information about how data views work, see Chapter 17, Directory Proxy Server Distribution, in Sun Java System Directory Server Enterprise Edition 6.2 Reference and Chapter 18, Directory Proxy Server Virtualization, in Sun Java System Directory Server Enterprise Edition 6.2 Reference.

The configuration of the sample scenario is divided into the following sections:

Aggregate Data From the HR LDAP Directory and the Administration LDIF File

The HR department stores information such as employee names, job start data, and job level. The administration department stores additional data such as building codes and office numbers. The client application that handles the HR data requires access to the combined data from both sources. Both data sources have a common attribute, the employeeNumber that exists in each entry.

The following diagram illustrates the requirements of the client application.

Figure 23–4 Aggregation of Data From LDAP Directory and LDIF File

Figure shows a join view of an LDAP directory and an LDIF file

To fulfill this application requirement, a data view is created for the payroll directory and for the administration LDIF file. These two data views are then joined to provide access to the aggregated data. This common attribute enables Directory Proxy Server to aggregate the data for each user.

For simplicity, the commands used in this section assume the following information:

To obtain the complete syntax of each command, run the command without any options. For example:

$ dpconf create-ldap-data-view
Operands are missing
Usage: dpcfg create-ldap-data-view VIEW_NAME POOL_NAME SUFFIX_DN

ProcedureCreate and Enable an LDAP Data View for the Payroll Directory

  1. Create an LDAP data source for the payroll directory.

    $ dpconf create-ldap-data-source payroll-directory payrollHost:2389

  2. Create an LDAP data source pool for the payroll directory.

    $ dpconf create-ldap-data-source-pool payroll-pool

  3. Attach the payroll data source to the data source pool.

    $ dpconf attach-ldap-data-source payroll-pool payroll-directory

  4. Configure the weights of the attached data source.

    $ dpconf set-attached-ldap-data-source-prop -h payrollHost -p 2389 \
payroll-pool payroll-directory add-weight:2 \
bind-weight:2 compare-weight:2 delete-weight:2 \
modify-dn-weight:2 modify-weight:2 search-weight:2

  5. Create an LDAP data view for the payroll directory.

    $ dpconf create-ldap-data-view payroll-view payroll-pool o=example.com

  6. Enable the LDAP data view so that client requests can be routed to this data view.

    $ dpconf set-ldap-data-view-prop payroll-view is-enabled:true

  7. Restart Directory Proxy Server for the changes to take effect.

    $ dpadm restart /local/myDPS

ProcedureCreate and Enable an LDIF Data View for the Administration Data

  1. Create an LDIF data view for the administration data.

    $ dpconf create-ldif-data-view admin-view example.ldif dc=example,dc=com

  2. Enable the LDIF data view for the administration data.

    $ dpconf set-ldif-data-view-prop admin-view is-enabled:true

  3. Specify that the admin view contains entries that are used by more than one entry in the payroll view.

    $ dpconf set-ldif-data-view-prop admin-view contains-shared-entries:true

    When this property is set to TRUE, deleting an entry in the payroll data view will not result in the deletion of the shared entry in the admin data view. Adding an entry to the payroll data view will only add the entry to the secondary data view if it does not already exist.

  4. Restart Directory Proxy Server for the changes to take effect.

    $ dpadm restart /local/myDPS

ProcedureJoin the Payroll Data View and the Admin Data View

  1. Create a filter join rule on the admin data view that specifies how the data should be aggregated.

    The following join rule specifies that data should be joined based on the employeeNumber attribute of the user entry.

    $ dpconf set-ldif-data-view-prop admin-view \
filter-join-rule:'employeeNumber=\${payroll-view.employeeNumber}'

  2. Create a join data view that aggregates the two data views.

    For the join data view, the organization uses the suffix DN dc=example,dc=com.

    $ dpconf create-join-data-view example-join-view payroll-view admin-view \
dc=example,dc=com

Add Data From Company 22 to Example.Com's DIT by Renaming the DN

The user data for Company 22 is stored under the DN dc=company22,dc=com. While Example.com wants to keep this user data separate in most cases, one client application needs to administer Company 22 employees along with the rest of the Example.com employees. This client application requires Company 22's user data to look like Example.com data.

The following diagram illustrates the requirements of the client application.

Figure 23–5 DN Renaming

Figure shows rename a DN to add data to a DIT

To fulfill this application requirement, a data view with a virtual DN of dc=example,dc=com is created for the Company 22's directory.

For simplicity, the commands used in this section assume the following information:

ProcedureCreate a Data View For Company 22's Directory With a Virtual DN

  1. Create an LDAP data source for Company 22's directory.

    $ dpconf create-ldap-data-source company22-directory company22Host:2389

  2. Create an LDAP data source pool for Company 22's directory.

    $ dpconf create-ldap-data-source-pool company22-pool

  3. Attach Company 22's data source to the data source pool.

    $ dpconf attach-ldap-data-source company22-pool company22-directory

  4. Configure the weights of the attached data source.

    $ dpconf set-attached-ldap-data-source-prop -h company22Host -p 2389 \
company22-pool company22-directory add-weight:2 \
bind-weight:2 compare-weight:2 delete-weight:2 \
modify-dn-weight:2 modify-weight:2 search-weight:2

  5. Create an LDAP data view for Company 22's directory with a virtual DN of dc=example,dc=com.

    $ dpconf create-ldap-data-view company22-view company22-pool dc=example,dc=com

  6. Instruct Directory Proxy Server to map this virtual DN to the real DN that is in Company 22's directory.

    $ dpconf set-ldap-data-view-prop company22-view \
dn-mapping-source-base-dn:dc=company22,dc=com

  7. Enable the LDAP data view for Company 22's directory so that client requests can be routed to this data view.

    $ dpconf set-ldap-data-view-prop company22-view is-enabled:true

  8. Restart Directory Proxy Server for the changes to take effect.

    $ dpadm restart /local/myDPS

Add Company 22's Data to the HR Data

The HR department requires an aggregated view of the HR data for Example.com and the newly acquired Company 22. The following diagram illustrates the requirements of the global HR application.

Figure 23–6 Aggregation of Data From Join Data View and LDAP Data View

Figure shows a complex join view of an LDAP directory and another join view

ProcedureJoin the Example Join Data View and the Company 22 Data View

  1. Create a filter join rule on the Company 22 data view that specifies how the data should be aggregated.

    The following join rule specifies that data should be joined based on the employeeNumber attribute of the user entry.

    $ dpconf set-ldif-data-view-prop company22-view \
filter-join-rule:'employeeNumber=\${example-join-view.employeeNumber}'

  2. Create a join data view that aggregates Company 22's data view and Example.com's join data view.

    $ dpconf create-join-data-view global-join-view example-join-view \
company22-view dc=example,dc=com

Enable LDAP Clients to Access the Payroll Data in an SQL Database

Example.com's payroll department stores salary data in an SQL database. The database has two tables, and employee table and a salary table. Example.com has an LDAP client application that requires access to that data. The client application requires the SQL data to look like LDAP data.

The following diagram illustrates the requirements of the client application.

Figure 23–7 JDBC Dataview Providing Access to an SQL Database

Figure shows JDBC data view providing access to an SQL datbase

To fulfill this application requirement, a JDBC data view is created that maps columns in the SQL tables to LDAP attributes.

For simplicity, the commands used in this section assume the following information:

ProcedureCreate a JDBC Data View For Example.com's Payroll Database

  1. Create a JDBC data source for the payroll database.

    $ dpconf create-jdbc-data-source -b payrollsqldb \
  -B jdbc:payrollsqldb:payrollsql://localhost/ \
  -J file://payrollsqldb.jar \
  -S org.payrollsqldb.jdbcDriver payroll-src

  2. Configure the JDBC data source with the properties of the SQL database.

    $ dpconf set-jdbc-data-source-prop payroll-src \
  db-user:proxy
  db-pwd-file:password-file-location/myPasswordFile

  3. Enable the JDBC data source.

    $ dpconf set-jdbc-data-source-prop payroll-src is-enabled:true

  4. Create a JDBC data source pool for the payroll database.

    $ dpconf create-jdbc-data-source-pool payroll-pool

  5. Attach the payroll data source to the data source pool.

    $ dpconf attach-jdbc-data-source payroll-pool payroll-src

  6. Create a JDBC data view for the payroll database, with a virtual DN of o=payroll.

    $ dpconf create-jdbc-data-view payroll-view payroll-pool o=payroll

  7. Create a JDBC table for each table in the SQL database.

    $ dpconf create-jdbc-table jdbc-employee employee
$ dpconf create-jdbc-table jdbc-salary salary

  8. Add a JDBC attribute for each column in the SQL tables.

    $ dpconf add-jdbc-attr jdbc-employee eid employee_id
$ dpconf add-jdbc-attr jdbc-employee first firstname
$ dpconf add-jdbc-attr jdbc-employee last lastname
$ dpconf add-jdbc-attr jdbc-employee description description
$ dpconf add-jdbc-attr jdbc-employee spouse spousename
$ dpconf add-jdbc-attr jdbc-salary salary salary
$ dpconf add-jdbc-attr jdbc-salary social ssn

  9. Specify which attributes can be viewed and which can be written, through the JDBC data view.

    $ dpconf set-jdbc-data-view-prop payroll-view \
 viewable-attr:eid \
 viewable-attr:first \
 viewable-attr:last \
 viewable-attr:desc \
 viewable-attr:spouse \
 viewable-attr:salary \
 viewable-attr:social 
 $ dpconf set-jdbc-data-view-prop payroll-view \
 writable-attr:eid \
 writable-attr:first \
 writable-attr:last \
 writable-attr:description \
 writable-attr:spouse \
 writable-attr:salary \
writable-attr:social

  10. Create a JDBC object class that maps to an LDAP object class.

    The following command creates an object class that maps to the LDAP person object class. The object class specifies that the employee table should be used as the primary table, and that the salary table should be used as the secondary table. The eid attribute should be used to construct the DN.

    $ dpcfg create-jdbc-object-class payroll-view \
 person jdbc-employee jdbc-salary eid

  11. Create a filter join rule on the secondary table that specifies how data from the secondary table should be linked to data from the primary table.

    The following join rule specifies that data should be joined based on the employee_id attribute.

    $ dpconf set-jdbc-table-prop jdbc-salary \
filter-join-rule:'employee_id=\${employee.employee_id}'

  12. Create a super class on the JDBC object class.

    $ set-jdbc-object-class-prop payroll-view person super-class:extensibleObject

Add Virtual Access Control

Access control on LDAP directories is handled by defining ACIs in the directories themselves. When data sources are accessed through virtual data views, ACIs must be defined that apply only to the data viewed through these data views.

Any access that goes through Directory Proxy Server is controlled by a connection handler. For information about connection handlers, see Chapter 25, Connections Between Clients and Directory Proxy Server .

ProcedureAdd an ACI That Allows Anonymous Access

  1. Add the ACI.

    $ ldapadd -v -D "cn=proxy manager" -w password -p 389
dn: cn=ldifonly-acis,cn=virtual access controls
objectclass: top
objectclass: aciSource
cn: ldifonly-acis
dpsaci: (targetattr="*")(version 3.0; acl "anonymous_access"; allow(all) \
(userdn="ldap:///anyone");)

  2. Point the connection handler to the virtual ACI.

    $ dpconf set-connection-handler-prop anonymous aci-source:ldifonly-acis

  3. Enable the connection handler.

    $ dpconf set-connection-handler-prop anonymous is-enabled:true