JXplorer es un cliente/navegador LDAP que usamos en soporte para conectarnos al Directorio Activo de un cliente con un usuario de solo lectura y localizar la ficha de un usuario concreto, para poder extraer, verificar o depurar los parámetros que luego se informan en BoldWebCfg.xml (Portal/Fullweb/APP) o los datos de un usuario para relacionarlos con la ficha de persona de BOLD.

Este artículo complementa a Configuración con LDAP — ese artículo explica qué parámetros existen (ADUserDN, ADUsersDirectory, ADFilter, ADPersonalCodeParam, etc.); esta guía explica cómo usar JXplorer para obtenerlos y, sobre todo, cómo usarlo para diagnosticar el error más habitual: que un usuario no se vincule con su empleado en BOLD.

1. Antes de abrir JXplorer: qué datos necesitas

Según el checklist de Configuración con LDAP, antes de conectar deberías tener del cliente:

1. Dirección del servidor LDAP (ej. ldap://ldapservername.com o su IP) y puerto.
2. Un usuario y contraseña de solo lectura sobre el árbol a consultar (el “usuario de browsing”). Es el único usuario con el que nos conectaremos.
3. El directorio raíz a partir del cual están las personas usuarias (ej. DC=cliente,DC=local).
4. El nombre del campo que usa BOLD para relacionar usuarios con empleados.
5. El nombre de usuario de la persona concreta cuyo caso queremos investigar (para buscarla dentro del árbol una vez conectados).

2. Instalación

Descarga JXplorer desde jxplorer.org (necesita tener Java instalado). Es la misma herramienta a la que enlaza el artículo de Configuración con LDAP; como alternativa se puede usar Softerra LDAP Browser, pero esta guía cubre JXplorer.

3. Antes de conectar: relación entre los campos de JXplorer y los de BoldWebCfg.xml

Para que a cualquier agente de soporte le resulte más fácil rellenar la configuración de BOLD a partir de lo que vea en JXplorer (o al revés, revisar en JXplorer lo que hay configurado en un cliente), esta es la equivalencia entre ambos:

Con esta tabla a la vista, el resto de la guía tiene sentido: cada vez que hagamos algo en JXplorer, sabremos en qué campo de BOLD acabará ese valor.

4. Conectar al LDAP del cliente

Conectamos siempre con el usuario de lectura, nunca con las credenciales de la persona empleada cuyo caso estamos revisando.

1. Abre JXplorer y ve a File → Connect… (o el icono de conexión/enchufe en la barra de herramientas).
2. Rellena Host, Port y, si aplica, “Use SSL” (puerto 636) según la tabla anterior.
3. En Base DN se pone lo indicado en el parámetro ADUsersDirectory.
4. En el nivel de autenticación (Level) elige “User + Password” (no “Anonymous”, salvo que el cliente lo permita explícitamente) y rellena User DN y Password del usuario de lectura.
5. Pulsa OK/Connect. Si la conexión y el bind son correctos, verás aparecer el árbol LDAP en el panel izquierdo.

5. Guardar la conexión y reutilizarla (conexiones recientes)

La mayoría de las veces la conexión a un cliente ya está guardada de una sesión anterior — antes de rellenar todo a mano, comprueba si ya existe:

• En el propio diálogo File → Connect… hay un desplegable/lista en la parte superior con las conexiones guardadas anteriormente. Si ves ahí el nombre del cliente, selecciónala directamente: se autocompletarán Host, Port, Base DN y User DN (la contraseña puede o no quedar guardada según cómo se guardó la conexión — si no, solo tendrás que volver a teclearla).
• Si es la primera vez que conectas a ese cliente, después de rellenar los campos y antes de pulsar Connect, usa el botón Save del propio diálogo para guardarla con un nombre claro (recomendado: nombre del cliente + entorno, ej. ClienteX - LDAP PRO), así cualquier compañero que abra JXplorer en ese mismo equipo la reconocerá.
• Ten en cuenta que las conexiones guardadas son locales al equipo/perfil de usuario donde se guardaron — si necesitas la misma conexión desde otro PC (o la sesión de otro compañero), habrá que volver a crearla y guardarla ahí.

6. Navegar el árbol y localizar a la persona del caso

• Expande los nodos del árbol (flechas/+) hasta encontrar el contenedor de usuarios (normalmente algo como OU=Usuarios o CN=Users), suele ser el primero de los nodos visibles.
• Para no navegar a mano por árboles grandes, usa el buscador: con el nodo más alto seleccionado, pulsa Ctrl+F (o Edit → Search…) y busca por el nombre, sAMAccountName o el atributo que corresponda del usuario cuyo caso estamos revisando.
• Selecciona en los resultados la entrada de esa persona — te llevará hasta su nodo en el árbol de la izquierda. Con esto ya tenemos localizada su ficha LDAP;

7. Revisar los atributos: ADPersonalCodeParam, ADDNIParam, ADMail

1. Con la persona del caso seleccionada, abre el panel de atributos (vista de tabla/HTML según la versión) — ahí verás la lista completa de atributos LDAP y sus valores.
2. Localiza qué atributo contiene el dato que BOLD necesita para identificar al empleado (habitualmente employeeID, employeeNumber o similar para código; algún atributo de DNI/NIE si se identifica por documento).
3. Anota el nombre del atributo (eso es lo que va en ADPersonalCodeParam/ADDNIParam de BoldWebCfg.xml) y también el valor exacto que tiene esa persona ahora mismo — para compararlo con BOLD.
4. Decide UserIDPolicy según cuál de los dos atributos anteriores se use (ByEmployeeCode, ByEmployeeCodeExt o ByEmployeeDNI).

9. El error más frecuente: el campo de vinculación no coincide (o está vacío)

Esta es, con diferencia, la causa más habitual de que una persona no pueda entrar aunque su login en LDAP sea correcto — el mensaje típico es “La persona profesional seleccionada no tiene información en BOLD” (ver Proceso de login y diagnóstico de casos de error). El problema casi nunca está en LDAP en sí, sino en que el valor del atributo configurado (ADPersonalCodeParam/ADDNIParam) no coincide carácter a carácter con el código o DNI guardado en la ficha del empleado en BOLD, o el atributo está simplemente vacío.

Casos concretos que hay que revisar, de más a menos frecuente:

Cómo diagnosticarlo con JXplorer:

1. Localiza a la persona en JXplorer y copia el valor exacto del atributo configurado como ADPersonalCodeParam/ADDNIParam — cuidado con ceros a la izquierda y espacios, que a simple vista pueden pasar desapercibidos.
2. Compara ese valor, carácter a carácter, con el código externo o DNI que tiene guardado ese mismo empleado en BOLD
3. Si no coincide, decide qué lado corregir: normalmente se corrige el dato en BOLD para que coincida con el valor real y vigente en el AD del cliente (salvo que el dato de AD esté desactualizado y el cliente pueda/deba corregirlo allí — en ese caso hay que pedírselo).
4. Si el atributo está vacío en AD, no es algo que se pueda arreglar desde BOLD: hay que pedir al cliente que lo rellene para esa persona.
5. Si el problema se repite en varios usuarios a la vez, sospecha del cuarto caso de la tabla (atributo mal elegido en la configuración) antes que de datos individuales — revisa ADPersonalCodeParam/ADDNIParam en BoldWebCfg.xml contra el nombre real del atributo en JXplorer.
6. Aunque el código/DNI coincida perfectamente, recuerda que el empleado también necesita tener marcada la propiedad “Acceso portal” en su ficha para poder entrar — si todo lo anterior coincide y sigue sin funcionar, revisa ese campo.

10. Verificar el filtro de login (ADFilter)

• El filtro típico es (cn=%s) o (sAMAccountName=%s). Para saber cuál corresponde, mira qué atributo de la persona del caso coincide con el nombre que se teclea al hacer login (normalmente sAMAccountName en Active Directory).
• Puedes comprobarlo repitiendo la búsqueda (Ctrl+F), pero filtrando directamente por ese atributo con el valor real, ej. buscando sAMAccountName=jperez — si devuelve exactamente a esa persona, el filtro (sAMAccountName=%s) es correcto. Sigue siendo una búsqueda con el usuario de lectura, no un intento de login real.

11. Errores de conexión habituales

12. Checklist de salida — qué debes tener antes de cerrar JXplorer

• ADUserDN y ADUsersDirectory (del “Copy DN” del usuario de lectura)
• Confirmación de que la persona del caso cuelga del mismo ADUsersDirectory
• Nombre del atributo para ADPersonalCodeParam o ADDNIParam, y el valor exacto que tiene esa persona (para comparar con BOLD)
• Nombre del atributo para ADMail
• El ADFilter verificado con una búsqueda real
• UserIDPolicy decidido
• La conexión guardada con un nombre reconocible, para la próxima vez (punto 5)

Con esos datos, configurar BoldWebCfg.xml desde cero — o diagnosticar por qué uno ya configurado está fallando — es prácticamente mecánico.

Artículos relacionados

• Configuración con LDAP — parámetros completos y ejemplo de configuración
• BoldWebCfg.xml — dónde se informan estos valores
• Validación cliente Windows LDAP
• Administración de usuarios · Gestión de personas usuarias — para comparar el código/DNI guardado en BOLD
• jxplorer.org — sitio oficial de la herramienta