miércoles, 1 de abril de 2015

Workaround para los errores de integración de vSphere 5.5 con Active Directory

A veces, cuando tratas de unir vSphere5.5 vCenter Server Appliance (vCSA) con Active Directory, no pasas de darte con el siguiente mensaje: “Error: Idm client exception: Failed to establish server connection”.
A continuacion, van las instrucciones para reproducir el error, y despues, como solventarlo, para de esta manera entender el motivo, y subsanarlo. 

Comenzamos con VMware vCenter Server Appliance unido a AD

Figura 1: VMware vCenter Server Appliance con la integración de Active Directory habilitada

Ingresamos con las credenciales vcsa SSO Administrator@vsphere.local . Cuenta con una contraseña predeterminada de vmware (Ver Figura 2). Tenga en cuenta que esta cuenta es diferente del usuario root .
Figura 2: Entrar vcsa con las credenciales de administrador de SSO
Figura 2: Entrar vcsa con las credenciales de administrador de SSO
Vamos a Inicio -> Administración -> Single Sign-On -> Configuración (Ver Figura 3).
Figura 3: Vaya a Administración -> Single Sign-On -> Configuración
Figura 3: Vaya a Administración -> Single Sign-On -> Configuración
A continuación, tratar de crear una nueva fuente de Identidad (Ver Figura 4).
Figura 4: Agregar una nueva identidad SSO Fuente
Figura 4: Agregar una nueva identidad SSO Fuente
A medida que el vcsa ya está unido al dominio de Active Directory la expectativa sería utilizar la autenticación integrada de Windows para Active Directory junto con el uso de la cuenta de equipo vcsa. Al final, es por eso que hemos añadido vcsa al Active Directory en el primer lugar. Desafortunadamente no tardaremos en ver que estamos decepcionó en esta expectativa.
Por ahora seleccionar como fuente de identidad escriba el valor de Active Directory (Windows integrada Autenticación) , confirme su nombre de dominio y seleccione la cuenta Uso máquina (Ver Figura 5).
Figura 5: Configurar una fuente de identidad de Active Directory con los parámetros por defecto
Figura 5: Configurar una fuente de identidad de Active Directory con los parámetros por defecto
Después de cerrar el cuadro de diálogo anterior con Aceptar , debería ver la nueva fuente de identidad (Ver Figura 6).
Figura 6: Fuente de la identidad de Active Directory
Figura 6: Fuente de la identidad de Active Directory
Despues, vamos hasta Administración -> Configuración -> Single Sign-On -> Usuarios y grupos -> Usuarios y pinchamos bajo dominio del dominio que acabamos de crear (Ver Figura 7).
Figura 7: intenta ver los usuarios en el origen de la identidad de Active Directory
Figura 7: intenta ver los usuarios en el origen de la identidad de Active Directory
En lugar de mostrar los usuarios de Active Directory como se esperaba, vcsa muestra el mensaje de error "Error: excepción cliente IDM: No se pudo establecer conexión con el servidor". Por tanto, parece como si la integración de Active Directory en vcsa por defecto estuviera rota (Ver Figura 8).
Figura 8: Mensaje de error mientras attemptting para ver los usuarios en el origen de la identidad de Active Directory
Figura 8: Mensaje de error mientras attemptting para ver los usuarios en el origen de la identidad de Active Directory
La Solución
Ahora que hemos visto el problema, vamos a trabajar para esquivarlo. De esta manera todavía podemos alcanzar el objetivo de utilizar Active Directory como fuente de identidad para los SSO en VMware vSphere.
Comienza por eliminar la fuente de la identidad de Active Directory que creamos previamente (Ver Figura 9).
Figura 9: Retire la fuente de identidad de Active Directory
Figura 9: Retire la fuente de identidad de Active Directory
Crear una nueva fuente de identidad. Seleccionamos esta vez para la fuente de identidad la casilla de Active Directory como un servidor LDAP . Rellene los campos restantes de la siguiente manera (ver Figura 10):
  • Nombre: Su nombre de dominio AD; Por ejemplo, "corp.local"
  • Base DN for users: Dividir su nombre de dominio en pedazos separados por puntos (".") Y el prefijo de cada parte con una "dc =". Coloque las comas "," entre cada parte; Por ejemplo, "dc = corp, dc = local"
  • Nombre de dominio: El nombre de dominio AD; Por ejemplo, "corp.local"
  • El alias de dominio: Su nombre NetBIOS del dominio de AD; Por ejemplo, "CORP"
  • Base DN for groups: Igual al DN for users; Por ejemplo, "dc = corp, dc = local"
  • URL del servidor primario: El servidor de Active Directory como una URL con el protocolo "ldap: //" y el puerto 389 .; Por ejemplo, ldap: //192.168.110.10: 389
  • Secondary Sever URL: Otro servidor de Active Directory como una URL si tenemos uno. De lo contrario, lo dejamos en blanco; Por ejemplo, ldap: //192.168.110.20: 389
  • Nombre de usuario: Un nombre de usuario de Active Directory en notación netbios con privilegios para leer todos los usuarios y grupos; Por ejemplo, "CORP \ Administrador"
  • Contraseña: La contraseña del usuario anterior.
