🥇Freeradius + Google Authenticator + LDAP + Fortigate

Como proceder se a autenticação de dois fatores é desejada, mas não há dinheiro para tokens de hardware, e no geral, recomenda-se manter o bom humor.

Esta solução não é nada superoriginal, mas sim uma mistura de várias soluções encontradas na internet.

Então, temos

Domínio Active Directory.

Usuários de domínio que trabalham via VPN, como muitos hoje em dia.

O gateway VPN é Fortigate.

Salvar a senha para o cliente VPN é proibido pela política de segurança.

A política Fortinet em relação a tokens próprios não pode ser chamada de menos que mesquinha — há 10 tokens gratuitos, os outros têm um preço bastante exorbitante. Não considerei RSASecureID, Duo e similares, pois procuro por soluções de código aberto.

Requisitos prévios: host *nix com freeradius instalado sssd, — adicionado ao domínio, os usuários de domínio podem autenticar-se confortavelmente nele. Pacotes adicionais:

shellinabox figlet, freeeradius-ldap, , fonterebel.tlf do repositório No meu exemplo — CentOS 7.8. https://github.com/xero/figlet-fonts.

A lógica de funcionamento é a seguinte: ao se conectar à VPN, o usuário deve inserir o login do domínio e o OTP em vez da senha.

Configuração dos serviços

muda apenas o usuário e o grupo sob os quais

Em /etc/raddb/radiusd.conf , já que o serviço sssdradiusd deve ser capaz de ler arquivos em todos os subdiretórios user = root group = root /home/.

Para que você possa usar grupos nas configurações

, é necessário passar FortigateVendor Specific Attribute . Para isso, no diretórioraddb/policy.d crio um arquivo com o seguinte conteúdo: group_authorization { if (&LDAP-Group[*] == "CN=vpn_admins,OU=vpn-groups,DC=domain,DC=local") { update reply { &Fortinet-Group-Name = "vpn_admins" } update control { &Auth-Type := PAM &Reply-Message := "Bem-vindo Admin" } } else { update reply { &Reply-Message := "Não autorizado para vpn" } reject } }

Após a instalação

freeradius-ldap raddb/mods-available no diretório um arquivo é criado É necessário criar um link simbólico no diretório ldap.

raddb/mods-enabled Ajusto o conteúdo para o seguinte formato:.

ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldap

ldap { server = 'domain.local' identity = 'CN=freerad_user,OU=users,DC=domain,DC=local' password = "SupeSecretP@ssword" base_dn = 'dc=domain,dc=local' sasl { } user { base_dn = "${..base_dn}" filter = "(sAMAccountname=%{%{Stripped-User-Name}:-%{User-Name}})" sasl { } scope = 'sub' } group { base_dn = "${..base_dn}" filter = '(objectClass=Group)' scope = 'sub' name_attribute = cn membership_filter = "(|(member=%{control:Ldap-UserDn})(memberUid=%{%{Stripped-User-Name}:-%{User-Name}}))" membership_attribute = 'memberOf' } }

Em arquivos

Nos arquivos raddb/sites-enabled/default e raddb/sites-enabled/inner-tunnel na seção autorizar adiciono o nome da política que será utilizada — group_authorization. Um ponto importante — o nome da política é determinado não pelo nome do arquivo no diretório policy.d, mas pela diretiva dentro do arquivo antes das chaves.
Na seção autenticar nestes mesmos arquivos, é necessário descomentar a linha pam.

No arquivo clients.conf definimos os parâmetros com os quais a conexão será feita Fortigate:

client fortigate {
    ipaddr = 192.168.1.200
    secret = testing123
    require_message_authenticator = no
    nas_type = other
}

Configuração do módulo pam.d/radiusd:

#%PAM-1.0
auth       sufficient   pam_google_authenticator.so
auth       include      password-auth
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
session    include      password-auth

As opções padrão de implementação da combinação sssd com google authenticator prevêm a inserção de dados pelo usuário no formato: username/password+OTP.

Considerando a quantidade de reclamações que surgiriam, caso a combinação padrão fosse usada sssd com Google Authenticator, foi tomada a decisão de utilizar a configuração do módulo pam de forma que verifique apenas o token Google Authenticator.

Ao conectar um usuário, ocorre o seguinte:

Freeradius verifica a existência do usuário no domínio e em um grupo específico e, em caso de sucesso, a verificação do token OTP é realizada.

Tudo parecia estar funcionando bem até o momento em que pensei: ‘E como registrar OTP para mais de 300 usuários?’

O usuário deve fazer login no servidor com sssd e com sua conta e iniciar o aplicativo Google authenticator, que gerará para o usuário o código QR para o aplicativo. É aqui que figlet vem a combinar com .bash_profile.

[root@freeradius ~]# yum install -y shellinabox

O arquivo de configuração do daemon está em /etc/sysconfig/shellinabox.
Indico lá a porta 443 e posso especificar meu certificado.

[root@freeradius ~]#systemctl enable --now shellinaboxd

O usuário apenas precisa acessar o link, inserir as credenciais do domínio e obter o código QR para o aplicativo.

O algoritmo é o seguinte:

O usuário faz login na máquina através do navegador.
Verifica-se se o usuário pertence ao domínio. Se não, nenhuma ação é tomada.
Se o usuário é do domínio, verifica-se a pertença ao grupo de administradores.
Se não for administrador, verifica-se se o Google Authenticator está configurado. Se não, um código QR é gerado e o usuário é desconectado.
Se não for administrador e o Google Authenticator estiver configurado, então apenas é feita a desconexão.
Se for administrador, a verificação do Google Authenticator é realizada novamente. Se não estiver configurado, um código QR é gerado.

