
LDAP (Lightweight Directory Access Protocol) é um protocolo cliente-servidor para ler e escrever em serviços de diretório através de uma rede. Definido na RFC 4511, fornece às aplicações uma forma normalizada de consultar um diretório, colocando perguntas como «este utilizador existe?», «a que grupos pertence?» e «a que recursos pode aceder?»
Apesar de ter sido normalizado pela primeira vez no início da década de 1990, o LDAP continua a ser a base da infraestrutura de identidade empresarial em 2026. O Active Directory, que assenta no LDAP, continua implementado em cerca de 90 % das organizações a nível mundial.
Pontos principais
- O LDAP é um protocolo. Define a forma como as aplicações consultam um diretório: contas de utilizador, pertença a grupos, direitos de acesso. O Active Directory implementa-o, mas o LDAP funciona de forma independente no OpenLDAP e noutros servidores, sem qualquer software da Microsoft.
- O AD não funciona sem o LDAP. Todos os sistemas não Windows que se autenticam no Active Directory fazem-no através do LDAP. Sem o LDAP, o AD deixa de poder servir aplicações de terceiros, dispositivos de rede e infraestrutura Linux.
- A porta 389 não é aceitável em produção. O LDAP padrão transmite as credenciais em texto em claro. O LDAPS, na porta 636, cifra toda a sessão. A Microsoft aplica, desde 2020, requisitos de assinatura e de channel binding (associação ao canal).
- Duas vulnerabilidades críticas foram corrigidas em 2025. A CVE-2025-26663 permite a execução remota de código (RCE) sem autenticação em controladores de domínio, através de uma falha de memória no serviço LDAP do Windows. A CVE-2025-54918 contorna as proteções de channel binding e de assinatura através de NTLM relay. Ambas têm correção disponível. Os controladores de domínio sem a correção aplicada são a prioridade máxima de correção.
- O LDAP e os protocolos modernos não são alternativas. O SAML assegura o SSO baseado em navegador. O OAuth assegura a autorização de acesso a APIs. O LDAP assegura as consultas ao diretório para sistemas que não utilizam nenhum dos dois. A maioria dos ambientes empresariais utiliza os três em simultâneo.
- A gestão manual de acessos cria lacunas. Quando as alterações aos grupos do AD não se propagam automaticamente aos sistemas dependentes, as contas permanecem ativas mais tempo do que deviam. Sincronizar o acesso às credenciais com a pertença a grupos do diretório elimina esse desfasamento.
Compreender o LDAP: Noções básicas
O LDAP é um protocolo padrão para aceder a serviços de informação de diretório distribuídos e geri-los. Funciona com um modelo de dados hierárquico derivado da norma X.500 e permite aos clientes autenticar utilizadores, consultar atributos e obter a pertença a grupos a partir de um diretório central. As organizações utilizam-no para responder, em grande escala, a uma pergunta fundamental: quem pode fazer o quê e onde?
Os dados organizados pelo LDAP encontram-se numa Directory Information Tree (DIT): uma estrutura hierárquica de entradas, cada uma identificada por um Distinguished Name (DN). Um DN típico tem o seguinte aspeto:
Copycn=jane.doe,ou=engineering,dc=company,dc=comCada entrada contém atributos: uma entrada de utilizador pode conter mail, uid, memberOf e userPassword. As aplicações consultam estes atributos para tomar decisões de autenticação e autorização.
Como funciona o LDAP? (modelo cliente-servidor)
Um cliente LDAP envia um pedido a um servidor LDAP (designado Directory System Agent, ou DSA). O servidor processa a operação na sua base de dados de diretório e devolve uma resposta. As operações principais definidas na RFC 4511 incluem:
- Bind – autenticar um cliente no diretório
- Search – consultar entradas que correspondem a um filtro
- Compare – verificar se uma entrada tem um valor de atributo específico
- Modify / Add / Delete – operações de escrita em entradas de diretório
- Unbind – terminar a sessão
A operação bind é aquela em que ocorre a autenticação. Um cliente envia um DN e credenciais. O servidor valida-as e concede ou recusa a sessão. A maioria das aplicações empresariais utiliza o bind LDAP para verificar a identidade do utilizador antes de conceder acesso.
LDAP na porta 389 vs. LDAPS na porta 636
O LDAP padrão funciona na porta TCP 389 e transmite os dados em texto em claro. Isto significa que as credenciais, incluindo palavras-passe, circulam pela rede sem cifragem. Em qualquer ambiente em que o tráfego de rede possa ser intercetado (ou seja, em todos), isto é inaceitável.
LDAPS (LDAP sobre SSL/TLS) funciona na porta TCP 636 e envolve toda a sessão LDAP em TLS, cifrando todo o tráfego, incluindo as credenciais de bind. Uma terceira opção, o StartTLS, promove uma ligação existente na porta 389 a TLS a meio da sessão, mas introduz complexidade de negociação e a sua configuração correta é mais propensa a erros.
| LDAP (porta 389) | LDAPS (porta 636) | |
|---|---|---|
| Transporte | TCP em texto em claro | TCP cifrado com TLS |
| Credenciais em trânsito | Expostas | Cifradas |
| Certificado necessário | Não | Sim |
| Suscetível a MITM | Sim | Não (com certificado válido) |
| Risco de NTLM relay | Elevado | Reduzido (com channel binding) |
| Aplicação pela Microsoft | Descontinuado em produção | Obrigatório (ADV190023) |
| Utilização em produção | Não | Sim |
| Alternativa StartTLS | Porta 389 + atualização via STARTTLS | N/D |
Desde 2020 que a Microsoft tem vindo a impor progressivamente o channel binding e a assinatura LDAP, com uma aplicação mais rigorosa nas atualizações subsequentes do Windows Server. Executar LDAP sem cifragem na porta 389 em produção é uma lacuna de segurança. A porta 636 é a predefinição correta.
O que é a porta TCP 389?
Porta TCP 389: a porta padrão, não cifrada, utilizada nas comunicações LDAP (Lightweight Directory Access Protocol). Permite que os serviços de diretório consultem e giram informações de utilizadores, credenciais de autenticação e dados organizacionais em servidores LDAP sem cifragem. É habitualmente utilizada em ambientes empresariais para consultas de diretório, mas transmite os dados em texto em claro, o que a torna menos segura do que as alternativas cifradas.
O que é a porta TCP 636?
Porta TCP 636: a porta padrão do LDAPS (LDAP sobre SSL/TLS), ou seja, a comunicação LDAP cifrada com protocolos de segurança SSL/TLS. Fornece ligações seguras e cifradas para consultas ao serviço de diretório e autenticação, protegendo os dados sensíveis contra a interceção. Esta porta é preferida à porta 389 em ambientes com requisitos de segurança elevados e é habitualmente utilizada em serviços de diretório empresariais como o Active Directory.
O que é o SSL/TLS?
SSL/TLS (Secure Sockets Layer / Transport Layer Security): protocolos criptográficos que estabelecem ligações seguras e cifradas entre clientes e servidores através de redes. O SSL é o protocolo mais antigo (atualmente obsoleto), enquanto o TLS é o seu sucessor moderno. Proporcionam autenticação, cifragem e integridade dos dados em comunicações sensíveis como HTTPS, e-mail e serviços de diretório. O TLS utiliza certificados digitais para verificar a identidade do servidor e cifra todos os dados transmitidos para impedir a interceção.
O que é o StartTLS?
StartTLS: uma extensão de protocolo que promove uma ligação existente não cifrada a uma ligação cifrada através de TLS. Em vez de exigir uma porta segura separada, o StartTLS permite que um cliente se ligue a uma porta padrão (como a porta 389 do LDAP ou a porta 25 do SMTP) e emita depois um comando STARTTLS para passar a ligação a cifrada. Oferece flexibilidade ao admitir modos cifrados e não cifrados na mesma porta, embora exija compatibilidade por parte do servidor e seja menos seguro do que portas cifradas dedicadas, como o LDAPS (porta 636).
LDAP vs. Active Directory: Qual é a diferença?
O Active Directory (AD) não é um substituto do LDAP: é um serviço de diretório que utiliza o LDAP como um dos seus protocolos de acesso. Confundir os dois é um dos equívocos mais comuns na TI empresarial. A dependência só existe num sentido: o LDAP funciona de forma autónoma, o AD não.
É possível executar o LDAP sem o AD?
Sim. O LDAP é um protocolo: define a forma como um cliente pede informações a um servidor de diretório e como esse servidor responde. Pode ser implementado de forma independente de qualquer software da Microsoft.
O OpenLDAP é a implementação de código aberto mais utilizada. O 389 Directory Server e o Apache Directory Server são alternativas comuns. Estes servidores autónomos armazenam identidades de utilizadores e pertença a grupos e disponibilizam essa informação a sistemas Linux/Unix, servidores de e-mail e aplicações personalizadas.
É possível executar o AD sem o LDAP?
Não. O Active Directory é um serviço de diretório completo, criado pela Microsoft com base no modelo de dados X.500. Os controladores de domínio utilizam o LDAP internamente para ler, escrever e replicar dados do diretório: utilizadores, computadores, políticas de grupo. Qualquer aplicação de terceiros ou máquina não Windows que se autentique no AD fá-lo ao comunicar com este em LDAP.
Sem o LDAP, o AD não consegue comunicar com o resto da infraestrutura.
Como se relacionam na prática
| Tipo | LDAP | Active Directory |
|---|---|---|
| Tipo | Protocolo aberto (RFC 4511) | Serviço de diretório proprietário |
| Fornecedor | Norma da IETF | Microsoft |
| Método de autenticação principal | Simple bind, SASL | Kerberos (Windows), bind LDAP (todos os restantes) |
| Plataforma | Multiplataforma | Windows Server |
| Funciona de forma independente | Sim | Não: requer LDAP |
| Implementações comuns | OpenLDAP, 389 Directory Server, Apache DS | Active Directory Domain Services |
Quando um servidor Linux se autentica no Active Directory, comunica em LDAP. Quando uma estação de trabalho Windows inicia sessão, utiliza Kerberos. O AD é compatível com ambos, mas é o LDAP que torna o AD acessível ao resto da infraestrutura.
Alternativas modernas: LDAP vs. SAML, OAuth e OpenID Connect
O LDAP foi concebido para a autenticação em redes internas: consultar um diretório dentro de um perímetro empresarial. Os protocolos que lhe sucederam foram concebidos para um mundo diferente: identidade federada entre fronteiras organizacionais, aplicações web e clientes móveis.
| Protocolo | Principal caso de utilização | Transporte | Exposição de credenciais |
|---|---|---|---|
| LDAP | Consultas internas ao diretório | TCP (porta 389/636) | Credenciais enviadas ao servidor |
| SAML | SSO federado (aplicações web empresariais) | HTTP/XML | As credenciais ficam no IdP |
| OAuth 2.0 | Autorização delegada (acesso a APIs) | HTTPS | Sem troca de credenciais |
| OpenID Connect | Autenticação federada sobre o OAuth | HTTPS | Sem troca de credenciais |
Estes protocolos não substituem o LDAP: operam numa camada diferente. O SAML e o OpenID Connect asseguram o SSO baseado em navegador. O LDAP assegura as consultas ao diretório e a autenticação de aplicações em sistemas que não conseguem comunicar em SAML. A maioria dos ambientes empresariais utiliza todos em simultâneo.
O LDAP ainda é relevante em 2026? (a realidade da nuvem híbrida)
O LDAP continua a ser o protocolo de autenticação empresarial dominante, presente em cerca de 90 % das organizações a nível mundial através das respetivas implementações do Active Directory. A adoção da nuvem não alterou esta situação.
A maioria das empresas não é totalmente nativa da nuvem. Funciona com um modelo híbrido: algumas cargas de trabalho no Azure ou na AWS, outras nas instalações, com o Active Directory como âncora de identidade para ambas. O Microsoft Entra ID (anteriormente Azure AD) liga-se ao AD das instalações através de sincronização, mas esse AD (e, portanto, o LDAP) continua a ser a fonte de referência para muitas decisões de identidade.
O papel do LDAP na arquitetura zero trust
O zero trust exige verificação contínua: todos os pedidos de acesso têm de ser autenticados e autorizados, independentemente da localização na rede. O LDAP situa-se num ponto crítico deste modelo, porque é frequentemente o sistema que responde a esses pedidos de verificação.
O desafio é que o LDAP não foi concebido com os princípios do zero trust em mente. Pressupõe adjacência de rede, utiliza ligações persistentes e, na sua forma não cifrada, expõe as credenciais em trânsito. Integrar o LDAP numa arquitetura zero trust exige controlos compensatórios:
- LDAPS obrigatório
- regras de firewall rigorosas
- limitação dos sistemas que podem aceder à porta 636
- imposição da assinatura LDAP
- monitorização das tentativas de bind para detetar padrões anómalos
O LDAP não é incompatível com o zero trust, mas exige um reforço deliberado da segurança para o permitir. As organizações que tratam o LDAP como um componente legado e o deixam sem configurar estão a criar precisamente o tipo de confiança implícita que o zero trust pretende eliminar.
Gestão de segredos em DevOps e CI/CD
Os pipelines automatizados colocam um desafio específico ao LDAP. Os sistemas de CI/CD (Jenkins, GitLab CI, runners do GitHub Actions) precisam frequentemente de se autenticar no LDAP para aceder a recursos internos. Essa autenticação envolve tipicamente uma conta de serviço: um bind DN dedicado com uma palavra-passe estática.
As credenciais estáticas de contas de serviço são um risco persistente. Raramente são rodadas, são frequentemente partilhadas entre pipelines e, quando aparecem em logs de compilação ou em ficheiros de configuração, são difíceis de detetar e revogar. A solução é gerir estas credenciais através de um gestor de segredos dedicado, em vez de as inserir diretamente na configuração dos pipelines.
Riscos de segurança críticos do LDAP em 2026
O LDAP não é apenas um protocolo legado com riscos teóricos. É uma superfície de ataque ativa, com vulnerabilidades documentadas e exploradas.
A ameaça do roubo de credenciais e do ransomware
De acordo com a IBM, no X-Force Threat Intelligence Index 2026, a recolha de credenciais foi o impacto de ataque mais comum observado em 2025. Os agentes de ameaça recolheram dados de início de sessão através de phishing e infostealers e confundiram-se depois com os fluxos normais de autenticação para se movimentarem lateralmente. As credenciais de contas de serviço LDAP encaixam precisamente neste padrão: são reutilizadas entre aplicações, raramente rodadas e quase nunca monitorizadas quanto a atividade de bind anómala.
A cadeia de ataque está bem documentada: comprometer uma credencial LDAP através de phishing ou password spraying, utilizá-la para enumerar o diretório, identificar contas privilegiadas e escalar privilégios. O Digital Defense Report da Microsoft tem associado de forma consistente o comprometimento de credenciais AD/LDAP à distribuição de ransomware. O diretório é um mapa da estrutura de acessos de toda a organização, e os atacantes leem-no antes de agir.
Vulnerabilidades recentes: CVE-2025-26663 e CVE-2025-54918
Duas vulnerabilidades críticas divulgadas em 2025 demonstram que a superfície de ataque do LDAP está a expandir-se ativamente.
CVE-2025-26663 é uma vulnerabilidade de execução remota de código por use-after-free no LDAP do Windows, divulgada em abril de 2025. Um atacante pode explorar uma falha de gestão de memória no serviço LDAP do Windows (concretamente em wldap32.dll) para executar código arbitrário num servidor-alvo sem credenciais válidas.
O ataque requer apenas acesso de rede ao serviço LDAP. Os controladores de domínio, que expõem o LDAP por conceção, são os alvos principais. Os controladores de domínio sem correção e afetados por esta vulnerabilidade ficam, na prática, abertos à execução remota de código (RCE) sem autenticação a partir de qualquer sistema que consiga alcançar a porta 389 ou 636.
CVE-2025-54918, divulgada em setembro de 2025, é uma vulnerabilidade de escalada de privilégios que combina o NT LAN Manager relay com autenticação coagida para contornar as proteções de channel binding e de assinatura LDAP. Um atacante com uma conta de domínio com poucos privilégios pode forçar um controlador de domínio a autenticar-se num sistema controlado pelo atacante, manipular em trânsito os pacotes de autenticação NTLM e retransmitir a autenticação modificada para o controlador de domínio, o que lhe confere acesso ao nível SYSTEM. O ataque é particularmente perigoso porque contorna controlos em que as organizações habitualmente confiam como medidas de reforço da segurança.
Boas práticas para proteger o LDAP em ambientes empresariais
A lista de verificação seguinte reúne os controlos mínimos para uma implementação LDAP em produção. São recomendações que respondem a um vetor de ataque específico e documentado.
- Imponha o LDAPS na porta 636. Desative o LDAP em texto em claro na porta 389 em todo o tráfego de produção. Configure certificados TLS emitidos pela CA interna ou por uma CA pública de confiança.
- Ative a assinatura LDAP e o channel binding. Impede ataques de relay. É necessário para a mitigação da CVE-2025-54918, mas note-se que a CVE-2025-54918 contorna estes controlos em sistemas sem correção, pelo que a aplicação de correções continua a ser obrigatória.
- Aplique todas as atualizações de segurança do Windows. A CVE-2025-26663 e a CVE-2025-54918 já têm correções. Os controladores de domínio sem a correção aplicada são a prioridade máxima de correção.
- Restrinja o acesso ao LDAP por IP. Só os sistemas que precisam legitimamente de consultar o LDAP devem conseguir alcançar a porta 636. As regras de firewall devem impor esta restrição, e não apenas pressupostos de segmentação de rede.
- Audite as credenciais das contas de serviço. Identifique todos os bind DN em utilização no ambiente. Rode as palavras-passe periodicamente. Remova as contas que já não são necessárias.
- Monitorize as tentativas de bind. Padrões de bind invulgares (falhas repetidas, binds a partir de endereços IP de origem inesperados, binds a horas atípicas) são indicadores precoces de credential stuffing ou de movimento lateral.
- Desative os binds LDAP anónimos. As consultas anónimas permitem a enumeração, sem autenticação, do conteúdo do diretório. A maioria das implementações modernas não tem nenhuma utilização legítima para binds anónimos.
- Separe as contas de serviço por finalidade. Uma conta de serviço utilizada por uma VPN não deve ter as mesmas permissões que uma utilizada por um sistema de cópias de segurança. O princípio do menor privilégio aplica-se também às contas de bind do LDAP.
Simplificar o acesso empresarial com a integração LDAP do Passwork

