Editor LDAP/Editor de búsqueda LDAP

Nombres LDAP

El método recomendado para elegir un sufijo de nombre es el descrito en RFC2247 , que asigna un dominio DNS a un DN. Si mi dominio DNS es bigcorp.com , se asignará al DN "dc=bigcorp,dc=com". El nodo superior de mi directorio LDAP será entonces "dc=bigcorp,dc=com". Para más información y para comprender la nomenclatura LDAP, recomendamos el libro "Comprender e implementar servicios de directorio LDAP" .

La compatibilidad con el componente dc ahora es obligatoria en todas las RFC X.509. Por ejemplo, si tengo este directorio:

dc =bigcorp, dc =com
|
+- dc = fi
|
|
+- dc =se
|
+-cn=Mike Jackson

El método más comprensible es tomar el nombre del sujeto en orden progresivo, como: cn=Mike Jackson,dc=se,dc=bigcorp,dc=com

Si el DN está ordenado de esta manera, debería publicarse en el objeto correcto en el árbol.

Si el DN está ordenado en sentido inverso, como: dc=bigcorp,dc=com,dc=se,cn=Mike Jackson, EJBCA lo reordenará incorrectamente en orden directo, por lo que la publicación será incorrecta.

Por lo tanto, utilice un orden hacia adelante de la siguiente manera: 'cn=Mike Jackson,dc=se,dc=bigcorp,dc=com' si utiliza el modelo dc o 'cn=Mike Jackson,o=bigcorp,c=se' si utiliza el modelo o,c.

Crear DN LDAP únicos es el siguiente reto. Si trabajas en una organización pequeña, usar el DN probablemente funcionará bien, pero en una organización más grande probablemente haya varias personas con el mismo nombre. De alguna manera, los nombres deben ser únicos, y una forma es introducir números, iniciales, etc. en el DN. Otra opción que recomendamos es usar uid en el DN LDAP. Los DN LDAP se verán así: "uid=tomas,dc=bigcorp,dc=com". Uid es el nombre de usuario, que normalmente se usa para iniciar sesión, etc., y probablemente ya tengas algún procedimiento para crear nombres de usuario únicos.

Conceptos básicos de LDAP

Si no está acostumbrado a la nomenclatura X.500, la estructura LDAP de ramas y nodos hoja puede parecer inusual. No puede simplemente soltar un objeto donde quiera; necesita crear el marco de trabajo que lo soporte. Es como si quisiera colocar entradas en /etc/hosts si el directorio /etc no existiera.

Primero, ejecuta mkdir /etc, luego crea el archivo y empieza a introducir información en él. La diferencia con LDAP y x.500 es que, en lugar de separar las rutas con barras, las separan con comas y signos "=".

Por ejemplo, si quieres crear un objeto "cn=ldaphost,ou=hosts,dc=yourdom,dc=com", primero debes asegurarte de que "dc=yourdom,dc=com" exista. Luego, asegúrate de que "ou=hosts,dc=yourdom,dc=com" exista. Después, puedes probar "cn=ldaphost,ou=hosts,dc=yourdom,dc=com".

EJBCA no crea ramas en LDAP. Debes añadirlas allí por otros medios antes de empezar a publicar.

Uso de LDAP

En Firefox, por ejemplo, puede ingresar una URL como: ldap://ip-address-of-ldap-server:389/cn=Tomas Gustavsson,dc=se,dc=bigcorp,dc=com y obtendrá una entrada de la libreta de direcciones con la información sobre el usuario, incluido el certificado.

El formato de URL LDAP se describe en RFC2255 .

Para utilizar los certificados de usuario de LDAP y usarlos para cifrar correo electrónico, parece haber un requisito para utilizar una conexión SSL al servidor LDAP ( Opciones de cuenta > Composiciones y direcciones > Editar directorios > Editar > Usar conexión segura ); consulte también a continuación cómo configurar OpenLDAP para SSL.

