Reemplazando Certificados en Aria Suite (vRealize Suite)

Una de las operaciones de día 2 que mas terror nos daba hace unos años o posiblemente con la que mas sufríamos, fue el reemplazo de certificados para las soluciones VMware. Los que tuvimos que luchar esa batalla, recordaremos lo tedioso que era tener que reemplazar cada uno de los certificados de una solución de forma manual y encontrarse errores diferentes conforme avanzábamos.

Por suerte, esto ha cambiado y ahora Aria Suite Lifecycle (antes vRealize Suite Lifecycle Manager) nos ofrece una forma fácil, rápida y segura de reemplazar los certificados, por lo menos de los productos asociados a la Aria Suite (antes vRealize Suite) y por supuesto que sean gestionados desde Aria Suite Lifecycle.

En el procedimiento a continuación estaremos explicando cómo reemplazar los certificado autofirmados por certificados customizados, es decir certificados firmados por una entidad certificadora del cliente o CA Enterprise. El cambio de un certificado de un autofirmado por otro igualmente autofirmado, es similar al proceso explicado en este post y simplemente costa de los siguientes dos pasos por lo que no representa mayor tiene mayor dificultad.

  1. Crear un certificado en el servicio de locker de vRealize Suite lifecycle Manager
  2. Reemplazar el certificado viejo por el nuevo

Reemplazo de Certificado autofirmado por certificados customizados

Lo primero que debemos tener presente es que el reemplazo de certificados autofirmados por certificados customizados, incluye la participación del equipo de seguridad del cliente, quien será el encargado de proveernos los certificados validos para nuestros productos.

Una manera fácil de hacer esto es solicitar al cliente el/los certificados en extensión .pem y de esta manera evitamos tener que generar un Certificate Signing Request (CSR), que si bien podemos generarlos desde vRealize Suite Lifecycle Manager, pues lo único que haría es agregarnos un paso mas en el proceso. Por esta razón, recomiendo solicitar al cliente crear directamente los certificados en su herramienta y exportarlo en el formato indicado y con el Key sin cifrar.

Una vez nos han enviado el/los certificados podemos continuar con los siguientes pasos:

1. Verificar que los certificados los entreguen en .pem y que estén bien generados. Para esto podemos abrir el archivo .pem con un editor de texto y verificar que tenga la siguiente estructura.

2. Algunas veces nos envían el certificado con el key cifrado, entonces debemos pedir que nos envíen el Key sin clave. Y Rearmar el .pem en otro archivo pero esta vez utilizando el Key sin cifrar.

Recordemos que la sección asociada al Key debería contener los siguiente:

—–BEGIN RSA PRIVATE KEY—–

—–END RSA PRIVATE KEY—–

3. Una vez hemos verificado la estructura del certificado podemos ir al servicio de Locker de Aria Suite Lifecycle e importarlos en -> Certificates -> Import. En este paso solo debemos hacer click en BROWSER FILE y buscar el archivo .pem que construimos en el paso anterior. Automáticamente los campos Private Key y Certificate Chain serán poblados. Finalizamos el proceso haciedo click en el boton IMPORT

4. Una vez importados se mostraran los detalles del certificado de manera que podremos verificar que los Subject Alternative Name de cada certificado contenga los FQDN de todos los nodos de cada solución incluyendo el FQDN del VIP del balanceador que le corresponda, de ser necesario.

5. Si vamos a reemplazar el certificado de una solucion que se encuentra detrás de un balanceador como por ejemplos VMware Identity Manager (vIDM), ahora llamado Workspace One Access (WS1), debemos primero reemplazar el certificado en el balanceador siguiendo la guía de cada fabricante.

6. Una vez realizado el cambio de certificados en el balanceador, debemos realizar la action Re-trust Load Balancer en el servicio Lifecycle Operations -> Environments -> Para este ejemplo globalenvironment (ambiente asociado a vIDM o WS1).

7. Para efectuar el reemplazo de certificados lo único que debemos hacer es ir al servicio de Lifecycle Operations -> Environments -> click en VIEW DETAILS del ambiente en cuestión (para este caso globalenvironment) -> Click en los tres puntos (…) para listar mas opciones  -> Replace Certificate

8. A continuación nos muestra un resumen del certificado actual

9. Hacemos click en NEXT para seleccionar el nuevo certificado (importado) desde la lista desplegable

10. Si el certificado es de una solución como vIDM del cual dependen otros productos, nos mostrará que durante el proceso de cambio de certificados hará un Re-Trust sobre los productos listados allí. Click en NEXT para continuar.

11. A continuación podremos seleccionar si queremos que Aria Suite Lifecycle cree por nosotros un snapshot en la VMs involucradas . Se recomienda esta acción a no ser que ya hayamos tomado un snapshot directamente desde el vCenter. Luego Click en NEXT

