Integração de SAMBA 4 Active Directory com AWS IAM Identity Center

Neste blog post, mostraremos como integrar uma solução de código aberto LDAP com o AWS IAM Identity Center utilizando o AWS Managed Active Directory ou o Active Directory Connector.

Introdução

Microsoft Active Directory tem sido uma solução de gerenciamento de identidade amplamente usada em redes Windows por décadas. Ele fornece protocolos de autenticação e acesso, como LDAP e Kerberos. À medida que os clientes buscam soluções de código aberto para economizar custos, o Samba Active Directory é útil como uma alternativa gratuita que roda em Linux.

A partir da versão 4.0 (lançada em 2012), Samba pode operar em um nível funcional de floresta Windows Server 2008 R2, o que é mais do que suficiente para gerenciar empresas sofisticadas que usam o Windows 10/11 com requisitos rígidos de conformidade (incluindo o NIST 800-171).

Além disso, os clientes geralmente exigem experiência de login único na AWS para seus usuários, usando seu Active Directory autogerenciado.

Requisitos do ambiente

Uma instância de Amazon Virtual Private Cloud (VPC) com pelo menos uma subnet que permita conexão de saída com a Internet (recomendamos usar subnets privadas);
Pelo menos uma conta da AWS dentro de uma AWS Organization;
AWS IAM Identity Center ativado em uma management account ou de administrador delegado;
Uma instância do AWS Managed Active Directory (Standard ou Enterprise) ou uma instância do Active Directory Connector (Small ou Large);
Resolução de nomes para DNS do domínio do AD gerenciado e do Samba 4 AD. Neste exemplo, usamos corp.local e samdom.internal, respectivamente;
Uma instância de Amazon Elastic Compute Cloud (Amazon EC2) executando um sistema operacional compatível com Samba 4 Active Directory. Como exemplo, usamos uma instância EC2 t3.small com Ubuntu 22.04 LTS e hospedada na subnet mencionada no primeiro requisito;
Uma instância do Amazon EC2 executando Windows Server, inserida no domínio Samba 4 AD com as ferramentas de gerenciamento de GUI do Active Directory instaladas (neste post, eu usamos uma instância t3.medium com Windows Server 2022).

Desde que você tenha conectividade e resolução de DNS, você pode executar o Samba 4 AD on-premises ou na AWS. Neste exemplo, o Samba está sendo executado na VPC na AWS. A implantação que propomos nesta postagem do blog corresponde à arquitetura da Figura 1. Observe que o AWS IAM Identity Center atualmente oferece suporte a um único provedor de identidade por vez, portanto, você pode obter a integração do AWS Managed AD ou do AD Connector com o AWS IAM Identity Center, mas não os dois ao mesmo tempo.

Diagrama de arquitetura cobrindo a solução proposta e destacando a relação entre os serviços

Figura 1 – Diagrama de arquitetura abrangendo a solução proposta

Qual solução escolher?

Nesta postagem, abordamos a integração do AWS IAM Identity Center com o AWS Managed AD ou o AD Connector. O AWS Managed AD oferece suporte a múltiplas relações de confiança, o que é ideal para cenários com várias florestas ou domínios, e exige uma configuração de confiança bidirecional com seu AD autogerenciado. O AD Connector será mais adequado se você tiver um único domínio ou se não puder usar relações de confiança bidirecionais entre seu AD autogerenciado e o AWS Managed AD. Você pode encontrar mais detalhes sobre as diferenças entre esses serviços aqui.

Configurações do Amazon Route 53 Resolver

Para esse exemplo de solução, utilizamos um endpoint de saída do Amazon Route 53 Resolver para a resolução de nomes do domínio AWS Managed AD e Samba 4 AD na VPC. Para configurar o Route 53, você pode seguir o guia técnico de AWS Hybrid DNS with Active Directory.