Al obtener certificados de LDAP con Firefox, por ejemplo con la URL: ldap://ldap-server-host/dc=bigcorp,dc=com??sub?(cn=MyName)?(objectclass=*), el certificado de CA debe estar instalado en el almacén de confianza de Windows, no solo en el de Firefox, para habilitar una casilla de verificación en el certificado obtenido.

Para usar SSL en un servidor LDAP con MS Outlook, debe asegurarse de que el CN del certificado del servidor LDAP coincida con el nombre de host. Un ejemplo de cómo agregar un usuario al servidor LDAP con la interfaz CLI es el siguiente:

bin /ejbca .sh ra addendentity ldap password "C=SE,O=Foo,CN=ldap.foo.se" MyCA 1 PEM SERVER

donde ldap.foo.se es el nombre de host del servidor LDAP que Outlook debe usar.

El certificado CA también debe importarse a Windows correctamente.

Configurar publicadores LDAP

Un publicador es un bean de sesión que implementa la interfaz IPublishSession y se utiliza para almacenar certificados y CRL de entidades. EJBCA admite un número ilimitado de publicadores, simplemente definiéndolos en la interfaz gráfica de administración. El usuario de EJBCA puede implementar sus propios publicadores, pero EJBCA ya incluye un publicador para LDAP.

EJBCA utiliza un DN base para publicar en diferentes estructuras LDAP. El DN utilizado en el certificado puede ser diferente de la estructura LDAP.

Configuración de EJBCA

Para configurar el editor para LDAP:

  1. Seleccione GUI de administración > Editar editores .

  2. Agregue un nuevo editor especificando un nombre, edite el editor y especifique los campos necesarios.

A continuación se enumeran los parámetros genéricos del publicador LDAP:

Campo

Descripción

Nombres de host

Lista de hosts separados por ';' donde se ubican los servidores LDAP. Por ejemplo, "ldap.company.com" o "ldap1.company.com;ldap2.company.com". Solo se utilizará el primer host disponible de la lista.

Puerto

Puerto en el que escucha el servidor LDAP, el predeterminado no SSL es 389. Opciones disponibles:
Conexión de texto simple: conexión sin cifrar, la más sencilla para comenzar y la más robusta si la red es segura.
Extensión STARTTLS: permite al servidor y al cliente negociar una conexión TLS (cifrada) si el servidor admite conexiones cifradas. Comienza con una conexión de texto plano y se actualiza a una conexión TLS utilizando el mismo puerto que la conexión de texto plano. Requiere configuración tanto en el servidor (clave y certificado del servidor TLS) como en el cliente (certificado de CA en el almacén de confianza).
Conexión TLS: Siempre utiliza una conexión TLS cifrada y falla si no está disponible. Requiere configuración de TLS tanto en el servidor (clave y certificado del servidor TLS) como en el cliente (certificado de CA en el almacén de confianza).

DN de inicio de sesión

El DN de un usuario en el servidor LDAP con permisos para agregar y actualizar entidades.

Contraseña de inicio de sesión

Contraseña para el usuario anterior.

Tiempo de espera de conexión

Número de milisegundos que un servidor debe responder antes de que se considere no disponible y se utilice el siguiente servidor en la lista de nombres de host (si lo hay). Este tiempo de espera se utiliza para sondear servidores LDAP, crear conexiones, enlazar y desconectar.

Tiempo de espera de lectura

Número de milisegundos que un servidor tiene para completar una operación de búsqueda o lectura LDAP antes de que se agote el tiempo de espera y falle.

Tiempo de espera de la tienda

Número de milisegundos que un servidor tiene para completar una operación de almacenamiento LDAP antes de que se agote el tiempo de espera y falle. Esto puede tardar un poco más si se almacenan CRL muy grandes en LDAP.

Crear usuarios inexistentes

Define si EJBCA debe crear un objeto LDAP si no existe ningún objeto cuando EJBCA publica el certificado.

Modificar usuarios existentes

Define si los atributos (como el correo electrónico) de los objetos LDAP existentes se reemplazan con nuevos valores o se añaden al actualizar una entrada con un nuevo certificado. Si esta opción no está activada, los usuarios existentes no se verán afectados, ni siquiera se actualizarán con un nuevo certificado.

Sobrescribir atributos existentes cuando la opción Modificar usuarios existentes está establecida en verdadero

Si se deben cambiar los valores de los atributos cuando ya existen.

Agregar atributos no existentes cuando la opción Modificar usuarios existentes está establecida en verdadero

Si se deben agregar atributos cuando aún no existen.

Agregar varios certificados por usuario

Define si se deben usar varias entradas de certificado para cada usuario o solo una. De forma predeterminada, solo se agrega un certificado a cada entrada de usuario en LDAP y, si el usuario obtiene un nuevo certificado, el antiguo se elimina y se reemplaza por el nuevo. Si esta casilla está marcada, los certificados se agregan a LDAP para que cada usuario pueda tener varias entradas de certificado. Asegúrese de que sus aplicaciones puedan gestionar esto antes de habilitar esta opción. Al revocar un usuario, se eliminarán todas las entradas de certificado de dicho usuario.

Eliminar certificados cuando se revocan

Si se selecciona, hace que el publicador elimine un certificado de LDAP cuando el certificado se revoca o se suspende.

Eliminar usuario LDAP cuando se revoca el certificado

Si se selecciona, hace que el publicador elimine toda la entrada de usuario LDAP cuando se revoca o suspende un certificado.

Establecer el atributo userPassword

 <p Especifica si el publicador LDAP debe establecer el atributo userPassword en el objeto LDAP. Si se publica una entrada de usuario con una contraseña no nula y esta casilla está marcada, el atributo userPassword se rellenará con la contraseña del usuario.

Clase de objeto de usuario

La clase de objeto para las entradas LDAP de los usuarios, donde se publican los certificados de usuario. La entrada es jerárquica y se separa mediante ';' para crear una estructura como: clase de objeto: superior clase de objeto: persona clase de objeto: personaorganizacional clase de objeto: personaOrganivista. Esta clase de objeto debe permitir el atributo userCertificate;binary. Valor predeterminado: superior; persona; personaorganizacional; personaOrganivista.

Clase de objeto CA

La clase de objeto para las entradas LDAP de las CA, donde se publican los certificados y las CRL de las CA. La entrada es jerárquica y se separa mediante ';' para crear una estructura. Esta clase de objeto debe permitir los atributos cACertificate;binary, certificateRevocationList;binary y authorityRevocationList;binary. Valor predeterminado: top;applicationProcess;certificationAuthority

Atributo del certificado de usuario

Nombre del atributo, en la clase userObjectClass, para el certificado de usuario. El valor predeterminado es userCertificate;binary.

Atributo del certificado de CA

Nombre del atributo, en cAObjectClass, para el certificado de la CA. El valor predeterminado es cACertificate;binary.

Atributo CRL

Nombre del atributo, en cAObjectClass, para las CRL (CRL de usuario) publicadas por la CA. El valor predeterminado es certificateRevocationList;binary.

Atributo ARL

Nombre del atributo, en cAObjectClass, para las ARL (CRL de CA) publicadas por la CA. El valor predeterminado es authorityRevocationList;binary (tenga en cuenta que las ARL puras aún no se implementan en EJBCA).

Campos de ubicación LDAP del DN del certificado

Al configurar el publicador LDAP, el DN base se usará como base para el DN publicado en LDAP y se añadirá a los campos de ubicación LDAP seleccionados. Por ejemplo: Si el DN de usuario en EJBCA es "cn=tomas gustavsson, uid=tomasg, O=PrimeKey Solutions AB, C=SE", el DN base es "dc=PrimeKey,dc=SE" y los campos de ubicación LDAP seleccionados son "CN", el DN LDAP utilizado para la publicación será "cn=tomas gustavsson, dc=PrimeKey, dc=SE" y "uid=tomasg" se añadirá como atributo en LDAP. El certificado almacenado en "cn=tomas gustavsson, dc=PrimeKey, dc=SE" tendrá el DN de sujeto "cn=tomas gustavsson, uid=tomasg, O=PrimeKey Solutions AB, C=SE".

Configuración de perfiles de certificado

Para permitir la publicación en LDAP, debe crear un perfil de certificado personalizado EJBCA.

Para publicar en LDAP, debe crear un perfil de certificado en EJBCA que publique en LDAP. Si el publicador para LDAP está configurado según la sección "Configuración de EJBCA" anterior, habrá una sección para "Publicadores" disponible al crear o editar un perfil de certificado (con "Editar perfiles de certificado ").

Seleccione esta opción y, luego, al agregar entidades finales, asegúrese de que utilicen el nuevo perfil de certificado y listo, se publicarán los certificados.

Diferentes editores LDAP

Editor LDAP

El publicador LDAP normal funciona buscando el DN en LDAP.

Cuando EJCA crea un objeto para publicar un certificado en LDAP, primero construye el DN a partir del DN base y los campos de ubicación LDAP para el DN del certificado. Comprueba si la entrada existe en LDAP y la crea o modifica.

Ejemplo: El DN del certificado es "CN=Tomas Gustavsson,O=Foo,C=SE", el DN base del editor es "DC=primekey,DC=se" y el CN está seleccionado en "Campos de ubicación LDAP del DN del certificado". El DN resultante que EJBCA buscará en el LDAP y creará si aún no existe es "CN=Tomas Gustavsson,DC=primekey,DC=se".

Si utiliza este publicador y tiene varios árboles en su LDAP (por ejemplo, "ou=foo,dc=primekey,dc=se" y "ou=bar,dc=primekey,dc=se"), puede:

  1. Incluya tanto CN como OU en 'Campos de ubicación LDAP del DN del certificado' y tenga sus DN del certificado como "CN=Tomas,OU=foo,O=MyOrg,C=SE.

  2. Utilice diferentes publicadores para ou=foo y ou=bar y emita certificados para las diferentes OU con diferentes perfiles de certificado.

Editor de búsqueda LDAP

El publicador de búsqueda LDAP funciona buscando entradas existentes en el LDAP mediante un filtro de búsqueda definido por el usuario. Si no existen entradas en el LDAP al buscar una, se crea una, igual que en el publicador LDAP normal.

El filtro de búsqueda se define en los siguientes campos en la configuración de búsqueda LDAP :

  • DN base de sufijo de búsqueda LDAP: la base para su filtro de búsqueda.

  • Filtro LDAP de la búsqueda: su filtro LDAP.

Si crea su filtro de búsqueda en componentes DN, también deberá seleccionar esos componentes como campos de ubicación LDAP .

El mejor ejemplo de este tipo de filtro de búsqueda es si la base es "dc=primekey,dc=se" y el filtro es "uid=$USERNAME". La búsqueda realizada por EJBCA será igual a la búsqueda: ldapsearch -x -b "dc=primekey,dc=se" "(uid=$USERNAME)"

$USERNAME se reemplaza por el nombre de usuario EJBCA del usuario que acaba de generar un nuevo certificado. Otras variables, además de $USERNAME, son $EMAIL, $UID, $CN, $O, $OU y $C, cuyos valores se toman del DN del certificado.

Cuando se genera un certificado para, por ejemplo, el usuario "ldap", EJBCA realizará la búsqueda:
ldapsearch -x -b "dc=clave principal,dc=se" "(uid=ldap)"

El certificado generado para LDAP se publicará en el objeto devuelto por la búsqueda. Esto resulta muy útil si desea publicar certificados en un directorio LDAP donde ya existen sus usuarios, como un directorio de correo electrónico. El DN en LDAP no tiene por qué coincidir con el DN en los certificados.

Si más de una entrada coincide con la búsqueda, se utilizará el primer resultado de búsqueda devuelto.

