Por: @jonasc
Publicado em: 2021-03-26

Suporte a autenticação de domínio windows AD (NTLM) para o SSO

Quando um máquina já está logada no domínio Windows, é possível autenticar o usuário sem pedir login e senha. O objetivo deste laboratório é estudar a melhor tecnologia para implementar a autenticação. Para isso, algumas ferramentas foram estudadas:

  • Apache:
    • mod_auth_ntlm / SSPI NTLM
    • mod_auth_ntlm_winbind
    • mod_auth_ntlm_kerb
    • mod_auth_gssapi
  • Nginx
    • Módulo NTLM
  • Squid
    • Como é feito no firewall v2
  • Via aplicação Web
    • Avaliar se existe alguma LIB que fala NTLM com navegador

Topologia

Topologia de rede padrão com FWFLEX. Requisitos mínimos: 1x LAN e 1x WAN. 1x Windows server AD na LAN e 1x cliente Windows na LAN integrado com AD.

Instalação

mod_auth_ntlm / SSPI NTLM

Instalado direto de um projeto não oficial do GitHub: https://github.com/TQsoft-GmbH/mod_authn_ntlm

Foi simplesmente copiado o binário.

mod_auth_ntlm_winbind

Não possui pacote para CentOS 8. Foi compilado a partir do repo oficial do samba.org.

Dependências:

yum install httpd php httpd-devel "@Development Tools" krb5-workstation samba-common authconfig samba-winbind samba-winbind-clients

Clonar os arquivos de https://www.samba.org/ftp/unpacked/lorikeet/mod_auth_ntlm_winbind/ e rodar os comandos abaixo.

autoconf
./configure
apxs -DAPACHE2 -c -i mod_auth_ntlm_winbind.c

mod_auth_ntlm_kerb

Não possui pacote para CentOS 8. Está sendo descontinuado e substituído pelo mod_auth_gssapi.

Seria possível compilar manualmente, mas não seguimos com esta ferramenta, por estar depreciada.

mod_auth_gssapi

O mais recente para Kerberos, isntalado via Yum:

yum install mod_auth_gssapi

Nginx

Disponível só na versão premium. Inviável.

Squid

Necessário instalar squid e samba/winbind igual é feito no v2.

Configuração

Devido a dificuldade para instalação dos módulos, seguimos a configuração apenas do mod_auth_ntlm_winbind e mod_auth_gssapi.

mod_auth_ntlm_winbind

Necessário ativar KeepAlive no Apache httpd.conf

KeepAlive On
MaxKeepAliveRequests 1000
KeepAliveTimeout 600

Dentro do vHost, configurar autenticação NTLM com helper ntlmssp:

    #Require all granted
    NTLMAuth on
    AuthType NTLM
    AuthName "NTLM Authentication"
    NTLMAuthHelper "/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp"
    #NTLMAuthHelper "/usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic"
    #NegotiateAuthHelper "/usr/bin/ntlm_auth --helper-protocol=gss-spnego"
    #NTLMBasicAuthoritative on
    Require valid-user
    #AuthType Negotitate
    #NegotiateAuth on

OBS: Os helpers basic e spnego foram testados, mas não funcionaram.

mod_auth_gssapi

Na teoria a configuração é relativamemte simples:

    AuthType GSSAPI
    AuthName "GSSAPI Single Sign On Login"
    GssapiBasicAuth On
    GssapiCredStore keytab:/etc/httpd/apache.keytab

    GssapiBasicAuthMech ntlmssp
    #GssapiBasicAuthMech krb5

    require valid-user

    #GssapiNegotiateOnce On
    #GssapiSSLonly Off
    #GssapiLocalName On
    #GssapiUseSessions On
    #GssapiDelegCcacheDir /run/httpd/clientcaches
    #GssapiPublishErrors On
    #GssapiAcceptorName HTTP@{HOSTNAME}
    #GssapiUseSessions On
    #Session On
    #SessionCookieName gssapi_session path=/private;httponly;secure;

A diferença é que o GSSAPI se autentica através de uma chave gerada para o usuário no Windows server, em vez de login e senha.

O GSSAPI é um recurso que negocia com o cliente o mecanismos de autenticação suportado (pode ser NTLM, krb5, iakerb). O GssapiBasicAuthMech pode ser usado para forçar um mecanismo específico.

As demais opções de sessão comentadas acima foram testadas, mas não surtiram efeito.

Para gerar a chave, executar o Powershell como Administrador no Windows Server:

ktpass -princ HTTP/jonasc-fwflex.itflex-eng.local@ITFLEX-ENG.LOCAL -mapuser admin@ITFLEX-ENG.LOCAL -crypto ALL -ptype KRB5_NT_PRINCIPAL -pass semprelinux -out c:\kerberos.keytab

O usuário admin precisa suportar Kerberos. Active Directory Users and Computers > Users > admin > properties > Account > This account supports AES 128 / 256 bit encryption.

O usuário admin precisa estar habilitado para delegação Active Directory Users and Computers > Users > admin > properties > Delegation > Trust this user for delegation to any service.

Caso for implementar o mecanismo do Kerberos, também é necessário configurar trusted URI no navegador do cliente. No Internet Explorer, Edge e Chrome, é definido no Local Intranet Sites, nas Opções da Internet do Windows. No firefox, é necessário configurar em about:config:

network.negotiate-auth.delegation-uris
network.negotiate-auth.trusted-uris

Resultados

O mod_auth_ntlm_winbind funcionou autenticação, porém pede login e senha para o usuário (não resolveu o problema).

O mod_auth_gssapi não funcionou. Os logs em modo debug não trazem muita informação. Por ser um recurso novo, tem pouca documentação. Foi encontrado apenas um artigo na Red Hat (acesso restrito).

Mesmo que um dos recursos acima funcionasse, ainda teria o trabalho do motor do SSO guardar a informação de qual usuário autenticou. Também não foi encontrado nenhuma biblioteca que fizesse o intermédio NTLM entre navegador e AD.

Nesse sentido, nenhuma ferramenta foi considerada viável. Optamos pela estratégia de prolongar o tempo de sessão do usuário que autenticou no SSO e manter a sessão com base nos cookies do navegador.

Copyright © iTFLEX Tecnologia Ltda 2019