IDIRA/CyberArk | Qué exige realmente implementar un conector de identidad: Análisis técnico de Idira Identity Connector

¿Porque como equipo revisamos esto?

Un conector de identidad no es un componente periférico. Es la pieza que conecta un proveedor de identidad en la nube con el Active Directory on-premise de una organización y eso significa que, por diseño, necesita tocar autenticación, contraseñas y membresías de grupo. Antes de recomendar una implementación a cualquier cliente, revisamos los requisitos completos: servidor, integración con AD, registro del conector y conectividad de red.

 Lo que cubre la revisión técnica

1. Requisitos de servidor. Windows Server 2016 o superior, 8 GB de RAM (4 GB reservados para caché del conector), 2 núcleos, acceso a internet hacia los servicios cloud del proveedor, certificado raíz GlobalSign Root CA – R3 instalado, y .NET 4.5+. El fabricante recomienda no instalar el conector en el mismo servidor que un controlador de dominio, y sugiere al menos dos servidores para redundancia.

2. Integración con Active Directory. Aquí es donde el nivel de exigencia sube. El servidor debe estar unido al dominio, con confianza transitiva bidireccional si hay múltiples dominios en el árbol o bosque. La instalación requiere un usuario de dominio con permisos de lectura como mínimo — pero varias funcionalidades adicionales (self-service password reset, aprovisionamiento inbound) requieren delegación de permisos mucho más amplia.

3. Registro del conector. Existen dos flujos distintos según el tipo de tenant: uno para Idira Identity standalone (usuario con rol "Register and Administer Connectors") y otro para entornos ISPSS, que usa una cuenta local ("Installeruser") cuya contraseña expira cada 24 horas. Confundir estos flujos o no saber cuál aplica es un error común y evitable si se confirma el tipo de tenant antes de iniciar la instalación.

4. Conectividad de red. Para configuraciones de WAN privada, el fabricante documenta puertos específicos para LDAP (389), LDAP SSL (636), LDAP Global Catalog (3268/3269) y Kerberos (88). Nota: esta sección aparece en la documentación, pero está detrás de contenido colapsable.

 El hallazgo central: el alcance de los permisos delegados

El punto que más nos llamó la atención no es un requisito técnico aislado es una decisión de diseño que el fabricante deja completamente en manos de quien implementa. Para habilitar aprovisionamiento inbound (crear usuarios, resetear contraseñas, forzar cambio de contraseña en el próximo inicio de sesión, modificar membresía de grupos), la documentación pide delegar estos permisos a una cuenta de servicio o al objeto de computadora del conector.

La diferencia entre delegar esto a nivel de una OU específica (vía dsacls, por ejemplo) y delegarlo a nivel de dominio completo no es cosmética: es la diferencia entre una cuenta de servicio con radio de impacto acotado y una cuenta que, si se compromete, tiene capacidad de crear cuentas, resetear contraseñas y modificar grupos en todo el directorio. Es exactamente el tipo de sobreexposición que después se convierte en el vector que un atacante aprovecha para escalar privilegios o moverse lateralmente.

Otros puntos que merecen seguimiento

• Dependencia de certificado raíz. El requisito del certificado GlobalSign Root CA – R3 introduce una dependencia externa que vale la pena monitorear activamente (vigencia, revocación), no solo instalar y olvidar.
• Diseño de redundancia. La recomendación de dos servidores está documentada, pero no se detalla la arquitectura de balanceo entre ellos algo a definir explícitamente en el diseño de la implementación, no a asumir.
• Tipo de tenant. Como se mencionó, standalone vs. ISPSS cambian el flujo de registro. Confirmarlo antes de la instalación evita retrabajo.

 Checklist práctico para equipos que evalúen esta implementación

1. Confirmar el tipo de tenant (standalone vs. ISPSS) antes de iniciar cualquier instalación.
2. Definir el alcance de la delegación de permisos AD por OU, no por dominio, y documentarlo formalmente.
3. Verificar la vigencia del certificado raíz requerido como parte del checklist de mantenimiento, no solo de instalación.
4. Confirmar los puertos de red directamente contra la documentación vigente del fabricante antes de diseñar reglas de firewall.
5. Evaluar la arquitectura de redundancia entre los dos servidores recomendados como parte del diseño, no como un detalle posterior.

Este es el estándar que aplicamos en Némesis para cualquier análisis técnico antes de una recomendación: no basta con confirmar que algo funciona según el manual del fabricante hay que identificar qué expone si se configura de la forma más simple, no de la forma más segura. Ese es el criterio que separa un checklist de instalación de un análisis de riesgo real.