Toda a lógica é executada utilizando /etc/skel/.bash_profile.

cat /etc/skel/.bash_profile

# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

# User specific environment and startup programs
# Make several commands available from user shell

if [[ -z $(id $USER | grep "admins") || -z $(cat /etc/passwd | grep $USER) ]]
  then
    [[ ! -d $HOME/bin ]] && mkdir $HOME/bin
    [[ ! -f $HOME/bin/id ]] && ln -s /usr/bin/id $HOME/bin/id
    [[ ! -f $HOME/bin/google-auth ]] && ln -s /usr/bin/google-authenticator $HOME/bin/google-auth
    [[ ! -f $HOME/bin/grep ]] && ln -s /usr/bin/grep $HOME/bin/grep
    [[ ! -f $HOME/bin/figlet ]] && ln -s /usr/bin/figlet $HOME/bin/figlet
    [[ ! -f $HOME/bin/rebel.tlf ]] && ln -s /usr/share/figlet/rebel.tlf $HOME/bin/rebel.tlf
    [[ ! -f $HOME/bin/sleep ]] && ln -s /usr/bin/sleep $HOME/bin/sleep
  # Set PATH env to <home user directory>/bin
    PATH=$HOME/bin
    export PATH
  else
    PATH=PATH=$PATH:$HOME/.local/bin:$HOME/bin
    export PATH
fi


if [[ -n $(id $USER | grep "domain users") ]]
  then
    if [[ ! -e $HOME/.google_authenticator ]]
      then
        if [[ -n $(id $USER | grep "admins") ]]
          then
            figlet -t -f $HOME/bin/rebel.tlf "Welcome to Company GAuth setup portal"
            sleep 1.5
            echo "Please, run any of these software on your device, where you would like to setup OTP:
Google Autheticator:
AppStore - https://apps.apple.com/us/app/google-authenticator/id388497605
Play Market - https://play.google.com/stor/apps/details?id=com.google.android.apps.authenticator2&hl=en
FreeOTP:
AppStore - https://apps.apple.com/us/app/freeotp-authenticator/id872559395
Play Market - https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp&hl=en

And prepare to scan QR code.

"
            sleep 5
            google-auth -f -t -w 3 -r 3 -R 30 -d -e 1
            echo "Congratulations, now you can use an OTP token from application as a password connecting to VPN."
          else
            figlet -t -f $HOME/bin/rebel.tlf "Welcome to Company GAuth setup portal"
            sleep 1.5
            echo "Please, run any of these software on your device, where you would like to setup OTP:
Google Autheticator:
AppStore - https://apps.apple.com/us/app/google-authenticator/id388497605
Play Market - https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en
FreeOTP:
AppStore - https://apps.apple.com/us/app/freeotp-authenticator/id872559395
Play Market - https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp&hl=en

And prepare to scan QR code.

"
            sleep 5
            google-auth -f -t -w 3 -r 3 -R 30 -d -e 1
            echo "Congratulations, now you can use an OTP token from application as a password to VPN."
            logout
        fi
      else
        echo "You have already setup a Google Authenticator"
        if [[ -z $(id $USER | grep "admins") ]]
          then
          logout
        fi
    fi
  else
    echo "You don't need to set up a Google Authenticator"
fi

Configuração do Fortigate:

Criamos Radius-servidor
Criamos os grupos necessários, caso seja necessário restringir o acesso por grupos. O nome do grupo deve Fortigate corresponder ao grupo que é passado para o . Para isso, no diretório Fortinet-Group-Name.
Editamos os necessários SSL-portais.
Adicionamos grupos às políticas.

As vantagens desta solução:

Há a possibilidade de autenticação por OTP em Fortigate solução open source.
Elimina a necessidade de digitar a senha do domínio pelo usuário ao se conectar via VPN, o que simplifica um pouco o processo de conexão. É mais fácil digitar uma senha de 6 dígitos do que a prevista pela política de segurança. Como consequência, diminui o número de tickets com o assunto: 'Não consigo me conectar à VPN'.

P.S. Planejo aprimorar essa solução para uma autenticação de dois fatores completa com challenge-response.

Update:

Como prometido, finalmente apliquei o modelo com challenge-response.
Então:
No arquivo /etc/raddb/sites-enabled/default seção autorizar fica da seguinte forma:

authorize {
    filter_username
    preprocess
    auth_log
    chap
    mschap
    suffix
    eap {
        ok = return
    }
    files
    -sql
    #-ldap
    expiration
    logintime
    if (!State) {
        if (&User-Password) {
            # Se !State e User-Password (PAP), então força LDAP:
            update control {
                Ldap-UserDN := "%{User-Name}"
                Auth-Type := LDAP
            }
        }
        else {
            reject
        }
    }
    else {
        # Se State, então proxy request:
        group_authorization
    }
pap
}

Seção autenticar agora tem o seguinte formato:

authenticate {
        Auth-Type PAP {
                pap
        }
        Auth-Type CHAP {
                chap
        }
        Auth-Type MS-CHAP {
                mschap
        }
        mschap
        digest
        # Tente autenticação com um bind LDAP direto:
        Auth-Type LDAP {
        ldap
        if (ok) {
            update reply {
                # Crie um atributo State aleatório:
                State := "%{randstr:aaaaaaaaaaaaaaaa}"
                Reply-Message := "Por favor, insira o OTP"
                }
            # Retorne Access-Challenge:
            challenge
            }
        }
        pam
        eap
}

Agora, a verificação do usuário ocorre pelo seguinte algoritmo: