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 │
│ │ └───────────────────────────────────────┘ │
│ └─────────────────────────────────────────────┘
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
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 │
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
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
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
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
-
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
- 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
Validação no FortiGate:
diagnose test authserver ldap AWS-Managed-AD <usuario> <senha>
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
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
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 |
Top comments (0)