As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Autenticação baseada em certificado
Você pode usar a autenticação baseada em certificado com frotas de WorkSpaces aplicativos unidas ao Microsoft Active Directory. Isso remove o prompt de usuário para a senha do domínio do Active Directory quando um usuário faz login. Ao usar a autenticação baseada em certificado com um domínio do Active Directory, você pode:
+ Basear-se no seu provedor de identidades SAML 2.0 para autenticar o usuário e fornecer declarações SAML que correspondam ao usuário no Active Directory.
+ Criar uma experiência de autenticação única com menos prompts de usuário.
+ Habilitar fluxos de autenticação sem senha usando seu provedor de identidades SAML 2.0.
A autenticação baseada em certificado usa recursos de Autoridade de Certificação AWS Privada (CA AWS Privada) em seu. Conta da AWS Com a CA AWS privada, você pode criar hierarquias de autoridade de certificação (CA) privada, incluindo raiz e subordinada. CAs Também pode criar sua própria hierarquia de CAs e emitir certificados dela para autenticar usuários internos. Para obter mais informações, consulte [O que é CA Privada da AWS](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html).
Quando você usa a CA AWS privada para autenticação baseada em certificados, os WorkSpaces aplicativos solicitam certificados para seus usuários automaticamente na reserva de sessão para cada instância da frota de WorkSpaces aplicativos. Ele autentica os usuários no Active Directory com um cartão inteligente virtual provisionado com os certificados.
A autenticação baseada em certificado (CBA) é suportada em frotas associadas ao domínio de WorkSpaces aplicativos (frotas de sessão única e de várias sessões) que executam instâncias do Windows. Para habilitar o CBA em frotas com várias sessões, você deve usar uma imagem de WorkSpaces aplicativos que use um agente de aplicativos lançado em ou WorkSpaces após 02-07-2025. Ou sua imagem deve usar atualizações de imagem de WorkSpaces aplicativos gerenciados lançadas em ou após 02-11-2025.
**Topics**
+ [Pré-requisitos](certificate-based-authentication-prereq.md)
+ [Habilitar a autenticação baseada em certificado](certificate-based-authentication-enable.md)
+ [Gerenciar a autenticação baseada em certificado](certificate-based-authentication-manage.md)
+ [Permitir compartilhamento de PCA entre contas](pca-sharing.md)
# Pré-requisitos
Conclua as etapas a seguir antes de usar a autenticação baseada em certificado.
1. Configure uma frota associada a um domínio e configure o SAML 2.0. Use o formato `username@domain.com` `userPrincipalName` para o `NameID` de SAML\$1Subject. Para obter mais informações, consulte [Etapa 5: criar declarações para a resposta de autenticação de SAML](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions).
**nota**
Não habilite **Smart card sign in for Active Directory** em sua pilha se quiser usar a autenticação baseada em certificado. Para obter mais informações, consulte [Cartões inteligentes](feature-support-USB-devices-qualified.md#feature-support-USB-devices-qualified-smart-cards).
1. Use o agente de WorkSpaces aplicativos versão 10-13-2022 ou posterior com sua imagem. Para obter mais informações, consulte [Mantenha a imagem de seus WorkSpaces aplicativos da Amazon Up-to-Date](keep-image-updated.md).
1. Configure o atributo `ObjectSid` na declaração SAML. Você pode usar esse atributo para realizar um mapeamento robusto com o usuário do Active Directory. A autenticação baseada em certificado falhará se o atributo `ObjectSid` não corresponder ao identificador de segurança (SID) do Active Directory do usuário especificado no `NameID` de SAML\$1Subject. Para obter mais informações, consulte [Etapa 5: criar declarações para a resposta de autenticação de SAML](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions). O `ObjectSid` é obrigatório para autenticação baseada em certificado após 10 de setembro de 2025. Para obter mais informações, consulte [KB5014754: Alterações na autenticação baseada em certificado em controladores de domínio do Windows](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16).
1. Adicione a permissão `sts:TagSession` à política de confiança do perfil do IAM que você usa com sua configuração do SAML 2.0. Para obter mais informações, consulte [Passar tags de sessão no AWS AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html.html). Essa permissão é necessária para usar a autenticação baseada em certificado. Para obter mais informações, consulte [Etapa 2: Criar um perfil do IAM de federação SAML 2.0](external-identity-providers-setting-up-saml.md#external-identity-providers-grantperms).
1. Crie uma autoridade de certificação (CA) AWS privada usando CA privada, se você não tiver uma configurada com seu Active Directory. AWS A CA privada é necessária para usar a autenticação baseada em certificado. Para obter mais informações, consulte [Planejar a implantação do CA Privada da AWS](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html). As seguintes configurações de CA AWS privada são comuns para muitos casos de uso de autenticação baseada em certificado:
+ **Opções de tipos de CA**
+ **Modo de uso de CA de certificados de curta duração**: recomendado se a CA emitir apenas certificados de usuário final para autenticação baseada em certificado.
+ **Hierarquia de nível único com uma CA raiz**: escolha uma CA subordinada para integrá-la a uma hierarquia de CAs existente.
+ **Opções de algoritmos de chave**: RSA 2048
+ **Opções de nome distinto de assunto**: use as opções mais apropriadas para identificar essa CA em seu repositório de Autoridades de Certificação Raiz Confiáveis do Active Directory.
+ **Opções de revogação de certificado**: distribuição de CRL
**nota**
A autenticação baseada em certificado requer um ponto de distribuição de CRL on-line acessível tanto pela instância da frota de WorkSpaces aplicativos quanto pelo controlador de domínio. Isso requer acesso não autenticado ao bucket do Amazon S3 configurado AWS para entradas privadas do CA CRL ou CloudFront uma distribuição com acesso ao bucket do Amazon S3, caso bloqueie o acesso público. Para obter mais informações sobre essas opções, consulte [Planejar uma lista de revogação de certificados (CRL)](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html).
1. Marque sua CA privada com uma chave autorizada `euc-private-ca` a designar a CA para uso com a autenticação baseada em certificado de WorkSpaces aplicativos. Essa chave não requer um valor. Para obter mais informações, consulte [Gerenciamento de etiquetas para sua CA privada](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCaTagging.html). Para obter mais informações sobre as políticas AWS gerenciadas usadas com WorkSpaces aplicativos para conceder permissões aos recursos em seu Conta da AWS, consulte[AWS Políticas gerenciadas necessárias para acessar os recursos de WorkSpaces aplicativos](managed-policies-required-to-access-appstream-resources.md).
1. A autenticação baseada em certificado usa cartões inteligentes virtuais para fazer login. Para obter mais informações, consulte [Diretrizes para habilitar o logon de cartão inteligente com autoridades de certificação de terceiros](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities). Siga estas etapas:
1. Configure controladores de domínio com um certificado de controlador de domínio para autenticar usuários de cartões inteligentes. Se você tiver uma CA corporativa dos Serviços de Certificados do Active Directory configurada em seu Active Directory, ela inscreverá automaticamente os controladores de domínio com certificados que permitem o login por cartão inteligente. Se você não tiver os Serviços de Certificados do Active Directory, consulte [Requisitos para certificados de controlador de domínio de uma CA terceirizada](https://learn.microsoft.com/en-US/troubleshoot/windows-server/windows-security/requirements-domain-controller). AWS recomenda que as autoridades de certificação corporativa do Active Directory gerenciem automaticamente a inscrição de certificados de controlador de domínio.
**nota**
Se você usa o AWS Managed Microsoft AD, você pode configurar os Serviços de Certificados em uma instância do Amazon EC2 que atenda aos requisitos de certificados de controlador de domínio. Consulte [Implantar o Active Directory em uma nova Amazon Virtual Private Cloud](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-ad-deploying-new-vpc.html) para ver, por exemplo, implantações do Microsoft AD AWS gerenciado configuradas com os Serviços de Certificados do Active Directory.
Com o AWS Managed Microsoft AD e o Active Directory Certificate Services, você também deve criar regras de saída do grupo de segurança VPC do controlador para a instância do Amazon EC2 que executa os Serviços de Certificados. Você deve fornecer ao grupo de segurança acesso à porta TCP 135 e às portas 49152 a 65535 para habilitar o registro automático de certificados. A instância do Amazon EC2 também deve permitir acesso de entrada nessas mesmas portas das instâncias do domínio, incluindo controladores de domínio. Para obter mais informações sobre como localizar o grupo de segurança para o AWS Managed Microsoft AD, consulte [Configurar suas sub-redes VPC](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_setup_trust_prepare_mad.html#tutorial_setup_trust_open_vpc) e grupos de segurança.
1. No console da CA AWS privada, ou com o SDK ou a CLI, exporte o certificado da CA privada. Para obter mais informações, consulte [Exportação de um certificado privado](https://docs.aws.amazon.com/acm/latest/userguide/export-private.html).
1. Publique a CA privada no Active Directory. Faça login em um controlador de domínio ou em uma máquina associada a um domínio. Copie o certificado de CA privada para qualquer `\` e execute os comandos a seguir como administrador de domínio. Você também pode usar a Política de Grupo e a Microsoft PKI Health Tool (PKIView) para publicar a CA. Para obter mais informações, consulte [Instruções de configuração](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
```
Verifique se os comandos são concluídos com êxito, depois remova o arquivo do certificado de CA privada. Dependendo das configurações de replicação do Active Directory, pode levar vários minutos para que a CA publique em seus controladores de domínio e instâncias da frota de WorkSpaces aplicativos.
**nota**
O Active Directory deve distribuir automaticamente a CA às Autoridades de Certificação Raiz Confiáveis e às NTAuth lojas corporativas para instâncias da frota de WorkSpaces aplicativos quando elas ingressam no domínio.
Para sistemas operacionais Windows, a distribuição da CA (autoridade certificadora) acontece automaticamente. No entanto, para Rocky Linux e Red Hat Enterprise Linux, você deve baixar o (s) certificado (s) de CA raiz da CA usada pelo seu WorkSpaces Applications Directory Config. Se seus certificados de CA raiz do KDC forem diferentes, também será necessário baixá-los. Antes de usar a autenticação baseada em certificado, é necessário importar esses certificados em uma imagem ou instantâneo.
Na imagem, deve haver um arquivo chamado /`etc/sssd/pki/sssd_auth_ca_db.pem`. Ele deve ter a seguinte aparência:
```
-----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**
Ao copiar uma imagem entre regiões ou contas, ou ao reassociar uma imagem a um novo Active Directory, esse arquivo precisará ser reconfigurado com os certificados relevantes em um criador de imagens e capturado novamente antes do uso.
Abaixo estão as instruções para baixar os certificados de CA raiz:
1. No criador de imagens, crie um arquivo chamado `/etc/sssd/pki/sssd_auth_ca_db.pem`.
1. Abra o [console de CA privada da AWS](https://console.aws.amazon.com/acm-pca/).
1. Escolha o certificado privado usado com seu WorkSpaces Applications Directory Config.
1. Escolha a guia **Certificado de CA**.
1. Copie a cadeia de certificados e o corpo do certificado para `/etc/sssd/pki/sssd_auth_ca_db.pem` no criador de imagens.
Se os certificados de CA raiz usados pelo KDCs forem diferentes do certificado de CA raiz usado pelo Configuração do Diretório de WorkSpaces Aplicativos, siga estas etapas de exemplo para baixá-los:
1. Conecte-se a uma instância do Windows associada ao mesmo domínio do seu criador de imagens.
1. Abra o `certlm.msc`.
1. No painel esquerdo, escolha **Autoridades de certificação raiz confiáveis** e, em seguida, escolha **Certificados**.
1. Para cada certificado de CA raiz, abra o menu de contexto (clique com o botão direito do mouse).
1. Escolha **Todas as tarefas** e **Exportar** para abrir o assistente de exportação de certificados e, em seguida, **Avançar**.
1. Escolha **X.509 codificado em Base64 (CER)** e escolha **Avançar**.
1. Escolha **Procurar**, insira um nome de arquivo e escolha **Avançar**.
1. Escolha **Terminar**.
1. Abra o certificado exportado em um editor de textos.
1. Copie o conteúdo do arquivo para `/etc/sssd/pki/sssd_auth_ca_db.pem` no criador de imagens.
# Habilitar a autenticação baseada em certificado
Conclua as etapas a seguir para habilitar a autenticação baseada em certificado.
**Como habilitar a autenticação baseada em certificado**
1. Abra o console de WorkSpaces aplicativos em [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2).
1. No painel de navegação, escolha **Directory Configs**. Selecione a configuração do diretório que você deseja configurar e escolha **Edit**.
1. Selecione **Enable Certificate-Based Authentication**.
1. Confirme se o ARN da CA privada está associado na lista. Para aparecer na lista, você deve armazenar a CA privada no mesmo Conta da AWS Região da AWS e. Você também deve marcar a CA privada com uma chave chamada `euc-private-ca`.
1. Configure o fallback de login no diretório. O fallback permite que os usuários façam login usando sua senha do domínio do AD se a autenticação baseada em certificado não for bem-sucedida. Isso é recomendado somente nos casos em que os usuários conhecem sua senha do domínio. Quando o fallback estiver desativado, uma sessão poderá desconectar o usuário se ocorrer uma tela de bloqueio ou um desligamento do Windows. Se o fallback estiver ativado, a sessão solicitará ao usuário a senha do domínio do AD.
1. Escolha **Salvar alterações**.
1. A autenticação baseada em certificado está habilitada. Quando os usuários se autenticam com o SAML 2.0 em uma pilha de WorkSpaces aplicativos usando a frota associada ao domínio do cliente web de WorkSpaces aplicativos ou do cliente para Windows (versão 1.1.1099 e posterior), eles não receberão mais uma solicitação para a senha do domínio. Os usuários receberão uma mensagem “Connecting with certificate-based authentication...” ao se conectarem a uma sessão habilitada para autenticação baseada em certificado.
# Gerenciar a autenticação baseada em certificado
Depois de habilitar a autenticação baseada em certificado, revise as tarefas a seguir.
**Topics**
+ [Certificado de CA privada](certificate-based-authentication-manage-CA.md)
+ [Certificados de usuário final](certificate-based-authentication-manage-certs.md)
+ [Relatórios de auditoria](certificate-based-authentication-manage-audit.md)
+ [Registro em log e monitoramento](certificate-based-authentication-manage-logging.md)
# Certificado de CA privada
Em uma configuração típica, o certificado de CA privada tem um período de validade de 10 anos. Para obter mais informações sobre como substituir uma CA privada por um certificado expirado ou reemitir a CA privada com um novo período de validade, consulte [Gerenciar o ciclo de vida da CA privada](https://docs.aws.amazon.com/privateca/latest/userguide/ca-lifecycle.html).
# Certificados de usuário final
Os certificados de usuário final emitidos pela AWS Private CA for WorkSpaces Applications com autenticação baseada em certificados não exigem renovação ou revogação. Esses certificados são de curta duração. WorkSpaces Os aplicativos emitem automaticamente um novo certificado para cada nova sessão ou a cada 24 horas para sessões de longa duração. A sessão de WorkSpaces Aplicativos rege o uso desses certificados de usuário final. Se você encerrar uma sessão, os WorkSpaces aplicativos deixarão de usar esse certificado. Esses certificados de usuário final têm um período de validade mais curto do que uma distribuição típica de CRL de CA AWS privada. Como resultado, os certificados de usuário final não precisam ser revogados e não aparecerão em uma CRL.
# Relatórios de auditoria
Você pode criar um relatório de auditoria para listar todos os certificados que sua CA privada emitiu ou revogou. Para obter mais informações, consulte [Como usar relatórios de auditoria com sua CA privada](https://docs.aws.amazon.com/privateca/latest/userguide/PcaAuditReport.html).
# Registro em log e monitoramento
Você pode usar CloudTrail para gravar chamadas de API para uma CA privada por WorkSpaces aplicativos. Para obter mais informações, consulte [O que é AWS CloudTrail?](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) e [usando CloudTrail](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html). No Histórico de CloudTrail eventos, você pode visualizar **GetCertificate**os nomes dos **IssueCertificate**eventos da fonte de eventos **acm-pca.amazonaws.com** criados pelo nome de usuário dos aplicativos. WorkSpaces **EcmAssumeRoleSession** Esses eventos serão registrados para cada solicitação de autenticação baseada em certificado de WorkSpaces aplicativos. Para obter mais informações, consulte [Visualização de eventos com histórico de CloudTrail eventos](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
# Permitir compartilhamento de PCA entre contas
O compartilhamento entre contas de CA privada (PCA) oferece a capacidade de conceder permissões para que outras contas usem uma CA centralizada. A CA pode gerar e emitir certificados usando o [AWS Resource Access Manager](https://aws.amazon.com/ram/) (RAM) para gerenciar as permissões. Isso elimina a necessidade de uma CA privada em todas as contas. O compartilhamento entre contas de CA privada pode ser usado com a Autenticação Baseada em Certificado de WorkSpaces Aplicativos (CBA) dentro da mesma. Região da AWS
Para usar um recurso de CA privada compartilhado com o WorkSpaces Applications CBA, conclua as seguintes etapas:
1. Configure a CA privada para CBA de forma centralizada Conta da AWS. Para obter mais informações, consulte [Autenticação baseada em certificado](certificate-based-authentication.md).
1. Compartilhe a CA privada com o recurso Contas da AWS em que os recursos de WorkSpaces aplicativos utilizam o CBA. Para fazer isso, siga as etapas em [How to use AWS RAM to share your ACM Private CA cross-account](https://aws.amazon.com/blogs/security/how-to-use-aws-ram-to-share-your-acm-private-ca-cross-account/). Não é necessário realizar a etapa 3 para criar um certificado. Você pode compartilhar a CA privada com uma pessoa Contas da AWS ou compartilhar por meio dela AWS Organizations. Se você compartilha com contas individuais, precisa aceitar a CA privada compartilhada em sua conta de recurso usando o AWS Resource Access Manager console ou APIs.
Ao configurar o compartilhamento, confirme se o compartilhamento de AWS Resource Access Manager recursos da CA privada na conta do recurso está usando o modelo de permissão `AWSRAMBlankEndEntityCertificateAPICSRPassthroughIssuanceCertificateAuthority` gerenciada. Esse modelo se alinha ao modelo de PCA usado pela função de serviço de WorkSpaces Aplicativos ao emitir certificados CBA.
1. Depois que o compartilhamento for bem-sucedido, visualize a CA privada compartilhada usando o console da CA privada na conta do recurso.
1. Use a API ou a CLI para associar o ARN privado da CA ao CBA na configuração do diretório de aplicativos. WorkSpaces No momento, o console de WorkSpaces aplicativos não oferece suporte à seleção de CA privada compartilhada ARNs. Veja a seguir exemplos de comandos CLI:
`aws appstream update-directory-config --directory-name --certificate-based-auth-properties Status=,CertificateAuthorityArn=`