Estendendo sua infraestrutura de Active Directory na AWS com o Okta Identity Cloud

Por Lucas Henrique Garcia, Arquiteto de Soluções de SMB na AWS,
Diego Voltz, Arquiteto de Soluções de Enterprise na AWS,
Pavankumar Kasani, Arquiteto de Soluções na AWS e
Xiaozang Li, Arquiteto de Soluções na AWS

Você está pronto para estender seu ambiente On-Premises de Active Directory (A.D) para AWS e diminuir o trabalho pesado de gestão de infraestrutura de AD? Você gostaria de manter um ambiente de Active Directory com alta disponibilidade na AWS para utilização em conjunto com outras aplicações? Alguns de nossos clientes que utilizam a aplicação Okta Identity Cloud para aplicações internas e externas ( e que precisam dos objetos do Active Directory sincronizados com a aplicação para autenticação) podem fazer uso de uma arquitetura centralizada para acessos on-premises e para aplicações Cloud através da configuração de uma extensão do ambiente Active Directory On-Premises utilizando o serviço AWS Managed Microsoft Active Directory e uma configuração de relação de confiança (“Trust Relationship”).

Neste artigo, demonstraremos uma das arquiteturas que você poderá utilizar para sincronizar os objetos entre seu ambiente de Active Directory On-Premises e um domínio configurado no AWS Managed Microsoft Active Directory. Um dos principais componentes desta arquitetura é o agente do Active Directory da aplicação Okta Identiy Cloud que será utilizado para realizar a sincronização de grupos e usuários entre estes domínios. O agente Okta AD pode ser instalado e configurado em servidores On-Premises que sejam membros de um domínio ou em instâncias EC2 na AWS conforme detalhamos abaixo (Figura 01).

Figura 01: Fluxo de sincronização entre os domínios locais e na AWS e o Okta Identity Cloud.

 Antes de seguirmos, gostaríamos de detalhar um pouco mais os serviços envolvidos e suas principais características.

O AWS Directory Services permite que você crie um ambiente de Active Directory como um serviço gerenciado, sustentado por servidores Domain Controllers Windows Server 2012 R2. Quando você seleciona e cria este tipo de diretório, um ambiente com alta disponibilidade de Domain Controllers é criado utilizando a estrutura redundante de rede do Amazon Virtual Private Cloud (VPC) através da utilização de Zonas de Disponibilidade.

Já o Okta identity Cloud é uma solução Enterprise de gerenciamento de identidade que é compatível com diversas aplicações On-Premises e nativas da Nuvem. O Okta Agent AD é o componente que permite a integração do Okta Identity Cloud ao seu ambiente de Active Directory, garantindo assim que você utilize aplicações SaaS compatíveis com o Okta e garantindo assim uma simplificação e centralização do gerenciamento de usuários e de suas credenciais de acesso com demais aplicações.

Vale lembrar que instâncias basedas em AMIs Windows Server criadas pela AWS, tais como Instâncias On-demand, Spot, instâncias Reservadas ou mesmo instâncias que utilizem Saving Plans também já possuem embutido o custo da licença para utilização do Windows Server.

Conectividade de Rede entre seu Datacenter e as regiões da AWS

Antes de começarmos com as configurações necessárias para a criação de uma relação de confiança entre o ambiente AD On-Premises e o AWS Managed Microsoft Active Directory, é importante que você reveja e valide os pré-requisitos necessários para a criação de relações de confiança publicados em nossa documentação neste link. Por exemplo, nós enfaticamente recomendados que você tenha uma solução de VPN ou AWS Direct Connect configurada entre o seu VPC e seu ambiente On-Premises.

Para entender como criar uma conexão resiliente de VPN na AWS, verifique nosso Guia de Usuário para Site-to-Site VPN. O AWS Site-to-Site VPN é um serviço gerenciado que utiliza túneis IPsec para criar uma rede segura entre o seu Datacenter ou escritório e seus recursos publicados na AWS. Quando utilizamos conexões de VPN Site-to-Site podemos criar conexões com AWS VPCs e também com o AWS Transit Gateway. Dois túneis por conexão são criados para garantia de redundância. Para um melhor entendimento sobre as conexões dedicadas do AWS Direct Connect e suas configurações, verifique nosso guia publicado neste link.

