DEV Community

AWS Community Builders profile image Railander Marques
Railander Marques for AWS Community Builders

Posted on

AWS Managed Microsoft AD - integração com FortiGate

#aws #ad #ldaps #fortigate

1. Objetivo

Migrar a autenticação LDAP do FortiGate do cliente (hoje em texto claro na porta 389, via túnel VPN) para LDAPS na porta 636, com criptografia TLS ponta a ponta, mantendo o mesmo diretório AWS Managed Microsoft AD.

Resultado esperado: os DCs gerenciados passam a escutar em 636 com um certificado válido, e o FortiGate valida esse certificado contra a CA que confiamos nele.

2. Conceitos — o que confunde todo mundo

2.1 Server-side vs client-side LDAPS

O console do AWS Directory Service tem uma aba de LDAPS com opção de registrar certificado. Ela não serve para este cenário.

Client-side LDAPS Server-side LDAPS (o nosso caso)
Quem é o servidor LDAP Um AD self-managed / outro diretório O AWS Managed AD
Quem é o cliente LDAP O AWS Managed AD e apps AWS O FortiGate
O que se faz no console Importa o certificado da CA do outro lado e habilita Nada
Onde está o trabalho Console Dentro da EC2 de gerência

Ou seja: não há nada para habilitar, importar ou emitir pelo console do Directory Service. A porta 636 sobe sozinha no momento em que os DCs recebem um certificado válido. Todo o trabalho é PKI dentro do Windows.

2.2 Por que não dá para subir um .pfx qualquer

O AWS Managed AD é serviço gerenciado: você não tem RDP nem administrador local nos DCs. A única forma de instalar um certificado neles é o autoenrollment do Active Directory — o próprio DC solicita o certificado a uma CA da floresta e instala sozinho.