Existem outras alternativas para fornecer resolução de DNS. Por exemplo, você pode aproveitar as zonas privadas do Route 53, configurar encaminhadores condicionais ou até mesmo definir manualmente as entradas nos arquivos hosts. Algumas dessas abordagens podem exigir alterações no DHC Option Set. Os recursos a seguir abordam essas e outras opções para resolução de DNS e tópicos de Active Directory na AWS:

Passo a passo

Esta seção abordará as seguintes etapas:

Configurando o controlador de domínio Samba 4 Active Directory no Amazon EC2
Definindo a confiança
Integração com o AWS IAM Identity Center

1. Configurando o controlador de domínio Samba 4 Active Directory no Amazon EC2

As etapas a seguir guiarão a instalação de um controlador de domínio Samba Active Directory, versão 4.18.2 (série atual de versões estáveis quando post foi publicado), no Amazon EC2. Analise a documentação oficial para seguir as melhores práticas em um ambiente de produção. Neste exemplo, selecionamos uma instância EC2 t3.small executando Ubuntu 22.04 LTS.

1.1. Depois de iniciada, conecte-se à instância do Amazon EC2 usando um cliente SSH com a key pair relacionada e emita um comando sudo para fazer login como root.

ssh -i yourKeyPair.pem ubuntu@IPV4

sudo su

1.2. Adicione o repositório do time The Linux Schools Project e verifique se o servidor está atualizado.

add-apt-repository ppa:linux-schools/samba-latest

apt-get update

apt-get upgrade

1.3. Em seguida, defina um nome de host (Figuras 2 e 3), certificando-se de que a configuração preserve_hostname do cloud-init esteja definida como true, para manter a atualização do nome do host (Figura 4). Em nosso exemplo, usamos dc1 como nome do host:

hostnamectl set-hostname dc1

Figura 2 – Configurando o nome do host do servidor Ubuntu

vi /etc/hosts
# Add the following entry to hosts file, replacing <IPV4> for the equivalent of your Amazon EC2 instance
IPV4 dc1.samdom.internal dc1

Figura 3 – Arquivo hosts com a entrada necessária

vi /etc/cloud/cloud.cfg
# Confirm if the parameter preserve_hostname is set to true
# If the parameter is not set to true or it is not listed, change it or add the following text to the end of the file:
preserve_hostname: true

Figura 4 – Parâmetro Cloud-init preserve_hostname

1.4. Instale o Samba 4 AD (Figura 5) e confirme SAMDOM.INTERNAL como o Default Kerberos version 5 realm (Figura 6). Insira dc1.samdom.internal em Kerberos servers for your realm (Figura 7) e em Administrative server for your Kerberos realm (Figura 8). Você pode verificar a documentação para outras instruções de instalação de pacotes específicos dependendo da distribuição.

apt-get install acl attr samba winbind libpam-winbind libnss-winbind krb5-config krb5-user dnsutils python3-setproctitle

Figura 5 – Fim do output após executar a instalação do pacote

Figura 6 – Default Kerberos version 5 realm

Figura 7 – Default Kerberos version 5 realm

Figura 8 – Administrative server for your Kerberos realm

1.5. Depois que a instalação for concluída, remova ou renomeie qualquer arquivo smb.conf existente, como na Figura 9.

# Check existing smb.conf files
smbd -b | grep "CONFIGFILE"

# Rename an existing smb.conf file
mv /etc/samba/smb.conf /etc/samba/smb.conf.bak

Figura 9 – Renomeando o arquivo smb.config padrão

1.6. Execute a linha de comando samba-tool usando os seguintes parâmetros. Isso provisionará o domínio no modo não interativo, conforme mostrado no output da Figura 10; mais detalhes estão disponíveis na documentação do Samba.

# Replace <YourAdminPassword> with a strong password.
# This is the password for the SAMDOM\Administrator user.

samba-tool domain provision --server-role=dc --use-rfc2307 --dns-backend=SAMBA_INTERNAL --realm=SAMDOM.INTERNAL --domain=SAMDOM --adminpass=YourAdminPassword

Figura 10 – Fim do output do provisionamento do Samba Active Directory

1.7. Configure o protocolo Kerberos, copiando o arquivo de configuração Kerberos para o controlador de domínio, que foi criado durante o provisionamento do domínio, como na Figura 11.

cp /var/lib/samba/private/krb5.conf /etc/krb5.conf

Figura 11 – Configurando o protocolo Kerberos

1.8. Defina o encaminhador de DNS para que o controlador de domínio encontre o nome de domínio AWS Managed AD. Isso pode ser o VPC+2, os servidores Microsoft AD existentes ou outros servidores DNS que podem fazer a resolução externa de nomes e estão cientes do domínio do Microsoft AD. Neste exemplo, estamos usando o VPC+2, pois estamos aproveitando o Route 53 Resolver para resolução de nomes. A Figura 12 mostra o exemplo de configuração.

vi /etc/samba/smb.conf
# Change the dns forwarder parameter to the related DNS service Ipv4
dns forwarder = forwarder_ipv4

Figura 12 – Configurando o encaminhador DNS para VPC+2 para aproveitar o Route 53 Resolver

1.9. Desative a ferramenta resolvconf para evitar alterações no arquivo /etc/resolv.conf, pois a mesma instância será o servidor DNS para o nome de domínio samdom.internal. Você pode ver o exemplo na Figura 13.

systemctl disable systemd-resolved.service

service systemd-resolved stop

Figura 13 – Desativando a ferramenta resolvconf

1.10. Reinicialize o servidor para garantir que todas as configurações sejam mantidas. Quando estiver on-line novamente, conecte-se à instância usando um cliente SSH, emita um comando sudo para fazer login como root novamente e execute o comando samba para verificar se os serviços foram iniciados (Figura 14).

reboot

sudo su

samba

Figura 14 – Nenhum output esperado ao iniciar o Samba

1.11. Teste a resolução de nomes DNS para os domínios Samba e AWS Managed AD, conforme mostrado na Figura 15.

nslookup samdom.internal

nslookup corp.local

Figura 15 – Resolução de DNS funcionando para ambos os domínios

1.12. Verifique se o protocolo Kerberos está funcionando. Você deve ver uma saída semelhante à mostrada na Figura 16.

kinit administrator
# Type the password defined on step 17

# Use klist command to check cached Kerberos tickets
klist

Figura 16 – Ticket Kerberos criado para o usuário administrador

Domain-join de uma instância Windows EC2 ao domínio Samba 4 AD

1.13. Para usar as ferramentas de gerenciamento de GUI do Active Directory, siga esta orientação para inserir uma instância Windows do Amazon EC2 ao domínio Samba. Aponte o servidor para o Samba 4 AD FQDN e, quando solicitado, use as credenciais SAMDOM\Administrator para permitir que o domínio participe. Essas etapas são ilustradas na Figura 17.

Figura 17 – Domain-join de uma instância Windows EC2 ao SAMDOM.internal

1.14. Depois que o servidor for reinicializado, abra a conexão RDP na instância Windows do Amazon EC2 usando as credenciais SAMDOM\Administrator. Você pode confirmar as credenciais conforme mostrado na Figura 18.

$Credencial SAMDOM\Administrator para acessar a máquina associada ao domínio do Windows$

Figura 18 – Credencial SAMDOM\Administrator para acessar a máquina associada ao domínio do Windows

1.15. Use o seguinte comando do PowerShell para instalar as Active Directory Management Tools. Você verá o resultado conforme mostrado na Figura 19.

Add-WindowsFeature RSAT-AD-PowerShell,RSAT-AD-AdminCenter,RSAT-ADDS-Tools,RSAT-ADLDS,RSAT-DNS-Server

Figura 19 – Instalando as ferramentas de gerenciamento do Active Directory

