Como configurar a autenticação LDAP externa para o Zimbra

Que alterações ocorrem na autenticação LDAP externa no Zimbra?

A autenticação LDAP externa permite que o Zimbra verifique a senha de um usuário em outro diretório, em vez da senha armazenada no LDAP interno do Zimbra. O Guia do Administrador do Zimbra Daffodil (v10) atual afirma que a autenticação LDAP externa é configurada por domínio e que o método externo tenta se conectar ao diretório especificado com as credenciais de usuário fornecidas. Se a conexão for bem-sucedida, a senha é considerada válida.

Isso não transforma automaticamente um diretório LDAP externo no banco de dados de contas do Zimbra. O Zimbra ainda armazena os dados de conta específicos do Zimbra em seu próprio diretório. O guia da versão 10 observa explicitamente que os usuários normalmente precisam existir tanto no Zimbra quanto no diretório externo, a menos que você configure o provisionamento automático separadamente.

Para obter a documentação atual do produto, consulte o Guia do Administrador do Zimbra Daffodil v10 e o Guia de Configuração do Zimbra v10 .

Lista de verificação para planejamento rápido

• Confirme o domínio Zimbra que deseja alterar, por exemplo example.com.
• Confirme se os mesmos usuários já existem no Zimbra ou planeje o provisionamento automático separadamente.
• Saiba o nome do host LDAP externo, a porta, o método TLS e a cadeia de certificados.
• Saiba como um nome de login do Zimbra é mapeado para um DN de usuário no LDAP.
• Se o DN não puder ser construído diretamente a partir do nome de login, prepare uma base de pesquisa, um filtro de pesquisa e uma conta de pesquisa com privilégios mínimos.
• Mantenha uma sessão de administrador do Zimbra aberta durante os testes para que você possa reverter rapidamente.

Escolha primeiro o método de mapeamento correto.

O Guia de Configuração v10 atual ainda define os atributos search-base, search-bind, search-filter e external-DN por conta. Materiais oficiais mais antigos do Centro Técnico do Zimbra explicam como esses mapeamentos são usados ​​na prática. Como esse material é anterior ao Daffodil, considere-o como informação operacional e verifique os detalhes com a sua versão instalada antes de aplicar uma migração em grande escala. Consulte as notas oficiais do Centro Técnico do Zimbra sobre LDAP externo .

Passo 1: Registre as configurações de autenticação de domínio atuais.

Execute comandos administrativos como o zimbrausuário do sistema operacional. Antes de alterar qualquer coisa, capture os valores de domínio existentes:

su - zimbra

zmprov gd example.com \
  zimbraAuthMech \
  zimbraAuthLdapURL \
  zimbraAuthLdapBindDn \
  zimbraAuthLdapSearchBase \
  zimbraAuthLdapSearchFilter \
  zimbraAuthFallbackToLocal

Salve a saída no seu registro de alterações. O Guia de Configuração v10 lista os valores válidos para zimbraAuthMech, incluindo zimbra, ldap, ad, e mecanismos Kerberos ou personalizados. Para este guia, o mecanismo de destino é ldap.

Passo 2: Verifique a conectividade da rede e o TLS antes de alterar o Zimbra.

Não tente solucionar problemas de mapeamento de autenticação até que a conectividade básica esteja funcionando. No servidor Zimbra, confirme a resolução de DNS e se o endpoint LDAP está acessível. Para LDAPS, você pode inspecionar a cadeia de certificados com o OpenSSL.

openssl s_client -connect ldap.example.net:636 \
  -servername ldap.example.net -showcerts

Para um diretório que utiliza LDAP padrão com StartTLS, teste o endpoint compatível com StartTLS usando um cliente LDAP apropriado para o seu sistema operacional. Se o cliente ldapsearchestiver instalado, uma verificação de conta de pesquisa pode ser feita da seguinte forma:

ldapsearch -x -H ldap://ldap.example.net:389 -ZZ \
  -D "cn=zimbra-search,ou=svc,dc=example,dc=net" -W \
  -b "ou=people,dc=example,dc=net" \
  "(uid=alice)" dn