Consequência: a CA precisa ser uma Microsoft Enterprise CA ingressada no domínio. Certificado de CA standalone, de CA pública (DigiCert, Let's Encrypt) ou arquivo avulso não funcionam — não é limitação da AWS, é como o autoenrollment do AD funciona.

2.3 A cadeia de confiança

Três certificados diferentes, papéis diferentes:

Certificado Onde vive Quem usa Sai da AWS?
Chave privada da CA EC2 de gerência Assina os demais Nunca
Certificado do DC Store LocalMachine\My de cada DC Apresentado no handshake TLS da 636 Não (você nem toca nele)
Certificado público da CA Exportado em .cer Base64 Importado no FortiGate Sim — é o único que se envia

O FortiGate não envia certificado nenhum para o AD. Ele só precisa confiar em quem assinou o certificado do DC.

O certificado de VPN que o cliente eventualmente tenha enviado não tem relação com isso. VPN e LDAPS são camadas independentes: a VPN entrega o pacote na VPC, o LDAPS criptografa a sessão LDAP dentro dela.

3. Arquitetura

3.1 Topologia 

   REDE DO CLIENTE                    │             AWS — VPC (sua conta)
                                      │
  ┌────────────────────┐              │    ┌──────────── Subnet privada AZ-a ────────────┐
  │     FortiGate      │              │    │  ┌───────────────────────────────────────┐  │
  │                    │              │    │  │ DC1 — AWS Managed Microsoft AD        │  │
  │ Trusted CA store:  │              │    │  │ ENI 10.0.1.10  ·  Windows Server 2019 │  │
  │  └ CORP-ROOT-CA    │              │    │  │ SG: d-xxxxxxxxxx_controllers          │  │
  └─────────┬──────────┘              │    │  └───────────────────────────────────────┘  │
            │                         │    └─────────────────────────────────────────────┘
            │ TCP 636 (LDAPS)         │
            │                         │    ┌──────────── Subnet privada AZ-b ────────────┐
  ┌─────────┴──────────┐   IPsec   ┌──┴──┐ │  ┌───────────────────────────────────────┐  │
  │  Túnel VPN / DX    │◄─────────►│ VGW │ │  │ DC2 — AWS Managed Microsoft AD        │  │
  └────────────────────┘           └──┬──┘ │  │ ENI 10.0.2.10                         │  │
                                      │    │  └───────────────────────────────────────┘  │
                                      │    └─────────────────────────────────────────────┘
                                      │
                                      │    ┌──────────── Subnet privada (gerência) ──────┐
                                      │    │  ┌───────────────────────────────────────┐  │
                                      │    │  │ EC2 Windows de gerência               │  │
                                      │    │  │  · ingressada no domínio              │  │
                                      │    │  │  · RSAT / AD Tools                    │  │
                                      │    │  │  · AD CS — Enterprise Root CA  ◄── chave privada  │
                                      │    │  └───────────────────────────────────────┘  │
                                      │    └─────────────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

3.2 Fluxo 1 — Emissão do certificado (uma vez, automático) 

  EC2 gerência                          DC1 / DC2 (gerenciados)
       │                                        │
       │  1. AD CS instalado como Enterprise CA │
       │──── publica na floresta ──────────────►│
       │     (CN=Configuration → Public Key     │
       │      Services → Certification          │
       │      Authorities / NTAuthCertificates) │
       │                                        │
       │                                        │ 2. DC detecta CA + template
       │                                        │    com permissão Autoenroll
       │                                        │
       │  3. Solicitação via RPC/DCOM (MS-ICPR) │
       │◄─────── TCP 135 + portas dinâmicas ────│
       │                                        │
       │  4. CA assina e devolve o certificado  │
       │──────────────────────────────────────► │
       │                                        │
       │                                        │ 5. Instala em LocalMachine\My
       │                                        │    → serviço LDAP abre a 636
Enter fullscreen mode Exit fullscreen mode

O passo 3 é o motivo de a AWS pedir liberação ampla entre o SG do diretório e o SG da CA: o enrollment usa RPC com portas dinâmicas, não uma porta fixa.

3.3 Fluxo 2 — Autenticação do FortiGate (a cada consulta) 

  FortiGate                                          DC (10.0.1.10)
      │                                                    │
      │ 1. TCP SYN :636 ─────────────────────────────────► │
      │ 2. ClientHello ──────────────────────────────────► │
      │ 3. ◄──────── ServerHello + certificado do DC       │
      │                                                    │
      │ 4. Valida: assinado pela CA que confio?            │
      │            CN/SAN bate com o nome que consultei?   │
      │            está dentro da validade?                │
      │                                                    │
      │ 5. Túnel TLS estabelecido ◄──────────────────────► │
      │ 6. LDAP bind (usuário de serviço) ───────────────► │
      │ 7. Search: (sAMAccountName=usuario) ─────────────► │
      │ 8. ◄──────── DN + grupos do usuário                │
Enter fullscreen mode Exit fullscreen mode

O passo 4 é onde 90% das integrações quebram — ver seção 9.

3.4 Portas

Origem → Destino Porta Para quê Obrigatória
FortiGate → DCs TCP 636 LDAPS Sim
FortiGate → DCs TCP 389 LDAP em claro (legado) Só até a migração concluir
DCs → EC2 da CA TCP 135 + dinâmicas (49152-65535) Autoenrollment RPC Sim
DCs → EC2 da CA TCP 445 CDP/AIA em file share Se usar publicação SMB
FortiGate → DCs TCP 3269 LDAPS no Global Catalog Só se buscar em múltiplos domínios

4. Pré-requisitos

  • [ ] EC2 Windows ingressada no domínio do AWS Managed AD (a instância de gerência já existente)
  • [ ] Credencial no grupo Admins ou AWS Delegated Enterprise Certificate Authority Administrators do diretório (a conta Admin padrão atende)
  • [ ] Conectividade FortiGate → VPC já funcionando (se o 389 funciona hoje, está atendido)
  • [ ] Usuário de serviço para bind já existente no domínio
  • [ ] Janela de ~1h, sendo até 30 min só de espera pela emissão

Atenção ao DN dos objetos. No AWS Managed AD você não cria objetos em CN=Users,DC=.... Tudo fica sob a sua OU delegada: OU=Users,OU=corp,DC=corp,DC=empresa,DC=com. Errar isso é a causa mais comum de bind falhando depois que o TLS já subiu.

5. Passo 1 — Security Groups (console AWS)

Duas liberações distintas, com finalidades diferentes:

a) FortiGate → DCs (o acesso final)

  1. EC2 → Security Groups → selecione d-xxxxxxxxxx_controllers
  2. Inbound rules → Edit → Add rule
    • Type: Custom TCP
    • Port: 636
    • Source: o mesmo CIDR/IP privado que hoje já libera o 389

Nunca use IP público como origem. Os DCs ficam em subnets privadas e não têm IP público — o tráfego chega exclusivamente pelo túnel.

b) DCs ↔ EC2 da CA (o enrollment)

  1. No SG da EC2 de gerência: Inbound → All traffic → Source = SG do diretório
  2. No SG do diretório: Outbound → All traffic → Destination = SG da EC2 de gerência

Sem o item (b) o DC nunca consegue pedir o certificado e o LDAPS jamais sobe, mesmo com o AD CS instalado corretamente.

6. Passo 2 — Instalar a CA

