Skip Navigation Links | |
Exit Print View | |
Oracle Directory Server Enterprise Edition Administration Guide 11g Release 1 (11.1.1.5.0) |
Part I Directory Server Administration
2. Directory Server Instances and Suffixes
3. Directory Server Configuration
6. Directory Server Access Control
7. Directory Server Password Policy
8. Directory Server Backup and Restore
9. Directory Server Groups, Roles, and CoS
10. Directory Server Replication
13. Directory Server Attribute Value Uniqueness
15. Directory Server Monitoring
Part II Directory Proxy Server Administration
16. Directory Proxy Server Tools
17. Directory Proxy Server Instances
19. Directory Proxy Server Certificates
20. Directory Proxy Server Load Balancing and Client Affinity
21. Directory Proxy Server Distribution
22. Directory Proxy Server Virtualization
Creating and Configuring LDIF Data Views
To Configure an LDIF Data View
Defining Access Control on Virtual Data Views
To Define a New ACI Storage Repository
To Configure Virtual Access Controls
Defining Schema Checking on Virtual Data Views
Creating and Configuring Join Data Views
To Configure a Join Data View to Enable Referencing of a Data View by Multiple Join Data Views
To Configure the Secondary View of a Join View
Creating and Configuring Coordinator Data Views
To Create a Coordinator Data View
To Configure a Coordinator Data View
Creating and Configuring JDBC Data Views
To Configure JDBC Tables, Attributes, and Object Classes
Defining Relationships Between JDBC Tables
Joining an LDAP Directory and a MySQL Database
Configuring and Testing the LDAP Data View
Configuring and Testing the JDBC Data View
Creating and Testing the Join Data View
Joining Multiple Disparate Data Sources
Client Application Requirements
Aggregate Data From the HR LDAP Directory and the Administration LDIF File
Add Data From Company 22 to Example.Com's DIT by Renaming the DN
Add Company 22's Data to the HR Data
Enable LDAP Clients to Access the Payroll Data in an SQL Database
23. Virtual Data Transformations
24. Connections Between Directory Proxy Server and Back-End LDAP Servers
25. Connections Between Clients and Directory Proxy Server
26. Directory Proxy Server Client Authentication
27. Directory Proxy Server Logging
28. Directory Proxy Server Monitoring and Alerts
Part III Directory Service Control Center Administration
The following section provides two sample configurations. These configurations illustrate the main features of a virtual directory, and indicate how these features are configured.
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 22-1 Sample Virtual Configuration
You can use the sample data provided in install-path/resources/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:
Configuring and testing the LDAP data view
Configuring and testing the JDBC data view
Configuring and testing the join data view
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:
1389
pwd.txt, a file containing the administrator password.
4389
cn=Directory Manager
Before You Begin
The tasks in this section assume the following information:
A Directory Server instance is running on host1, on port 4389.
Data in the Directory Server is stored under the suffix dc=example,dc=com. To duplicate this example, create a Directory Server instance, create the suffix dc=example,dc=com, and import the sample data in install-path/resources/ldif/Example.ldif.
% dpconf create-ldap-data-source myds1 host1:4389
% dpconf set-ldap-data-source-prop myds1 is-enabled:true is-read-only:false
% dpconf create-ldap-data-source-pool myds1-pool
% dpconf attach-ldap-data-source myds1-pool myds1
% dpconf set-attached-ldap-data-source-prop myds1-pool myds1 add-weight:100 \ bind-weight:100 modify-weight:100 search-weight:100
% dpconf create-ldap-data-view myds1-view myds1-pool dc=example,dc=com
% 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.
% 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.
The following tasks assume that a MySQL database is installed, running and populated with data, and that the MySQL database has the following characteristics:
Database name : sample_sql
Database URL : host2.example.com:3306/
JDBC driver URL : file:/net/host2.example/local/mysql/lib/jdbc.jar
Driver class : com.mysql.jdbc.Driver
Database user : root
Database password file : mysqlpwd.txt
The following table describes the tables in the database, and their composite fields. You need this information to set up the JDBC data view.
|
% 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
Note - You can set the number of connections for JDBC data source using the num-connection-incr(5dpconf), num-connection-init(5dpconf), and num-connection-limit(5dpconf) JDBC data source properties.
% dpconf set-jdbc-data-source-prop mysql1 db-pwd:sqlpwd db-user:rootUser
The sqlpwd and rootUser are the password and username of the authenticating user and these credentials are stored in the database. You must configure the proxy server with username and password when configuring a JDBC data source.
The db-vendor property of the JDBC data source should be set using set-jdbc-data-source-prop if a third party JDBC driver, which is other than the one provided by DB Vendor, is used to connect to the RDBMS back-end. This data is used to construct vendor specific SQL statements, whenever possible, to improve performance. For more information, see db-vendor(5dpconf).
% dpadm restart /local/dps
% dpconf set-jdbc-data-source-prop mysql1 is-enabled:true is-read-only:false
For more information, see monitoring-inactivity-timeout(5dpconf), monitoring-interval(5dpconf), and monitoring-mode(5dpconf)
% dpconf create-jdbc-data-source-pool mysql1-pool
% dpconf attach-jdbc-data-source mysql1-pool mysql1
% dpconf create-jdbc-data-view mysql1-view mysql1-pool o=sql
% 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.
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 roomNumber ROOM % dpconf add-jdbc-attr phone1 telephoneNumber NUMBER % dpconf add-jdbc-attr country1 countryName NAME
It is not necessary to create JDBC attributes for the phone1 user_id and country1 id columns, because these columns only contain the values that are present in EMPLOYEE.ID for which an LDAP attribute uid is already created.
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
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}
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
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.
% 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
% dpconf create-connection-handler mysql1-handler
% dpconf set-connection-handler-prop mysql1-handler is-enabled:true \ bind-dn-filters:"uid=.*,o=sql"
% dpconf set-connection-handler-prop mysql1-handler aci-source:mysql1
% 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.
% ldapmodify -p 1389 -D "uid=kvaughan,o=sql" -w mypwd dn: uid=kvaughan,o=sql changetype: modify replace: userPassword userPassword: myNewpwd
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
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}
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.
% 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.
% dpconf set-jdbc-data-view-prop mysql1-view viewable-attr:dn \ viewable-attr:objectclass viewable-attr:sn viewable-attr:roomNumber \ viewable-attr:userpassword viewable-attr:jobtitle viewable-attr:countryName \ viewable-attr:telephoneNumber % dpconf set-jdbc-data-view-prop mysql1-view writable-attr:dn \ writable-attr:objectclass writable-attr:sn writable-attr:roomNumber \ writable-attr:userpassword writable-attr:jobtitle \ writable-attr:countryName writable-attr:telephoneNumber
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.
% 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
% dpconf set-connection-handler-prop default-connection-handler aci-source:myjoin1
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.
% ldapmodify -p 1389 dn: uid=kvaughan,ou=people,o=join changetype: modify replace: userPassword userPassword: myPassword
This configuration describes an organization, Example.com, whose specific directory service requirements are met by some of the features of a virtual directory.
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 22-2 Data Storage In Disparate Sources
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 22-3 Client Application Requirements
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 Oracle Directory Server Enterprise Edition Reference and Chapter 18, Directory Proxy Server Virtualization, in Oracle Directory Server Enterprise Edition 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
Add Data From Company 22 to Example.Com's DIT by Renaming the DN
Enable LDAP Clients to Access the Payroll Data in an SQL Database
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 22-4 Aggregation of Data From LDAP Directory and 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:
A Directory Proxy Server instance runs on the local host, with the default LDAP port (389).
The Directory Proxy Server instance is located at /local/myDPS.
The path to the file containing the Proxy Manager password has been set as a variable, LDAP_ADMIN_PWF.
The payroll LDAP directory runs on a host named payrollHost, on port 2389.
The LDIF file used to store the administration data is named example.ldif.
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: dpconf create-ldap-data-view VIEW_NAME POOL_NAME SUFFIX_DN
$ dpconf create-ldap-data-source payroll-directory payrollHost:2389
$ dpconf create-ldap-data-source-pool payroll-pool
$ dpconf attach-ldap-data-source payroll-pool payroll-directory
$ 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
$ dpconf create-ldap-data-view payroll-view payroll-pool o=example.com
$ dpconf set-ldap-data-view-prop payroll-view is-enabled:true
$ dpadm restart /local/myDPS
$ dpconf create-ldif-data-view admin-view example.ldif dc=example,dc=com
$ dpconf set-ldif-data-view-prop admin-view is-enabled:true
$ 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 administrator 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.
$ dpadm restart /local/myDPS
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}
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
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 22-5 DN Renaming
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:
A Directory Proxy Server instance runs on the local host, with the default LDAP port (389).
The Directory Proxy Server instance is located at /local/myDPS.
The path to the file containing the Proxy Manager password has been set as a variable, LDAP_ADMIN_PWF.
The Company 22 LDAP directory runs on a host named company22Host, on port 2389.
$ dpconf create-ldap-data-source company22-directory company22Host:2389
$ dpconf create-ldap-data-source-pool company22-pool
$ dpconf attach-ldap-data-source company22-pool company22-directory
$ dpconf set-attached-ldap-data-source-prop -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
$ dpconf create-ldap-data-view company22-view company22-pool dc=example,dc=com
$ dpconf set-ldap-data-view-prop company22-view \ dn-mapping-source-base-dn:dc=company22,dc=com
$ dpconf set-ldap-data-view-prop company22-view is-enabled:true
$ dpadm restart /local/myDPS
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 22-6 Aggregation of Data From Join Data View and LDAP Data View
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}
$ dpconf create-join-data-view global-join-view example-join-view \ company22-view dc=example,dc=com
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 22-7 JDBC Dataview Providing Access to an SQL Database
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:
A Directory Proxy Server instance runs on the local host, with the default LDAP port (389).
The Directory Proxy Server instance is located at /local/myDPS.
The path to the file containing the Proxy Manager password has been set as a variable, LDAP_ADMIN_PWF.
The SQL database is up and running.
The JAVA_HOME variable has been set to the correct Java path.
The password to the SQL database is myPassword stored in the myPasswordFile file.
$ dpconf create-jdbc-data-source -b payrollsqldb \ -B jdbc:payrollsqldb:payrollsql://localhost/ \ -J file://payrollsqldb.jar \ -S org.payrollsqldb.jdbcDriver payroll-src
$ dpconf set-jdbc-data-source-prop payroll-src \ db-user:proxy db-pwd-file:password-file-location/myPasswordFile
$ dpconf set-jdbc-data-source-prop payroll-src is-enabled:true
$ dpconf create-jdbc-data-source-pool payroll-pool
$ dpconf attach-jdbc-data-source payroll-pool payroll-src
$ dpconf create-jdbc-data-view payroll-view payroll-pool o=payroll
$ dpconf create-jdbc-table jdbc-employee employee $ dpconf create-jdbc-table jdbc-salary salary
$ 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
$ 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
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.
$ dpconf create-jdbc-object-class payroll-view \ person jdbc-employee jdbc-salary eid
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}
$ dpconf set-jdbc-object-class-prop payroll-view person super-class:extensibleObject
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 .
$ 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");)
$ dpconf set-connection-handler-prop anonymous aci-source:ldifonly-acis
$ dpconf set-connection-handler-prop anonymous is-enabled:true