

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á.

# Usando o Active Directory com WorkSpaces aplicativos
<a name="active-directory"></a>

Você pode unir suas frotas e criadores de imagens do Amazon WorkSpaces Applications Always-On e On-Demand Windows a domínios no Microsoft Active Directory e usar seus domínios existentes do Active Directory, baseados na nuvem ou no local, para iniciar instâncias de streaming associadas ao domínio. Você também pode usar AWS Directory Service for Microsoft Active Directory, também conhecido como Microsoft AD AWS gerenciado, para criar um domínio do Active Directory e usá-lo para oferecer suporte aos recursos de seus WorkSpaces aplicativos. Para obter mais informações sobre como usar o AWS Managed Microsoft AD, consulte [Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) no *Guia de administração do AWS Directory Service *.

**nota**  
No momento, frotas, criadores de imagens, frotas elásticas e construtores de blocos de aplicações do Amazon Linux 2 não são compatíveis com a associação de domínios.

Ao unir WorkSpaces aplicativos ao seu domínio do Active Directory, você pode:
+ Permitir que os usuários e os aplicativos acessem os recursos do Active Directory, como impressoras e compartilhamentos de arquivos, em sessões de streaming.
+ Use as configurações da Group Policy (Política de grupo) disponíveis no Console de Gerenciamento de Diretiva de Grupo (GPMC) para definir a experiência do usuário final.
+ Transmitir aplicativos que requerem autenticação dos usuários usando suas credenciais de login do Active Directory.
+ Aplique suas políticas corporativas de conformidade e segurança às suas instâncias de streaming de WorkSpaces aplicativos.

**Topics**
+ [Visão geral dos domínios do Active Directory](active-directory-overview.md)
+ [Antes de começar a usar o Active Directory com os WorkSpaces aplicativos da Amazon](active-directory-prerequisites.md)
+ [Tutorial: Configuração do Active Directory](active-directory-directory-setup.md)
+ [Autenticação baseada em certificado](certificate-based-authentication.md)
+ [WorkSpaces Aplicativos: Administração do Active Directory](active-directory-admin.md)
+ [Mais informações](active-directory-more-info.md)

# Visão geral dos domínios do Active Directory
<a name="active-directory-overview"></a>

Usar domínios do Active Directory com WorkSpaces aplicativos requer uma compreensão de como eles funcionam juntos e das tarefas de configuração que você precisará concluir. Será necessário concluir as seguintes tarefas:

1. Definir as configurações da Política de grupo conforme necessário para definir a experiência do usuário final e os requisitos de segurança dos aplicativos.

1. Crie a pilha de aplicativos associados ao domínio em Aplicativos. WorkSpaces 

1. Crie o aplicativo WorkSpaces Applications no provedor de identidade SAML 2.0 e atribua-o aos usuários finais diretamente ou por meio de grupos do Active Directory.

Para que seus usuários sejam autenticados em um domínio, várias etapas devem ocorrer quando esses usuários iniciam uma sessão de streaming de WorkSpaces aplicativos. O diagrama a seguir ilustra o fluxo de autenticação end-to-end do usuário a partir da solicitação inicial do navegador por meio da autenticação SAML e do Active Directory.