Qué almacena/crea/modifica EJBCA

Además del DN en la entrada, también se almacenan varios atributos. Algunos son obligatorios por esquema, otros son opcionales. EJBCA encuentra atributos en el certificado; si se trata de una OU (unidad organizativa), EJBCA la utiliza para rellenar el atributo de OU en la entrada LDAP.

Al actualizar una entrada que ya existe, EJBCA utiliza el reemplazo en los atributos existentes, por lo que si ya existe un atributo de correo electrónico y EJBCA encuentra una dirección de correo electrónico en el certificado, el atributo de correo electrónico en LDAP se reemplaza con la dirección de correo electrónico del certificado.

Los atributos solo se reemplazan o actualizan si la opción " Modificar usuarios existentes" en el publicador está activa. Sin embargo, el atributo del certificado siempre se actualiza. Los atributos que forman parte del DN, es decir, los que reflejan la ubicación de la entrada en LDAP, no se modifican, ya que esto no suele estar permitido.

Los atributos que EJBCA crea o reemplaza son:

  • cn (nombre común)

  • l (localidad)

  • ou (unidad organizativa)

  • sn (apellido)

  • gn (nombre de pila)

  • st (estado)

  • o (organización)

  • uid (identificación de usuario)

  • iniciales

  • título

  • serialnumber - Si hemos seleccionado utilizar el SN (campo DN del serialNUmber) en los campos de ubicación de Ldap , también lo agregaremos como atributo.

Publicar certificados de CA

Incluso si solo se publican CRL en LDAP, EJBCA debe publicar el emisor de CRL antes de poder publicar cualquier CRL. Si intenta publicar una CRL sin publicar primero el emisor, el servidor LDAP se quejará de la falta del atributo cACertificate y el publicador fallará.

Puede publicar el emisor de CRL manualmente editando la CA (emisor de CRL) en EJBCA. Asegúrese de que el publicador LDAP esté seleccionado en la lista de publicadores y, a continuación, haga clic en "Republicar certificados de CA" en la sección "Ciclo de vida de la CA".

Configurar OpenLDAP

La clase de objeto inetOrgPerson se utiliza de forma predeterminada para almacenar certificados.

Ejemplo:

dn: cn=Mike Jackson,ou=people, dc =company, dc =com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: Mike Jackson
sn: Jackson
userCertificate;binary::

Las CA se publican en el formato:

dn: cn=ejbca, dc =jackson, dc =net
objectClass: top
objectClass: applicationProcess
objectClass: certificationAuthority
cn: ejbca
cACertificate;binary:
certificateRevocationList;binary:
authorityRevocationList;binary:

Para configurar OpenLDAP (versión 2.2.5) para que incluya inetOrgPerson , agregue las siguientes líneas a slapd.conf. Esta ya es la configuración predeterminada en versiones recientes:

include /etc/ldap/schema/cosine .schema
include /etc/ldap/schema/inetorgperson .schema

Agregue el objeto superior creando un archivo LDIF (org.ldif):

dn: o=AnaTom,c=SE
objectclass: dcObject
objectclass: organization
o: AnaTom
dc : AnaTom
dn: cn=Admin,o=AnaTom,c=SE
objectclass: organizationalRole
cn: Admin

Y usando el comando:

ldapadd -x -D "cn=Admin,o=AnaTom,c=SE" -W -f org.ldif

Comprueba lo que tienes en el LDAP mediante:

ldapsearch -x -b 'o=AnaTom,c=SE' '(objectclass=*)'

Configurar SSL

Cree un usuario en EJBCA (este ejemplo sirve para agregar un usuario con la interfaz CLI; agregar un usuario con la interfaz gráfica de usuario de administración funciona igual de bien). En el directorio EJBCA de correo, escriba (use simplemente "ra" en Windows):

bin /ejbca .sh ra addendentity ldap foo123 "C=SE,O=Foo,CN=ldap" null ManagementCA null 1 PEM SERVER
bin /ejbca .sh ra setclearpwd ldap foo123