A carga operacional da gestão de acessos baseada em LDAP acumula-se ao longo do tempo. Os utilizadores mudam de equipa, entram em projetos e deixam a organização, e cada transição exige alterações de acesso em vários sistemas. Quando essas alterações são manuais, ficam atrasadas. As contas permanecem ativas mais tempo do que deviam. As credenciais acumulam-se em locais que ninguém está a acompanhar.
O Passwork liga-se diretamente ao Active Directory ou a qualquer diretório compatível com LDAP e mapeia automaticamente a pertença a grupos para o acesso aos cofres:
- Adicionar um utilizador ao grupo SRE no AD: as credenciais corretas surgem no respetivo cofre do Passwork, sem necessidade de uma ação de administração separada
- Remover o utilizador do grupo: o acesso é revogado
- O diretório continua a ser a fonte única de verdade sobre quem tem acesso a quê
Em ambientes autoalojados, o Passwork é implementado inteiramente no perímetro da própria organização. As credenciais nunca o abandonam. O SSO por SAML é compatível a par do LDAP, pelo que as equipas que utilizam ambos os protocolos em diferentes camadas de aplicação não precisam de reconstruir a arquitetura de identidade.
Cada leitura, escrita, partilha e exportação fica registada no registo de auditoria, o que é relevante tanto para as revisões de segurança internas como para demonstrar conformidade com o SOC 2 CC6.1 e com o artigo 32.º do RGPD.
Conclusão
O LDAP não vai desaparecer. O mercado de software de diretório foi avaliado em 8,4 mil milhões de dólares em 2025 e deverá atingir 19,7 mil milhões de dólares até 2034, de acordo com a investigação de mercado da Dataintelo, um valor que reflete o investimento empresarial continuado em infraestrutura de diretório, e não uma tecnologia em declínio. Com 90 % das empresas ainda a utilizar o Active Directory, o LDAP continua a ser o elemento de ligação da gestão de identidades empresariais.
O que mudou foi o ambiente de ameaças. A CVE-2025-26663 e a CVE-2025-54918 são vulnerabilidades com correção disponível que visam os serviços LDAP que os controladores de domínio expõem neste momento.
A ação prática é simples: impor o LDAPS, corrigir os controladores de domínio, auditar as credenciais das contas de serviço e garantir que as alterações de acesso no diretório se propagam automaticamente aos sistemas que dependem dele. A gestão manual de acessos, à escala em que a maioria das empresas opera, é onde surgem as lacunas.
Perguntas frequentes sobre o LDAP