1.16. Use o snap-in mmc de Active Directory Users and Computers, conforme exemplificado na Figura 20, para gerenciar objetos de domínio samdom.internal.

Figura 20 – Snap-in do Active Directory Users and Computers

2. Definindo a confiança

Quando tivermos o controlador de domínio Samba 4 AD instalado e funcionando, podemos aproveitar o AWS Managed AD ou o AD Connector para integrar seu banco de dados de diretórios ao AWS IAM Identity Center. As próximas duas subseções fornecerão as instruções para fazer as duas coisas, então escolha a que melhor se adequa ao seu caso de uso.

Com o AWS Managed AD

2.1. Você precisa identificar qual controlador de domínio do AWS Managed AD está hospedando a função FSMO do PDC Emulator antes de definir a configuração de confiança. Caso contrário, você poderá receber uma exceção de “object not found”. Você pode usar uma máquina associada a um domínio do Windows Server e executar o seguinte comando PowerShell, conforme apresentado na Figura 21.

(Invoke-Command {netdom query fsmo | findstr PDC}).split(" ")[$_.length-1] | nslookup

Figura 21 – Recuperando o endereço IP do PDC do AWS Managed AD

2.2. Conecte-se ao servidor Samba 4 AD usando um cliente SSH e emita um comando sudo para fazer login como root. Use a linha de comando samba-tool para configurar uma relação de confiança bidirecional na floresta no domínio do Samba. O comando solicitará uma trust password — defina uma e salve-a para uso posterior. Você pode ver um resultado semelhante na Figura 22.

Observação: se você receber uma “uncaught exception”, poderá ignorá-la neste laboratório. Trata-se de um bug que foi corrigido na próxima série de lançamentos (4.19), mas não foi transferido para a versão estável atual (4.18.2).

samba-tool domain trust create Microsoft_AD_FQDN --type=forest --direction=both --create-location=local --skip-validation --ipaddress=PDC_IPV4 --username=admin@Microsoft_AD_FQDN --password=AdminPassword

# Replace <Microsoft_AD_FQDN> with the AWS Managed AD fully qualified domain name (FQDN) – in this example, corp.local.

# Replace <PDC_IPV4> with the IP retrieved in the earlier step

# Replace admin@Microsoft_AD_FQDN with an equivalent delegated administrator user from the AWS Managed AD domain

# Replace <AdminPassword> with the admin user password

Figura 22 – Configurando a confiança no lado do Samba 4 AD

2.3. Adicione a mesma configuração de confiança no AWS Managed AD (floresta bidirecional), com a mesma trust password. Defina o endereço IP do Samba AD como conditional forwarder. Acesse o console do AWS Directory Service (Figura 23), selecione Directories e selecione a instância do seu AWS Managed AD atual (Figura 24):

Figura 23 – Console do AWS Directory Services

Figura 24 – Selecione sua instância atual do AWS Managed AD

2.4. Na página de configurações do AWS Managed AD, vá para baixo até Trust relationships e selecione Add trust relationship, conforme mostrado na Figura 25.

Figura 25 – Adicionar relação de confiança

2.5. Defina as seguintes informações da relação de confiança e selecione Add. Você pode ver um exemplo na Figura 26.

Trust type: Forest trust;
Existing or new remote domain: samdom.internal;
Trust password: Password definida na seção 2.2;
Trust direction: Two-way;
Conditional forwarder IP address: endereço IP do Samba 4 AD domain controller.

$Adicionar uma relação de confiança \ Informações da relação de confiança$

Figura 26 – Adicionar uma relação de confiança \ Informações da relação de confiança

2.6. Depois de alguns minutos, atualize e o status da confiança será atualizado para Verified, conforme apresentado na Figura 27.

Figura 27 – Status da relação de confiança verified

Com o AD Connector

2.7. Crie uma conta de serviço no domínio AD do Samba 4 e delegue as permissões necessárias seguindo a documentação do AD Connector. Você pode usar a instância Windows do Amazon EC2 associada ao domínio descrita entre as etapas 1.13 e 1.16.

