Blog de Amazon Web Services (AWS)

AWS AD Connector: el curioso caso de error en la ubicación del objeto

Por: Caio Ribeiro César, Divyank Pandya

 

Esta entrada de blog está diseñada para ayudar a los clientes, socios e ingenieros de soporte de AWS con conocimientos de Active Directory en el contexto de los escenarios de AWS AD Connector. Describiremos algunas de las características del producto y elaboraremos un plan de acción para un problema conocido en pequeñas, medianas y grandes empresas.

Muchos clientes de AWS utilizan la solución Conector de Active Directory para conectarse a su directorio existente en AWS.  Utilizamos esta solución como una “puerta de entrada” o “gateway” donde podemos dirigir solicitudes a AD local, eliminando la necesidad de mantener la información almacenada en caché en la nube.

Creamos un entorno siguiendo los conceptos de prerrequisitos: VPC con diferentes subredes que tienen ruta y conectividad en los puertos seleccionados, una cuenta de servicio con autorización correcta en un dominio con un nivel funcional superior a WS2003, objetos con la configuración predeterminada de autenticación previa de Kerberos.

Una vez que terminamos las configuraciones de requisitos previos, eliminamos algunos problemas de red instalando una nueva instancia EC2 y ejecutando las pruebas de DirectoryServicePortTest en una subred que utilizaría AD Connector.

Podemos validar en la siguiente prueba que hacemos una conexión a los puertos de servicios DNS, Kerberos y LDAP:

DirectoryServicePortTest.exe -d   <domain_name> -ip <server_IP_address> -tcp «53.88,389" -udp «53.88,389"

A continuación, procedemos a crear AD Connector en el servicio de directorio:

La instancia que ejecutó la prueba DirectoryServicePortTest.exe estaba en una de las subredes anteriores.

 

Validamos que el directorio se creó correctamente:

Seguimos el procedimiento para crear un espacio de trabajo simple. Plantilla seguida para una prueba de uso de directorios sincronizada por AD Connector.

Al ingresar a la pantalla de inicio de Workspaces, vemos nuestro directorio listado como «activo»:

Procedemos con el paso de prueba y seleccionamos la opción «Iniciar espacios de trabajo». Seleccionamos el directorio creado y tan pronto como intentamos localizar usuarios en una consulta específica, recibimos un error genérico (junto con la carga interminable en el proceso de búsqueda del objeto «aws»):

Debido a que el error de la consola de búsqueda era genérico, necesitamos una colección de registros específica en los controladores de dominio en nuestro entorno.

WireShark se instaló y se ejecutó para la recopilación de seguimiento de red junto con un filtro simple para paquetes «ldap». En esta colección, podemos analizar que la consulta se realiza para dc=caiorc, dc=corp y hay un error específico de “unavailableCriticalExtension”.

Si expandimos el paquete con el error, tenemos más información sobre el error:

Mensaje de error LDAP.00000057: Ldaperr: DSID-0C090AF4, comentario: Error al procesar el control, fecha 0, v4563

El código de error LDAP 12 indica que el servidor LDAP no pudo satisfacer una solicitud porque una o más extensiones críticas no estaban disponibles. En otras palabras, el servidor no admite el control o el control no es apropiado para el tipo de operación (LDAP RFC).

Vamos a centrarnos en los controles soportados por el protocolo, es decir, los elementos que existen en el mensaje LDAP que definen cómo se debe procesar la operación.

Cuando recopilamos resultados de objetos de un servidor (LDAP SearchRequest), el control VLV llamó nuestra atención (Virtual View List).

¿Qué es la lista de vistas virtuales? Es una operación de búsqueda LDAP que permite al cliente solicitar una búsqueda ordenada con un número específico de resultados antes del resultado real. Es decir, en una búsqueda de 800k objetos (que es el número aproximado de objetos en este laboratorio), puedo crear un subconjunto de 80 objetos, lo que me permite obtener resultados más rápido, sin almacenar un millón de objetos en una sola consulta.

En una aplicación, el desarrollador puede configurar un VLV para ver algunas entradas a la vez — actualizar la lista con la interacción del usuario (desplazarse hacia abajo, introducir más información en la búsqueda, etc.).

Consejo: Una buena estrategia en la solución de problemas es tener un entorno de trabajo y recopilar trazas. Una vez recolectamos, compara el paquete y valida lo que se está haciendo exactamente. La última imagen de este post muestra cómo esto puede facilitar en el alcance del problema.

Siempre que WorkSpaces (y otras aplicaciones que utilizan ldap) consulta el Active Directory local, consulta la opción de control LDAP_CONTROL_VLVREQUEST. Si no tenemos VLV, la consulta fallará.

Para Microsoft Active Directory, VLV está habilitado de forma predeterminada, pero como tenemos personalizaciones en nuestro entorno de prueba, hemos validado la configuración:

a. Iniciamos sesión en DC con permiso de administrador de Enterprise.

b. Abrimos ADISEDIT, partición de configuración.

c. Ampliamos el objeto CN=Configuration, DC=DomainNameContainer, CN=Services, CN=Windows NT.

d. Con el clic derecho, seleccionamos la opción de propiedades en CN=Directory Service.

e. En la lista de atributos, seleccionamos la opción «MSDS-Other-Settings».

f. Cambiamos la opción de DisablevlvSupport=1 a DisablevlSupport=0 (predeterminado).

A continuación, ejecutamos una nueva prueba en WorkSpaces:

La nueva traza también muestra el comportamiento predeterminado de esta búsqueda:

Conclusión

Se requiere la implementación de AWS AD Connector para utilizar una puerta de enlace en entornos que conecten su directorio existente a AWS. En esta publicación, hemos discutido algunos pasos de solución de problemas y también cómo resolver un problema de error genérico en el portal.

Discutimos cómo realizar un análisis de seguimiento ldap mediante WireShark y sobre la vista de lista virtual y sus impactos si se deshabilita en una implementación de AWS AD Connector.

Para obtener más información acerca de AWS AD Connector, recomendamos leer  este blog.


Sobre el autor

Caio Ribeiro César

Actualmente, Caio trabaja como arquitecto de soluciones especializado en tecnología de Microsoft en la nube de AWS. Comenzó su carrera profesional como administrador de sistemas, que continuó durante más de 12 años en áreas como seguridad de la información, identidad en línea y plataformas de correo electrónico corporativo. Recientemente se hizo fanático de la computación en la nube de AWS y ayuda a los clientes a aprovechar el poder de la tecnología de Microsoft en AWS.

 

Divyank Pandya

Divyank Pandya es ingeniero de soporte en la nube en Amazon Web Services, ayudando a los clientes a diseñar soluciones, cargas de trabajo y usar los servicios de AWS para adaptarse mejor a su entorno.

 

 

 

Si tiene dudas, comuníquese con nuestro equipo a través del chat en línea.