test

Notas de la versión de Sun Java System Directory Server Enterprise Edition 6.3.1

Problemas conocidos y limitaciones de Directory Proxy Server 6.3.1 Update 1

En esta sección, se enumeran los problemas conocidos y las limitaciones encontradas en el momento del lanzamiento de Directory Proxy Server 6.3.1 update 1.

Nota –

Los problemas conocidos y las limitaciones de Directory Proxy Server 6.3.1 persisten incluso tras la ejecución del parche para Directory Proxy Server 6.3.1 update 1. Para obtener más información sobre estos problemas, consulte Limitaciones y problemas conocidos de Directory Proxy Server.

Limitaciones conocidas de Directory Proxy Server 6.3.1 Update 1

En esta sección, se muestra la limitación detectada en el momento del lanzamiento de Directory Proxy Server 6.3.1.

Como se describe en el apartado JDBC Object Classes de Sun Java System Directory Server Enterprise Edition 6.3 Reference, la definición de tablas JDBC utiliza tablas principales y secundarias. Directory Proxy Server no permite que una tabla secundaria sea la tabla principal de una tercera tabla. Esto es, Directory Proxy Server no admite más de un nivel de join-rule.

Problemas conocidos de Directory Proxy Server 6.3.1 Update 1

En esta sección, se muestran los problemas detectados en el momento del lanzamiento de Directory Proxy Server 6.3.1 update 1.

6728746

En la versión 6.3, si una entrada tiene más de dos clases de objeto, falla la adición de una entrada por medio de una vista conjunta (LDAP y JDBC) debido a la revisión de CR 6636463. Para añadir este tipo de entrada, deben definirse estas clases de objeto como una superclase en la entrada de configuración jdbc-object-class mediante el siguiente ldapmodify, ya que dpconf set-jdbc-object-class-prop sólo puede añadir una superclase.

En este ejemplo, se añade la siguiente entrada:

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

La vista JDBC está definida como se muestra en el siguiente ejemplo, que era funcional antes de la versión 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

Debido a que objectClass:organizationalPerson y objectClass:inetOrgPerson existen en la entrada añadida, es necesario especificar ambas clases como superclases, como se demuestra con el siguiente comando ldapmodify.


$ 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

Tras la ejecución de este ejemplo ldapmodify, se define jdbc-object-class tal y como se muestra en el siguiente ejemplo.

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
6826694

Pese a que la configuración predeterminada para la propiedad log-level-data-sources-detailed está documentada como none, el valor predeterminado real es all. No obstante, la definición de log-level-data-sources-detailed en cualquier valor distinto de none afecta al rendimiento del servidor y provoca que el archivo access crezca rápidamente. Por este motivo, el valor del parámetro log-level-data-sources-detailed se define automáticamente en none cuando se crean instancias de servidor DPS. Se recomienda que no se defina este parámetro en ningún otro valor.

6832498

Debido al problema descrito en Vulnerability Note VU#836068, MD5 vulnerable to collision attacks, Directory Proxy Server debería evitar el uso del algoritmo MD5 para certificados firmados.

Para determinar el algoritmo de firma de un certificado, siga los siguientes pasos:

  1. Ejecute el siguiente comando para mostrar la lista de los certificados definidos en una instancia específica de Directory Proxy Server.


    $ dpadm list-certs instance-path

  2. Ejecute los siguientes comandos en cada certificado definido para determinar si se ha firmado con el algoritmo MD5.


    $ 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

    En el siguiente ejemplo, se muestra el resultado típico del comando dsadm show-cert para un certificado firmado con el algoritmo de firma MD5:


    Certificate:
   Data:
   ...
   Signature Algorithm: PKCS #1 MD5 With RSA Encryption
   ...

  3. Ejecute el siguiente comando para eliminar de la base de datos cualquier certificado firmado con MD5:


    $ dsadm remove-cert instance-path cert-alias

Siga los siguientes pasos para actualizar la contraseña de la base de datos de certificados. (El comando dpadm genera una contraseña de base de datos de certificados predeterminada al crear una instancia de Directory Proxy Server.)

  1. Detenga la instancia de Directory Proxy Server.

  2. Ejecute el comando siguiente:


    $ dpadm set-flags instance-path cert-pwd-prompt=on

    Aparece un mensaje de solicitud de contraseña.

  3. Introduzca una contraseña con un mínimo de ocho caracteres.

  4. Reinicie la instancia de Directory Proxy Server y proporcione el Internal (Software) Token cuando se le solicite.

Reemplace cualquier certificado que utilice la función MD5 por certificados que utilicen el algoritmo de firma SHA-1. Utilice uno de los siguientes procedimientos dependiendo de si su instalación utiliza un certificado autofirmado o un certificado adquirido de una entidad emisora de certificados (Certificate Authority).

Siga los siguientes pasos para generar y almacenar certificados autofirmados:

  1. Ejecute el comando siguiente:


    $ dpadm add-selfsign-cert  --sigalg SHA1withRSA \
dps-instance-path cert-alias
    Nota –

    El algoritmo de firma predeterminado es MD5withRSA.

    Aparece el siguiente mensaje:


    [Password or Pin for "NSS Certificate DB"]

  2. Introduzca la nueva contraseña de la base de datos de certificados.

Siga los siguientes pasos para generar y almacenar un certificado adquirido de una entidad emisora de certificados (Certificate Authority o CA):

  1. Ejecute el siguiente comando para generar una solicitud de certificado de servidor firmado por una entidad emisora de certificados (CA-Signed Server Certificate):


    $ dpadm request-cert  --sigalg SHA1withRSA instance-path cert-alias

  2. Asegúrese de que la entidad emisora de certificados no siga utilizando el algoritmo de firma MD5 y, tras esto, envíele la solicitud de certificado (de forma interna, desde su empresa, o externa, según su reglamento empresarial) para recibir un certificado firmado por entidad emisora tal y como se describe en el apartado To Request a CA-Signed Server Certificate de Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.

  3. Cuando la entidad emisora le envíe el nuevo certificado, ejecute el siguiente comando para añadirlo a la base de datos de certificados:


    $ dpadm add-cert instance-path cert-alias

    Este paso se describe en el apartado Creating, Requesting and Installing Certificates for Directory Proxy Server de Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.

  4. Si todavía no se ha almacenado el certificado de confianza de la entidad emisora en la base de datos de certificados, ejecute el siguiente comando para añadirlo:


    $ dpadm add-cert --ca instance-path trusted-cert-alias

    Este paso se describe en el apartado Creating, Requesting and Installing Certificates for Directory Proxy Server de Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.

  5. Ejecute los siguientes comandos para comprobar si se está utilizando el nuevo certificado.


    $ 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
6854861

Con un servidor de fondo de Microsoft SQL Server, al utilizar los campos smalldate, sólo se admite la versión larga de las fechas o, de lo contrario, se produce un error de conversión tal y como se muestra en el siguiente ejemplo.


ldap_modify: Operations error
ldap_modify: additional info: java.lang.Exception: \
com.microsoft.sqlserver.jdbc.SQLServerException: \
Conversion failed when converting datetime from character string.
Nota –

La versión larga de una fecha emplea el formato YYYY -MM-DD HH:MM.