12. Para validar que el certificado que vamos a aplicar es correcto, debemos ejecutar un PRECHECK haciendo click en el botón RUN PRECHECK

13. Después de finalizar el PRECHECK podemos ver que nos solicita una acción de aceptar y nos indica que el remplazo de los certificados sobre los balanceadores debe hacerse manual como lo comentamos anteriormente. Procedemos entonces a hacer click en ACEPTAR y después en FINISH

Nota 1: Si por alguna razon, reemplaza el certificado de una solucion de Aria Suite (vRealize Suite) sin haber cambiado el certificado del balanceador recibirá una notificación en el Aria Suite Lifecycle (vRealize Suite Lifecycle Manager) indicándole que debe reemplazar el certificado en el balanceador (Importar el certificado nuevo en NSX-T, NSX-v, F5, o el balanceador que corresponda) siguiendo la guia del fabricante, como comentamos anteriormente.

Nota 2: De igual forma, si se cambia el certificado del balanceador despues de cambiar el certificado de vIDM entonces recibirá una unas notificaciones en Aria Suite Lifecycle indicándole que debe realizar una acción de re-trust en cada una de las soluciones que se encuentren detras de ese balanceador. Comenzando de nuevo por Workspace One Access (WS1A).

Nota 3: Sino hacemos esto vamos a recibir un Bad Gateway al intentar a hacer login en WS1A. Para evitar esto, recomendamos reemplazar el certificado del balanceador en primer lugar como lo hemos mencionado anteriormente

14. Si realizamos el reemplazo del certificado en el balanceador, en primera instancia como lo hemos recomendado, la URL de acceso al WS1 (VIP)después del reemplazo de los certificados del globalenvironment, debería mostrar el sitio como seguro y con los detalles del certificado que hemos importado.

15. Como hemos realizado un cambio que esta por fuera del control de Aria Suite Lifecycle (vRealize Suite Lifecycle Manager) debemos realizar la acción de Re-trust Load Balancer, desde la solucion de Workspace One Access / VMware Identity Manager (globalenvironment) y para esto vamos a Environment -> global environment -> click en los tres puntos (…) para mas opciones y luego click en Re-trust Load Balancer

16. (Opcional) Cuando termine vamos a cada unos de los productos que estaba integrados con vIDM o WS1A, como por ejemplo Aria Operations (antes vRealize Operations Manager), Aria Automation (antes vRealize Automation), Aria Operations for Logs (vRealize Log Insight), etc. En algunas ocasiones podríamos necesitar hacer click Re-Trust with Identity Manager en cada una de las soluciones de Aria Suite (vRealize Suite), aunque este proceso por lo general se hace automático durante el reemplazo de certificados de Workspace One Access (WS1A).

17. El reemplazo de certificados de todas las soluciones de la Aria Suite tienen el mismo procedimiento que hemos mencionado para el Workspace One Access (globalenvironement), razon por la cual no haremos este post mas largo.

Nota 4: Para las soluciones que no están detrás de un balanceador, es claro que podemos hacer directamente el reemplazo de certificados siguiendo los pasos 7-13.

Por ultimo, vamos a realizar el reemplazo de certificados de la solucion Aria Suite Lifecycle (vRealize Suite Lifecycle Manager). El reemplazo de esta solucion no tiene un orden especifico y se puede realizar en primero o ultimo lugar. Vemos entonces los siguientes pasos.

Remplazo de certificados de Aria Suite Lifecycle (vRealize Suite Lifecycle Manager)

1. En el servicio de Locker vamos a crear o importar un certificado para esta solucion. Como ya explicamos como importar un certificado, en este caso generaremos uno nuevo desde la opción -> Certificates -> Add Certificate. Recordar que si lo generamos desde el servicio de Locker, sera entonces un certificado autofirmado o Self-Signed.

2. En Lifecycle Operations click en –> Settings -> Change Certificate

3. Click en el boton REPLACE CERTIFICATE

4. Revisamos los detalles del certificado actual y hacemos click en NEXT

5. Seleccionamos el nuevo certificado, que importamos o generamos en el servicio de Locker y click en NEXT

6. Click en RUN PRECHECK para verificar que todo este bien con el certificado y si todo esta ok, click en FINISH

Nota: Después de un par de minutos, en el servicio de Lifecycle Operations deberíamos ver el Request asociado a este reemplazo de certificados como Completed.

Y podemos validar que el Subject del certificado ahora contienes los datos que configuramos en el nuevo certificado.

Nota 5: (Opcional) Si ha realizado reemplazo de certificados para WS1A antes de cambiar los de Aria Suite Lifecycle entonces realize una acción de RE-REGISTER dentro del servicio de Lifecycle Operations -> Settings -> Authentication Provider. Debería haberse realizado de manera automática, pero si tiene algún problema con la autenticación de usuarios de dominio en la solucion Aria Suite Lifecycle, este paso solucionara el inconveniente.

