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ênciaOu 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 StoreLocalMachine\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ínios4. Pré-requisitos
- [ ] EC2 Windows ingressada no domínio do AWS Managed AD (a instância de gerência já existente)
- [ ] Credencial no grupo
AdminsouAWS Delegated Enterprise Certificate Authority Administratorsdo diretório (a contaAdminpadrã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)
- EC2 → Security Groups → selecione
d-xxxxxxxxxx_controllers - 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)
- No SG da EC2 de gerência: Inbound → All traffic → Source = SG do diretório
- 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.StandaloneRootCAnã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:
- Server Manager → Tools → Certification Authority
- Botão direito em Certificate Templates → Manage
- Botão direito em Kerberos Authentication → Duplicate Template
- Aba Compatibility: Certification recipient → Windows 10 / Windows Server 2016 (os DCs do AWS Managed AD rodam Windows Server 2019)
- Aba General: Template display name →
LDAPOverSSL - Aba Security: selecione Domain Controllers e confirme Read, Enroll e Autoenroll marcados
- OK, feche o console de templates
- 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 verifylista os DCs com certificado válido e sem erro de cadeia
Teste funcional de bind com o ldp.exe (vem com as AD Tools):
-
ldp.exe→ Connection → Connect - Server: FQDN do domínio · Port: 636 · marcar SSL
- A janela deve retornar os atributos do RootDSE (se aparecer só erro 81 = servidor indisponível, o certificado ainda não foi emitido)
- 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 CAca-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
- System → Certificates → Import → CA Certificate → upload do
.cer - User & Authentication → LDAP Servers → editar o objeto existente
- Server Port →
636· Secure Connection → marcar · Protocol → LDAPS · Certificate → a CA importada - 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çãoTest-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 CRLcertutil -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