Criando relações de confiança entre os domínios Active Directory On-Premises e AWS Managed AD

Uma relação de confiança é um link entre dois domínios diferentes (identificados como “Trusted Domain” e como “Trusting Domain”). Estas relações podem ser configuradas de diferentes maneiras a fim de permitir tipos de acessos específicos entre estes mesmos domínios. Por exemplo, um cenário configurado como “One-Way Trust” permite que as contas de usuários do domínio classificado como “Trusted Domain” acessem recursos do domínio “Trusting Domain”. Em um cenário de “Two-way Trust”, as contas de ambos os domínios podem acessar recursos publicados em cada um deles, garantindo uma conexão bidirecional.

Relações do tipo “Two-Way Trust” são as mais comuns quando configuramos extensões entre o ambiente On-Premises do Active Directory e o AWS Managed Microsoft Active Directory, permitindo que várias aplicações sejam integradas aos serviços de diretório garantindo assim os acessos em ambos os domínios utilizando um logon unificado via Single-Sign On (SSO). O AWS Managed Microsoft Active Directory suporta relações de confiança do tipo Externo e Floresta (External e Forest) com o seu ambiente On-Premises dos seguintes tipos (direções):

1. Unidirecional de Entrada – One-Way Incoming
2. Unidrecional de Saída – One-Way Outgoing
3. Bidirecional (Two-way Bidirectional)

Para criar uma relação de confiança, siga os passos abaixo:

1. Prepare o seu domínio On-Premises para a relação de confiança. Isso inclui realizar configurações de firewall, habilitar a pré-autenticação do protocolo Kerberos e configurar os Encaminhadores Condicionais de DNS (Conditional Forwarder).
2. Prepare o seu ambiente AWS Managed Microsoft AD para a relação de configuraça. Isto inclui configurar as subredes de seu VPC, Security Groups e habilitar a pré-autenticação do protocolo Kerberos.
3. Crie uma relação de confiança entre o seu domínio Active Directory On-Premises e o seu domímio AWS Managed Microsoft Active Directory (AD).

Instalando e Configurando o agente Okta para Active Directory

Primeiramente, baixe e instale o agente do Okta AD em uma instância EC2, que deverá ser configurada como membro do domínio configurado em seu ambiente AWS Managed Microsoft AD. Um Agente Okta pode ser associado à vários domínios. Uma vez que uma relação de confiança exista entre seu domínio local e seu domínio criado na AWS, você poderá associar estes domínios ao agente configurado na instância EC2, ao invés de criar múltiplos servidores com agentes diferentes apontando para domínios específicos.

Para uma alta-disponibilidade desta arquitetura, a configuração de um agente Okta configurado no seu ambiente On-Premises é recomendada. Isso irá diminuir o impacto caso haja uma indisponibilidade de rede entre o seu Datacenter local e a AWS. A Okta recomenda também que mais agentes sejam instalados em servidores para uma maior redundância e proteção em casos de falha. Para um melhor entendimento das opções de instalação e configuração do Agente Okta e sua integração com o Active Directory, recomendamos a leitura deste guia.

Validando Objetos do Active Directory

Uma vez que o agente do Okta esteja instalado e configurado na instância EC2, faça o Login na console de administração do Okta. Na guia “provisioning”, faça a importação dos usuários (full import) listados no seu diretório AWS Managed AD (consulte a Figura 02 e Figura 03). A sincronização dos outros objetos criados posteriormente poderá ser feita através da configuração de importações agendadas com um intervalo mínimo de uma hora. Após o processo de importação ter sido concluído, se você tiver alguma conta de usuário que entrou em conflito (overlap) entre o AWS Managed AD e o Okta, você poderá associar manualmente estes objetos. Além disso, você poderá configurar regras de associação para automaticamente mapear estes usuários caso deseje. Verifique os passos de como realizar essa configuração no guia “Import AD Users to Okta”.