2.8. Depois que a conta de serviço estiver pronta, configure um AD Connector apontando para o domínio do Samba AD. Acesse o console do AWS Directory Services, selecione Directories (Figura 28) e selecione Set up directory (Figura 29).

Figura 28 – Console do AWS Directory Services

Figura 29 – Configurar um diretório

2.9. Na tela Select a directory type, como na Figura 30, selecione AD Connector e selecione Next.

Figura 30 – Selecione o AD Connector

2.10. Em Enter AD Connector information, apresentado na Figura 31, escolha Small ou Large, de acordo com seus requisitos. Neste exemplo, usaremos Small. Em seguida, selecione Next.

Figura 31 – Escolha o tamanho do AD Connector

2.11. Configure-o na mesma VPC em que o servidor Samba 4 AD está hospedado, forneça duas sub-redes e selecione Next. Você pode ver um exemplo na Figura 32.

Figura 32 – Definir a configuração da VPC

2.12. Em Active Directory information, preencha as informações do domínio AD do Samba 4, como o exemplo na Figura 33, incluindo a conta de serviço criada e selecione Next.

Directory DNS name: samdom.internal;
Directory NetBIOS name: SAMDOM;
DNS IP addresses: endereço IP do controlador de domínio Samba AD;
Service account username: nome de usuário da conta de serviço;
Service account password: senha da conta de serviço.

Figura 33 – Informações do Active Directory exigidas pelo AD Connector

2.13. Revise todas as configurações e selecione Create directory, conforme mostrado na Figura 34.

Figura 34 – Revise e crie o AD Connector

2.14. Após 5 a 10 minutos, selecione Refresh e um status Active será exibido para o AD Connector, como na Figura 35.

Figura 35 – Status ativo do AD Connector

3. Integração com o AWS IAM Identity Center

Agora temos o Samba 4 AD (samdom.internal) instalado, funcionando e conectado ao AWS Managed AD ou ao AD Connector. Podemos aproveitar essa integração para sincronizar seus usuários e grupos com o AWS IAM Identity Center. Da mesma forma que na seção anterior, escolha entre AWS Managed AD ou AD Connector, de acordo com as configurações que você seguiu anteriormente.

3.1. No console do AWS IAM Identity Center, apresentado na Figura 36, selecione Enable (Figura 37).

Figura 36 – Console do AWS IAM Identity Center

Figura 37 – Habilitar o AWS IAM Identity Center

3.2. Depois de habilitado, vá em Settings (Figura 38) e em Identity source, como na Figura 39, selecione Actions \ Change identity source.

Figura 38 – Configurações do AWS IAM Identity Center

Figura 39 – Alterar fonte de identidade

3.3. Em Choose identity source, como na Figura 40, selecione Active Directory e selecione Next.

Figura 40 – Escolha o Active Directory como fonte de identidade

3.4. Em Connect Active Directory, você verá o AWS Managed AD (corp.local), como na Figura 41, ou o AD Connector (samdom.internal), apresentado na Figura 42, como uma opção em Existing Directories. Selecione aquele que faz sentido para seu caso de uso e selecione Next.

Figura 41 – AWS Managed AD existente que tem uma relação de confiança com samdom.internal

Figura 42 – AD Connector existente conectado ao domínio AD do Samba 4

3.5. Na próxima página, como na Figura 43, revise a configuração, digite ACCEPT e selecione Change identity source.

Figura 43 – Revise e aceite a alteração da fonte de identidade

3.6. Quando a configuração estiver concluída, o AWS Managed Microsoft Active Directory ou AD Connector será indicado como a Identity source, conforme mostrado respectivamente nas Figuras 44 e 45. Selecione Actions \ Manage sync.

Figura 44 – AWS Managed AD como fonte de identidade

Figura 45 – AD Connector como fonte de identidade

