FREERADIUS: Proxy-Radius

FREERADIUS: Proxy-Radius

Cuando necesitamos hacer consultas a otro servidor radius para autenticar usuarios que no estan en nuestra base de datos local se puede usar al servidor radius local como un proxy para enviar las consultas al servidor correspondiente, en esta guía vamos a configurar un servidor radius local para que haga de proxy solamente para los usuarios con formato «username@conare.ac.cr» y que los usuarios con formato «username@siua.ac.cr» y con el formato «username» se validen de manera local.

  • Partimos de que se tiene el servidor radius configurado y funcionando según la guía
/?p=500
  • Para configurar el servidor radius como proxy solamente debemos editar el archivo
nano /etc/freeradius/3.0/proxy.conf
  • Para hacer una configuración de proxy solamente necesitamos saber cual va ser el «delimitador» y cual va ser el «realm», los realm están definidos en 
nano /etc/freeradius/3.0/mods-available/realm
#  'username@realm'
#
realm suffix {
        format = suffix
        delimiter = "@"

        # The next 3 configuration items are valid ONLY
        # for a trust-router.  For all other realms,
        # they are ignored.
#       trust_router = "localhost"
#       rp_realm = "painless-security.com"
#       default_community = "apc.moonshot.ja.net"
}
  • En el extracto de código anterior podemos ver la definición realm que nos interesa que tiene el formato username@realm, siendo en este caso el «@» nuestro delimitador y además es de formato «sufijo» lo que quiere decir que el «username» siempre será lo que se encuentre antes del delimitador y el «realm» lo que esta después, pero podemos definir cualquier realm para ser usado en el radius. Se pueden definir multiples realm y serán buscados en el orden en que aparecen en la sección authorize y preacct del archivo
nano /etc/freeradius/3.0/sites-enabled/default
  • En nuestro caso solo vamos a usar el realm suffix, pero si necesitamos otro solo lo listamos en este archivo en el orden que queremos que se comparen.
  • Teniendo claro lo anterior editamos el archivo 
nano /etc/freeradius/3.0/proxy.conf
  • Vamos al final del archivo y agremos el servidor al que haremos proxy y los realm
############################################################################
######################### RADIUS-PROXY DE CONARE ###########################
############################################################################

home_server conare {
         type = auth
         ipaddr = 163.178.80.35
         port = 1812
         secret = siua_conare
}

#home_server_pool pool_dns {
#        type = fail-over
#        home_server = conare
#}

#########################################################################

realm siua.ac.cr {
        authhost = LOCAL
}

realm conare.ac.cr {
        #auth_pool = pool_dns
        authhost = conare
        secret = siua_conare
        nostrip
}

realm itcr.ac.cr {
        #auth_pool = pool_dns
        authhost = conare
        secret = siua_conare
        nostrip
}

realm estudiantes.tec.cr {
        #auth_pool = pool_dns
        authhost = conare
        secret = siua_conare
        nostrip
}
  • Hemos agregado un home_server llamado conare, el cual usaremos para authenticar tipo auth con la ip 163.178.80.35 en el puerto 1812 y con el password precompartido $SECRET$
  • También agregamos el realm siua.ac.cr y le indicamos que este realm hace una autenticación con el servidor LOCAL
  • Luego agregamos los realm que nos interesa autenticar con el PROXY-SERVER para que haga una autenticación con el home_server conare, además agregamos la línea nostrip esto es para que el username y el realm no sean separados y la consulta se pase al servidor proxy tal como llego a nuestro servidor, en el caso de el realm siua.ac.cr no usamos la linea nostrip esto porque la autenticacion en este caso es local y le pasaremos la consulta a la base de datos con el username solamente sin la parte del realm.
  • Por ejemplo:
    • El usuario user1@siua.ac.cr es autenticado localmente pues tiene el realm = siua.ac.cr y como este realm no tiene la línea nostrip el username será separado en Stripped-User-Name = user1 y el realm = siua.ac.cr, la consulta se hace a la base de datos local con el Stripped-User-Name = user1.
    • El usuario user2@conare.ac.cr es autenticado contra el servidor conare pues tiene el realm = conare.ac.cr y como este realm si tiene la linea nostrip el User-Name = user2@conare.ac.cr no se separa y la consulta se pasa al servidor conare con el User-Name = user2@conare.ac.cr.
  • NOTA: Cuando el User-Name = user1@siua.ac.cr es separado en Stripped-User-Name = user1 y el realm = siua.ac.cr, la consulta a la base de datos establece el atributo «SQL-User-Name» = Stripped-User-Name si y solo si se descomentan y comentan las líneas que se muestra a continuación en el archivo