Donde foo123 es la contraseña del usuario LDAP, C=SE... es el DN del usuario y ManagementCA es el nombre que eligió para su CA. El tipo de usuario es usuario final (1), el tipo de almacén de claves es PEM y, si usa la interfaz gráfica de administración, marque "batch ".

Generar por lotes el almacén de claves PEM:

bin /ejbca .sh batch

Copie los archivos resultantes p12/pem/ldap.pem, p12/pem/ldap-CA.pem y p12/pem/ldap-Key.pem a su servidor LDAP. En este ejemplo, slapd.conf se encuentra en /etc/ldap, por lo que copiamos los archivos a ese directorio. Proteja estos archivos para que solo sean legibles por el servidor LDAP.

Agregue lo siguiente a su slapd.conf:

# Use SSL
TLSCipherSuite HIGH:MEDIUM:+SSLv3
TLSCertificateFile /etc/ldap/ldap .pem
.pem de clave TLSCertificateKeyFile /etc/ldap/ldap-Key
TLSCACertificateFile /etc/ldap/ldap-CA .pem

Reiniciar slapd:

. /slapd -h "ldap:/// ldaps:///"

y verifique que se esté ejecutando con ps -ef|grep slapd .

En SuSE, si utiliza OpenLDAP integrado, debe habilitar ldaps en /etc/sysconfig/openldap:

OPENLDAP_START_LDAPS= "yes"

y luego ejecuta:

SuSEconfig

y luego:

rcldap start

Configure su editor LDAP en EJBCA para usar SSL marcando la casilla de verificación Conexión TLS ; el puerto debe cambiar al puerto 636.

¡Nota! El certificado de la CA raíz utilizada para firmar el certificado del servidor LDAP debe estar presente en el almacén de certificados de confianza de Java ($JAVA_HOME/jre/lib/security/cacerts). De lo contrario, deberá agregarlo mediante algo como: Primero, obtenga el certificado de la CA:

bin /ejbca .sh ca getcacert MyCA myca.der -der

Luego agréguelo al almacén de confianza de Java:

keytool - import -trustcacert - alias MyCA -keystore $JAVA_HOME /jre/lib/security/cacerts -storepass changeit - file myca.der

Debes reiniciar JBoss después de agregar cualquier cosa al almacén de confianza de Java.

Para obtener más información sobre la configuración de OpenLDAP en Solaris, consulte bolthole.com

Ejemplo de instalación de Ubuntu

- sudo apt-get install slapd ldap-utils
- sudo dpkg-reconfigure slapd
Configure slapd with your domain and admin password (primekey.com in this case ).
- sudo /etc/init .d /slapd restart
- 'ps -ef|grep slap'
should show a slapd running
- ldapsearch -x -b 'dc=primekey,dc=se' '(objectclass=*)'
To look at the results
- slapcat -l backup.ldif
Make backup
- slapadd -l backup.ldif
- /etc/init .d /slapd restart
Restore backup


Ejecute el siguiente comando para agregar nuevos nodos LDAP:

- ldapadd -x -D "cn=admin,dc=PrimeKey,dc=com" -W -f primekey.ldif
where primekey.ldif is:
dn: dc =PrimeKey, dc =com
dc : PrimeKey
objectclass: dcObject
objectclass: organization
o: PrimeKey Solutions AB
description: Parent Object for PrimeKey LDAP Directory
dn: ou=Standard, dc =PrimeKey, dc =com
ou: Standard
objectClass: top
objectClass: organizationalUnit
description: Parent Object for all Standard Certificates
dn: ou=High, dc =PrimeKey, dc =com
ou: High
objectClass: top
objectClass: organizationalUnit
description: Parent Object for all High Certificates

OpenDJ

OpenDJ es un servidor LDAP moderno, compatible con estándares y basado en Java, fácil de configurar y usar. También incluye herramientas GUI para administración y consultas.

