Autenticación basada en certificados y WorkSpaces Personal
Puede usar la autenticación basada en certificados con WorkSpaces para eliminar la solicitud de usuario de la contraseña del dominio de Active Directory. Al usar la autenticación basada en certificados con su dominio de Active Directory, puede:
-
Confiar en su proveedor de identidades SAML 2.0 para autenticar al usuario y proporcionar declaraciones de SAML que coincidan con las del usuario de Active Directory.
-
Crear una experiencia de inicio de sesión único con menos solicitudes al usuario.
-
Habilitar los flujos de autenticación sin contraseña con su proveedor de identidades SAML 2.0.
La autenticación basada en certificados utiliza los recursos de AWS Private CA de su cuenta AWS. AWS Private CA permite la creación de jerarquías de autoridades de certificación (CA) privadas, incluidas las CA raíz y subordinadas. Con AWS Private CA, también puede crear su propia jerarquía de CA y emitir certificados desde ella que autentiquen a los usuarios internos. Para obtener más información, consulte la Guía del usuario de AWS Private Certificate Authority.
Cuando se usa AWS Private CA para la autenticación basada en certificados, WorkSpaces solicitará certificados para sus usuarios automáticamente durante la autenticación de la sesión. Autentica a los usuarios en Active Directory con una tarjeta inteligente virtual proporcionada con los certificados.
La autenticación basada en certificados es compatible con los paquetes de escritorios de WorkSpaces para Windows con DCV que utilizan las aplicaciones cliente más recientes de Web Access, Windows y macOS de WorkSpaces. Abra descargas de clientes
Cliente de Windows (versión 5.5.0 o posterior)
Cliente para macOS (versión 5.6.0 o posterior)
Para obtener más información sobre cómo configurar una autenticación basada en certificados con Amazon WorkSpaces, consulte How to configure certificate-based authentication for Amazon WorkSpaces
Requisitos previos
Realice los siguientes pasos antes de habilitar la autenticación basada en certificados.
-
Configure su directorio de WorkSpaces con la integración de SAML 2.0 para usar la autenticación basada en certificados. Para obtener más información, consulte Integración de WorkSpaces con SAML 2.0.
-
Configurar el atributo
userPrincipalNameen su declaración de SAML. Para obtener más información, consulte Crear declaraciones para la respuesta de autenticación SAML. -
Configurar el atributo
ObjectSiden su declaración de SAML. Esto es necesario para realizar un mapeo fuerte al usuario de Active Directory. La autenticación basada en certificados fallará si el atributo no coincide con el identificador de seguridad (SID) de Active Directory para el usuario especificado en SAML_SubjectNameID. Para obtener más información, consulte Crear declaraciones para la respuesta de autenticación SAML.nota
Según Microsoft KB5014754
, el atributo ObjectSidserá obligatorio para la autenticación basada en certificados después del 10 de septiembre de 2025. -
Añada el permiso STS:TagSession a la política de confianza de su rol de IAM utilizada con la configuración SAML 2.0 si aún no está presente. Este permiso es necesario para usar la autenticación basada en certificados. Para obtener más información, consulte Crear un rol de IAM de federación SAML 2.0..
-
Cree una autoridad de certificación (CA) privada utilizando AWS Private CA si no tiene ninguna configurada con su Active Directory. Se necesita AWS Private CA para utilizar la autenticación basada en certificados. Para obtener más información, consulte Planear la implementación de AWS Private CA y siga las instrucciones para configurar una CA para la autenticación basada en certificados. La siguiente configuración de AWS Private CA es la más habitual en los casos de uso de la autenticación basada en certificados:
-
Opciones de tipo de CA
-
Modo de uso de CA con certificados de corta duración (se recomienda si la CA solo emite certificados de usuario final para la autenticación basada en certificados)
-
Jerarquía de un solo nivel con una CA raíz (también puede elegir una CA subordinada si quiere integrarla con una jerarquía de CA existente)
-
-
Opciones de algoritmos de clave: RSA 2048
-
Opciones de nombre distintivo por asunto: utilice la combinación de opciones más adecuada para identificar la CA en el almacén de entidades emisoras de certificados raíz de confianza de Active Directory.
-
Opciones de revocación de certificados: distribución de CRL
nota
La autenticación basada en certificados requiere un punto de distribución de CRL en línea al que se pueda acceder tanto desde los escritorios como desde el controlador de dominio. Esto requiere acceso no autenticado al bucket de Amazon S3 configurado para entradas de CRL de CA privada de o una distribución de CloudFront con acceso al bucket de Amazon S3 si bloquea el acceso público. Para obtener más información sobre estas opciones, consulte Planificación de una lista de revocación de certificados (CRL).
-
-
Etiquete su CA privada con una clave
euc-private-caque permita designar la CA para su uso con la autenticación basada en certificados. Esta clave no requiere ningún valor. Para obtener más información, consulte Administrar las etiquetas de su CA privada. -
La autenticación basada en certificados utiliza tarjetas inteligentes virtuales para iniciar sesión. Siguiendo las directrices para habilitar el inicio de sesión con tarjetas inteligentes con entidades emisoras de certificados de terceros
en Active Directory, lleve a cabo los siguientes pasos: -
Configure los controladores de dominio con un certificado de controlador de dominio para autenticar a los usuarios de tarjetas inteligentes. Si tiene una CA empresarial de Active Directory Certificate Services configurada en su Active Directory, los controladores de dominio se inscriben automáticamente con certificados para permitir el inicio de sesión con tarjeta inteligente. Si no tiene los Servicios de certificados de Active Directory, consulte Requirements for domain controller certificates from a third-party CA
. Puede crear un certificado de controlador de dominio con AWS Private CA. Si lo hace, no utilice una CA privada configurada para certificados de corta duración. nota
Si utiliza AWS Managed Microsoft AD, puede configurar los servicios de certificados en una instancia EC2 para cumplir con el requisito de los certificados de controlador de dominio. Consulte AWS Launch Wizard para ver ejemplos de implementaciones de AWS Managed Microsoft AD configurado con Servicios de certificados de Active Directory. AWS Private CA se puede configurar como una entidad subordinada a la CA de Servicios de certificados de Active Directory o como su propia entidad raíz al utilizar AWS Managed Microsoft AD.
Una tarea de configuración adicional con los Servicios de certificados de Active Directory de AWS Managed Microsoft AD consiste en crear reglas de salida desde el grupo de seguridad de VPC del controlador hasta la instancia EC2 que ejecuta los Servicios de certificados, lo que permite que los puertos TCP 135 y 49152-65535 habiliten la inscripción automática de certificados. Además, la instancia EC2 en ejecución también debe permitir el acceso entrante a estos mismos puertos desde las instancias de dominio, incluidos los controladores de dominio. Para obtener más información sobre la ubicación del grupo de seguridad de AWS Managed Microsoft AD, consulte Configuración de las subredes de VPC y los grupos de seguridad.
-
En la consola de AWS Private CA o mediante el SDK o la CLI, seleccione su CA y, en el certificado de CA, exporte el certificado privado de CA. Para obtener más información, consulte Exportación de un certificado privado.
-
Publique la CA en Active Directory. Inicie sesión en un controlador de dominio o en una máquina asociada a un dominio. Copie el certificado de CA privado en cualquier
<path>\<file>y ejecute los siguientes comandos como administrador de dominio. También puede usar la política de grupo y la herramienta PKI Health Tool (PKIView) de Microsoft para publicar la CA. Para obtener más información, consulte Configuration instructions. certutil -dspublish -f <path>\<file> RootCA certutil -dspublish -f <path>\<file> NTAuthCAAsegúrese de que los comandos se completen correctamente y, a continuación, elimine el archivo de certificado privado. Según la configuración de replicación de Active Directory, la CA puede tardar varios minutos en publicar en los controladores de dominio y en las instancias de escritorio.
nota
Active Directory debe distribuir la CA a las entidades de certificación raíz de confianza y Enterprise NTAuth almacena automáticamente los escritorios de WorkSpaces cuando se asocian al dominio.
-
Habilitación de la autenticación basada en certificados
Realice los siguientes pasos antes de habilitar la autenticación basada en certificados.
Abra la consola de WorkSpaces en https://console.aws.amazon.com/workspaces/v2/home
. -
En el panel de navegación, elija Directories (Directorios).
-
Seleccione el ID de los directorios de WorkSpaces.
-
En Autenticación, haga clic en Editar.
-
Haga clic en Editar la autenticación basada en certificados.
-
Elija Habilitar la autenticación basada en certificados.
-
Confirme que su ARN de CA privada esté asociado a la lista. La CA privada debe estar en la misma cuenta AWS y Región de AWS debe estar etiquetada con una clave denominada euc-private-ca para que aparezca en la lista.
-
Haga clic en Save Changes (Guardar cambios). Ya está habilitada la autenticación basada en certificados.
-
Reinicie los paquetes de escritorio de WorkSpaces para Windows con DCV para que los cambios tengan efecto. Para obtener más información, consulte Reinicio de un espacio de trabajo.
-
Tras el reinicio, cuando los usuarios se autentiquen mediante SAML 2.0 mediante un cliente compatible, ya no se les solicitará la contraseña del dominio.
nota
Cuando la autenticación basada en certificados está habilitada para iniciar sesión en WorkSpaces, no se solicita a los usuarios la autenticación multifactor (MFA) aunque esté habilitada en el Directorio. Al usar la autenticación basada en certificados, la MFA se puede habilitar a través de su proveedor de identidad SAML 2.0. Para obtener más información sobre la autenticación multifactor de AWS Directory Service, Autenticación multifactor (Conector AD) o Habilitación de la autenticación multifactor para Conector ADAWS Managed Microsoft AD.
Administración de la autenticación basada en certificados
Certificado de entidad de certificación
En una configuración típica, el certificado de CA privada tiene un período de validez de 10 años. Consulte Administración del ciclo de vida de entidad de certificación privada para obtener más información sobre cómo reemplazar una CA privada con un certificado vencido o cómo volver a emitir la CA privada con un nuevo período de validez.
Certificados de usuario final
Los certificados de usuario final emitidos por AWS Private CA para la autenticación basada en certificados de WorkSpaces no requieren renovación ni revocación. Estos certificados son de corta duración. WorkSpaces emite automáticamente un nuevo certificado cada 24 horas. Estos certificados de usuario final tienen un período de validez más corto que una distribución de CRL de CA privada de AWS Private CA típica. Como resultado, no es necesario revocar los certificados de usuario final y no aparecerán en una CRL.
Informes de auditoría
Puede crear un informe de auditoría para mostrar todos los certificados que la CA privada ha emitido o revocado. Para obtener más información, consulte Using audit reports with your private CA.
Registro y supervisión
Se puede utilizar AWS CloudTrail para grabar las llamadas a la API AWS Private CA realizadas por WorkSpaces. Para obtener más información acerca del uso de CloudTrail, consulte Uso de CloudTrail. En el historial de eventos de CloudTrail, puede ver los nombres de evento GetCertificate y IssueCertificate eventos desde la fuente de acm-pca.amazonaws.com eventos creada por el nombre de usuario de EcmAssumeRoleSession WorkSpaces. Estos eventos se registrarán para cada solicitud de autenticación basada en certificados de EUC.
Habilitación del uso compartido entre cuentas de una CA privada
Al utilizar el uso compartido entre cuentas de una CA privada, puede conceder permisos a otras cuentas para usar una CA centralizada, lo que elimina la necesidad de una CA privada en todas las cuentas. La CA puede generar y emitir certificados mediante AWS Resource Access Manager
Cómo utilizar un recurso compartido de una CA privada con la CBA de WorkSpaces
Configure la CA privada para la CBA en una cuenta centralizada de AWS. Para obtener más información, consulte Autenticación basada en certificados y WorkSpaces Personal.
Para compartir la CA privada con las cuentas de recursos de AWS en las que los recursos de WorkSpaces utilizan la CBA, siga los pasos que se indican en How to use AWS RAM to share your ACM Private CA cross-account
. No es necesario completar el paso 3 para crear un certificado. Puede compartir la CA privada con cuentas individuales de AWS o compartirla a través de AWS Organizations. Para compartir con cuentas individuales, debe aceptar la CA privada compartida en la cuenta de recursos mediante la consola de Resource Access Manager (RAM) o las API. Al configurar el recurso compartido, confirme que el recurso compartido de RAM de la CA privada de la cuenta de recursos utilice la plantilla de permisos administrada por AWSRAMBlankEndEntityCertificateAPICSRPassthroughIssuanceCertificateAuthority. Esta plantilla se alinea con la plantilla de PCA que utiliza el rol de servicio de WorkSpaces al emitir certificados de CBA.Una vez que el recurso se haya compartido correctamente, podrá ver la CA privada compartida mediante la consola de Private CA en la cuenta de recursos.
Utilice la API o la CLI para asociar el ARN de la CA privada con la CBA en las propiedades del directorio de WorkSpaces. En este momento, la consola de WorkSpaces no admite la selección de ARN de CA privadas compartidas. Ejemplo de comandos de la CLI:
aws workspaces modify-certificate-based-auth-properties —resource-id <value> —certificate-based-auth-properties Status=<value>,CertificateAuthorityArn=<value>