nano /etc/freeradius/3.0/mods-config/sql/main/mysql/queries.conf
  • Con este cambio se usará el Stripped-User-Name si es que lo hay y si no hay un Stripped-User-Name se usará el User-Name.
  • Si no se hace este cambio el atributo «SQL-User-Name» se establece como el User-Name, que es user1@siua.ac.cr, y como este usuario no existe en la base de datos el acceso es denegado, pues el usuario en la base de datos local es user1 y no user1@siua.ac.cr.

OTROS DATOS

  • En el proceso de autenticación del radius lo primero que se ejecuta es la sección authorize del archivo:
/etc/freeradius/3.0/sites-enabled/default
  • Este es el preproceso
  • Aquí compara los realm que se definieron en nuestro caso «suffix» con el demimitador @
  • Luego envía la consulta a la base de datos o el proxy según corresponda
  • Después de que se recibe la respuesta
  • Si la repuesta es de un proxy (Accept o Deny)
    • Received Access-Reject o Received Access-Accept
      • Executing section post-proxy from file /etc/freeradius/3.0/sites-enabled/default
  • Después si la respuesta es Accept
    • Found Auth-Type = AcceptAuth-Type = Accept, accepting the user# Executing section post-auth from file /etc/freeradius/3.0/sites-enabled/default
    • SE GUARDA UN REGISTRO EN LA TABLA radpostauth
  • Si la respuesta es Deny
    • Using Post-Auth-Type Reject# Executing group from file /etc/freeradius/3.0/sites-enabled/default
    • Post-Auth-Type REJECT { SE GUARDA UN REGISTRO EN LA TABLA radpostauth
  • Si la respuesta es LOCAL
    • Found Auth-Type = PAP
    • Executing group from file /etc/freeradius/3.0/sites-enabled/default
    • Auth-Type PAP {
      • pap: Login attempt with password
      • pap: Comparing with «known good» Cleartext-Password
      • pap: User authenticated successfully
      • [pap] = ok
      • } # Auth-Type PAP = ok
  • O si falla
    • Found Auth-Type = PAP
    • Executing group from file /etc/freeradius/3.0/sites-enabled/default
    • Auth-Type PAP {
      • pap: Login attempt with password
      • pap: Comparing with «known good» Cleartext-Password
      • pap: ERROR: Cleartext password «user» does not match «known good» password
      • pap: Passwords don’t match
      • [pap] = reject
      • } # Auth-Type PAP = reject
  • Después si la respuesta es Accept
    • Found Auth-Type = Accept
    • Auth-Type = Accept, accepting the user
    • Executing section post-auth from file /etc/freeradius/3.0/sites-enabled/default
      • post-auth {
      • update {
        • No attributes updated
        • } # update = noop
    • SE GUARDA UN REGISTRO EN LA TABLA radpostauth

Agregando atributos POST-AUTENTICACION

  • Si hacemos autenticación de los usuarios en nuestra base de datos MYSQL podemos asignarle los atributos que deseamos, pero si la autenticacion se hace por medio del proxy debemos recibir estos tributos del radius al que se envía la consulta o asignarlos nosotros mismo en la sección post-auth del archivo
nano /etc/freeradius/3.0/sites-enabled/default
        update {
                &reply: += &session-state:
        }
#############################################################################################
#############################################################################################
#############################################################################################
        if (&Realm == "conare.ac.cr"){
                update reply {
                        Tunnel-Type := VLAN
                        Tunnel-Medium-Type := IEEE-802
                        Tunnel-Private-Group-Id := "190"
                }
        }

        if (&Realm == "itcr.ac.cr"){
                update reply {
                        Tunnel-Type := VLAN
                        Tunnel-Medium-Type := IEEE-802
                        Tunnel-Private-Group-Id := "130"
                }
        }

        if (&Realm == "estudiantes.tec.cr"){
                update reply {
                        Tunnel-Type := VLAN
                        Tunnel-Medium-Type := IEEE-802
                        Tunnel-Private-Group-Id := "130"
                }
        }

        if (&Realm == "una.cr"){
                update reply {
                        Tunnel-Type := VLAN
                        Tunnel-Medium-Type := IEEE-802
                        Tunnel-Private-Group-Id := "168"
                }
        }

#############################################################################################
#############################################################################################
#############################################################################################
  • Aquí por ejemplo hemos agregado un «if» en la sección post-auth, para asignarle la vlan 190 a los usuarios con el realm == conare.ac.cr que tienen una autenticación exitosa, la 130 a los usuarios TEC y la 168 a usuario UNA.