Referencias

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.

Actualizar VMware Identity Manager (vIDM) o Workspace One Access (WSA)

Antes de comenzar es importante aclarar que si esta realizando una actualización de la solución vRealize Automation 8.x, debería seguir esta serie de posts en el siguiente orden.

1  Crear Backup para la solución de vRealize Automation

2. Actualizar vRealize Suite Lifecycle Manager (vRSLCM) 8.x

3. Configurar Binarios en vRealize Suite Lifecycle Manager (vRSLCM)

4. Actualizar VMware Identity Manager

5. Actualizar vRealize Automation 8.x

En esta oportunidad estaremos actualizando el componente de VMware Identity Manager (ahora Workspace ONE Access). Para este capitulo tendremos una serie de prerrequisitos que verificar. Pero si ha seguido esta serie de publicaciones no debería tener ningún problema.

PRERREQUISITOS

– Verifique que no hayan errores en el dashboard de la consola de administración de vIDM. Si existe algún problema resuélvalo antes de continuar.

– Verifique que haya tomado una snapshot de los nodos de VMware Identity Manager.

– Para una actualización de VMware Identity Manager en clúster, asegúrese de deshabilitar todos los nodos en espera en el balanceador de carga para que el tráfico no se enrute a los nodos en espera y habilítelos nuevamente una vez que se complete la actualización.

– Por ultimo, debemos verificar que los Binarios ya se encuentre disponibles en vRealize Lifecycle Manager (vLCM). Desde el servicio de Lifecycle Operations vaya a la sección Home -> Settings -> Binary Mapping. Sino ha seguido esta serie de post no se preocupe! en el Post Configurar Binarios en vRealize Suite Lifecycle manager (vRSLCM)  explico cual es el procedimiento para hacerlo. No tomara mas de 5 min de lectura. (Léalo y vuelva cuando este listo).

Nota: En este post estaremos explicando el procedimiento para deshabilitar los nodos secundarios en un balanceador basado en NSX-T. Si ha desplegado vRA utilizando un balanceador de un tercero, por favor remítase a la documentación del fabricante para realizar el proceso homologado.

Deshabilitar nodos secundarios en el balanceador de vIDM (NSX-T)

Como pudimos observar uno de los prerrequisitos cuando tenemos una configuración de cluster en vIDM, es que debemos deshabilitar los miembros del balanceador que estén en Standby, es decir los nodos que son secundarios.

Para saber cuales es el nodo primario y cuales los nodos secundarios basta con ir a vLCM ->Lifecycle Operations ->Environments y clic en VIEW DETAILS de globalenvironment.

Nota 1: Bajo Product References podrá ver cual es el nodo primario (Primary Node) y cuales los nodos secundarios (Secondary Node). Tenga en cuenta esta información para cuando vaya a deshabilitar los miembros del balanceador.

Podemos ahora continuar con los siguientes pasos en la interface de NSX-T Manager.

1. Una vez identificado los nodos Standby (Secondary Nodes) debe hacer login en NSX-T y luego en Networking -> Load Balancing -> Virtual Servers, para editar el balanceador y sus miembros.

Identifique el Server Pool asociado a la solución de VMware Identity Manager (para este caso es wsa-server-pool).

2. Vaya a la sección de SERVER POOLS en la interface de NSX-T y luego seleccione el server pool asociado al vIDM.

3. Haga clic en los tres puntos verticales al lado izquierdo y luego Edit.

4. Después haga clic en el numero 3 que indica los miembros del Server Pool, para editarlo.

5. En esta vista haga clic en los tres punto y luego Edit en los miembros del pool que son secundarios.(Para este caso los nodos secundarios son vidm01 y vidm02).

Cambie el estado a Disabled para ambos miembros y clic en SAVE para cada uno.

6. Clic en APPLY para aplicar los cambio y debería verse de la siguiente forma.

7. Nuevamente Clic en APPLY y luego en SAVE para terminar.

Una vez hemos completado los prerrequisitos. Podemos continuar con el proceso de actualización de vIDM desde la interface de vRealize Lifecycle Manager.

PROCEDIMIENTO

1. En el servicio Lifecycle Operations haga clic en Environments.

2. Navegue hasta la instancia globalenvironment.

3. Clic en VIEW DETAILS. 

4. Clic en los tres punto a la derecha de VMware Identity Manager y después en Trigger Cluster Health.

El resultado del Request debería ser Completed.

5. Vuelva a Environments -> globalenvironment y haga clic en el botón Upgrade. Y marque los check asociados al snapshot y al cluster health.

Nota 2: Si ya verifico la salud del cluster (Cluster Health) marque el check.