Para que serve o LDAP?
O LDAP é utilizado para autenticar utilizadores e consultar informação de diretório (pertença a grupos, endereços de e-mail, atributos de contas) em aplicações empresariais. Os casos de utilização comuns incluem a autenticação em VPN, a consulta de utilizadores em servidores de e-mail, o SSO de aplicações e a gestão centralizada de utilizadores. A maioria das aplicações empresariais que precisam de verificar a identidade num diretório empresarial utiliza o LDAP.
Qual é a diferença entre o LDAP e o Active Directory?
O LDAP é um protocolo aberto (RFC 4511) para aceder a serviços de diretório. O Active Directory é o serviço de diretório da Microsoft, que utiliza o LDAP como um dos seus protocolos de acesso. O AD também utiliza Kerberos para a autenticação no Windows. É possível utilizar o LDAP sem o Active Directory (por exemplo, através do OpenLDAP), mas o Active Directory depende do LDAP para servir consultas de diretório a aplicações não Windows.
O que é o LDAPS e porque é que é importante?
O LDAPS é o LDAP sobre TLS, na porta 636. O LDAP padrão na porta 389 transmite as credenciais em texto em claro, o que as torna visíveis para qualquer pessoa que consiga intercetar o tráfego de rede. O LDAPS cifra toda a sessão. Em 2026, executar LDAP sem cifragem em produção é indefensável: a Microsoft aplica requisitos de assinatura LDAP e de channel binding desde 2020, e tanto a CVE-2025-26663 como a CVE-2025-54918 visam diretamente serviços LDAP.
O LDAP ainda é utilizado em 2026?
Sim. O Active Directory, que assenta no LDAP, está implementado em cerca de 90 % das empresas a nível mundial. A adoção da nuvem não o substituiu: a maioria das organizações utiliza ambientes híbridos em que o AD das instalações continua a ser a fonte de identidade de referência. O LDAP está também incorporado em milhares de aplicações que se autenticam em diretórios empresariais e não será substituído por SAML ou OAuth sem uma reengenharia significativa.
Como se enquadra o LDAP numa arquitetura zero trust?
O LDAP pode ser compatível com o zero trust se for corretamente reforçado. O zero trust exige a verificação contínua de cada pedido de acesso, e o LDAP é frequentemente o sistema que responde a esses pedidos. Os requisitos: impor o LDAPS (porta 636), ativar a assinatura e o channel binding, restringir o acesso ao diretório por IP de origem, monitorizar as tentativas de bind e rodar regularmente as credenciais das contas de serviço. A configuração predefinida do LDAP não é compatível com o zero trust, mas o protocolo em si não é o obstáculo.
Quais são os principais riscos de segurança do LDAP?
Os riscos principais são a exposição de credenciais em ligações não cifradas (porta 389), o roubo de credenciais de contas de serviço, os ataques de NTLM relay (CVE-2025-54918) e a RCE sem autenticação através de vulnerabilidades de corrupção de memória (CVE-2025-26663). O X-Force Threat Intelligence Index 2025 da IBM concluiu que os ataques baseados em identidade, muitos deles dirigidos a credenciais de diretório, representaram 30 % de todas as intrusões em 2024. A aplicação de correções, a imposição do LDAPS e a higiene das contas de serviço respondem à maioria destes riscos.
O LDAP pode ser substituído por SAML ou OAuth?
Não totalmente. O SAML e o OAuth tratam, respetivamente, da autenticação federada baseada em navegador e da autorização de APIs. O LDAP trata das consultas ao diretório e da autenticação de aplicações em sistemas que não conseguem comunicar em SAML. A maioria dos ambientes empresariais utiliza os três protocolos em diferentes camadas da pilha aplicacional. A questão não é qual escolher: é saber que aplicações exigem LDAP e se essas ligações estão devidamente protegidas.