RDP na instância de gerência com a conta Admin do diretório. PowerShell como administrador:

Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

Install-AdcsCertificationAuthority -CAType EnterpriseRootCA `
  -CACommonName "CORP-ROOT-CA" `
  -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
  -KeyLength 2048 -HashAlgorithmName SHA256 `
  -ValidityPeriod Years -ValidityPeriodUnits 10 -Force
Enter fullscreen mode Exit fullscreen mode

O que cada escolha significa:

  • EnterpriseRootCA — é o que registra a CA na floresta e habilita autoenrollment. StandaloneRootCA não funciona para este fim.
  • CACommonName — nome livre. Não precisa ser o domínio; o AD CS descobre o domínio sozinho porque a instância está ingressada. Escolha algo identificável, porque esse nome vai aparecer no FortiGate do cliente.
  • ValidityPeriod 10 anos — validade da CA raiz. Os certificados dos DCs terão 1 ano e renovam automaticamente.

Se o cliente já possui PKI corporativa, o correto é instalar como EnterpriseSubordinateCA e submeter o request à raiz dele — nesse caso o pacote enviado precisa conter a cadeia completa, não só um certificado.

7. Passo 3 — Template de certificado

Uma Enterprise CA nova já publica por padrão os templates Domain Controller Authentication e Kerberos Authentication, e os DCs têm permissão de Autoenroll neles. Na maioria dos casos a 636 sobe sem nenhuma configuração adicional — pule para o Passo 4 e só volte aqui se não subir.

Caminho oficial da AWS, caso necessário:

  1. Server Manager → Tools → Certification Authority
  2. Botão direito em Certificate Templates → Manage
  3. Botão direito em Kerberos Authentication → Duplicate Template
  4. Aba Compatibility: Certification recipient → Windows 10 / Windows Server 2016 (os DCs do AWS Managed AD rodam Windows Server 2019)
  5. Aba General: Template display name → LDAPOverSSL
  6. Aba Security: selecione Domain Controllers e confirme Read, Enroll e Autoenroll marcados
  7. OK, feche o console de templates
  8. Botão direito em Certificate Templates → New → Certificate Template to Issue → selecione LDAPOverSSL

O template Kerberos Authentication é o escolhido porque já traz os EKUs certos (Server Authentication, Client Authentication, Smart Card Logon, KDC Authentication) e preenche o SAN com o FQDN do DC e o FQDN do domínio — é isso que permite ao FortiGate consultar por corp.empresa.com sem erro de identidade.

8. Passo 4 — Validar

Aguarde até 30 minutos após o Passo 2/3 e rode na instância de gerência:

$fqdn = (Get-WmiObject Win32_ComputerSystem).Domain
Test-NetConnection $fqdn -Port 636
certutil -dcinfo verify
Enter fullscreen mode Exit fullscreen mode

Critérios de aceite:

  • TcpTestSucceeded : True
  • certutil -dcinfo verify lista os DCs com certificado válido e sem erro de cadeia

Teste funcional de bind com o ldp.exe (vem com as AD Tools):

  1. ldp.exe → Connection → Connect
  2. Server: FQDN do domínio · Port: 636 · marcar SSL
  3. A janela deve retornar os atributos do RootDSE (se aparecer só erro 81 = servidor indisponível, o certificado ainda não foi emitido)
  4. Connection → Bind com o usuário de serviço, para confirmar que a conta de bind funciona

Só avance quando os dois passarem. Se falhar aqui, o problema é seu — não adianta enviar nada ao cliente.

9. Passo 5 — Exportar o material e montar o pacote 

certutil -ca.cert C:\ca-der.cer
certutil -encode C:\ca-der.cer C:\ca-publica-base64.cer
certutil -backupkey C:\backup-ca
Enter fullscreen mode Exit fullscreen mode
  • ca-publica-base64.cer → é o arquivo que vai para o cliente. Base64/PEM é o formato que o FortiGate importa.
  • C:\backup-ca → backup da chave privada. Guarde em local seguro fora da instância (S3 com KMS, cofre de senhas). Nunca envie ao cliente.

Pacote a entregar:

Item Valor
Certificado da CA ca-publica-base64.cer
Servidor LDAP FQDN do domínio, ex. corp.empresa.com (não IP)
IPs dos DCs 10.0.1.10 e 10.0.2.10 — apenas para DNS/rota, não para configurar como servidor
Porta 636
Base DN DC=corp,DC=empresa,DC=com
Common Name Identifier sAMAccountName
Usuário de bind o mesmo já em uso no 389

10. Passo 6 — Lado do cliente (FortiGate)

GUI

  1. System → Certificates → Import → CA Certificate → upload do .cer
  2. User & Authentication → LDAP Servers → editar o objeto existente
  3. Server Port → 636 · Secure Connection → marcar · Protocol → LDAPS · Certificate → a CA importada
  4. Test Connectivity e Test User Credentials

CLI equivalente

config user ldap
    edit "AWS-Managed-AD"
        set server "corp.empresa.com"
        set cnid "sAMAccountName"
        set dn "DC=corp,DC=empresa,DC=com"
        set type regular
        set username "CN=svc_fortigate,OU=Users,OU=corp,DC=corp,DC=empresa,DC=com"
        set password ********
        set port 636
        set secure ldaps
        set ca-cert "CORP-ROOT-CA"
        set server-identity-check enable
    next
end
Enter fullscreen mode Exit fullscreen mode

Validação no FortiGate:

diagnose test authserver ldap AWS-Managed-AD <usuario> <senha>
Enter fullscreen mode Exit fullscreen mode

Pré-requisito no lado dele: o FortiGate precisa resolver o FQDN do domínio pelos DCs do AD. Se o DNS dele não aponta para os DCs, configure set dns-primary para o IP de um DC ou negocie o uso do FQDN do DC específico.

11. Troubleshooting

Sintoma Causa provável Ação
Test-NetConnection :636 = False na instância de gerência Certificado ainda não emitido Aguardar 30 min; conferir SG DCs ↔ CA; conferir se a CA é Enterprise, não Standalone
Idem, após 1h Template sem Autoenroll para Domain Controllers ou não publicado Executar o Passo 3
ldp.exe erro 81 LDAP não está escutando na 636 Mesmo diagnóstico acima
636 OK interno, FortiGate não conecta SG inbound 636 ou rota do túnel Conferir origem da regra (IP privado, não público)
Failed to establish SSL connection no FortiGate CA não importada, ou cadeia incompleta (caso subordinada) Reenviar cadeia completa
Erro de certificado apesar da CA importada FortiGate apontando para IP; server-identity-check compara com o CN/SAN Usar FQDN, ou set server-identity-check disable
TLS OK mas bind falha DN do usuário de serviço errado Usar a OU delegada, não CN=Users
Funcionou e parou de funcionar ~1 ano depois Certificado do DC expirou sem renovar Ver seção 12

Comando de diagnóstico no FortiGate:

diagnose debug application fnbamd -1
diagnose debug enable
Enter fullscreen mode Exit fullscreen mode

12. Operação contínua — o que não pode ser esquecido

Ao instalar a CA na instância de gerência, ela vira um trust anchor de longo prazo. Isso cria obrigações:

Item Risco Mitigação
Certificado do DC expira em 1 ano Renovação automática só ocorre se a CA estiver online Manter a instância viva e monitorada
Instância descartada / recriada Perda da chave privada da CA → sem renovação e sem CRL certutil -backupkey guardado fora da instância; documentar restore
CRL expira (padrão: 1 semana) Validações de certificado passam a falhar Aumentar o intervalo de publicação ou garantir que a CA fica online
Instância desligada por economia Enrollment e CRL param Não incluir essa instância em schedulers de stop

Comandos úteis de operação:

certutil -CRL                                   # publica CRL manualmente
certutil -getreg CA\CRLPeriod*                  # consulta período da CRL
certutil -getreg CA\ValidityPeriod*             # validade dos certs emitidos
Enter fullscreen mode Exit fullscreen mode

Adicione ao monitoramento: expiração do certificado dos DCs, expiração da CRL e status do serviço CertSvc.

13. Anexo — por que não usar o AWS Private CA

O AWS Private CA Connector for AD faz o mesmo trabalho de forma gerenciada, sem EC2 e sem chave privada sob sua custódia. É tecnicamente superior, mas custa USD 400/mês por CA em modo general-purpose (o connector em si é gratuito; paga-se a CA e os certificados).

Para um caso de uso restrito a habilitar LDAPS, o AD CS na instância de gerência já existente resolve com custo marginal zero. O Private CA passa a valer a pena quando há emissão de certificados em escala (usuários, máquinas, mTLS) ou quando a custódia da chave privada em EC2 é inaceitável por compliance.

Diferenças operacionais relevantes:

AD CS na EC2 AWS Private CA + Connector
Custo Só a EC2 ~USD 400/mês por CA
Chave privada Sob sua responsabilidade Gerenciada pela AWS
Habilitar cert nos DCs Automático via autoenrollment Explícito: Actions → Enable domain controller certificates
Patching / disponibilidade Sua responsabilidade AWS
Tempo até emissão Até 30 min Até 8 horas

Referências

Top comments (0)