Errores frecuentes en FreeRADIUS 3.x con PAM: guía de diagnóstico

Configurar FreeRADIUS 3.x con autenticación PAM —especialmente combinando pam_google_authenticator, pam_winbind y fail2ban— genera un conjunto de errores que aparecen una y otra vez. Este artículo los recoge con causa exacta y solución directa, sin rodeos.

Tabla resumen

#

Error 1: Failed to change user id to "usuario"

#

Síntoma

#

(0)  pam: pam_authenticate: Failed to change user id to "usuario"
(0)  pam: ERROR: PAM auth for user "usuario" failed

Causa

#

pam_google_authenticator.so se carga con el parámetro user=root, lo que obliga a PAM a hacer setuid(root) antes de leer el fichero TOTP. El proceso freeradius corre como usuario freerad y no tiene permiso para asumir la identidad de root.

Solución

#

En /etc/pam.d/radiusd, cambiar user=root por user=freerad:

# /etc/pam.d/radiusd
auth required pam_google_authenticator.so secret=/etc/google-authenticator/${USER} user=freerad

Asegurarse de que los ficheros TOTP son legibles por freerad:

chown freerad /etc/google-authenticator/
ls -la /etc/google-authenticator/

Verificación

#

id freerad
# uid=116(freerad) gid=125(freerad) ...

ls -la /etc/google-authenticator/
# drwxr-xr-x  freerad freerad  .
# -rw-------  freerad freerad  usuario

Error 2: user not found / getpwnam() failed

#

Síntoma

#

pam_winbind(radiusd:auth): user 'DOMINIO\usuario' not found
getpwnam() failed: No such user

Causa

#

Winbind puede autenticar al usuario contra Active Directory (wbinfo -a funciona), pero si smb.conf no tiene una configuración idmap correcta para el dominio, getpwnam() no puede asignar un UID Unix al usuario AD. El sistema operativo no lo encuentra aunque las credenciales sean válidas.

Solución

#

Añadir los bloques idmap config en /etc/samba/smb.conf:

[global]
   # ... configuración existente ...

   # Backend por defecto para dominios no especificados
   idmap config * : backend = tdb
   idmap config * : range = 3000-7999

   # Backend RID para el dominio corporativo
   idmap config DOMINIO : backend = rid
   idmap config DOMINIO : range = 10000-99999

Reiniciar winbind (no solo reload):

systemctl restart winbind
systemctl status winbind

Diagnóstico

#

# Listar usuarios del dominio
wbinfo -u | grep usuario

# Resolver usuario AD a entidad Unix
getent passwd 'DOMINIO\usuario'
# DOMINIO\usuario:*:12345:10001:Nombre Apellido:/home/DOMINIO/usuario:/bin/bash

Si getent no devuelve nada, el problema está en el rango idmap o en el backend. Si wbinfo -u tampoco funciona, el problema es previo: la unión al dominio o la conectividad con el DC.

Error 3: Secret file permissions (0644) are more permissive than 0600

#

Síntoma

#

pam_google_authenticator(radiusd:auth): Secret file permissions (0644)
are more permissive than 0600.
(0) pam: ERROR: PAM auth for user "usuario" failed

Causa

#

pam_google_authenticator comprueba los permisos del fichero TOTP antes de leerlo. Si son 0644 o más abiertos, rechaza el fichero por razones de seguridad. El error puede aparecer como autenticación fallida sin mayor detalle en los logs de freeradius, lo que dificulta el diagnóstico si no se ejecuta freeradius -X.

Solución

#

