A maioria das organizações gerencia a identidade do usuário em um diretório LDAP ou AD. Quando uma nova aplicação entra em operação, a mesma pergunta surge novamente: como essa aplicação se conectará ao diretório, como autenticará o usuário, qual informação de grupo lerá e onde tomará a decisão de acesso? Se essa conexão for feita separadamente em cada aplicação, a arquitetura de identidade rapidamente se dispersa.
A integração LDAP por aplicação gera dívida operacional. Cada aplicação carrega sua própria conta de serviço, endereço de conexão, filtro de busca, valor de timeout e configuração de validação de certificado. Quando o esquema do diretório muda, a estrutura de OU é movida, a senha da conta de serviço é rotacionada ou ocorre uma migração de domínio, essa alteração se propaga para muitas aplicações.
Do lado da segurança, o risco também cresce. O uso de LDAP sem criptografia pode levar ao transporte desprotegido de senhas na rede. As senhas de contas de serviço ficam armazenadas nas configurações das aplicações. A autorização baseada em grupos, por sua vez, dispersa-se pelo próprio código das aplicações; autenticação e política de acesso são aplicadas em sistemas diferentes com regras diferentes.
A auditoria e a visibilidade também se fragmentam. A informação sobre qual aplicação se conectou ao diretório com qual conta de serviço, qual usuário foi autenticado, qual grupo foi consultado e qual acesso foi negado costuma ficar enterrada nos logs das aplicações. As equipes de SOC e auditoria são forçadas a juntar logs dispersos em vez de um fluxo de identidade central.
O TR7 LDAP / AD Bind resolve esse problema na plataforma de acesso: métodos direct-bind e search-bind, transporte seguro LDAPS, consulta de pertinência a grupos, filtro de bind restriction, failover de múltiplos servidores e a política de acesso condicional do AAM unificam-se em uma única arquitetura.
O TR7 AAM trata a conexão LDAP/AD não apenas como validação de senha, mas como um fluxo de busca de usuário, consulta de grupos, transporte seguro e geração de política de acesso.
O direct-bind converte o nome de usuário no valor de bind principal por UPN, NetBIOS, UID, CN ou um padrão personalizado. O search-bind, por sua vez, procura a informação de DN do usuário com uma conta de serviço e, em seguida, faz a validação de bind com a própria senha do usuário.
No modo search-bind, a busca de grupos pode ser habilitada e as pertinências a grupos do usuário são adicionadas à sessão AAM. Essa informação de grupo pode ser usada em decisões de acesso à aplicação, exigência de MFA ou autorização baseada em backend.
O TR7 pode estabelecer uma conexão protegida por TLS via LDAPS. Ao configurar a validação de certificado e a política de certificado self-signed, o nível de segurança da conexão de diretório é definido de acordo com o padrão da organização.
Mais de um servidor LDAP/AD pode ser definido em uma única configuração. As conexões são distribuídas pelos métodos roundrobin, weighted ou failover; quando o servidor de diretório primário fica inacessível, um servidor alternativo pode ser acionado.
O LDAP / AD Bind conecta a validação de diretório corporativo ao fluxo AAM com templates de bind, filtros de busca, pertinência a grupos, transporte seguro e gerenciamento de múltiplos servidores.
No modo direct-bind, o nome de usuário é convertido no valor de bind principal por um dos templates UPN, NetBIOS, UID, CN ou custom. Em ambientes AD, os formatos UPN e NetBIOS são comuns; em diretórios OpenLDAP ou POSIX, os padrões UID e CN podem ser mais adequados. Com o padrão custom, é possível montar uma estrutura específica da organização como uid={{username}},ou=people,dc=company,dc=com. Essa flexibilidade facilita conectar diferentes esquemas de diretório a um único fluxo de validação AAM.
No modo search-bind, o TR7 primeiro conecta-se ao diretório com uma conta de serviço e procura a informação de DN do usuário. Quando o usuário é encontrado, no segundo passo a operação de bind é feita com o DN e a senha do próprio usuário. Esse modelo é útil em ambientes em que os usuários estão em OUs diferentes, em que o DN não pode ser gerado diretamente a partir do nome de usuário ou em que se requer um filtro de busca mais controlado. A conta de serviço e a base DN de busca são gerenciadas de forma centralizada.
O filtro de search-bind no modo automático pode avaliar em conjunto os campos userPrincipalName, sAMAccountName e cn. No modo custom, o operador define seu próprio filtro LDAP; por exemplo, pode-se fazer uma busca mais restrita como (sAMAccountName={{username}}). Essa abordagem adapta-se a diferentes esquemas de diretório e formatos de nome de usuário. Para reduzir correspondências de usuário incorretas, o filtro deve ser definido o mais claramente possível.
Mesmo que a senha do usuário esteja correta, pode não ser desejável que cada usuário do diretório acesse cada aplicação. Com o filtro de bind restriction, garante-se que apenas os usuários que satisfazem uma condição de OU, grupo ou atributo específica passem pelo fluxo de validação. Por exemplo, apenas os usuários do grupo VPN Users podem ser aceitos em determinado backend. Esse filtro avalia a autenticação em conjunto com o escopo de acesso.
Quando ldapEnableGroupSearch está ativo, o TR7 pode consultar as pertinências a grupos usando o valor de DN do usuário. Com ldapGroupSearchBase e ldapGroupFilter define-se em qual região do diretório e com qual filtro os grupos serão procurados. A lista de grupos retornada é adicionada à sessão AAM. Os fluxos de acesso condicional podem tomar decisões diferentes de aplicação, MFA, permissão ou negação com base nessa informação de grupo.
Quando o LDAPS é usado, a conexão LDAP é protegida com TLS e tipicamente opera pela porta 636. O comportamento de validação do certificado do servidor pode ser configurado com ajustes como sslValidateCertificate e sslAllowSelfSigned. Em ambiente de produção, o LDAP sem criptografia não deve ser preferido. A segurança da conexão de diretório é um requisito fundamental para proteger dados sensíveis como a senha do usuário e a conta de serviço.
Os valores de timeout de conexão e de operação LDAP podem ser configurados. Se a conexão não puder ser estabelecida ou o servidor de diretório responder lentamente, o fluxo AAM não aguarda indefinidamente. Comportamento lento de domain controller em horários de pico ou latência de segmento de rede podem ser controlados com esses valores. As configurações de timeout devem ser planejadas em conjunto com a experiência do usuário e o comportamento de failover.
O TR7 pode buscar usuários sob uma base de busca específica e transferir valores de atributos como e-mail e telefone para o perfil de usuário local do AAM. Campos como queryMailField e queryPhoneField podem ser ajustados de acordo com o esquema da organização. Esse recurso ajuda no gerenciamento da lista de usuários e das informações de contato. Em ambiente de cluster, a busca da lista de usuários é restringida para rodar apenas no primary node.
Mais de um servidor LDAP/AD pode ser definido no array hosts. O lbMethod pode ser selecionado como roundrobin, weighted ou failover. No modo failover, quando o servidor primário fica inacessível, ocorre a transição para o servidor alternativo. A abordagem de pool de conexões e circuit breaker reduz a chance de servidores continuamente falhos prejudicarem o fluxo.
Por qual namespace de rede se chegará ao servidor LDAP pode ser configurado. Isso é importante para domain controllers em segmento separado ou estruturas de diretório específicas de tenant. O tráfego de gerenciamento de acesso é transportado pela tabela de rotas correta e pelo isolamento de rede adequado. Em arquiteturas multi-tenant ou de data centers segregados, proporciona um controle de rede mais claro.
O LDAP / AD Bind é operado em conjunto com o ciclo de vida da conexão, a segurança de filtros, a limpeza de conexões, o comportamento de search-bind, a restrição de cluster e a seleção de atributos.
Quando as configurações LDAP são atualizadas, a informação de conexão é preparada novamente e o fluxo de validação roda com as novas configurações. A informação de conexão é gerada a partir dos parâmetros protocol, host, port, TLS e timeout. A aplicação das alterações de configuração dentro de um ciclo de vida centralizado garante consistência de configuração.
Antes de as entradas do usuário serem colocadas no filtro LDAP, os caracteres especiais são escapados. Valores como barra invertida, asterisco, parênteses e caractere nulo são escapados para reduzir o risco de LDAP injection. Esse comportamento é especialmente crítico em estruturas que usam filtro custom.
Depois de usada, a conexão LDAP tem o cliente limpo e os listeners removidos. Essa abordagem reduz conexões zombie e uso desnecessário de memória. O comportamento de keep-alive de longa duração deve ser usado apenas em modos especiais como a busca da lista de usuários.
O filtro de search-bind automático pode avaliar em conjunto os campos userPrincipalName, sAMAccountName e cn. No modo de filtro custom, o operador define seu próprio filtro LDAP. O filtro custom é poderoso; no entanto, como filtros incorretamente amplos podem levar a correspondências de usuário inesperadas, devem ser projetados com cuidado.
A estrutura de nova geração do pool do backend LDAP pode gerenciar as conexões de cliente LDAP com lógica de pool. Quando o LDAPS é selecionado, as opções de TLS são adicionadas ao estabelecimento da conexão. O tempo de DNS lookup personalizado e os valores de timeout de conexão ganham importância em redes lentas ou segmentadas.
A busca da lista de usuários é restringida para rodar apenas no primary node em ambiente de cluster. Esse comportamento impede que a mesma lista de usuários seja buscada simultaneamente por múltiplos nós e gere carga desnecessária. Já o fluxo de bind de autenticação continua funcionando de acordo com o modelo de conexão definido.
Com o array ldapAttributes define-se quais campos retornam do diretório. Os campos padrão podem abranger valores como dn, cn, userPrincipalName, displayName, mail e telefone. Campos adicionais como department, employeeID ou atributos personalizados podem ser adicionados à lista conforme a necessidade da organização.
Em uma grande organização, os funcionários acessam as aplicações via AAM com o nome de usuário e a senha AD existentes. As pertinências a grupos são transferidas para a política AAM; grupos de finanças, RH e TI podem ser direcionados a diferentes fluxos de aplicação ou MFA. Quando a política de senhas do AD muda, as aplicações não são atualizadas uma a uma.
Em uma estrutura com dois domain controllers em dois data centers, o TR7 pode estabelecer conexão pelo método failover. Quando o servidor de diretório primário fica inacessível, ocorre a transição para o servidor alternativo. O fluxo de validação de usuário não fica dependente da falha de um único DC.
Determinado backend pode ser aberto apenas aos usuários do grupo VPN Users. Mesmo que o bind seja bem-sucedido, o usuário que não passa pela condição bindRestrictionFilter é rejeitado. Assim, a validação de senha e a autorização de acesso à aplicação não são consideradas a mesma coisa.
Organizações que usam OpenLDAP em vez de AD podem fazer a validação de usuário com os templates de bind UID ou CN. Em diretórios baseados em posixAccount, o mapeamento de e-mail, telefone e atributos personalizados pode ser transferido para o perfil AAM. Estabelecendo uma conexão segura com LDAPS, diretórios LDAP clássicos são incluídos no fluxo de acesso moderno.
Conexão LDAP/AD, política baseada em grupos, transporte seguro LDAPS e auditoria centralizada em uma única plataforma. Vamos guiá-lo por uma instalação ao vivo no seu próprio ambiente.