Figura 02: Importando usuários do Active Directory no Okta Identity Cloud

Figura 03: Resultados do processo de importação dos objetos do Active Directory na console do Okta Identity Cloud.

Você pode importar grupos de qualquer floresta ou domínio conectado ao Okta. Isso acontece pois o o Agente Okta AD detecta automaticamente todos os grupos nos domínios ou OUs que você selecionou. Se você registrar o Agente Okta AD para mais de um domínio e você tiver a OU Raiz (root OU) selecionada para todos eles, todos os grupos serão importados. Verifique o guia “Import Ad Groups to Okta” para um melhor entendimento de como sincronizar estes grupos.

Sincronizando senhas com o Okta

Quando você faz o Login no Okta utilizando suas credenciais do Active Directory, o processo de autenticação é delegado para o domínio Active Directory. Isto quer dizer que o Okta não analisa e não armazena nenhuma credencial.

Em alguns casos, as credenciais precisam ser sincronizadas entre o Active Directory e o Okta para que sejam utilizadas por uma determinada aplicação. Se um usuário altera sua senha de domínio no Active Directory e tenta acessar aplicações em uma sessão Single-Sign On existente, por exemplo, eles encontrarão erros de senha incorreta. Isso acontece porque a nova senha ainda não foi sincronizada, e um novo processo de logon será necessário para validar o acesso. Para evitar experiências disruptivas como esta, você poderá utilizar o agente Okta AD Password Sync, que irá rastrear as mudanças realizadas e irá sincronizá-las com o Okta e suas demais aplicações integradas. Para maiores detalhes de como esse processo de sincronização funciona e o detalhamento de como todo o fluxo de reset de senha é acompanhado pelo Agente Okta Password Sync, verifique este guia dedicado ao assunto.

Sumário

Neste artigo, nós exemplificamos uma das formas de realizar a sincronização das credenciais de um ambiente Active Directory On-Premises e o AWS Managed AD para a solução Okta Identity Cloud. Com esta sincronização, você poderá centralizar o acesso de suas aplicações Cloud e On-Premises e garantir um acesso transparente para aplicações compatíveis com os serviços de Active Directory na AWS. Nossos clientes também podem realizar uma migração completa de seu ambiente On-Premises para o serviço gerenciado AWS Managed Microsoft AD utilizando ferramentas como o Active Directory Migration Tool (ADMT) em conjunto com o serviço PES (Password Export Server).

Sobre os autores

Lucas Henrique Garcia é arquiteto de soluções do time de SMB e trabalhou previamente do time de Premium Support na AWS em Dublin. Seu foco está em ajudar clientes da AWS a resolverem seus problemas e a desenhar arquiteturas para seus negócios.

Diego Voltz atua como arquiteto de soluções senior no seguimento de enterprise na AWS. Ele atuou por 15 anos como CTO de Startups no seguimento de Web Hosting e Health, tendo como foco virtualização, Storage e containers, hoje ajuda os clientes da AWS na jornada de adoção da nuvem e na otimização dos custos.

Pavankumar Kasani é arquiteto de soluções da AWS e mora na cidade de Nova York. Ele adora ajudar os clientes a projetar soluções escalonáveis, bem arquitetadas e modernizadas na nuvem AWS. Fora do trabalho, ele adora ficar com a família, jogar críquete, tênis de mesa e também testar novas receitas na cozinha.

Xiaozang Li é arquiteto de soluções na Amazon Web Services (AWS), onde está obcecado em ajudar clientes corporativos a iniciar sua jornada na nuvem para obter agilidade, elasticidade e inovação mais rápida. Antes da AWS, Xiaozang trabalhou Content delivery network (CDN), ajudando as empresas a entregar conteúdo da web e streaming de maneira rápida, confiável e segura. Xiaozang mora em Boston e passa o inverno fazendo snowboard e esquiando nas montanhas.