chmod 600 /etc/google-authenticator/*
ls -la /etc/google-authenticator/
# -rw-------  freerad freerad  usuario

Consecuencia si no se corrige

#

pam_google_authenticator rechaza la autenticación silenciosamente desde la perspectiva de FreeRADIUS. El usuario recibe un Access-Reject sin causa aparente. Solo freeradius -X muestra el mensaje de permisos.

Error 4: Failed to create tempfile: Permission denied

#

Síntoma

#

pam_google_authenticator(radiusd:auth): Failed to create tempfile
"/etc/google-authenticator/.usuario.XXXXXX": Permission denied

Causa

#

pam_google_authenticator escribe un fichero temporal en el mismo directorio donde está el secreto TOTP antes de actualizar el contador de uso único (para evitar replay attacks). Si el directorio /etc/google-authenticator/ pertenece a root y el proceso corre como freerad, la escritura falla.

Este error es distinto del error 1: el setuid puede estar correctamente configurado con user=freerad, pero el directorio sigue siendo propiedad de root.

Solución

#

chown freerad:freerad /etc/google-authenticator/

Verificar que los ficheros individuales siguen siendo 0600 después del cambio:

ls -la /etc/google-authenticator/
# drwxr-xr-x  freerad freerad  .
# -rw-------  freerad freerad  usuario

El directorio necesita permisos de escritura para freerad; los ficheros individuales solo necesitan lectura.

Error 5: Contraseñas visibles en el log tras configurar auth_badpass = no

#

Síntoma

#

Se configura auth_badpass = no en radiusd.conf esperando que las contraseñas fallidas dejen de aparecer en los logs, pero siguen siendo visibles.

Causa

#

Hay dos causas independientes que pueden ocurrir simultáneamente:

1. Reinicio incompleto: el cambio en radiusd.conf requiere restart, no reload. Con reload, el proceso mantiene la configuración anterior en memoria.
2. Módulo auth_log: si está habilitado en la sección authorize del virtual server, registra la petición —incluyendo atributos sensibles— independientemente de la configuración de auth_badpass.

Solución

#

Reinicio completo:

systemctl restart freeradius
# No usar: systemctl reload freeradius

Verificar el módulo auth_log en el virtual server (normalmente /etc/freeradius/3.0/sites-enabled/default):

authorize {
    # Si este módulo está aquí, loguea independientemente de auth_badpass
    # auth_log   ← comentar o eliminar si no se necesita
    ...
}

Confirmar que el cambio surtió efecto:

grep -n 'auth_badpass' /etc/freeradius/3.0/radiusd.conf
freeradius -X 2>&1 | grep -i "bad.*pass\|log.*pass"

Error 6: No Auth-Type found: rejecting via Post-Auth-Type = Reject

#

Síntoma

#

(0) No Auth-Type found: rejecting the user via Post-Auth-Type = Reject
(0) Failed to authenticate the user

La autenticación PAM funciona en pruebas directas (pamtester), pero FreeRADIUS rechaza sin llegar a invocarla.

Causa

#

FreeRADIUS necesita saber qué método de autenticación usar. Si ningún módulo en la sección authorize establece Auth-Type, el servidor no sabe que debe delegar en PAM y rechaza la petición. Esto ocurre habitualmente cuando se migra de autenticación local a PAM sin actualizar el virtual server.

Solución

#

En el virtual server activo (/etc/freeradius/3.0/sites-enabled/default), añadir en la sección authorize:

authorize {
    preprocess
    update control {
        &Auth-Type := PAP
    }
    pam
    ...
}

Y asegurarse de que el módulo pam está habilitado en la sección authenticate:

authenticate {
    Auth-Type PAP {
        pam
    }
}

Verificar que el módulo PAM está habilitado:

ls /etc/freeradius/3.0/mods-enabled/pam

Si no existe, crear el enlace:

cd /etc/freeradius/3.0/mods-enabled && ln -s ../mods-available/pam pam

Error 7: fail2ban no arranca — Jail 'sshd' is not valid

#

Síntoma

#

ERROR  Failed during configuration: Have not found 'logpath' option in 'sshd' jail
# o bien:
ERROR  Jail 'sshd' is not valid

systemctl start fail2ban falla o el servicio se inicia pero sin jails activos.

Causa

#

Dos variantes comunes:

1. logpath duplicado: jail.local define logpath dos veces en la misma sección [sshd], lo que invalida la configuración del jail.
2. Jails de servicios no instalados: si jail.local habilita jails para apache, vsftpd u otros servicios que no están presentes, fail2ban no encuentra los ficheros de log y falla.

Solución

#

Validar la configuración antes de (re)iniciar el servicio:

fail2ban-client -t
# Si hay errores, los muestra con fichero y línea

Editar /etc/fail2ban/jail.local y eliminar entradas duplicadas:

[sshd]
enabled = true
port    = ssh
# Solo un logpath:
logpath = %(sshd_log)s
maxretry = 5

Comentar jails de servicios no instalados:

# [apache-auth]
# enabled = true
# ...

# [vsftpd]
# enabled = true
# ...

Reiniciar tras validar:

fail2ban-client -t && systemctl restart fail2ban
fail2ban-client status

Herramientas de diagnóstico

#

Antes de revisar código o configuración, estas herramientas reducen el tiempo de diagnóstico a minutos:

freeradius -X — modo debug interactivo. Detener el servicio y ejecutar en primer plano para ver cada paso del procesamiento, incluyendo los mensajes de PAM que no aparecen en los logs normales:

systemctl stop freeradius
freeradius -X

radtest — enviar una petición de autenticación de prueba directamente desde la línea de comandos:

radtest usuario contraseña+totp 127.0.0.1 0 secreto-compartido

journalctl — seguir los logs del servicio en tiempo real:

journalctl -u freeradius -f

wbinfo -P — verificar que Winbind tiene conectividad con el controlador de dominio:

wbinfo -P
# checking the NETLOGON for domain[DOMINIO] dc connection ... succeeded

fail2ban-client -t — validar la configuración completa de fail2ban sin iniciar el servicio:

fail2ban-client -t

Conclusión

#

La mayoría de estos errores comparten un patrón: el proceso freerad no tiene los permisos correctos sobre los recursos que necesita, o la configuración requiere un reinicio completo para surtir efecto. El orden de diagnóstico recomendado es:

1. Ejecutar freeradius -X para ver el error completo
2. Verificar propietario y permisos con ls -la sobre los directorios afectados
3. Confirmar que Winbind resuelve usuarios con getent passwd antes de depurar FreeRADIUS
4. Validar configuraciones antes de aplicarlas (fail2ban-client -t)
5. Reiniciar, no recargar, cuando se cambia configuración que afecta al proceso en memoria

Con estos siete errores cubiertos y las herramientas de diagnóstico adecuadas, la mayoría de los problemas habituales en entornos FreeRADIUS + PAM se resuelven sin necesidad de escalar.