3.7. Em Manage sync, você pode receber um aviso mencionando “Configurable AD sync paused “, conforme apresentado na Figura 46. Selecione Resume sync e, em seguida, selecione Add users and groups.

Figura 46 – Gerenciar a sincronização do AWS IAM Identity Center

Observação: criamos alguns objetos no domínio samdom.internal para testes, como os da Figura 47.

Figura 47 – Objetos de teste do domínio samdom.internal

3.8. Em Add users and groups, você pode esperar o seguinte comportamento.

Se a fonte de identidade estiver definida como AWS Managed AD, você verá corp.local e samdom.internal como opções no menu suspenso, devido à confiança entre ambos
Se a identidade estiver definida como AD Connector, você verá somente samdom.internal como uma opção no menu suspenso

Escolha samdom.internal para adicionar usuários e grupos do domínio de AD do Samba 4. Insira nomes de usuários/grupos e selecione Add. Depois que os usuários/grupos tiverem sido adicionados, selecione submit, como mostra o exemplo na Figura 48:

Figura 48 – Adicionando usuários e grupos para serem sincronizados

Clique aqui para obter mais informações sobre o AWS IAM Identity Center configurable AD sync.

3.9. Os objetos sincronizados geralmente aparecem dentro de 2 a 4 horas. Depois de concluído, você verá objetos do domínio Samba 4 AD sincronizados com o banco de dados do AWS IAM Identity Center, conforme indicado nas Figuras 49 e 50, permitindo que você aplique permission sets às contas.

Figura 49 – Usuários sincronizados

Figura 50 – Grupos sincronizados

3.10. Em nosso exemplo, criamos e aplicamos dois permission sets aos grupos de teste e vinculamos às contas da AWS da Aws Organization em que a solução foi implantada, como na Figura 51.

Figura 51 – Exemplo de permission sets

3.11. Neste exemplo, acessamos o portal do AWS IAM Identity Center usando a credencial test.user1 (Figura 52). Podemos ver os permission sets aplicados e o usuário samdom.internal acessando as contas da AWS por meio do Identity Center (Figura 53).

Figura 52 – test.user1 acessando a URL do portal de acesso do Identity Center

Figura 53 – Acesso do Test User 1

Conclusão

Nesta postagem do blog, documentamos as etapas para implantar um controlador de domínio Samba 4 Active Directory em uma instância do Amazon EC2 e integrá-lo ao AWS IAM Identity Center. Os clientes que usam a solução de código aberto LDAP podem sincronizar seu banco de dados de identidade com a AWS e aproveitar outras integrações de serviços.

Esse artigo foi originalmente publicado em inglês no AWS Blog (link aqui)

Autores e tradutores

	Luciano Bernardes trabalha atualmente como Sr Solutions Architect na AWS, especializado em workloads Microsoft. Com 17 anos de experiência no mercado, trabalhou a maior parte em consultoria técnica especializada em Microsoft, em clientes de várias verticais, com demandas voltadas para infraestrutura on-premises e em nuvem. Como SA, trabalha próximo a clientes e parceiros de consultoria em U.S. e LATAM, para apoiá-los em tomadas de decisão e revisão de arquitetura de workoads Microsoft na nuvem AWS.
	Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 15 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias afim de ajudar os clientes em seus desafios diários.

Luciano Bernardes trabalha atualmente como Sr Solutions Architect na AWS, especializado em workloads Microsoft. Com 17 anos de experiência no mercado, trabalhou a maior parte em consultoria técnica especializada em Microsoft, em clientes de várias verticais, com demandas voltadas para infraestrutura on-premises e em nuvem. Como SA, trabalha próximo a clientes e parceiros de consultoria em U.S. e LATAM, para apoiá-los em tomadas de decisão e revisão de arquitetura de workoads Microsoft na nuvem AWS.

Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 15 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias afim de ajudar os clientes em seus desafios diários.

O blog da AWS