Figura 10: Agregar una fuente de identidad con Active Directory como un servidor LDAP
Figura 10: Agregar una fuente de identidad con Active Directory como un servidor LDAP
Probamos la configuración haciendo clic en la Prueba de conexión botón. Este intentará conectarse a Active Directory como un servidor LDAP con los ajustes previstos (Ver Figura 11).
Figura 11: Prueba de la conectividad de la nueva fuente de identidad
Figura 11: Prueba de la conectividad de la nueva fuente de identidad
Si la prueba de conexión se ha realizado correctamente, guardamos los ajustes. Deberia aparecer la nueva fuente de identidad, que acabamos de añadir(Ver Figura 12).
Figura 12: Fuente de la identidad de Active Directory a través de LDAP
Figura 12: Fuente de la identidad de Active Directory a través de LDAP
Ahora, si usted volvemos a Administración -> Configuración -> Single Sign-On -> Usuarios y grupos -> Usuarios y pinchamos bajo dominio del dominio que acabamos de crear, veremos los usuarios y grupos de este Active Directory (Ver Figura 13). Con esto hemos logrado nuestro objetivo.
Figura 13: Los usuarios en una fuente de identidad de Active Directory muestran con éxito
Figura 13: Los usuarios en una fuente de identidad de Active Directory muestran con éxito
No nos olvidemos de agregar usuarios de Active Directory para los correspondientes grupos vcsa para conceder acceso a estos usuarios (Ver Figura 14).
Figura 14: Agregar usuarios a los grupos para asignar permisos
Figura 14: Agregar usuarios a los grupos para asignar permisos
Asimismo, debemos agregar usuarios de Active Directory para los Permisos de vCenter (Ver Figura 15).
Figura 15: Agregar usuarios al vCenter
Figura 15: Agregar usuarios al vCenter
Autenticación con usuario de sesion de Windows
La autenticacion de inicio de sesión con el usuario de Windows para el cliente vSphere Web (Ver Figura 16) seguirá funcionando con esta solución. La razón es que vcsa utiliza Kerberos para autenticar el cliente de Windows contra el cliente vSphere Web (a través de un plugin instalable). Una vez que la autenticación tiene éxito, únicamente los controles en la fuente de la identidad que coinciden con el nombre de dominio si existe ese usuario. Sin contraseña es cada vez transferida desde el cliente de Windows a la vcsa o la fuente de identidad.
Figura 16: La autenticación de sesión de Windows aún funciona
Figura 16: La autenticación de sesión de Windows aún funciona
Observaciones finales
es de esperar que después de unirse vcsa al dominio de Active Directory, es posible, utilizar la autenticación integrada de Windows para Active Directory junto con el uso de la cuenta de equipo vcsa. Esta solución al menos permitirá utilizar un Active Directory como fuente de identidad para los SSO en VMware vSphere.
¡Ten en cuenta que realmente no es necesario unir el vCSA (vCenter Server Appliance) a AD con el fin de administrarlo!

No hay comentarios:

Publicar un comentario

¡Gracias por colaborar en este blog con tus comentarios! :)