Objective 1.3
Describe SSO Architecture and components
En la versión 6.0 de vSphere, el servicio Single Sign-On existente en versiones anteriores, forma parte de Platform Services Controller (PSC). PSC es un componente encargado de realizar las siguientes funciones:
- Gestión de identidades y permisos
- Gestión de certificados del entorno vSphere
- Almacena y replica las licencias VMware
- Gestiona los permisos globales
- Almacena y replica las Etiquetas (Tags) y categorías
Los servicios que incluye el componente PSC 6 son:
- VMware Appliance Management Service (only in Appliance-based PSC)
- VMware License Service
- VMware Component Manager
- VMware Identity Management Service
- VMware HTTP Reverse Proxy
- VMware Service Control Agent
- VMware Security Token Service
- VMware Common Logging Service
- VMware Syslog Health Service
- VMware Authentication Framework
- VMware Certificate Service
- VMware Directory Service
vCenter Single Sign-On es un conjunto de servicios que permite que los components de vSphere se comuniquen entre ellos mediante un mecanismo de token seguro en lugar de solicitor a los usuarios que se autentiquen por separado en cada componente. Dependiendo del tipo de usuario, se utiliza un procedimiento diferente:
- Usuarios humanos: se utiliza usuario y contraseña
- Usuarios de solución: se utilizan certificados Los componentes de vCenter Single Sign-On son:
- Security Token Service (STS): es el encargado de emitir los tokens en lenguaje SAML. Estos tokens de seguridad representan la identidad de un usuario. Este servicio firma todos los tokens con un certificado de firma.
- Administration Server: es el servicio que permite la administración y configuración de vCenter Single Sign-On desde vSphere Web Client.
- VMware Directory Service (vmdir): es el servicio de directorio de VMware asociado al dominio indicado durante la instalación (normalmente vsphere.local) Se trata de un servicio que pone a disposición un directorio LDAP en el puerto 389). Este directorio almacena información sobre vCenter Single Sign-On e información sobre certificados.
- Identity Management Service: controla los orígenes de identidad y las solicitudes de autenticación de STS
Conceptos
- Dominio Single Sign-On: cuando se instala PSC 6.0 (o se migra una instalación de Single Sign-On 5.5 existente) se utiliza un dominio interno (por defecto llamado vsphere.local) Sólo puede haber un dominio por implementación vSphere.
- Sitio Single Sign-On: es un contenedor lógico en el que se agrupan los objetos del componente PSC en el dominio. Se utilizan para configurar y agrupar servidores PSC en Alta Disponiblidad tras un Balanceador de carga. Pueden existir varios sitios en una implementación vSphere.
Topologías recomendadas de instalación de vCenter Server 6.0
| Topología 1: todo en uno |
|---|
 |
- Descripción topología 1:
- 1 Single Sign-On domain
- 1 Single Sign-On site
- 1 vCenter Server with embedded Platform Services Controller
| Topología 2: PSC dedicado |
|---|
 |
- Descripción topología 2:
- 1 Single Sign-On domain
- 1 Single Sign-On site
- 1 external Platform Services Controllers
- 1 or more vCenter Server with external Platform Services Controllers
| Topología 3: PSC dedicado y replicado |
|---|
 |
- Descripción topología 3
- 1 Single Sign-On domain
- 2 or more Single Sign-On sites
- 2 or more external Platform Services Controllers
- 2 or more vCenter Server with external Platform Services Controller
| Topología 4: PSC con Load Balancer |
|---|
 |
- Descripción topología 4
- 1 Single Sign-On domain
- 1 Single Sign-On site
- 2 or more external Platform Services Controllers
- 1 or more vCenter Server with external Platform Services Controllers
- 1 third-party load balancer
| Topología 5: Multisitio con Load Balancer |
|---|
 |
- Descripción topología 5
- 1 Single Sign-On domain
- 2 Single Sign-On sites
- 2 or more external Platform Services Controllers
- 1 or more vCenter Server with external Platform Services Controllers
- 2 third-party load balancers
| Topología 6: Multisitio |
|---|
 |
