Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Autenticación basada en certificados
Puede usar la autenticación basada en certificados con WorkSpaces las flotas de aplicaciones unidas a Microsoft Active Directory. Esto elimina la solicitud al usuario de la contraseña del dominio de Active Directory cuando el usuario inicia sesión. 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 una autoridad de certificación AWS privada (CA AWS privada) en su. Cuenta de AWS Con la CA AWS privada, puede crear jerarquías de autoridades de certificación (CA) privadas, incluidas las de raíz y subordinada. CAs 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 [Qué es](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html). AWS Private CA
Cuando utiliza una CA AWS privada para la autenticación basada en certificados, WorkSpaces Applications solicita los certificados de sus usuarios automáticamente al reservar la sesión para cada instancia de la flota de WorkSpaces aplicaciones. Autentica a los usuarios en Active Directory con una tarjeta inteligente virtual proporcionada con los certificados.
La autenticación basada en certificados (CBA) se admite en WorkSpaces las flotas unidas a un dominio de Applications (flotas de sesión única o multisesión) que ejecutan instancias de Windows. Para habilitar la CBA en flotas con varias sesiones, debe usar una imagen de aplicaciones que utilice un agente de WorkSpaces aplicaciones publicado el 2 de julio de 2025 o después de esa fecha. WorkSpaces O bien, su imagen debe utilizar las actualizaciones de imagen de WorkSpaces las aplicaciones gestionadas publicadas el 2 de noviembre de 2025 o después de esa fecha.
**Topics**
+ [Requisitos previos](certificate-based-authentication-prereq.md)
+ [Habilitación de la autenticación basada en certificados](certificate-based-authentication-enable.md)
+ [Administración de la autenticación basada en certificados](certificate-based-authentication-manage.md)
+ [Habilitación del uso compartido entre cuentas de una CA privada](pca-sharing.md)
# Requisitos previos
Realice los siguientes pasos antes de utilizar la autenticación basada en certificados.
1. Configure una flota asociada a un dominio y configure SAML 2.0. Asegúrese de utilizar el formato `username@domain.com``userPrincipalName` para el `NameID` de SAML\$1Subject. Para obtener más información, consulte [Paso 5: creación de aserciones para la respuesta de autenticación de SAML](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions).
**nota**
No habilite el **Inicio de sesión con tarjeta inteligente para Active Directory** en su pila si desea utilizar la autenticación basada en certificados. Para obtener más información, consulte [Tarjetas inteligentes](feature-support-USB-devices-qualified.md#feature-support-USB-devices-qualified-smart-cards).
1. Utilice el agente de WorkSpaces aplicaciones con la versión 10-13-2022 o posterior con la imagen. Para obtener más información, consulte [Conserve la imagen de sus WorkSpaces aplicaciones de Amazon Up-to-Date](keep-image-updated.md).
1. Configurar el atributo `ObjectSid` en su declaración de SAML. Puede usar este atributo para realizar una asignación sólida con el usuario de Active Directory. La autenticación basada en certificados produce un error si el atributo `ObjectSid` no coincide con el identificador de seguridad (SID) de Active Directory del usuario especificado en el `NameID`de SAML\$1Subject. Para obtener más información, consulte [Paso 5: creación de aserciones para la respuesta de autenticación de SAML](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions). El `ObjectSid` es obligatorio para la autenticación basada en certificados a partir del 10 de septiembre de 2025. Para obtener más información, consulte [KB5014754: Cambios en la autenticación basada en certificados en los controladores de dominio de Windows](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16).
1. Agregue el permiso `sts:TagSession` a la política de confianza de roles de IAM que utiliza con su configuración de SAML 2.0. Para obtener más información, consulte [Transferencia de etiquetas de sesión en AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html.html). Este permiso es necesario para usar la autenticación basada en certificados. Para obtener más información, consulte [Paso 2: creación de un rol de IAM de federación de SAML 2.0](external-identity-providers-setting-up-saml.md#external-identity-providers-grantperms).
1. Cree una entidad de certificación (CA) AWS privada mediante una CA privada, si no tiene ninguna configurada con Active Directory. AWS Se requiere una CA privada para usar la autenticación basada en certificados. Para obtener más información, consulte [Planning your AWS Private CA deployment](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html). La siguiente configuración de CA AWS privada es común en muchos 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**: elija una CA subordinada para integrarla con una jerarquía de CA existente.
+ **Opciones de algoritmos de clave**: RSA 2048
+ **Opciones de nombre distintivo por asunto**: utilice las opciones más adecuadas para identificar esta 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 desde la instancia de WorkSpaces Applications Fleet y desde el controlador de dominio. Esto requiere acceso no autenticado al bucket de Amazon S3 configurado para entradas de CRL de CA AWS privadas o a una CloudFront distribución con acceso al bucket de Amazon S3 si bloquea el acceso público. Para obtener más información sobre estas opciones, consulte [Planning a certificate revocation list (CRL)](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html).
1. Etiquete su CA privada con una clave que permita designar la CA `euc-private-ca` para su uso con la autenticación basada en certificados de WorkSpaces aplicaciones. Esta clave no requiere ningún valor. Para obtener más información, consulte [Managing tags for your private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCaTagging.html). Para obtener más información sobre las políticas AWS administradas que se utilizan con WorkSpaces las aplicaciones para conceder permisos a los recursos de su empresa Cuenta de AWS, consulte. [AWS Se requieren políticas administradas para acceder a los recursos de WorkSpaces las aplicaciones](managed-policies-required-to-access-appstream-resources.md)
1. La autenticación basada en certificados utiliza tarjetas inteligentes virtuales para iniciar sesión. Para obtener más información, consulte [Guidelines for enabling smart card logon with third-party certification authorities](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities). Siga estos pasos:
1. 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 Servicios de certificados de Active Directory configurada en su Active Directory, inscribirá automáticamente los controladores de dominio con certificados que permiten el inicio de sesión con tarjeta inteligente. Si no dispone de los servicios de certificados de Active Directory, consulte [Requisitos para los certificados de controlador de dominio de una entidad emisora de certificados de terceros](https://learn.microsoft.com/en-US/troubleshoot/windows-server/windows-security/requirements-domain-controller). AWS recomienda a las autoridades certificadoras empresariales de Active Directory que administren automáticamente la inscripción de los certificados de controladores de dominio.
**nota**
Si utiliza Microsoft AD AWS administrado, puede configurar los servicios de certificación en una instancia de Amazon EC2 que cumpla los requisitos de los certificados de controlador de dominio. Consulte [Implementación de Active Directory en una nueva Amazon Virtual Private Cloud](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-ad-deploying-new-vpc.html) para ver, por ejemplo, las implementaciones de Microsoft AD AWS gestionado configuradas con Active Directory Certificate Services.
Con los servicios de certificados AWS gestionados de Microsoft AD y Active Directory, también debe crear reglas de salida desde el grupo de seguridad de VPC del controlador hasta la instancia de Amazon EC2 que ejecuta Certificate Services. El grupo de seguridad debe tener acceso al puerto 135 de TCP y a los puertos 49152 a 65535 para habilitar la inscripción automática de certificados. La instancia de Amazon EC2 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 Microsoft AD AWS administrado, consulte [Configurar las subredes y grupos de seguridad de la VPC](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_setup_trust_prepare_mad.html#tutorial_setup_trust_open_vpc).
1. En la consola de CA AWS privada, o con el SDK o la CLI, exporte el certificado de CA privada. Para obtener más información, consulte [Exportación de un certificado privado](https://docs.aws.amazon.com/acm/latest/userguide/export-private.html).
1. Publique la CA privada 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 cualquiera `\` y ejecute los siguientes comandos como administrador de dominio. También puede usar la política de grupo y la herramienta Microsoft PKI Health Tool (PKIView) para publicar la CA. Para obtener más información, consulte [Configuration instructions](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities#configuration-instructions).
```
certutil -dspublish -f \ RootCA
```
```
certutil -dspublish -f \ NTAuthCA
```
Asegúrese de que los comandos se completen correctamente y, a continuación, elimine el archivo de certificado de CA privada. 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 la flota de WorkSpaces aplicaciones.
**nota**
Active Directory debe distribuir la CA a las autoridades de certificación raíz de confianza y Enterprise NTAuth almacena automáticamente las instancias de la flota de WorkSpaces aplicaciones cuando se unen al dominio.
En los sistemas operativos Windows, la distribución de la CA (autoridad de certificación) se realiza automáticamente. Sin embargo, para Rocky Linux y Red Hat Enterprise Linux, debe descargar los certificados de CA raíz de la CA utilizada por WorkSpaces Applications Directory Config. Si sus certificados de CA raíz de KDC son diferentes, también debe descargarlos. Antes de utilizar la autenticación basada en certificados, es necesario importar estos certificados a una imagen o instantánea.
En la imagen, debe haber un archivo llamado /`etc/sssd/pki/sssd_auth_ca_db.pem`. Debe parecerse a lo siguiente:
```
-----BEGIN CERTIFICATE-----
Base64-encoded certificate chain from ACM Private CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded certificate body from ACM private CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded root CA KDC certificate chain
-----END CERTIFICATE-----
```
**nota**
Al copiar una imagen entre regiones o cuentas, o al volver a asociar una imagen a un nuevo Active Directory, será necesario volver a configurar este archivo con los certificados correspondientes en un generador de imágenes y volver a capturarlo antes de usarlo.
A continuación se indican las instrucciones para descargar los certificados de CA raíz:
1. En el generador de imágenes, cree un archivo con el nombre `/etc/sssd/pki/sssd_auth_ca_db.pem`.
1. Abra la [consola de AWS Private CA](https://console.aws.amazon.com/acm-pca/).
1. Elija el certificado privado que se utiliza con la configuración del directorio de WorkSpaces aplicaciones.
1. Seleccione la pestaña **Certificados de CA**.
1. Copie la cadena de certificados y el cuerpo del certificado a `/etc/sssd/pki/sssd_auth_ca_db.pem` en el generador de imágenes.
Si los certificados de CA raíz que utiliza KDCs son diferentes del certificado de CA raíz que utiliza su WorkSpaces Applications Directory Config, siga estos pasos de ejemplo para descargarlos:
1. Conéctese a una instancia de Windows unida al mismo dominio que su generador de imágenes.
1. Abra `certlm.msc`.
1. En el panel izquierdo, seleccione **Entidades de certificación raíz de confianza** y, a continuación, seleccione **Certificados**.
1. Para cada certificado de CA raíz, abra el menú contextual (clic con el botón secundario).
1. Seleccione **Todas las tareas**, seleccione **Exportar** para abrir el asistente de exportación de certificados y, a continuación, seleccione **Siguiente**.
1. Elija **X.509 codificado en base64 (.CER)** y seleccione **Siguiente**.
1. Seleccione **Examinar**, introduzca un nombre de archivo y seleccione **Siguiente**.
1. Seleccione **Finalizar**.
1. Abra el certificado exportado en un editor de texto.
1. Copie el contenido del archivo a `/etc/sssd/pki/sssd_auth_ca_db.pem` en el generador de imágenes.
# Habilitación de la autenticación basada en certificados
Realice los siguientes pasos antes de habilitar la autenticación basada en certificados.
**Para habilitar la autenticación basada en certificados**
1. Abra la consola de WorkSpaces aplicaciones en [https://console.aws.amazon.com/appstream2.](https://console.aws.amazon.com/appstream2)
1. En el panel de navegación, elija **Config de directorios**. Seleccione la configuración de directorio que desee configurar y elija **Editar**.
1. Elija **Habilitar la autenticación basada en certificados.**
1. Confirme que su ARN de CA privada esté asociado a la lista. Para que aparezca en la lista, debe almacenar la CA privada en el mismo espacio. Cuenta de AWS Región de AWS También debe etiquetar la CA privada con una clave denominada `euc-private-ca`.
1. Configure el registro del directorio como alternativa. La opción de alternativa permite a los usuarios iniciar sesión con la contraseña de dominio de AD si la autenticación basada en certificados no se realiza correctamente. Esto solo se recomienda en los casos en que los usuarios conozcan las contraseñas de sus dominios. Cuando la opción de alternativa está desactivada, una sesión puede desconectar al usuario si se produce una pantalla de bloqueo o si se cierra sesión en Windows. Si la opción de alternativa está activada, la sesión solicita al usuario su contraseña de dominio de AD.
1. Elija **Save changes (Guardar cambios)**.
1. Ya está habilitada la autenticación basada en certificados. Cuando los usuarios se autentiquen con SAML 2.0 en una pila de WorkSpaces aplicaciones mediante la flota unida a un dominio desde el cliente web de WorkSpaces Applications o el cliente para Windows (versión 1.1.1099 y posteriores), dejarán de recibir la solicitud de la contraseña del dominio. Los usuarios verán un mensaje que indica que se está realizando la conexión con autenticación basada en certificados al conectarse a una sesión habilitada para la autenticación basada en certificados.
# Administración de la autenticación basada en certificados
Tras habilitar la autenticación basada en certificados, revise las siguientes tareas.
**Topics**
+ [Certificado de CA privada](certificate-based-authentication-manage-CA.md)
+ [Certificados de usuario final](certificate-based-authentication-manage-certs.md)
+ [Informes de auditoría](certificate-based-authentication-manage-audit.md)
+ [Registro y supervisión](certificate-based-authentication-manage-logging.md)
# Certificado de CA privada
En una configuración típica, el certificado de CA privada tiene un período de validez de 10 años. 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, consulte [Managing the private CA lifecycle](https://docs.aws.amazon.com/privateca/latest/userguide/ca-lifecycle.html).
# Certificados de usuario final
Los certificados de usuario final emitidos por AWS Private CA for WorkSpaces Applications para la autenticación basada en certificados no requieren renovación ni revocación. Estos certificados son de corta duración. WorkSpaces Las aplicaciones emiten automáticamente un nuevo certificado para cada nueva sesión o cada 24 horas para las sesiones de larga duración. La sesión de WorkSpaces aplicaciones regula el uso de estos certificados de usuario final. Si finaliza una sesión, WorkSpaces las aplicaciones dejan de usar ese certificado. Estos certificados de usuario final tienen un período de validez más corto que una distribución CRL de CA AWS privada 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](https://docs.aws.amazon.com/privateca/latest/userguide/PcaAuditReport.html).
# Registro y supervisión
Puede utilizarlos CloudTrail para grabar las llamadas a la API a una CA privada por parte de WorkSpaces las aplicaciones. Para obtener más información, consulte [¿Qué es AWS CloudTrail?](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) y [uso CloudTrail](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html). En el historial de CloudTrail eventos, puede ver los nombres de **GetCertificate**los **IssueCertificate**eventos de la fuente de eventos **acm-pca.amazonaws.com** creados con el nombre de usuario de la aplicación. WorkSpaces **EcmAssumeRoleSession** Estos eventos se registrarán para cada solicitud de autenticación basada en un certificado de la aplicación. WorkSpaces Para obtener más información, consulte [Visualización de eventos con el historial de CloudTrail eventos](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
# Habilitación del uso compartido entre cuentas de una CA privada
El uso compartido entre cuentas de una CA privada (PCA) ofrece la posibilidad de conceder permisos para que otras cuentas usen una CA centralizada. La CA puede generar y emitir certificados mediante [AWS Resource Access Manager](https://aws.amazon.com/ram/) (RAM) para administrar los permisos. Esto elimina la necesidad de una CA privada en cada cuenta. El uso compartido entre cuentas privadas de CA se puede utilizar con la autenticación basada en certificados (CBA) de WorkSpaces las aplicaciones dentro de la misma. Región de AWS
Para utilizar un recurso de CA privada compartido con la CBA de WorkSpaces aplicaciones, siga estos pasos:
1. Configure la CA privada para la CBA de forma centralizada. Cuenta de AWS Para obtener más información, consulte [Autenticación basada en certificados](certificate-based-authentication.md).
1. Comparta la CA privada con el recurso Cuentas de AWS donde los recursos de WorkSpaces las aplicaciones utilizan la CBA. Para ello, siga los pasos que se indican en [Cómo usar la RAM de AWS para compartir su cuenta cruzada de CA privada de AWS](https://aws.amazon.com/blogs/security/how-to-use-aws-ram-to-share-your-acm-private-ca-cross-account/). No necesita completar el paso 3 para crear un certificado. Puede compartir la CA privada con una persona Cuentas de AWS o compartirla a través AWS Organizations de ella. Si compartes con cuentas individuales, debes aceptar la CA privada compartida en tu cuenta de recursos mediante la AWS Resource Access Manager consola o APIs.
Al configurar el recurso compartido, confirme que el AWS Resource Access Manager recurso compartido de la CA privada de la cuenta de recursos utiliza la plantilla de permisos `AWSRAMBlankEndEntityCertificateAPICSRPassthroughIssuanceCertificateAuthority` gestionados. Esta plantilla se alinea con la plantilla de PCA que utiliza el rol de servicio de WorkSpaces aplicaciones al emitir los certificados CBA.
1. 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.
1. Utilice la API o la CLI para asociar el ARN de CA privado con el CBA en la configuración del WorkSpaces directorio de aplicaciones. En este momento, la consola de WorkSpaces aplicaciones no admite la selección de una CA privada compartida. ARNs A continuación se muestran ejemplos de comandos de la CLI.
`aws appstream update-directory-config --directory-name --certificate-based-auth-properties Status=,CertificateAuthorityArn=`