O Guia do Administrador do Zimbra v10 afirma que um ldaps:endpoint requer que o certificado do servidor LDAP seja confiável para o Zimbra. Não ignore a validação do certificado apenas para que o teste seja aprovado. Instale a CA ou a cadeia de certificados apropriada de acordo com o procedimento de armazenamento de certificados confiáveis ​​para a sua versão específica do Zimbra.

Etapa 3: Configure um modelo de DN de vinculação direta quando os DNs do usuário forem previsíveis.

Este é o padrão mais simples. Suponha que o diretório externo armazene usuários como uid=alice,ou=people,dc=example,dc=nete o login do Zimbra seja alice@example.com. Configure o domínio da seguinte forma:

zmprov md example.com zimbraAuthMech ldap

zmprov md example.com \
  zimbraAuthLdapURL "ldaps://ldap.example.net:636"

zmprov md example.com \
  zimbraAuthLdapBindDn "uid=%u,ou=people,dc=example,dc=net"

O Guia do Administrador descreve zimbraAuthLdapBindDnuma string de formato usada para determinar o DN usado para a vinculação externa. A documentação oficial do Centro Técnico do Zimbra descreve valores de substituição comuns, como %upara a parte local do nome de login e %npara o nome de login completo.

Use um modelo de DN somente quando ele identificar deterministicamente o objeto de diretório correto. Se os usuários estiverem localizados em unidades organizacionais diferentes ou se o DN deles não for derivado do nome de login, use o padrão de filtro de pesquisa.

Etapa 4: Use o mapeamento de filtro de pesquisa quando o DN não puder ser construído diretamente.

O mapeamento de filtro de pesquisa permite que o Zimbra primeiro localize a entrada do usuário e, em seguida, autentique-se com base no DN retornado. O Guia de Configuração v10 define os atributos de domínio necessários relacionados à pesquisa.

Uma configuração típica no estilo OpenLDAP é:

zmprov md example.com \
  zimbraAuthLdapSearchBase "ou=people,dc=example,dc=net"

zmprov md example.com \
  zimbraAuthLdapSearchFilter "(uid=%u)"

zmprov md example.com \
  zimbraAuthLdapSearchBindDn \
  "cn=zimbra-search,ou=svc,dc=example,dc=net"

Para evitar inserir a senha de um diretório diretamente no histórico do shell, leia-a primeiro para uma variável temporária do shell:

read -s LDAP_BIND_PASSWORD
zmprov md example.com \
  zimbraAuthLdapSearchBindPassword "$LDAP_BIND_PASSWORD"
unset LDAP_BIND_PASSWORD

A conta de pesquisa deve ter apenas o acesso de leitura necessário para encontrar usuários na base configurada. Ela não precisa de amplos privilégios de administração de diretório.

Para o Active Directory, um filtro pode usar `<nome_do_usuário>` sAMAccountNameou userPrincipalName`<nome_do_usuário>`, dependendo da sua convenção de login. O Zimbra também fornece um mecanismo de autenticação externo para o Active Directory; portanto, use o mecanismo específico do AD quando ele se adequar melhor à sua implementação, em vez de forçar todos os ambientes do AD a usar configurações LDAP genéricas.

Etapa 5: Verifique o que o Zimbra realmente armazenou.

Leia novamente os atributos do domínio após a alteração:

zmprov gd example.com \
  zimbraAuthMech \
  zimbraAuthLdapURL \
  zimbraAuthLdapBindDn \
  zimbraAuthLdapSearchBase \
  zimbraAuthLdapSearchFilter \
  zimbraAuthLdapSearchBindDn \
  zimbraAuthFallbackToLocal

Verifique se há erros de citação, um DN base incorreto, um nome de host inesperado ou um mapeamento antigo remanescente de uma tentativa anterior. Não imprima a senha de busca e vinculação em documentação, capturas de tela, tickets ou transcrições do shell.

Etapa 6: Teste com um usuário controlado antes da implementação em larga escala.

Escolha uma conta de teste sem privilégios de administrador que exista tanto no Zimbra quanto no diretório externo. Teste esses casos cuidadosamente:

• A senha LDAP externa correta permite o login no Zimbra.
• Uma senha LDAP externa incorreta foi rejeitada.
• Uma conta de diretório desativada ou bloqueada comporta-se de acordo com a sua política de diretório.
• Uma conta Zimbra que não existe não pode fazer login a menos que o provisionamento automático tenha sido configurado.
• Uma falha no servidor LDAP ou na rede produz o comportamento de falha esperado.

O último teste é importante porque zimbraAuthFallbackToLocalse trata de uma opção de domínio separada. A documentação da versão 10 indica que o padrão é FALSE. Habilitar o fallback pode ser útil para uma migração cuidadosamente planejada, mas também pode frustrar a expectativa de que desabilitar ou alterar uma senha no diretório externo bloqueie imediatamente o acesso se uma senha antiga do Zimbra local ainda for válida. Considere o fallback como uma decisão de política de segurança, não como uma opção genérica para solução de problemas.

Etapa 7: Decida se você também precisa de provisionamento automático.

A autenticação externa e o provisionamento de contas são funções diferentes. Se novos usuários do diretório devem receber contas Zimbra automaticamente, configure o provisionamento automático do Zimbra separadamente. O Guia do Administrador da versão 10 documenta os modos EAGER, LAZY e MANUAL e seus respectivos zimbraAutoProv*atributos.

Não reutilize indiscriminadamente as configurações de autenticação para o provisionamento automático. O provisionamento automático possui opções separadas para URL, vinculação, base de pesquisa, filtro, mapeamento de nome de conta e mapeamento de atributos. Primeiro, torne a autenticação externa confiável para um usuário existente; em seguida, projete o provisionamento como uma alteração subsequente.

Padrões comuns de falhas e o que verificar

Plano de reversão

Se a configuração do diretório externo impedir a autenticação normal do usuário, altere o domínio de volta para a autenticação interna do Zimbra usando uma sessão de administrador que já esteja aberta:

zmprov md example.com zimbraAuthMech zimbra

Em seguida, verifique o valor:

zmprov gd example.com zimbraAuthMech

Não exclua os atributos LDAP externos durante um rollback de emergência, a menos que tenha um motivo para isso. Mantê-los permite inspecionar o que falhou e tentar novamente após corrigir o problema de mapeamento ou TLS.

Resumo de referência prática

• zimbraAuthMech: seleciona o mecanismo de autenticação para o domínio.
• zimbraAuthLdapURL: ponto de extremidade LDAP externo; usar ldaps:para LDAP sobre SSL.
• zimbraAuthLdapBindDn: formato usado para construir o DN do usuário para vinculação direta.
• zimbraAuthLdapSearchBase: subárvore na qual o Zimbra procura o usuário externo.
• zimbraAuthLdapSearchFilterFiltro LDAP usado para localizar o usuário.
• zimbraAuthLdapSearchBindDne zimbraAuthLdapSearchBindPassword: credenciais usadas para a pesquisa quando a busca anônima não é apropriada.
• zimbraAuthLdapExternalDnMapeamento DN externo explícito para uma única conta Zimbra.
• zimbraAuthFallbackToLocal: controla se o Zimbra recorrerá à autenticação local caso a autenticação externa falhe.

Lista de verificação de validação final

• O endpoint LDAP externo pode ser acessado a partir do servidor de caixa de correio Zimbra.
• A validação do certificado TLS é bem-sucedida sem soluções alternativas inseguras.
• O modelo bind-DN ​​ou filtro de pesquisa escolhido mapeia um login para exatamente uma entrada de diretório.
• O usuário de teste existe no Zimbra ou o provisionamento automático está configurado intencionalmente.
• Os testes de senha correta e incorreta se comportam conforme o esperado.
• O comportamento alternativo está de acordo com sua política de segurança.
• As configurações originais do domínio e o comando de reversão estão documentados.

Para alterações em produção, prefira uma implementação gradual com um domínio de teste ou um pequeno grupo de usuários. A autenticação LDAP externa é simples quando o mapeamento de identidades é previsível; as falhas mais complexas decorrem do mapeamento de nomes distintos (DNs), da confiança em certificados ou da confusão entre autenticação e provisionamento de contas.