![\[Authentication flow diagram showing steps from user login to AWSWorkSpaces Applications session start.\]](http://docs.aws.amazon.com/pt_br/appstream2/latest/developerguide/images/domain-join-UPDATED.png)


**Fluxo de autenticação do usuário**

1. O usuário navega até `https://applications.exampleco.com`. A página de logon solicita a autenticação do usuário.

1. O serviço de federação solicita autenticação do armazenamento de identidades da organização.

1. O armazenamento de identidades autentica o usuário e retorna a resposta de autenticação ao serviço de federação.

1. Quando uma autenticação é bem-sucedida, o serviço de federação publica a declaração SAML no navegador do usuário.

1. O navegador do usuário publica a declaração SAML no endpoint SAML de AWS login (). `https://signin.aws.amazon.com/saml` AWS O login recebe a solicitação SAML, processa a solicitação, autentica o usuário e encaminha o token de autenticação para o serviço de aplicativos. WorkSpaces 

1. Usando o token de autenticação do AWS, o WorkSpaces Applications autoriza o usuário e apresenta os aplicativos ao navegador.

1. O usuário escolhe um aplicativo e, dependendo do método de autenticação de login do Windows habilitado na pilha de WorkSpaces aplicativos, ele é solicitado a inserir sua senha de domínio do Active Directory ou escolher um cartão inteligente. Se os dois métodos de autenticação estiverem habilitados, o usuário poderá escolher entre inserir a senha do domínio ou usar o cartão inteligente. A autenticação baseada em certificado também pode ser usada para autenticar usuários, removendo o prompt.

1. O controlador de domínio é contatado para a autenticação do usuário.

1. Após a autenticação no domínio, a sessão do usuário é iniciada com a conectividade do domínio.

Da perspectiva do usuário, esse processo é transparente. O usuário começa navegando até o portal interno da sua organização e é redirecionado para um portal de WorkSpaces aplicativos de aplicativos, sem precisar inserir AWS credenciais. Só é necessário usar uma senha de domínio do Active Directory ou credenciais de cartão inteligente.

Para que um usuário possa iniciar esse processo, você deve configurar o Active Directory com os direitos e as configurações da Política de grupo necessários e criar uma pilha de aplicativos ingressados no domínio.

# Antes de começar a usar o Active Directory com os WorkSpaces aplicativos da Amazon
<a name="active-directory-prerequisites"></a>

Antes de usar os domínios do Microsoft Active Directory com WorkSpaces aplicativos, esteja ciente dos seguintes requisitos e considerações.

**Topics**
+ [Ambiente de domínio do Active Directory](active-directory-prerequisites-domain-environment.md)
+ [Instâncias de streaming de aplicativos unidos ao domínio WorkSpaces](active-directory-prerequisites-streaming-instances.md)
+ [Configurações da política de grupo](active-directory-prerequisites-group-policy-settings.md)
+ [Autenticação por cartão inteligente](active-directory-prerequisites-smart-card-authentication.md)

# Ambiente de domínio do Active Directory
<a name="active-directory-prerequisites-domain-environment"></a>

O ambiente de domínio do Active Directory deve atender aos requisitos a seguir.
+ Você precisa ter um domínio do Microsoft Active Directory no qual associar suas instâncias de streaming. Se você não tiver um domínio do Active Directory ou quiser usar seu ambiente local do Active Directory, consulte os [Serviços de Domínio do Active Directory no Guia de Implantação da Solução de AWS Parceiros](https://aws-solutions-library-samples.github.io/cfn-ps-microsoft-activedirectory/).
+ Você deve ter uma conta de serviço de domínio com permissões para criar e gerenciar objetos de computador no domínio que você pretende usar com os WorkSpaces Aplicativos. Para obter mais informações, consulte [Como criar uma conta de domínio no Active Directory](https://msdn.microsoft.com/en-us/library/aa545262(v=cs.70).aspx) na documentação da Microsoft.

  Ao associar esse domínio do Active Directory aos WorkSpaces Aplicativos, forneça o nome e a senha da conta de serviço. WorkSpaces Os aplicativos usam essa conta para criar e gerenciar objetos de computador no diretório. Para obter mais informações, consulte [Conceder permissões para criar e gerenciar objetos de computador do Active Directory](active-directory-permissions.md).
+ Ao registrar seu domínio do Active Directory com WorkSpaces Aplicativos, você deve fornecer um nome distinto de unidade organizacional (OU). Crie uma UO para essa finalidade. O contêiner Computers padrão não é uma UO e não pode ser usado por WorkSpaces aplicativos. Para obter mais informações, consulte [Localizar o nome distinto da unidade organizacional](active-directory-oudn.md).
+ Os diretórios que você planeja usar com os WorkSpaces aplicativos devem estar acessíveis por meio de seus nomes de domínio totalmente qualificados (FQDNs) por meio da nuvem privada virtual (VPC) na qual suas instâncias de streaming são iniciadas. Para obter mais informações, consulte [Requisitos da porta do Active Directory e do Active Directory Domain Services](https://technet.microsoft.com/en-us/library/dd772723.aspx) na documentação da Microsoft.
+ O acesso ao controlador de domínio também pode ser suportado IPv6 e exigir [atualizações do conjunto de opções DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html).

# Instâncias de streaming de aplicativos unidos ao domínio WorkSpaces
<a name="active-directory-prerequisites-streaming-instances"></a>

A federação de usuários baseada no SAML 2.0 é necessária para streaming de aplicações em frotas sempre ativas e sob demanda associadas a um domínio. Você não pode iniciar sessões em instâncias associadas ao domínio usando o [CreateStreamingURL](https://docs.aws.amazon.com/appstream2/latest/APIReference/API_CreateStreamingURL.html) ou o grupo de usuários de WorkSpaces aplicativos.

Você deve usar uma imagem compatível com a associação de construtores de imagens e frotas a um domínio do Active Directory. Todas as imagens públicas publicadas em 24 de julho de 2017 ou depois oferecem suporte ao ingresso em um domínio do Active Directory. Para obter mais informações, consulte [WorkSpaces Notas de versão do Applications Base Image e Managed Image Update](base-image-version-history.md) e [Tutorial: Configuração do Active Directory](active-directory-directory-setup.md).

**nota**  
Você pode unir instâncias de streaming de frota sempre ativas e sob demanda a um domínio do Active Directory. Os sistemas operacionais compatíveis incluem Windows, Red Hat Enterprise Linux e Rocky Linux.

# Configurações da política de grupo
<a name="active-directory-prerequisites-group-policy-settings"></a>

Verifique sua configuração para as configurações de política de grupo a seguir. Se necessário, atualize as configurações conforme descrito nesta seção para que elas não bloqueiem os WorkSpaces aplicativos de autenticar e fazer login nos usuários do seu domínio. Caso contrário, quando seus usuários tentarem fazer login nos WorkSpaces Aplicativos, o login poderá não ser bem-sucedido. Em vez disso, uma mensagem é exibida, notificando os usuários de que "An unknown error occurred" (Ocorreu um erro desconhecido).
+ **Computer Configuration > Administrative Templates > Windows Components > Windows Logon Options > Disable or Enable software Secure Attention Sequence**: defina como **Enabled** em **Services**.
+ **Computer Configuration (Configuração do Computador) > Administrative Templates (Modelos Administrativos) > System (Sistema) > Logon > Exclude credential providers (Excluir provedores de credenciais)**: verifique se o seguinte CLSID *não* está listado: `e7c1bab5-4b49-4e64-a966-8d99686f8c7c` e `f148bAed-5f7f-40c9-8D48-51e24e571825`
+ **Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Interactive Logon > Interactive Logon: Message text for users attempting to log on**: defina como **Not defined**.
+ **Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Interactive Logon > Interactive Logon: Message title for users attempting to log on**: defina como **Not defined**.
+ **Configuração do computador > Políticas > Configurações do Windows > Configurações de segurança > Políticas locais > Atribuição de direitos de usuário > Permitir login localmente** — defina **como Não definido** ou adicione o domínio user/group a essa lista.
+ **Computer Configuration (Configuração do computador) > Policies (Políticas) > Windows Settings (Configurações do Windows) > Security Settings (Configurações de segurança) > Local Policies (Políticas locais) > User Rights Assignment (Atribuição de direitos de usuário) > Deny log on locally (Negar login localmente)**: defina como **Not defined (Não definido)** ou verifique se os usuários/grupos do domínio não estão incluídos na lista.

Se estiver usando frotas multissessão, também precisará seguir as configurações da Política de grupos além das configurações especificadas acima.
+ **Configuração do computador > Políticas > Configurações do Windows > Configurações de segurança > Políticas locais > Atribuição de direitos de usuário > Permitir login por meio de serviços de área de trabalho remota** — defina **como Não definido** ou adicione o domínio user/group a essa lista.
+ **Configuração do computador > Políticas > Configurações do Windows > Configurações de segurança > Políticas locais > Atribuição de direitos de usuário > Negar login por meio de Serviços de Área de Trabalho Remota** — Defina isso **como Não definido** ou certifique-se de que o domínio não users/groups esteja incluído na lista.

# Autenticação por cartão inteligente
<a name="active-directory-prerequisites-smart-card-authentication"></a>

WorkSpaces Os aplicativos oferecem suporte ao uso de senhas de domínio do Active Directory ou cartões inteligentes, como cartões inteligentes [Common Access Card (CAC)](https://www.cac.mil/Common-Access-Card) e [Personal Identity Verification (PIV)](https://piv.idmanagement.gov/) para login do Windows em instâncias de streaming de WorkSpaces aplicativos. Para obter informações sobre como configurar seu ambiente do Active Directory para habilitar o login por cartão inteligente usando autoridades de certificação de terceiros (CAs), consulte [Diretrizes para habilitar o login por cartão inteligente com autoridades de certificação de terceiros](https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities) na documentação da Microsoft.

**nota**  
WorkSpaces Os aplicativos também oferecem suporte ao uso de cartões inteligentes para autenticação na sessão depois que um usuário faz login em uma instância de streaming. Esse recurso é suportado somente para usuários que têm o cliente de WorkSpaces aplicativos para Windows versão 1.1.257 ou posterior instalado. Para obter informações sobre requisitos adicionais, consulte [Cartões inteligentes](feature-support-USB-devices-qualified.md#feature-support-USB-devices-qualified-smart-cards).

# Tutorial: Configuração do Active Directory
<a name="active-directory-directory-setup"></a>

Para usar o Active Directory com WorkSpaces aplicativos, você deve primeiro registrar sua configuração de diretório criando um objeto de Configuração de diretório em WorkSpaces Aplicativos. Esse objeto inclui as informações necessárias para ingressar instâncias de streaming em um domínio do Active Directory. Você cria um objeto Directory Config usando o console de gerenciamento de WorkSpaces aplicativos, o AWS SDK ou. AWS CLI Depois, você pode usar a configuração do diretório para iniciar frotas e construtores de imagens sempre ativos e sob demanda associados a um domínio. 

**nota**  
Só é possível associar instâncias de streaming de frotas sempre ativas e sob demanda a um domínio do Active Directory.

**Topics**
+ [Etapa 1: Criar um objeto de configuração do diretório](#active-directory-setup-config)
+ [Etapa 2: Criar uma imagem usando um construtor de imagens ingressado no domínio](#active-directory-setup-image-builder)
+ [Etapa 3: Criar uma frota ingressada no domínio](#active-directory-setup-fleet)
+ [Etapa 4: Configurar o SAML 2.0](#active-directory-setup-saml)

## Etapa 1: Criar um objeto de configuração do diretório
<a name="active-directory-setup-config"></a>

O objeto Directory Config que você cria em WorkSpaces Applications será usado em etapas posteriores.

Se você estiver usando o AWS SDK, poderá usar a [CreateDirectoryConfig](https://docs.aws.amazon.com/appstream2/latest/APIReference/API_CreateDirectoryConfig.html)operação. Se você estiver usando o AWS CLI, você pode usar o [create-directory-config](https://docs.aws.amazon.com/cli/latest/reference/appstream/create-directory-config.html)comando.

**Para criar um objeto Directory Config usando o WorkSpaces console de aplicativos**

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, selecione **Directory Configs** (Configurações de diretório), **Create Directory Config** (Criar configuração de diretório).

1. Em **Directory Name** (Nome do diretório), informe o nome do domínio totalmente qualificado (FQDN) do domínio do Active Directory (por exemplo, `corp.example.com`). Cada região pode ter apenas um valor de **Directory Config** com um nome de diretório específico.

1. Em **Service Account Name** (Nome da conta de serviço), digite o nome de uma conta que pode criar objetos de computador e que tenha permissões para ingressar no domínio. Para obter mais informações, consulte [Conceder permissões para criar e gerenciar objetos de computador do Active Directory](active-directory-permissions.md). O nome da conta deve estar no formato `DOMAIN\username`.

1. Em **Password** (Senha) e **Confirm Password** (Confirmar senha), digite a senha do diretório da conta especificada.

1. Em **Organizational Unit (OU)**, digite o nome distinto de pelo menos uma UO para objetos de computador da instância de streaming. 
**nota**  
O nome da OU não pode conter espaços. Se você especificar um nome de OU que contenha espaços, quando um construtor de frotas ou imagens tentar se juntar novamente ao domínio do Active Directory, os WorkSpaces aplicativos não poderão alternar os objetos do computador corretamente e a reassociação ao domínio não será bem-sucedida. Para obter informações sobre como solucionar esse problema, consulte o tópico *DOMAIN\$1JOIN\$1INTERNAL\$1SERVICE\$1ERROR* para a mensagem “The account already exists” em [Ingresso no Domínio do Active Directory](troubleshooting-notification-codes.md#troubleshooting-notification-codes-ad).  
Além disso, o contêiner Computers padrão não é uma UO e não pode ser usado por WorkSpaces aplicativos. Para obter mais informações, consulte [Localizar o nome distinto da unidade organizacional](active-directory-oudn.md).

1. Para adicionar mais de uma UO, selecione o sinal de mais (**\$1**) ao lado de **Organizational Unit (OU)**. Para remover OUs, escolha o ícone **x.**

1. Escolha **Próximo**.

1. Revise as informações de configuração e selecione **Create**.

## Etapa 2: Criar uma imagem usando um construtor de imagens ingressado no domínio
<a name="active-directory-setup-image-builder"></a>

Em seguida, usando o construtor de imagens de WorkSpaces aplicativos, crie uma nova imagem com recursos de associação de domínio do Active Directory. Observe que a frota e a imagem podem ser membros de domínios diferentes. Você ingressa o construtor de imagens em um domínio para habilitar o ingresso no domínio e para instalar aplicativos. O ingresso de frota no domínio é abordado na próxima seção.

**Para criar uma imagem para a inicialização de frotas ingressadas em um domínio**

1. Siga os procedimentos em [Tutorial: Crie uma imagem de WorkSpaces aplicativos personalizada usando o console de WorkSpaces aplicativos](tutorial-image-builder.md).

1. Para a etapa de seleção da imagem base, use uma imagem AWS base lançada em ou após 24 de julho de 2017. Para obter uma lista atual das AWS imagens lançadas, consulte[WorkSpaces Notas de versão do Applications Base Image e Managed Image Update](base-image-version-history.md).

1. Na **Step 3: Configure Network**, selecione uma VPC e as sub-redes que tenham conectividade de rede com seu ambiente do Active Directory. Selecione os security groups configurados para permitir acesso ao diretório por meio das sub-redes da VPC.

1. Além disso, na **Etapa 3: Configurar rede**, expanda a seção **Domínio do Active Directory (Opcional)** e selecione os valores para o **Nome do Diretório** e a **UO do Diretório** aos quais o criador da imagem será vinculado.

1. Reveja as informações da configuração do construtor de imagens e selecione **Create**.

1. Aguarde até que o novo construtor de imagens atinja o estado **Running** e selecione **Connect**.

1. Faça login no construtor de imagens em modo de administrador ou como um usuário do diretório com permissões de administrador local. Para obter mais informações, consulte [Concessão de direitos de administrador local em construtores de imagens](active-directory-image-builder-local-admin.md).

1. Conclua as etapas em [Tutorial: Crie uma imagem de WorkSpaces aplicativos personalizada usando o console de WorkSpaces aplicativos](tutorial-image-builder.md) para instalar os aplicativos e criar uma nova imagem.

## Etapa 3: Criar uma frota ingressada no domínio
<a name="active-directory-setup-fleet"></a>

Usando a imagem privada criada na etapa anterior, crie uma frota sempre ativa ou sob demanda associada a um domínio do Active Directory para aplicações de streaming. O domínio pode ser diferente do usado pelo construtor de imagens para criar a imagem.

**Como criar uma frota sempre ativa ou sob demanda associada a um domínio**

1. Siga os procedimentos em [Crie uma frota nos WorkSpaces aplicativos da Amazon](set-up-stacks-fleets-create.md).

1. Na etapa de seleção de imagem, use a imagem criada na etapa anterior [Etapa 2: Criar uma imagem usando um construtor de imagens ingressado no domínio](#active-directory-setup-image-builder).

1. Na **Step 4: Configure Network**, selecione uma VPC e as sub-redes que tenham conectividade de rede com seu ambiente do Active Directory. Selecione os security groups configurados para permitir comunicação com seu domínio.

1. Também na **Step 4: Configure Network (Etapa 4: Configurar rede)**, expanda a seção **Active Directory Domain (Optional) (Domínio do Active Directory (opcional))** e selecione os valores para **Directory Name (Nome do diretório)** e **Directory OU (UO do diretório)** nos quais a frota deve ingressar.

1. Reveja a configuração da frota e selecione **Create**.

1. Conclua as etapas restantes em [Crie uma frota e uma pilha de WorkSpaces aplicativos da Amazon](set-up-stacks-fleets.md) para que sua frota seja associada a uma pilha e esteja em execução.

## Etapa 4: Configurar o SAML 2.0
<a name="active-directory-setup-saml"></a>

Seus usuários devem usar o ambiente de federação de identidades baseada no SAML 2.0 para iniciar sessões de streaming na frota ingressada no domínio.

**Para configurar o SAML 2.0 para acesso de logon único**

1. Siga os procedimentos em [Configuração do SAML](external-identity-providers-setting-up-saml.md).

1. WorkSpaces Os aplicativos exigem que o `NameID` valor SAML\$1Subject para o usuário que está fazendo login seja fornecido em um dos seguintes formatos:
   + `domain\username`usando o AMAccount nome s
   + `username@domain.com`usando o userPrincipalName

   Se você estiver usando o formato s AMAccount Name, poderá especificá-lo `domain` usando o nome NetBIOS ou o nome de domínio totalmente qualificado (FQDN).

1. Forneça acesso aos usuários ou grupos do Active Directory para permitir o acesso à pilha de WorkSpaces aplicativos a partir do portal de aplicativos do provedor de identidade.

1. Conclua as etapas restantes em [Configuração do SAML](external-identity-providers-setting-up-saml.md).

**Para fazer login de um usuário com o SAML 2.0**

1. Faça login no catálogo de aplicativos do seu provedor de SAML 2.0 e abra o aplicativo SAML de WorkSpaces aplicativos que você criou no procedimento anterior.

1. Quando o catálogo de WorkSpaces aplicativos de aplicativos for exibido, selecione um aplicativo para iniciar.

1. Quando um ícone de carregamento for exibido, você será solicitado a fornecer uma senha. O nome do usuário do domínio fornecido pelo provedor de identidade do SAML 2.0 aparece acima do campo de senha. Digite a senha e selecione **log in** (fazer login).

A instância de streaming executa o procedimento de login do Windows e o aplicativo selecionado é aberto.

# Autenticação baseada em certificado
<a name="certificate-based-authentication"></a>

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
<a name="certificate-based-authentication-prereq"></a>

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 `<path>\<file>` 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 <path>\<file> RootCA
      ```

      ```
      certutil -dspublish -f <path>\<file> 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
<a name="certificate-based-authentication-enable"></a>

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
<a name="certificate-based-authentication-manage"></a>

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
<a name="certificate-based-authentication-manage-CA"></a>

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
<a name="certificate-based-authentication-manage-certs"></a>

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
<a name="certificate-based-authentication-manage-audit"></a>

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
<a name="certificate-based-authentication-manage-logging"></a>

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
<a name="pca-sharing"></a>

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 <value> --certificate-based-auth-properties Status=<value>,CertificateAuthorityArn=<value>` 

# WorkSpaces Aplicativos: Administração do Active Directory
<a name="active-directory-admin"></a>

Configurar e usar o Active Directory com WorkSpaces aplicativos envolve as seguintes tarefas administrativas.

**Topics**
+ [Conceder permissões para criar e gerenciar objetos de computador do Active Directory](active-directory-permissions.md)
+ [Localizar o nome distinto da unidade organizacional](active-directory-oudn.md)
+ [Concessão de direitos de administrador local em construtores de imagens](active-directory-image-builder-local-admin.md)
+ [Atualizar a conta de serviço usada para ingresso no domínio](active-directory-service-acct.md)
+ [Bloquear a sessão de streaming quando o usuário está ocioso](active-directory-session-lock.md)
+ [Editar a configuração do diretório](active-directory-config-edit.md)
+ [Excluir uma configuração de diretório](active-directory-config-delete.md)
+ [Configurando WorkSpaces aplicativos para usar relações de confiança de domínio](active-directory-domain-trusts.md)
+ [Gerenciando WorkSpaces aplicativos e objetos de computador no Active Directory](active-directory-identify-objects.md)

# Conceder permissões para criar e gerenciar objetos de computador do Active Directory
<a name="active-directory-permissions"></a>

Para permitir que WorkSpaces os aplicativos executem operações de objetos de computador do Active Directory, você precisa de uma conta com permissões suficientes. Como uma melhor prática, use uma conta que tenha apenas os privilégios mínimos necessários. As permissões mínimas da unidade organizacional (UO) do Active Directory são as seguintes:
+ Criar objetos de computador
+ Alterar senha
+ Redefinir senha
+ Gravar descrição

Antes de configurar as permissões, é necessário fazer o seguinte:
+ Obter acesso a um computador ou a uma instância do EC2 ingressada no domínio.
+ Instale o usuário do Active Directory e o snap-in do MMC de Computadores. Para obter mais informações, consulte [Instalar ou remover ferramentas de administração de servidores remotos para Windows 7](https://technet.microsoft.com/en-us/library/ee449483.aspx) na documentação da Microsoft.
+ Faça login como um usuário do domínio com as permissões apropriadas para modificar as configurações de segurança da UO.
+ Crie ou identifique o usuário, a conta de serviço ou o grupo ao qual delegar permissões.

**Para configurar permissões mínimas**

1. Abra **Active Directory Users and Computers** (Usuários e computadores do Active Directory) em seu domínio ou no controlador de domínio.

1. No painel de navegação à esquerda, selecione a primeira UO para a qual fornecer privilégios de ingresso no domínio, abra o menu de contexto (clique com o botão direito do mouse) e selecione **Delegate Control** (Delegar controle).

1. Na página **Delegation of Control Wizard**, selecione **Next**, **Add**.

1. Em **Select Users, Computers, or Groups**, selecione o usuário, a conta do serviço ou o grupo pré-criado e escolha **OK**.

1. Na página **Tasks to Delegate** (Tarefas para delegar), selecione **Create a custom task to delegate** (Criar uma tarefa personalizada para delegar) e, em seguida, selecione **Next** (Avançar).

1. Selecione **Only the following objects in the folder**, **Computer objects**.

1. Selecione **Create selected objects in this folder**, **Next**.

1. Em **Permissions**, selecione **Read**, **Write**, **Change Password**, **Reset Password**, **Next**.

1. Na página **Completing the Delegation of Control Wizard**, verifique as informações e selecione **Finish**.

1. Repita as etapas de 2 a 9 para qualquer outra OUs que exija essas permissões.

Se você delegou permissões a um grupo, crie um usuário ou conta de serviço com uma senha forte e adicione essa conta ao grupo. Esta conta, portanto, deverá ter privilégios suficientes para conectar o streaming de instâncias ao diretório. Use essa conta ao criar sua configuração de diretório de WorkSpaces aplicativos.

# Localizar o nome distinto da unidade organizacional
<a name="active-directory-oudn"></a>

Ao registrar seu domínio do Active Directory com WorkSpaces Aplicativos, você deve fornecer um nome distinto de unidade organizacional (OU). Crie uma UO para essa finalidade. O contêiner Computers padrão não é uma UO e não pode ser usado por WorkSpaces aplicativos. O procedimento a seguir mostra como obter esse nome.

**nota**  
O nome distinto deve começar com **OU=** ou não poderá ser usado para objetos de computador.

Para concluir esse procedimento, primeiro, é necessário fazer o seguinte:
+ Obter acesso a um computador ou a uma instância do EC2 ingressada no domínio.
+ Instale o usuário do Active Directory e o snap-in do MMC de Computadores. Para obter mais informações, consulte [Instalar ou remover ferramentas de administração de servidores remotos para Windows 7](https://technet.microsoft.com/en-us/library/ee449483.aspx) na documentação da Microsoft.
+ Faça login como um usuário do domínio com as permissões apropriadas para ler as propriedades de segurança da UO.

**Para localizar o nome distinto de uma UO**

1. Abra **Active Directory Users and Computers** (Usuários e computadores do Active Directory) em seu domínio ou no controlador de domínio.

1. Em **View**, verifique se a opção **Advanced Features** está habilitada.

1. **No painel de navegação esquerdo, selecione a primeira UO a ser usada para objetos de computador da instância de streaming de WorkSpaces aplicativos, abra o menu de contexto (clique com o botão direito do mouse) e escolha Propriedades.**

1. Selecione **Atribuir Editor**.

1. Em **Attributes**, em **distinguishedName**, selecione **View**.

1. Em **Value** (Valor), selecione o nome distinto, abra o menu de contexto e selecione **Copy** (Copiar).

# Concessão de direitos de administrador local em construtores de imagens
<a name="active-directory-image-builder-local-admin"></a>

Por padrão, os usuários do domínio do Active Directory não têm direitos de administrador local nas instâncias de construtor de imagens. É possível conceder esses direitos usando as preferências da Política de grupo no diretório ou, manualmente, usando a conta do administrador local em um construtor de imagens. Conceder direitos de administrador local a um usuário do domínio permite que esse usuário instale aplicativos e crie imagens em um construtor de imagens de WorkSpaces aplicativos.

**Topics**
+ [Uso de preferências da Política de grupo](group-policy.md)
+ [Uso do grupo de administradores locais no construtor de imagens](manual-procedure.md)

# Uso de preferências da Política de grupo
<a name="group-policy"></a>

As preferências da Política de grupo podem ser usadas para conceder direitos de administrador local a usuários ou grupos do Active Directory e a todos os objetos de computador na UO especificada. Os usuários ou grupos do Active Directory aos quais você deseja conceder permissões de administrador local já devem existir. Para usar as preferências da Política do grupo, você precisa fazer o seguinte primeiro:
+ Obter acesso a um computador ou a uma instância do EC2 ingressada no domínio.
+ Instalar o snap-in do MMC do Console de Gerenciamento de Diretiva de Grupo (GPMC). Para obter mais informações, consulte [Instalar ou remover ferramentas de administração de servidores remotos para Windows 7](https://technet.microsoft.com/en-us/library/ee449483.aspx) na documentação da Microsoft.
+ Faça login como um usuário do domínio com permissões para criar objetos de Política de Grupo (GPOs). Link GPOs para o apropriado OUs.

**Para usar as preferências da Política de grupo para conceder permissões de administrador local**

1. Em seu diretório ou em um controlador de domínio, abra o prompt de comando como um administrador, digite `gpmc.msc` e pressione ENTER.

1. Na árvore do console à esquerda, selecione a UO onde criará um novo GPO ou use um GPO existente e, em seguida, execute uma das seguintes ações: 
   + Crie um novo GPO abrindo o menu de contexto (clique com o botão direito do mouse) e selecionando **Create a GPO in this domain, Link it here** (Criar um GPO neste domínio e vinculá-lo aqui). Em **Name**, forneça um nome descritivo para esse GPO.
   + Selecione um GPO existente.

1. Abra o menu de contexto do GPO e selecione **Edit** (Editar).

1. Na árvore do console, selecione **Computer Configuration** (Configuração do computador), **Preferences** (Preferências), **Windows Settings** (Configurações do Windows), **Control Panel Settings** (Configurações do Painel de controle) e **Local Users and Groups** (Usuários e grupos locais).

1. Selecione os **Local Users and Groups** (Usuários e grupos locais) marcados, abra o menu de contexto e selecione **New** (Novo), **Local group** (Grupo local).

1. Em **Action**, selecione **Update**.

1. Em **Group name**, selecione **Administrators (built-in)**.

1. Em **Members**, selecione **Add...** e especifique os usuários ou grupos do Active Directory aos quais atribuir direitos de administrador local na instância de streaming. Em **Action**, selecione **Add to this group** e selecione **OK**.

1. Para aplicar esse GPO a outro OUs, selecione a OU adicional, abra o menu de contexto e escolha **Vincular um GPO existente**.

1. Usando o nome do GPO novo ou existente especificado na etapa 2, role até encontrar o GPO e, em seguida, clique em **OK**. 

1. Repita as etapas 9 e 10 para obter outras OUs que devem ter essa preferência.

1. Clique em **OK** para fechar a caixa de diálogo **New Local Group Properties** (Propriedades do novo grupo local).

1. Clique em **OK** novamente para fechar o GPMC.

Para aplicar a nova preferência ao GPO, interrompa e reinicie todos os construtores de imagens ou frotas em execução. Os usuários e grupos do Active Directory especificados na etapa 8 recebem automaticamente os direitos de administrador local nas frotas e nos construtores de imagens na UO à qual o GPO está vinculado.

# Uso do grupo de administradores locais no construtor de imagens
<a name="manual-procedure"></a>

Para conceder direitos de administrador local aos usuários ou grupos do Active Directory no construtor de imagens, você pode adicionar esses usuários ou grupos ao grupo de administradores locais no construtor de imagens. Os construtores de imagem criados a partir de imagens com esses direitos mantêm os mesmos direitos. 

Os usuários ou grupos do Active Directory aos quais conceder direitos de administrador local já devem existir.

**Para adicionar usuários ou grupos do Active Directory ao grupo administradores locais no construtor de imagens**

1. Abra o console de WorkSpaces aplicativos em [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2).

1. Conecte-se ao construtor de imagens em modo de administrador. O criador de imagens deve estar em execução e associado a um domínio. Para obter mais informações, consulte [Tutorial: Configuração do Active Directory](active-directory-directory-setup.md).

1. Selecione **Start** (Iniciar), **Administrative Tools** (Ferramentas administrativas) e, em seguida, clique duas vezes em **Computer Management** (Gerenciamento de computador).

1. No painel de navegação à esquerda, selecione **Local Users and Groups** e abra a pasta **Groups**.

1. Abra o grupo **Administrators** e selecione **Add...**.

1. Selecione todos os usuários ou grupos do Active Directory aos quais atribuir direitos de administrador local e selecione **OK**. Clique em **OK** novamente para fechar a caixa de diálogo **Administrator Properties** (Propriedades de administrador).

1. Feche o Computer Management (Gerenciamento de computador).

1. Para fazer login como um usuário do Active Directory e testar se esse usuário tem direitos de administrador local no construtor de imagens, selecione **Admin Commands** (Comandos de administrador), **Switch user** (Alternar usuário) e, em seguida, insira as credenciais do usuário relevante.

# Atualizar a conta de serviço usada para ingresso no domínio
<a name="active-directory-service-acct"></a>

Para atualizar a conta de serviço que o WorkSpaces Applications usa para ingressar no domínio, recomendamos o uso de duas contas de serviço separadas para unir construtores de imagens e frotas ao seu domínio do Active Directory. O uso de duas contas de serviço separadas garante que não ocorra nenhuma interrupção no serviço quando uma conta de serviço precisar ser atualizada (por exemplo, quando uma senha expirar). 

**Para atualizar uma conta de serviço**

1. Crie um grupo do Active Directory e delegue as permissões corretas ao grupo.

1. Adicione suas contas de serviço ao novo grupo do Active Directory.

1. Quando necessário, edite seu objeto do WorkSpaces Applications Directory Config inserindo as credenciais de login da nova conta de serviço.

Depois de configurar o grupo do Active Directory com a nova conta de serviço, todas as novas operações da instância de streaming usarão a nova conta de serviço enquanto as operações em andamento da instância de streaming continuam a usar a conta antiga sem interrupção. 

O tempo de sobreposição da conta de serviço enquanto as operações de instância de streaming são concluídas é bastante curto, não mais que um dia. O tempo de sobreposição é necessário porque você não deve excluir ou alterar a senha da conta de serviço antiga durante o período de sobreposição, do contrário, as operações existentes podem falhar.

# Bloquear a sessão de streaming quando o usuário está ocioso
<a name="active-directory-session-lock"></a>

WorkSpaces Os aplicativos dependem de uma configuração que você define no GPMC para bloquear a sessão de streaming depois que o usuário estiver ocioso por um determinado período de tempo. Para usar o GPMC, primeiro, você precisa fazer o seguinte:
+ Obter acesso a um computador ou a uma instância do EC2 ingressada no domínio.
+ Instalar o GPMC. Para obter mais informações, consulte [Instalar ou remover ferramentas de administração de servidores remotos para Windows 7](https://technet.microsoft.com/en-us/library/ee449483.aspx) na documentação da Microsoft.
+ Faça login como usuário do domínio com permissões para criar GPOs. Link GPOs para o apropriado OUs.

**Para bloquear automaticamente a instância de streaming quando o usuário está ocioso**

1. Em seu diretório ou em um controlador de domínio, abra o prompt de comando como um administrador, digite `gpmc.msc` e pressione ENTER.

1. Na árvore do console à esquerda, selecione a UO onde criará um novo GPO ou use um GPO existente e, em seguida, execute uma das seguintes ações: 
   + Crie um novo GPO abrindo o menu de contexto (clique com o botão direito do mouse) e selecionando **Create a GPO in this domain, Link it here** (Criar um GPO neste domínio e vinculá-lo aqui). Em **Name**, forneça um nome descritivo para esse GPO.
   + Selecione um GPO existente.

1. Abra o menu de contexto do GPO e selecione **Edit** (Editar). 

1. Em **User Configuration** (Configuração do usuário), expanda **Policies** (Políticas), **Administrative Templates** (Modelos administrativos), **Control Panel** (Painel de controle) e, em seguida, selecione **Personalization** (Personalização). 

1. Clique duas vezes em **Enable screen saver** (Habilitar proteção de tela).

1. Na configuração **Enable screen saver** (Habilitar proteção de tela) da política, escolha **Enabled** (Ativado).

1. Escolha **Apply** e, em seguida, escolha **OK**.

1. Clique duas vezes em **Force specific screen saver** (Forçar proteção de tela específica). 

1. Na configuração **Force specific screen saver** (Forçar proteção de tela específica) da política, escolha **Enabled** (Ativado).

1. Em **Screen saver executable name (Nome do arquivo executável da proteção de tela)**, digite **scrnsave.scr**. Quando essa configuração é habilitada, o sistema exibirá uma proteção de tela preta na área de trabalho do usuário.

1. Escolha **Apply** e, em seguida, escolha **OK**.

1. Clique duas vezes em **Password protect the screen saver** (Proteger a proteção de tela com senha).

1. Na configuração **Password protect the screen saver** (Proteger a proteção de tela com senha) da política, escolha **Enabled** (Ativado).

1. Escolha **Apply** e, em seguida, escolha **OK**.

1. Clique duas vezes em **Screen saver timeout** (Tempo limite da proteção de tela).

1. Na configuração **Screen saver timeout** (Tempo limite da proteção de tela) da política, escolha **Enabled** (Ativado).

1. Em **Seconds** (Segundos), especifique o período em que os usuários devem estar ociosos para que a proteção de tela seja aplicada. Para definir o tempo de inatividade como 10 minutos, especifique 600 segundos.

1. Escolha **Apply** e, em seguida, escolha **OK**.

1. Na árvore do console, em **User Configuration** (Configuração do usuário), expanda **Policies** (Políticas), **Administrative Templates** (Modelos administrativos), **System** (Sistema) e, em seguida, clique em **Ctrl\$1Alt\$1Del Options** (Opções de Ctrl\$1Alt\$1Del). 

1. Clique duas vezes em **Remove Lock Computer** (Remover bloquear computador).

1. Na configuração de **Remove Lock Computer** (Remover bloquear computador) da política, selecione **Disabled** (Desabilitado).

1. Escolha **Apply** e, em seguida, escolha **OK**.

# Editar a configuração do diretório
<a name="active-directory-config-edit"></a>

Depois que uma configuração do diretório de WorkSpaces aplicativos for criada, você poderá editá-la para adicionar, remover ou modificar unidades organizacionais, atualizar o nome de usuário da conta de serviço ou atualizar a senha da conta de serviço. 

**Para criar uma configuração de diretório**

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 à esquerda, selecione **Directory Configs** e selecione a configuração do diretório a ser editada.

1. Selecione **Ações**, **Editar**.

1. Atualize os campos a serem alterados. Para adicionar mais OUs, selecione o sinal de adição (**\$1**) ao lado do campo OU mais alto. Para remover um campo de UO, selecione **x** ao lado do campo.
**nota**  
É necessária pelo menos uma OU. OUs que estão atualmente em uso não podem ser removidos.

1. Para salvar as alterações, selecione **Update Directory Config**.

1. As informações da guia **Details** agora devem estar atualizadas para refletir as alterações.

As alterações nas credenciais de login da conta de serviço não afetam as operações da instância de streaming em andamento. As novas operações da instância de streaming usam as credenciais atualizadas. Para obter mais informações, consulte [Atualizar a conta de serviço usada para ingresso no domínio](active-directory-service-acct.md).

# Excluir uma configuração de diretório
<a name="active-directory-config-delete"></a>

Você pode excluir uma configuração de diretório de WorkSpaces aplicativos que não seja mais necessária. As configurações do diretório associadas a todos os criadores de imagens ou frotas não podem ser excluídas.

**Para excluir uma configuração de diretório**

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 à esquerda, selecione **Directory Configs** e selecione a configuração do diretório a ser excluída.

1. Selecione **Ações**, **Excluir**.

1. Verifique o nome na mensagem pop-up e selecione **Delete**.

1. Selecione **Update Directory Config**.

# Configurando WorkSpaces aplicativos para usar relações de confiança de domínio
<a name="active-directory-domain-trusts"></a>

WorkSpaces Os aplicativos oferecem suporte a ambientes de domínio do Active Directory em que recursos de rede, como servidores de arquivos, aplicativos e objetos de computador, residem em um domínio e os objetos de usuário residem em outro. A conta de serviço de domínio usada para operações de objetos de computador não precisa estar no mesmo domínio dos objetos de computador dos WorkSpaces Aplicativos. 

Ao criar a configuração do diretório, especifique uma conta de serviço que tenha as permissões adequadas para gerenciar objetos de computador no domínio do Active Directory onde residem os servidores de arquivos, aplicativos, objetos de computador e outros recursos de rede.

Suas contas de usuário final do Active Directory devem ter as permissões “Allowed to Authenticate” (Permissão para Autenticar) referentes ao seguinte:
+ WorkSpaces Aplicativos: objetos de computador
+ Controladores de domínio do domínio

Para obter mais informações, consulte [Conceder permissões para criar e gerenciar objetos de computador do Active Directory](active-directory-permissions.md).

# Gerenciando WorkSpaces aplicativos e objetos de computador no Active Directory
<a name="active-directory-identify-objects"></a>

WorkSpaces Os aplicativos não excluem objetos de computador do Active Directory. Esses objetos de computador podem ser identificados facilmente em seu diretório. Cada objeto de computador no diretório é criado com o atributo `Description` que especifica uma frota ou uma instância de construtor de imagens e o nome. 


**Exemplos de descrição de objeto de computador**  

| Tipo | Nome | Atributo da descrição | 
| --- | --- | --- | 
|  Frota  |  ExampleFleet  |  `WorkSpaces Applications - fleet:ExampleFleet`  | 
|  Construtor de imagens  |  ExampleImageBuilder  |  `WorkSpaces Applications - image-builder:ExampleImageBuilder`  | 

Você pode identificar e excluir objetos de computador inativos criados por WorkSpaces aplicativos usando os `dsrm` comandos `dsquery computer` a seguir. Para obter mais informações, consulte [Dsquery computer](https://technet.microsoft.com/en-us/library/cc730720.aspx) e [Dsrm](https://technet.microsoft.com/en-us/library/cc731865.aspx) na documentação da Microsoft.

O comando `dsquery` identifica objetos de computador inativos durante um determinado período e usa o seguinte formato. O `dsquery` comando também deve ser executado com o parâmetro `-desc "WorkSpaces Applications*"` para exibir somente objetos WorkSpaces Applications. 

```
dsquery computer "OU-distinguished-name" -desc "WorkSpaces Applications*" -inactive number-of-weeks-since-last-login
```
+ `OU-distinguished-name` é o nome distinto da unidade organizacional. Para obter mais informações, consulte [Localizar o nome distinto da unidade organizacional](active-directory-oudn.md). Se você não fornecer o *OU-distinguished-name* parâmetro, o comando pesquisará o diretório inteiro. 
+ `number-of-weeks-since-last-log-in` é o valor desejado com base em como você deseja definir inatividade. 

Por exemplo, o seguinte comando exibe todos os objetos de computador na unidade organizacional `OU=ExampleOU,DC=EXAMPLECO,DC=COM` que não fizeram login nas últimas duas semanas.

```
dsquery computer OU=ExampleOU,DC=EXAMPLECO,DC=COM -desc "WorkSpaces Applications*" -inactive 2
```

Se nenhuma correspondência for encontrada, o resultado será um ou mais nomes de objetos. O comando `dsrm` exclui o objeto especificado e usa o seguinte formato:

```
dsrm objectname
```

Em que `objectname` é o nome completo do objeto na saída do comando `dsquery`. Por exemplo, se o `dsquery` comando acima resultar em um objeto de computador chamado "ExampleComputer“, o `dsrm` comando para excluí-lo seria o seguinte:

```
dsrm "CN=ExampleComputer,OU=ExampleOU,DC=EXAMPLECO,DC=COM"
```

Você pode encadear esses comandos em conjunto usando o operador pipe (`|`). Por exemplo, para excluir todos os objetos de computador dos WorkSpaces Aplicativos, solicitando a confirmação de cada um, use o formato a seguir. Adicione o parâmetro `-noprompt` ao `dsrm` para desabilitar a confirmação.

```
dsquery computer OU-distinguished-name -desc "WorkSpaces Applications*" –inactive number-of-weeks-since-last-log-in | dsrm
```

# Mais informações
<a name="active-directory-more-info"></a>

Para obter mais informações relacionadas a este tópico, consulte os recursos a seguir:
+ [Códigos de notificação de solução de problemas](troubleshooting-notification-codes.md)-Resoluções para os erros de códigos de notificação.
+ [Solucionar problemas no Active Directory](troubleshooting-active-directory.md)-Ajuda em relação a dificuldades comuns.
+ [Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) — Informações sobre o uso Directory Service.