This section lists the known problems and limitations that are found at the time of the Directory Proxy Server 6.3.1 update 1 release.
Known issues and limitations in Directory Proxy Server 6.3.1 persist even after the patch for Directory Proxy Server 6.3.1 update 1 is applied. Refer to Known Problems and Limitations in Directory Proxy Server for information about these issues.
This section lists the known limitation that is found at the time of the Directory Proxy Server 6.3.1 update 1 release.
As described in JDBC Object Classes in Sun Java System Directory Server Enterprise Edition 6.3 Reference, defining JDBC tables uses primary and secondary tables. Directory Proxy Server does not allow a secondary table to be the primary table of a third table. That is, Directory Proxy Server does not support more than one level of join-rule.
This section lists the known problems that are found at the time of the Directory Proxy Server 6.3.1 update 1 release.
In release 6.3, if an entry has more than two object classes, adding an entry through a join view (LDAP and JDBC) fails because of the fix for CR 6636463. To add such an entry, these object classes must be defined as a super-class in the jdbc-object-class configuration entry by the following ldapmodify, because dpconf set-jdbc-object-class-prop can add only one super-class.
This example adds the following entry:
dn: uid=test,ou=people,o=join sn: User cn: Test User objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson uid: test userpassword: password givenname: Test mail: test@example.com telephonenumber: 8888-8888 roomnumber: 8000
The JDBC view is defined as shown in the following example, which was functional before release 6.3.
dn: cn=person,cn=example-view,cn=data views,cn=config secondaryTable: country1 secondaryTable: phone1 primaryTable: employee1 objectClass: top objectClass: configEntry objectClass: jdbcObjectClassMapping dnPattern: uid cn: person superclass: top
Because objectClass:organizationalPerson and objectClass:inetOrgPerson both exist in the entry being added, it is necessary to specify both object classes as super classes, as demonstrated by following ldapmodify command.
$ ldapmodify -p dpsPort -D "cn=Proxy manager" -w password dn: cn=person,cn=example-view,cn=data views,cn=config changetype: modify add: superClass superClass: inetOrgPerson - add: superClass superClass: organizationalPerson |
After this ldapmodify example runs, jdbc-object-class is defined as shown in the following example.
dn: cn=person,cn=example-view,cn=data views,cn=config secondaryTable: country1 secondaryTable: phone1 primaryTable: employee1 objectClass: top objectClass: configEntry objectClass: jdbcObjectClassMapping dnPattern: uid cn: person superclass: top superclass: inetOrgPerson Added superclass: organizationalPerson Added
Although the default setting for the log-level-data-sources-detailed property is documented as being none, the actual default value is all. However, setting log-level-data-sources-detailedto any value other than none impacts server performance and makes the access file grow quickly. For that reason, the value of the log-level-data-sources-detailed setting is automatically set to none when a DPS server instances is created. It is recommended that you not set this setting to some other value.
Because of a problem described in Vulnerability Note VU#836068, MD5 vulnerable to collision attacks, Directory Proxy Server should avoid using the MD5 algorithm in signed certificates.
Use the following steps to determine the signature algorithm of a certificate.
Run the following command to display the list of certificates defined in a specific Directory Proxy Server instance:
$ dpadm list-certs instance-path |
Run the following commands on each defined certificate to determine whether the certificate is signed with the MD5 algorithm:
$ dpadm show-cert -F ascii -o cert-output-file \ dps-instance-path cert-alias $ dsadm add-cert ds-instance-path cert-alias \ cert-output-file $ dsadm show-cert ds-instance-path cert-alias |
The following example shows typical output from the dsadm show-cert command for a certificate signed with the MD5 signature algorithm:
Certificate: Data: ... Signature Algorithm: PKCS #1 MD5 With RSA Encryption ... |
Run the following command to remove any MD5–signed certificates from the database:
$ dsadm remove-cert instance-path cert-alias |
Use the following steps to update the certificate database password. (The dpadm command generates a default certificate database password when creating a directory proxy server instance.)
Stop the Directory Proxy Server instance.
Run the following command:
$ dpadm set-flags instance-path cert-pwd-prompt=on |
A message appears, prompting you for a password.
Enter a password that is at least eight characters long.
Restart the Directory Proxy Server instance and provide the Internal (Software) Token when prompted for it.
Replace any certificates using the MD5 function with certificates that use the SHA-1 signature algorithm. Use one of the following procedures, depending on whether your installation uses a self-signed certificate or a certificate acquired from a Certificate Authority.
Use the following steps to generate and store a self-signed certificate:
Run the following command:
$ dpadm add-selfsign-cert --sigalg SHA1withRSA \ dps-instance-path cert-alias |
The default signature algorithm is MD5withRSA.
The following prompt appears:
[Password or Pin for "NSS Certificate DB"] |
Enter the new certificate database password.
Use the following steps to generate and store a certificate acquired from a Certificate Authority (CA):
Run the following command to issue a CA-Signed Server Certificate request:
$ dpadm request-cert --sigalg SHA1withRSA instance-path cert-alias |
Make sure that your Certificate Authority is no longer using the MD5 signature algorithm, and then send the certificate request to the Certificate Authority (either internal to your company or external, depending on your rules) to receive a CA-signed server certificate as described in To Request a CA-Signed Server Certificate in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.
When the Certificate Authority sends you the new certificate, run the following command to add the certificate to the certificates database:
$ dpadm add-cert instance-path cert-alias |
This step is described in Creating, Requesting and Installing Certificates for Directory Proxy Server in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.
If the trusted Certificate Authority certificate is not already stored in the certificate database, run the following command to add it:
$ dpadm add-cert --ca instance-path trusted-cert-alias |
This step is described in Creating, Requesting and Installing Certificates for Directory Proxy Server in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.
Run the following commands to verify that the new certificate is being used.
$ dpadm show-cert -F ascii -o cert-output-file \ dps-instance-path cert-alias $ dsadm add-cert ds-instance-path cert-alias \ cert-output-file $ dsadm show-cert ds-instance-path cert-alias |
With a Microsoft SQL Server back end, when using smalldate fields, only the long version of dates are supported, or else a conversion error occurs, as shown in the following example.
ldap_modify: Operations error ldap_modify: additional info: java.lang.Exception: \ com.microsoft.sqlserver.jdbc.SQLServerException: \ Conversion failed when converting datetime from character string. |
The long version of a date uses the form YYYY-MM-DD HH:MM.