6. Clic en el botón TRIGGER INVENTORY SYNC. Es mandatorio para poder habilitar el botón de PROCEED.

7. Clic en PROCEED y seleccione el tipo de repositorio.

Nota 3: Puede seleccionar cualquiera de los siguiente repositorios

Nota 4: De manera opcional puede hacer clic en el botón VIEW COMPATIBILITY MATRIX para verificar la compatibilidad de la nueva versión con las soluciones existentes. Se requiere acceso a internet en la IP de vLCM para esta acción.

8. Si ya tomó un Snapshot de manera manual a cada uno de los appliances,  demarque el check «Take product snapshot», sino es así, déjelo marcado para que vRSLCM cree uno para los appliances de vIDM.

Nota 5: En este caso dejare el check sin marcar porque ya tomé un snapshot directamente desde el vCenter.

9. Clic en el botón RUN PRECHECK.

10. Lea los comentario y marque el check «I took care of the manual steps above and am ready to proceed» para habilitar el botón RUN PRECHECK.

11. Clic en RUN PRECHECK una vez mas y espere a que termine la validación.

12. Revise la información presentada y luego clic en NEXT.

13. Luego clic en SUBMIT y espere a que el proceso de actualización termine. Sea paciente, este proceso puede tardar más de una hora. Al final el resultado del Request debería ser Completed.

14. Vaya a de nuevo Environments -> globalenvironment y verifique la versión del producto. Para este caso mostrara 3.3.6.

15. Inicie sesión en la URL del Tenant en vIDM y verifique el correcto funcionamiento de la solución.

16. Siguiendo los pasos anteriormente mencionado para deshabilitar los miembros Standby del balanceador de vIDM, debemos hacer lo mismo pero esta vez para volver a activarlos. Deberían quedar todos los miembros con el estado en Enabled.

17. Por ultimo, verifique que hasta aquí continúe con acceso al portal de vRealize Automation.

18. Si todo esta OK, podemos remover los snapshots de cada uno de los appliances asociados a la solución VMware Identity Manager.

Referencia

https://docs.vmware.com/en/VMware-vRealize-Suite-Lifecycle-Manager/8.7/com.vmware.vrsuite.lcm.8.7.doc/GUID-F2072ADF-4C4B-454E-A074-DB4B0B472184.html

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.

Cambiando tiempo de expiración de contraseñas para VMware Identity Manager (vIDM) o Workspace One Access (WSA)

Como bien sabemos cuando desplegamos VMware Identity Manager ahora llamado Workspace One Access, desde vRealize Suite Lifecycle Manager, los password son administrados desde el servicio de Locker de este componentes y su periodo de expiración por defecto es de 60 días, el cual si bien es una muy buena practica, puede ser un periodo de rotación de password muy corto para la mayoría de los usuarios y muchos suelen olvidar cambiar los password hasta que tienen una actividad de mantenimiento, troubleshooting o una actualización.

Y es en ese momento es cuando solemos entrar a verificar la plataforma y nos encontramos con una molesta X roja en los dashboards del Identity Manager, indicándonos que nuestros password de root y sshuser han expirado.

En esta ocasión revisaremos un sencillo TIP para cambiar el tiempo de expiración de los password asociados a los usuarios root y ssh de estos appliances.

PROCEDIMIENTO

Iniciar sesión ssh en cada uno de los appliances de la solución VMware Identity Manager (vIDM) o Workspace One Access (WS1 Access).

Ejecutar el comando en cada una de las sesión ssh para verificar el tiempo de expiración actual.

cat /etc/shadow

Nota 1: En la imagen anterior podemos ver que dentro del recuadro azul se ha resaltado el numero de días de expiración para los usuarios root y sshuser.

Cambiar este periodo es muy sencillo y basa con ejecutar los siguientes comandos en cada una de las sesiones ssh asociadas a los appliances de vIDM o WS1 Access presentes en nuestra infraestructura. En este caso al ser un ambiente de laboratorio definiremos el tiempo de expiración a un año (365 días).

passwd -x 365 root
passwd -x 365 sshuser

Una vez ejecutados los comandos anteriores podemos verificar el cambio ejecutando nuevamente el comando cat /etc/shadow, o directamente desde la interfaz gráfica hacer un refresh frente a la politica User Password Expiration y eso es todo. Ya tenemos un nuevo periodo de expiración definido.

Nota 2: Después de unos minutos el dashboard debería volver a un estado óptimo cambiando la molesta X roja de la esquina superior derecha por un check color verde .

Nota 3: Recuerde que es necesario ejecutar el comando tanto para el usuario root como para el usuario sshuser.

Referencias

Todos los créditos para el blogger Rafael Moura quien compartió esta información hace un par de meses atrás.

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.