Instalación de OpenDJ

Este ejemplo utiliza OpenDJ 2.5.0 como ejemplo, pero otras versiones deberían funcionar de manera similar.

  • descomprimir OpenDJ-2.5.0-Xpress1.zip en el Panel de control

  • cd OpenDJ-2.5.0-Xpress1

  • ./configuración

    • Esto inicia la configuración gráfica, puedes ejecutar setup --cli para instalar sin GUI.

    • Utilice el DN de usuario raíz predeterminado: cn=Administrador de directorios

    • DN base del directorio: dc=ejemplo,dc=com)

    • Si desea poder ejecutar OpenDJ en el mismo servidor que JBoss/EJBCA, elija otro puerto para la administración, es decir, 5555 en lugar de 4444.

  • Puede finalizar iniciando Launch Control Panel o puede iniciarlo más tarde con bin/control-panel.

Luego, se configura un publicador EJBCA para una instalación predeterminada con:

  • DN base: dc=ejemplo,dc=com

  • Administrador: cn=Administrador de directorios

Se puede acceder al navegador gráfico LDAP desde el Panel de control > Administrar entradas . Puede iniciar o detener OpenDJ desde el Panel de control o con bin/start-ds y stop-ds.

Las tareas de gestión, como la creación de nuevos atributos y tipos de objetos, son fáciles de realizar en la GUI del Panel de control.

OpenDJ escucha en el puerto 1389 por defecto, pero también ocupa otros puertos, lo que impide que se ejecute en el mismo servidor que JBoss. Si desea cambiar el puerto de administración (predeterminado 4444) después de la instalación, puede editar confif/config.ldif y config/tools.properties.

Configurar SSL/TLS

Para obtener información sobre cómo configurar SSL/TLS con OpenDJ, consulte la documentación de OpenDJ .

Si ejecuta la instalación usando la línea de comando (--cli), se le solicitarán preguntas sobre TLS y tendrá la posibilidad de configurar TLS directamente.

Esquemas personalizados

Consulte doc/ldapschema para obtener archivos con esquemas personalizados y tipos de atributos para agregar a su esquema LDAP.

Número de serie del certificado

Este es un atributo y una extensión del esquema que permite almacenar el número de serie del certificado en el objeto LDAP inetOrgPerson para las entradas del usuario final. Esto se logra añadiendo una extensión a inetOrgPerson llamada inetOrgPersonWithCertSerno con un nuevo atributo opcional llamado certificateSerialNumber.

Una vez que haya instalado el nuevo esquema en el servidor LDAP, puede usarlo configurando el publicador LDAP con:

  • Clase de objeto de usuario: top;persona;organizationalPerson;inetOrgPerson;inetOrgPersonWithCertSerno

En lugar del valor predeterminado:

  • Clase de objeto de usuario: top;persona;organizationalPerson;inetOrgPerson

Luego, el atributo certificateSerialNumber se agregará/modificará automáticamente al publicar en LDAP.

Esquema de dispositivo adicional

Para almacenar certificados para dispositivos (por ejemplo, enrutadores, tostadoras, etc.) en LDAP, no hay una clase de objeto estándar realmente adecuada. inetOrgPerson requiere apellidos, etc., y la clase de objeto del dispositivo no incluye un atributo de certificado.

Mike Jackson ha contribuido amablemente con objetos adicionales que amplían la clase de dispositivo estándar con un atributo de certificado. ejbcaDevice utiliza identificadores de objeto de PrimeKey Solutions AB.

Instalación

Para los servidores Netscape/SUN, en UNIX, copie el archivo 85ejbca.ldif en:

/usr/netscape/servers/slapd-hostname/config/schema/

y reinicie el servidor LDAP.

Para OpenLDAP, copie el archivo ejbca.schema en, por ejemplo:

/etc/ldap/schema/

y edite slapd.conf para agregar la siguiente línea:

include /etc/ldap/schema/ejbca .schema

Luego reinicie el servidor.