- Descripción topología 6
- 1 Single Sign-On domain
- 2 Single Sign-On sites
- 2 or more external Platform Services Controllers
- 1 or more vCenter Server with external Platform Services Controllers
Respecto al servidor vCenter, podemos implantar el componente PSC de 2 formas:
- Embedded PSC
- Es suficiente en la mayoría de los entornos simples.
- Sencillo de desplegar, mantener y realizar backups
- Soporta los productos y características que un PSC externo
- No está soportada la réplica entre instancias embedded
- External PSC
- Recomendada si se tiene varios servidores vCenter
- El modo Enhanced Linked Mode proporciona una vista única para diferentes servidores vCenter del mismo dominio
- Permite optimizar los recursos al compartir el componente PSC entre varios servidores vCenter La configuración en Alta Disponibilidad requiere de:
- La configuración adicional con los scripts PSC HA de VMware
- Un balanceador de carga
Differentiate available authentication methods with VMware vCenter
vCenter Single Sign-On y Windows Session Authentication Podemos acceder a la infraestructura utilizando Windows Session Authentication (SSPI), para ello debemos tener:
- Correctamente configurado Directorio Activo como origen de identidad de Single Sign-On
- Instalado vSPhere Web Client Integration Plug-In en el cliente
- El usuario debe de haberse conectado a su equipo Windows con una cuenta de Directorio Activo
Perform a Multi-Site SSO installation
En una configuración multisitio, cada sitio es independiente, con replicación PSC entre los sitios. Los servidores vCenter utilizan los servicios PSC locales al sitio en el que se encuentran. Se comparte el dominio SSO y se replican las licencias, los permisos globales, las etiquetas (tags) y roles entre todos los sitios. Esta topología utiliza Enhanced Linked Mode para facilitar un único punto de acceso y visualizar toda la infraestructura de todos los servidores vCenter.
Configuración ejemplo de un entorno Multi-Sitio
Para realizar una instalación Multi-Sitio seguimos los siguientes pasos:
- Instalamos un servidor con el componente PSC
- En este servidor creamos el dominio y el sitio inicial
- Instalamos un segundo servidor con el componente PSC
- Indicamos que vamos a unirlo a un dominio Single Sign-On existente
- Indicamos si queremos que pertenezca al mismo sitio
- O creamos un nuevo sitio en el dominio Single Sign-On
- Si tenemos más de un servidor PSC por sitio, tenemos que configurar un balanceador de carga que publique los servicios para cada sitio.
- Como último paso instalamos el servidor vCenter apuntando al componente PSC correspondiente al sitio en el que se está instalando el servidor vCenter
Para añadir Active Directory como origen de identidad de vCenter Single Sign-On seguimos estos pasos: Nota: antes de poder añadir el origen de identidad, es necesario que el serivdor donde se ejecuta el servicio vCenter Single Sign-On esté unido al dominio:
- Si es un servidor Windows, añadimos el servidor al dominio como cualquier otro sistema
- Si es un appliance virtual (VCSA) seguimos estos pasos:
- Accedemos a vSphere Web Client
- Administration → Deployment → System Configuration → Nodes
- Accedemos a Manage → Settings → Active Directory
- Pinchamos en Join… e indicamos la siguiente información:
- Domain: Nombre del dominio de Active Directory, por ejemplo localdomain.local
- Organizational unit (opcional) sólo si queremos ubicar la máquina en una OU en concreto de Active Directory
- Nombre de usuario: nombre de usuario en formato UPN, por ejemplo [email protected]
- Password: contraseña del usuario
- Reiniciamos el servidor para que se apliquen los cambios
Una vez que tenemos el servidor vCenter añadido al dominio, agregamos el origen de identidad
- Accedemos a vSphere Web Client
- Administration → Single Sign-On Configuration → Identity Sources
- Pinchamos en el símbolo +
- Seleccionamos
- Indicamos el nombre del dominio
- Confirmamos que el dominio se ha añadido correctamente
Configure/Manage Platform Services Controller (PSC)
Configuración de Single Sign-On
- Policies
- Password Policy: se pueden establecer un conjunto de reglas que determinan el formato y caducidad de las contraseñas de los usuarios del dominio Single Sign-On
- Lockout Policy: se puede establecer las reglas que configuran la política de bloqueo de cuentas del dominio Single Sign-On cuando se produce un error de acceso
- Token Policy: establece las reglas de tiempos de validez de los token, tolerancia en el desfase de la hora:
Administración desde vSphere Web Client
- Accedemos a Administration -> Deploymen -> System Configuration
- Vemos los nodos y servicios de la infraestructura
- Desde aquí podemos
- Ver y editar configuración de red
- Ver certificados del nodo
Configure/Manage Active Directory authentication
Para que los usuarios puedan iniciar sesión con sus cuentas de Directorio Activo es necesario agregarlo como un origen de identidad de vCenter Single Sign-On. vCenter Single Sing-On, admite los siguientes orígenes de identidad:
- Active Directory (Integrated Windows Authentication): compatible con versiones de Active Directory 2003 y posteriores. vCenter Single Sign-On permite especificar un único dominio de Active Directory como origen de identidad.
- Active Directory as an LDAP Server: vCenter Single Sign-On admite varios orígenes de identidad de Active Directory en LDAP. Este tipo de origen de identidad se mantiene para proporcionar compatibilidad con el servicio vCenter Signle Sing-On de vSphere 5.1
- Open LDAP: versiones 2.4 o posteriores. vCenter Single Sign-On es compatible con varios orígenes de identidad de Open LDAP.
- Local OS: los usuarios del sistema operativo local del sistema donde se ejecuta el servicio vCenter Single Sign-On. Sólo está disponible en implementaciones de vCenter Single Sign-On básicas, no en implementaciones con varias instancias
- Usuarios del dominio de vCenter Single Sign-On: son los usuarios del dominio vsphere.local (nombre por defecto) que se crea al isntalar vCenter Single Sign-On. Inmediatamente después de la instalación, quedan disponibles los orígenes de identidad de vsphere.local y Local OS. El resto de origenes es necesario añadirlos en un paso posterior a la instalación.
Configure/Manage VMware Certificate Authority (VMCA)
En la infraestructura vSphere se utilizan certificados para establecer las conexiones con los servidores o también en el caso de usuarios de soluciones específicas. Existen 2 formas básicas en las que un administrador gestiona los certificados:
- Administradores que no reemplazan los certificados de VMware: en este caso, en lugar de certificados autofirmados como ocurría en versiones anteriores, el servicio VMware Certificate Authority (VMCA) se encarga de aprovisionar los certificados a vCenter Server con componentes y a los host ESXi. Certificados que usan VMCA como entidad de certificación raíz.
- Administradores que reemplazan certificados de VMware por certificados personalizados. Si la política de empresa establece que los certificados tienen que estar firmados por una entidad de certificación externa o empresarial, se pueden reemplazar los certificados utilizando dos alternativas
- Utilizar VMCA como entidad intermedia, de forma que el certificado raíz de VMCA sea firmado por la entidad de certificación, y actue como certificado intermedio. Los certificados que proporciona VMCA a vCenter Server y servidores ESXi son certificados que incluyen la cadena completa de certificados
- Si no se permiten certificados intermedios en la cadena, se reemplazan los certificados por los certificados personalizados que se ajusten a la política de empresa sin utilizar VMCA
En el caso de vCenter Server, es posible ver y reemplazar certificados con las siguientes herramientas:
- Interfaz web de Platform Services Controller
- Explorar los almacenes de certificados actuals, agregar y quitar almacenes de certificados y agragar y quitar entradas del almacen de certificados
- Explorar la instancia de VMCA asociada con esta instancia de PSC
- Renovar los certificados actuales o reemplazarlos
- vSphere Certificate Manager
- Conversión de VMCA en una CA intermedia
- Generar CSR
- Usar certificados personalizados
- Comandos CLI (certool, vecs-cli, dir-cli)
- Reemplazar certificado raíz del servicio de directorio de VMware (vmdir
- Reemplazar el certificado de Single Sign-On En el caso de vCenter Server, PSC y las máquinas y servicios relacionados, se admiten los siguientes certificados:
- Certificados generados y firmados por la entidad de certificación VMCA
- Certificados personalizados
- Certificados empresariales que se generan desde su propia PKI interna
- Certificados externos firmados por una entidad de certificación que se genera mediante una PKI externa. No se admiten los certificados autofirmados que se crearon mediante OpenSSL donde no existe una entidad de certificación raíz. En el caso de los servidores ESXi existen las siguientes opciones:
- VMware Certificate Authority mode (default): certificados firmados por VMCA
- Custom Certificate Authority mode: certificados no firmados por VMCA
- Thumbprint mode: utilizado para mantener certificados de versiones de ESXi anteriores (por ejemplo 5.5) Usar este modo de forma temporal. Certificados en la infraestructura vSphere
- Certificados de ESXi: proporcionados por defecto por VMCA cuando se agrega el host al vCenter y se almacenan localmente en cada servidor ESXi. Se almacenan en /etc/vmware/ssl
Certificados SSL de máquina: proporcionado por defecto por VMCA y se almacena en VECS. Permite crear un socket de SSL en el lado del servidor al cual se conectan los clientes SSL mediante protolos HTTPS o LDAPS
Certificados de Usuarios de solución: proporcionado por defecto por VMCA y se almacena en VECS. Un usuario de solución agrupa uno o más servicios de vCenter Server y utiliza certificados para autenticarse en vCenter Single Sign-On. Los siguientes almacenes de certificados de usuarios de solución se incluyen en VECS
- machine: lo utilizan el administrador de componentes, el servidor de licencias y el servicio de registro
- vpxd: almacén del demonio del servicio vCenter (vpxd) de los nodos de administración.
- vpxd-extensions: almacén de estensiones de vCenter, como Auto Deploy, servicio de inventario…
- vsphere-webclient: almacén de vSphere Web Client.
Certificado de firma SSL vCenter Sign-On: se genera durante la instalación. Cuando vCenter Single Sign-On emite tokens SAML para la autenticación de usuarios, firma cada token con su certificado de firma.
Certificado de SSL de VMware Directory Service (vmdir): se genera durante la instalación.
VMware Endpoint Certificate Store (VECS) sirve de repositorio local para certificados, claves privados y cualquier información de certificados que se pueda guardar. Podemos acceder desde el interfaz de administración de PSC
Reemplazar certificados existentes con nuevos certificados firmados por VMCA
- Generar un nuevo certificado root de VMCA
- Reemplazar los certificados SSL de máquina con nuevos certificados firmados por VMCA
- Reemplazar los certificados de los usuarios de solución con nuevos certificados firmados por VMCA
- Reemplazar el certificado de servicio de directorio de VMware
Convertir VMCA en una entidad de certificación intermedia
- Generar la solicitud de firma de certificado (CSR)
- Agregar el nuevo certificado raíz den VMCA
- Reemplazar el certificado SSL de máquina por un certificado de VMCA (entidad de certificación intermedia)
- Renovar los certificados de usuarios de solución por un certificado de VMCA (entidad de certificación intermedia)
- Reemplazar certificado para el servicio de directorio de VMware
Reemplazar todos los certificados por certificados personalizado
- Generar las solicitudes de firma de certificado
- Reemplazar el certificado SSL de máquina con un certificado personalizado
- Renovar los certificados de usuarios de solución con un certificado personalizado
Enable/Disable Single Sign-On (SSO) users
- Accedemos a la sección de configuración de usuarios de Single Sign-On
- Podemos deshabilitar una cuenta utilizamos el botón Disable
- Para volver a habilitarla utilizamos el botón Enable
