Então, consegui descobrir como fazer isso finalmente.
A primeira tarefa para obter esse trabalho foi obter o controlador de domínio configurado como uma autoridade de certificação. Para fazer isso, segui este vídeo: link
Depois que consegui me conectar ao AD na porta 636, tive que configurar o openldap na máquina do CentOS para usar essa porta. Imaginei que, se conseguisse fazer o ldapsearch fazer uma consulta ao AD na porta 636, a etapa final seria fazer com que o tac_plus fizesse o mesmo. Para configurar o openldap, tudo o que eu precisava fazer era editar o arquivo /etc/openldap/ldap.conf
.
Eu modifiquei três campos; BASE, URI e adicionou a linha "TLS_REQCERT allow"
.
O campo BASE foi importante para ficar correto. Deve ser o formato adequado e apontar para onde suas contas de usuário são encontradas no AD. O meu foi: "CN=users, DC=ent, DC=local"
.
O campo URI também foi importante para ficar correto. Eu usei o nome de domínio totalmente qualificado para o servidor e o número da porta. Acabou sendo: "ldaps://dc1-ent.ent.local:636"
.
A linha "TLS_REQCERT allow"
permite que a máquina do CentOS solicite um certificado do Controlador de Domínio como parte do processo de estabelecer uma sessão com o servidor. Isso é semelhante a como o SSH implementa seu algoritmo de troca de chaves ao estabelecer uma sessão SSH com um host remoto.
Então usei o seguinte comando ldapsearch para verificar se funciona:
ldapsearch -D "[email protected]" -W -p 636 -h ldaps://dc1-ent.ent.local -b "CN=users, DC=ent, DC=local" -s Sub -x -ZZ "(objectclass=*)" -d1
A opção -d1
no comando acima permite saída de depuração detalhada para que eu possa ver a troca da chave pública do servidor a ser usada para criptografar a sessão.
Tudo funcionou de lá em diante. Consegui usar o wireshark para capturar o tráfego e confirmar que uma sessão TLS criptografada foi estabelecida no momento da autenticação. Eu acredito que este método de autenticação com AD é conhecido como PEAP. Eu não me preocupei em trabalhar com EAP-TLS ou EAP-TTLS.