EN ESTA PÁGINA
Uso de solicitudes dinámicas de RADIUS para la administración de acceso de suscriptores
Configurar la compatibilidad con solicitudes dinámicas iniciadas por RADIUS
Descripción general del cambio de autorización (CoA) iniciado por RADIUS
Descripción general de los inicios de sesión del suscriptor y los fallos de activación del servicio
Configurar cómo afectan los errores de activación del servicio al inicio de sesión del suscriptor
Códigos de causa de error (atributo RADIUS 101) para solicitudes dinámicas
Gestión dinámica de servicios con RADIUS
Uso de solicitudes dinámicas de RADIUS para la administración de acceso de suscriptores
Las solicitudes dinámicas de RADIUS ofrecen una manera eficiente de administrar de forma centralizada las sesiones de los suscriptores. El soporte de solicitudes dinámicas de RADIUS del marco de servicio AAA permite a los servidores RADIUS iniciar operaciones relacionadas con el usuario, como una operación de terminación, mediante el envío de mensajes de solicitud no solicitados al enrutador. Sin la función de solicitud dinámica de RADIUS, la única manera de desconectar a un usuario de RADIUS es desde el enrutador, lo que puede ser engorroso y requerir mucho tiempo en redes grandes.
En un entorno típico de RADIUS cliente-servidor, el enrutador funciona como cliente e inicia las solicitudes enviadas al servidor remoto de RADIUS. Sin embargo, cuando se utilizan solicitudes dinámicas de RADIUS, los roles se invierten. Por ejemplo, durante una operación de desconexión, el servidor remoto de RADIUS actúa como cliente e inicia la solicitud (la acción de desconexión): el enrutador funciona como servidor en la relación.
Cree un perfil de acceso para configurar el enrutador de modo que admita solicitudes dinámicas de RADIUS. Esta configuración permite que el enrutador reciba y actúe sobre los siguientes tipos de mensajes de servidores RADIUS remotos:
Mensajes de acceso y aceptación: active dinámicamente servicios en función de los atributos de los mensajes de acceso y aceptación de RADIUS recibidos cuando un suscriptor inicia sesión.
Mensajes de cambio de autorización (CoA): modifique dinámicamente las sesiones activas en función de los atributos de los mensajes CoA. Los mensajes de CoA pueden incluir solicitudes de creación de servicio, solicitudes de eliminación, atributos de RADIUS y VSA de Juniper Networks.
Desconectar mensajes: finaliza inmediatamente sesiones específicas de suscriptores.
De forma predeterminada, el enrutador supervisa el puerto UDP 3799 para las solicitudes de CoA de los servidores RADIUS. También puede configurar un puerto no predeterminado para servidores RADIUS. Debe utilizar el puerto predeterminado para todos los servidores RADIUS o configurar el mismo puerto no predeterminado para todos los servidores RADIUS. Esta regla se aplica tanto en el nivel de acceso global como en el de perfil de acceso.
Cualquier otra configuración da como resultado un error en la comprobación de confirmación. No se admiten varios números de puerto, es decir, números de puerto diferentes para distintos servidores.
Beneficios de las solicitudes dinámicas de RADIUS
Permite una administración centralizada simplificada de las sesiones de suscriptores mediante el envío de cambios no solicitados a las sesiones de suscriptores, incluidos los cambios en los atributos, la activación del servicio, la desactivación del servicio y la terminación de la sesión.
Ver también
Configurar la compatibilidad con solicitudes dinámicas iniciadas por RADIUS
El enrutador utiliza la lista de servidores de autenticación RADIUS especificados para las operaciones de autenticación y de solicitud dinámica. De forma predeterminada, el enrutador supervisa el puerto UDP 3799 para las solicitudes dinámicas, también conocidas como solicitudes de cambio de autorización (CoA).
Para configurar la compatibilidad con solicitudes dinámicas de RADIUS:
Especifique la dirección IP del servidor de RADIUS.
[edit access profile isp-bos-metro-fiber-basic radius] user@host# set authentication-server 192.168.1.3
Para configurar el enrutador de modo que admita solicitudes dinámicas desde más de un servidor RADIUS:
Especifique las direcciones IP de varios servidores RADIUS.
[edit access profile isp-bos-metro-fiber-basic radius] user@host# set authentication-server 192.168.1.3 192.168.10.15
Cuando configure puertos de solicitud dinámicos, debe realizar una de las siguientes acciones:
Utilice el puerto predeterminado para todos los servidores de RADIUS, tanto en el nivel de acceso global como en todos los perfiles de acceso.
Configure el mismo puerto no predeterminado para todos los servidores, tanto en el nivel de acceso global como en todos los perfiles de acceso.
Cualquier otra configuración da como resultado un error en la comprobación de confirmación. No se admiten varios números de puerto, es decir, números de puerto diferentes para distintos servidores.
Para especificar un puerto de solicitud dinámico global:
[edit access] user@host# set radius-server server-address dynamic-request-port port-number
Para especificar el puerto de solicitud dinámica para un perfil de acceso específico:
[edit access] user@host# set profile profile-name radius-server server-address dynamic-request-port port-number
Considere los siguientes escenarios:
La siguiente configuración utiliza el puerto predeterminado tanto para un servidor globalmente como para un servidor diferente en el perfil de acceso. Esta es una configuración válida.
[edit access] user@host# set radius-server 192.0.2.1 user@host# set profile ap1 radius-server 192.0.2.3
La siguiente configuración especifica el puerto no predeterminado 50201 para un servidor globalmente y un servidor diferente en el perfil de acceso. Esta es una configuración válida.
[edit access] user@host# set radius-server 192.0.2.1 dynamic-request-port 50201 user@host# set profile ap1 radius-server 192.0.2.3 dynamic-request-port 50201
La siguiente configuración especifica el puerto 50201 globalmente para un servidor y el puerto 51133 para el mismo servidor en el perfil de acceso AP1. Se trata de una configuración no válida y se produce un error en la comprobación de confirmación, ya que no se admiten varios puertos no predeterminados.
[edit access] user@host# set radius-server 192.0.2.1 dynamic-request-port 50201 user@host# set profile ap1 radius-server 192.0.2.1 dynamic-request-port 51133
La siguiente configuración utiliza el puerto predeterminado 3799 para un servidor globalmente y el puerto 51133 para otro servidor globalmente. Se trata de una configuración no válida y se produce un error en la comprobación de confirmación, ya que para todos los servidores debe configurar el puerto predeterminado o el mismo puerto no predeterminado.
[edit access] user@host# set radius-server 192.0.2.1 user@host# set radius-server 192.0.2.3 dynamic-request-port 51133
Ver también
Descripción general del cambio de autorización (CoA) iniciado por RADIUS
El marco de servicio AAA utiliza mensajes CoA para modificar dinámicamente las sesiones de los suscriptores activos. Por ejemplo, los atributos RADIUS de los mensajes CoA pueden indicar al marco que cree, modifique o finalice un servicio de suscriptor. También puede utilizar mensajes CoA para establecer o modificar umbrales de uso para los servicios del suscriptor actual.
- Mensajes CoA
- Requisitos para el cambio de autorización
- Intercambio de mensajes
- Transacciones de CoA masivas
- Beneficios del cambio de autorización iniciado por Radius
Mensajes CoA
La compatibilidad con solicitudes dinámicas permite que el enrutador reciba y procese mensajes de CoA no solicitados desde servidores RADIUS externos. Los mensajes de CoA iniciados por RADIUS utilizan los siguientes códigos en los mensajes de solicitud y respuesta:
Solicitud de CoA (43)
CoA-ACK (44)
CoA-NAK (45)
Requisitos para el cambio de autorización
Para completar el cambio de autorización de un usuario, especifique atributos de identificación y atributos de sesión. Los atributos de identificación identifican al suscriptor. Los atributos de sesión especifican la operación (activación o desactivación) que se realizará en la sesión del suscriptor e incluyen también los atributos de cliente para la sesión (por ejemplo, atributos de QoS). El marco de servicio de AAA controla la solicitud real.
En el Cuadro 1 se muestran los atributos de identificación de las operaciones de CoA.
Atributo |
Descripción |
|---|---|
Nombre de usuario [atributo RADIUS 1] |
Nombre de usuario del suscriptor. |
Acct-session-ID [atributo RADIUS 44] |
Sesión específica de suscriptor. |
El uso del atributo Acct-Session-ID para identificar la sesión del suscriptor es más explícito que el uso del atributo User-Name. Cuando se utiliza el nombre de usuario como identificador, la operación CoA se aplica a la primera sesión en la que se inició sesión con el nombre de usuario especificado. Sin embargo, dado que un suscriptor puede tener varias sesiones asociadas con el mismo nombre de usuario, es posible que la primera sesión no sea la sesión correcta para la operación CoA.
Cuando utiliza el atributo Acct-Session-ID, identifica la sesión específica del suscriptor, evitando ese posible error. Aunque el atributo Acct-Session-ID puede incluir un especificador de interfaz además del ID de sesión, cuando el atributo está en el formato de descripción, solo se utiliza el ID de sesión para la coincidencia de suscriptores. Por ejemplo, si el suscriptor tiene un ID de sesión de suscriptor de , el suscriptor coincide cuando el atributo Acct-Session-ID es 54785 (formato decimal54785), o jnpr demux0.1073759682:54785 (formato de descripción), o incluso any value:54785 (formato de descripción).
En la tabla 2 se muestran los atributos de sesión para las operaciones de CoA. Cualquier atributo de cliente adicional que incluya dependerá de los requisitos de sesión particulares.
Atributo |
Descripción |
|---|---|
Activar servicio [Juniper Networks VSA 26-65] |
Servicio para activar para el suscriptor. |
Desactivar-servicio [Juniper Networks VSA 26-66] |
Servicio a desactivar para el suscriptor. |
Volumen de servicio [Juniper Networks VSA 26-67] |
Cantidad de tráfico, en MB, que puede usar el servicio; El servicio se desactiva cuando se supera el volumen. |
Tiempo de espera del servicio [Juniper Networks VSA 26-68] |
Número de segundos que el servicio puede estar activo; El servicio se desactiva cuando expira el tiempo de espera. |
Volumen de servicio en gigapalabras [Juniper Networks VSA 26-179] |
Cantidad de tráfico, en unidades de 4 GB, que puede utilizar el servicio; El servicio se desactiva cuando se supera el volumen. |
Servicio de actualización [Juniper Networks VSA 26-180] |
Nuevos valores de servicio y cuotas de tiempo para el servicio existente. |
Intercambio de mensajes
El servidor RADIUS y el marco de servicio AAA en el enrutador intercambian mensajes utilizando UDP. El mensaje de solicitud de CoA enviado por el servidor de RADIUS tiene el mismo formato que el paquete de solicitud de desconexión que se envía para una operación de desconexión.
La respuesta es un mensaje CoA-ACK o CoA-NAK:
Si el marco de servicio AAA cambia correctamente la autorización, la respuesta es un paquete con formato RADIUS con un mensaje CoA-ACK y el filtro de datos se aplica a la sesión.
Si AAA Service Framework no tiene éxito, la solicitud tiene un formato incorrecto o faltan atributos, la respuesta es un paquete con formato RADIUS con un mensaje CoA-NAK.
El marco de servicio de AAA procesa una solicitud dinámica a la vez por suscriptor. Si el marco recibe una segunda solicitud dinámica (ya sea otro CoA o una solicitud de desconexión) mientras procesa una solicitud anterior para el mismo suscriptor, el marco responde con un mensaje CoA-NAK. A partir de Junos OS versión 15.1R5, se ignoran los mensajes de reintento de solicitud de CoA y no se envía ninguna CoA-NAK en respuesta a ellos.
Transacciones de CoA masivas
A partir de Junos OS versión 17.2R1, se admiten solicitudes de CoA masivas para mejorar la eficiencia del procesamiento de los servicios de suscriptor basados en RADIUS en el BNG. La funcionalidad de CoA masivo permite la acumulación de una serie de solicitudes de CoA y las compromete todas juntas, de forma masiva, automáticamente.
Todos los servicios en una solicitud de CoA masiva deben ser para la misma sesión de suscriptor.
Las transacciones masivas de CoA son particularmente valiosas para los servicios comerciales. Los servicios de suscriptor basados en RADIUS utilizan los VSA de Juniper Networks, Activate-Service (26-65) y Deactivate-Service (26-66). Los VSA se proporcionan en los mensajes de RADIUS-Accept durante el inicio de sesión o en las solicitudes de CoA después del inicio de sesión.
Para servicios convencionales y dinámicos basados en perfiles, pueden caber fácilmente hasta 12 activaciones de servicio dentro de cualquiera de los mensajes de RADIUS. Sin embargo, los servicios basados en scripts de operación que utilizan las empresas suelen tener requisitos de escalado que superan la capacidad de cualquiera de los mensajes. Esto significa que especificar y activar todos los servicios necesarios en una sesión de suscriptor determinada puede requerir el uso de un mensaje de acceso de aceptación y varias solicitudes de CoA.
Cada mensaje de solicitud de CoA es independiente de las solicitudes de CoA anteriores y futuras en la misma sesión de suscriptor. Todas las activaciones y desactivaciones de servicio en un mensaje se procesan antes de que se ofrezca una respuesta CoA. La solicitud de CoA proporciona una manera de modificar incrementalmente una sesión de suscriptor sin afectar los servicios existentes que ya están presentes.
Para los servicios basados en script operativo, los procesos authd y essmd crean las sesiones de servicio de manera colaborativa, de modo que la última operación inicie una confirmación para aplicar todas las interfaces lógicas empresariales estáticas resultantes de la solicitud CoA. Dado que el tiempo de confirmación es generalmente la mayor parte de la aplicación de un servicio empresarial estático, hay una ventaja en empaquetar tantas activaciones o desactivaciones de servicio como quepan dentro de un mensaje RADIUS para usar eficazmente la ventana de confirmación. Hasta que se complete la operación de confirmación, el BNG no puede aceptar una solicitud de CoA posterior para aplicar servicios empresariales adicionales para la misma sesión de suscriptor.
La CoA masiva mejora la eficiencia del procesamiento de confirmación mediante el uso de una única acción de confirmación para todos los servicios de la transacción masiva. La transacción masiva tiene el efecto de administrar una serie de solicitudes como una sola metasolicitud. Aplaza el procesamiento de confirmación hasta que se recibe la solicitud CoA final en la transacción masiva.
La CoA masiva requiere que cada solicitud individual contenga una sola instancia de VSA de Juniper Networks Bulk-CoA-Transaction-ID (26–194). Este VSA identifica las solicitudes como pertenecientes a la misma transacción masiva; 26–194 deben tener el mismo valor en todas las solicitudes de CoA de la serie masiva. Cada transacción masiva sucesiva en la sesión debe tener un identificador diferente; por ejemplo, tres transacciones masivas sucesivas pueden tener ID de 1, 2 y 1, pero no pueden tener ID sucesivos de 1, 1 y 2. En la práctica, el valor Bulk-CoA-Transaction-Id normalmente se incrementa para varias transacciones masivas, pero esto no es obligatorio. Un valor de ID utilizado en una sesión de suscriptor determinada también se puede utilizar en diferentes sesiones de suscriptor.
Cada solicitud de CoA dentro de una transacción masiva tiene su propio identificador único, proporcionado por una única instancia del VSA de identificador de CoA masivo (26-195) en cada CoA. Una serie creciente de valores para el ID es típica, pero no se aplica. Los valores se pueden reutilizar dentro de una sesión determinada y entre sesiones. La última solicitud de CoA de la serie se identifica por tener un valor de 0xFFFFFFFF para el identificador de CoA masivo.
Beneficios del cambio de autorización iniciado por Radius
Permite que los cambios en los valores de atributo se envíen dinámicamente a las sesiones de suscriptor, así como la activación y desactivación dinámica de los servicios de suscriptor.
Ver también
Descripción general de la desconexión iniciada por RADIUS
En esta sección, se describe la compatibilidad del marco de servicio AAA con las solicitudes dinámicas de desconexión iniciadas por RADIUS. El marco de servicio AAA utiliza mensajes de desconexión para terminar dinámicamente las sesiones de los suscriptores activos.
- Mensajes de desconexión
- Requisitos para la desconexión
- Intercambio de mensajes
- Beneficios de las desconexiones iniciadas por radio
Mensajes de desconexión
Para controlar centralmente la desconexión de los suscriptores de acceso remoto, la función de solicitud dinámica de RADIUS en el enrutador recibe y procesa mensajes no solicitados de los servidores de RADIUS.
La función de solicitud dinámica utiliza el formato existente de mensajes de solicitud y respuesta de desconexión de RADIUS. La desconexión iniciada por RADIUS utiliza los siguientes códigos en sus mensajes de solicitud y respuesta de RADIUS:
Solicitud de desconexión (40)
Desconectar-ACK (41)
Desconectar-NAK (42)
Requisitos para la desconexión
Para que el marco de servicio AAA desconecte a un usuario, el mensaje de solicitud de desconexión debe contener un atributo con un ID de sesión de contabilidad. El mensaje Disconnect-Request puede contener un atributo Acct-Session-Id (44) o un atributo Acct-Multi-Session-Id (50) para el ID de sesión, o ambos. Si los atributos Acct-Session-ID y Acct-Multi-Session-Id están presentes en la solicitud, el enrutador utiliza ambos atributos. Si el atributo Nombre de usuario (1) también está presente en la solicitud, el nombre de usuario y el ID de sesión de contabilidad se utilizan para realizar la desconexión. El marco de servicio de AAA controla la solicitud real.
Intercambio de mensajes
El servidor RADIUS y el marco de servicio AAA intercambian mensajes utilizando UDP. El mensaje de solicitud de desconexión enviado por el servidor de RADIUS tiene el mismo formato que el paquete de solicitud de CoA que se envía para una operación de cambio de autorización.
La respuesta de desconexión es un mensaje Disconnect-ACK o Disconnect-NAK:
Si el marco de servicio AAA desconecta correctamente al usuario, la respuesta es un paquete con formato RADIUS con un mensaje Disconnect-ACK.
Si el marco de servicio AAA no puede desconectar al usuario, la solicitud tiene un formato incorrecto o faltan atributos en la solicitud, la respuesta es un paquete con formato RADIUS con un mensaje Disconnect-NAK.
El marco de servicio de AAA procesa una solicitud dinámica a la vez por suscriptor. Si el marco recibe una segunda solicitud dinámica mientras procesa una solicitud anterior (ya sea un CoA u otra solicitud de desconexión) para el mismo suscriptor, el marco responde con un mensaje Disconnect-NAK.
Beneficios de las desconexiones iniciadas por radio
Habilita un servidor RADIUS para terminar dinámicamente las sesiones de los suscriptores. Esta función de administración centralizada de suscriptores simplifica el manejo de grandes cantidades de suscriptores, ya que, de lo contrario, la terminación del operador requeriría acción en el enrutador.
Ver también
Umbrales de uso para servicios de suscriptor
A partir de Junos OS versión 14.1, la administración de suscriptores le permite administrar servicios de suscriptores mediante el establecimiento de umbrales de uso cuando un servicio se activa dinámicamente o cuando un servicio existente se modifica por una acción de CoA de RADIUS. El servicio se desactiva cuando se alcanza el umbral especificado.
La administración de suscriptores admite dos tipos de umbrales de uso: volumen de tráfico y tiempo. Utilice VSA de Juniper Networks para establecer los umbrales de uso. Los VSA se transmiten en mensajes de aceptación de acceso de RADIUS para servicios activados dinámicamente o en mensajes de solicitud de CoA iniciados por RADIUS para servicios existentes. El umbral de volumen establece la cantidad máxima del tráfico total de entrada y salida que puede utilizar el servicio antes de que se desactive. Un umbral de tiempo establece la cantidad máxima de tiempo que el servicio puede estar activo. La Tabla 3 muestra los VSA utilizados para los umbrales de volumen y tiempo.
Número de atributo |
Nombre del atributo |
Descripción |
Valor |
|---|---|---|---|
26-67 |
Volumen de servicio |
Cantidad de tráfico de entrada y salida, en MB, que puede usar el servicio; El servicio se desactiva cuando se supera el volumen. VSA etiquetado, que admite 8 etiquetas (1-8). El enrutador sondea el tráfico en intervalos de 10 minutos. |
|
26-68 |
Tiempo de espera de servicio |
Número de segundos que el servicio puede estar activo; El servicio se desactiva cuando expira el tiempo de espera. VSA etiquetado, que admite 8 etiquetas (1-8). |
|
26-179 |
Volumen de servicio gigawords |
Cantidad de tráfico de entrada y salida, en unidades de 4GB, que puede utilizar el servicio; El servicio se desactiva cuando se supera el volumen. VSA etiquetado, que admite 8 etiquetas (1-8). El enrutador sondea el tráfico en intervalos de 10 minutos. |
|
26-180 |
Servicio de actualización |
Nuevos valores de servicio y cuotas de tiempo para un servicio existente. VSA etiquetado, que admite 8 etiquetas (1-8). |
Cadena: service-name |
Ver también
Descripción general de los inicios de sesión del suscriptor y los fallos de activación del servicio
Cuando un suscriptor intenta iniciar sesión y es autenticado por RADIUS, el mensaje de aceptación de acceso puede incluir servicios en el VSA de activación de servicio de RADIUS (26-65) que se activarán para una familia de red en particular. Según la configuración y el tipo de servicio, si no se activa un servicio, se puede denegar el inicio de sesión del suscriptor.
Puede usar la service activation instrucción en el nivel de [edit access profile profile-name radius optionsjerarquía ] para configurar el comportamiento posterior a un error de activación.
Use las siguientes opciones para configurar este comportamiento por separado para dos tipos de servicios:
dynamic-profile: este tipo de servicio se configura en el perfil dinámico que aplica el perfil de acceso del suscriptor.extensible-service: este tipo de servicio se configura en una secuencia de comandos de operación de Extensible Subscriber Services Manager (ESSM). Estos servicios suelen configurar nuevas interfaces para suscriptores empresariales.
Utilice las siguientes opciones para especificar si la activación correcta de estos servicios es necesaria u opcional para el acceso de inicio de sesión del suscriptor:
required-at-login: es necesaria la activación. Si se produce un error por cualquier motivo, se producirá un error en Network-Family-Activate-Request para esa familia de redes. Si no hay ninguna otra familia de red activa para el suscriptor, la aplicación cliente cierra la sesión del suscriptor. Este es el comportamiento predeterminado para el tipo dedynamic-profileservicio.optional-at-login: la activación es opcional. Un error debido a errores de configuración no impide la activación de la familia de direcciones; Permite el acceso de los suscriptores. Un error por cualquier otro motivo provoca un error en la activación de la familia de red. Si no hay ninguna otra familia de red activa para el suscriptor, la aplicación cliente cierra la sesión del suscriptor. Este es el comportamiento predeterminado para el tipo deextensible-serviceservicio.
Los errores asociados con la activación de políticas seguras de suscriptor (para suscribir tráfico a un dispositivo de mediación) no tienen ningún efecto en el acceso de los suscriptores sujetos a la política.
Esta configuración no se aplica a los servicios activados por medio de solicitudes CoA de RADIUS, mensajes de solicitud de perfil de inserción (PPR) de JSRC o políticas de seguridad del suscriptor.
Para el tipo de dynamic-profile servicio, los errores de configuración incluyen los siguientes:
Errores de análisis del perfil dinámico y sus atributos.
Faltan variables de usuario obligatorias.
Referencias a perfiles dinámicos que no existen.
Errores de comprobación semántica en el perfil dinámico.
Para el tipo de extensible-service servicio, los errores de configuración incluyen los siguientes:
Errores de análisis de la secuencia de comandos de operación.
Cometa errores.
Para activar un servicio, authd envía una solicitud de activación para los servicios apropiados a la infraestructura de gestión de suscriptores (SMI). Por ejemplo, si la solicitud es para la familia IPv4, solicita la activación de solo los servicios IPv4. A su vez, la SMI envía solicitudes a los demonios de servidor asociados con el servicio, como cosd o filterd. Los resultados devueltos por los daemons determinan si la activación del servicio se realiza correctamente o no.
Cuando todos los demonios de servidor informan de que se han realizado correctamente, SMI informa de que se ha realizado correctamente a authd y se activa el servicio.
Si algún daemon de servidor informa de un error de configuración y ningún daemon informa de un error de no configuración, SMI informa de un error de configuración a authd. El servicio no está activado, pero dependiendo de la configuración, la activación de la familia de red puede realizarse correctamente.
Si algún daemon de servidor informa de un error de no configuración, SMI informa de un error a authd y el servicio no se activa.
Proceso de activación de la familia de servicios y redes
Cuando un suscriptor inicia sesión, authd tiene que activar la familia de direcciones correspondiente después de autenticar al suscriptor. La aplicación cliente, como DHCP o PPP, puede solicitar la activación de una sola familia de red, IPv4 o IPv6, o puede solicitar secuencialmente que se activen ambas familias. La activación exitosa de la familia de la red está relacionada con la activación de los servicios asociados. Los siguientes pasos describen el proceso cuando authd está configurado para usar RADIUS para la autenticación:
Un suscriptor intenta iniciar sesión.
La aplicación cliente solicita autenticación de authd.
authd envía un mensaje de solicitud de acceso al servidor RADIUS.
El servidor RADIUS envía un mensaje Access-Accept a authd que incluye el VSA RADIUS Activate-Service (26-65).
AUTHD almacena en caché los atributos de activación del servicio y envía una concesión a la aplicación cliente.
La aplicación cliente envía la primera solicitud Network-Family-Activate para la familia de direcciones IPv4 o IPv6. Esta solicitud se denomina a veces solicitud client-activate.
authd revisa los atributos de activación de servicios almacenados en caché y envía una solicitud de activación para los servicios adecuados a la infraestructura de administración de suscriptores (SMI). Por ejemplo, si la solicitud es para la familia IPv4, solicita la activación de solo los servicios IPv4. A su vez, la SMI envía solicitudes a los demonios de servidor asociados con el servicio, como cosd o filterd.
Lo que authd haga a continuación depende de si la solicitud de activación del servicio falla y si el servicio es opcional o obligatorio.
Cuando se produce un error en la activación del servicio debido a un error de configuración y el servicio es opcional:
AUTHD elimina los atributos de activación del servicio almacenados en caché para el servicio.
Nota:Esta eliminación le permite volver a emitir la solicitud de servicio mediante una solicitud de cambio de autorización (CoA) de RADIUS o un comando de CLI, sin interferencia del servicio con errores.
authd envía un ACK en respuesta a la solicitud de activación de la familia y la familia se activa.
El inicio de sesión del suscriptor continúa.
Cuando se produce un error en la activación del servicio debido a un error de configuración y se requiere el servicio:
AUTHD elimina los atributos de activación del servicio almacenados en caché para el servicio.
Nota:Esta eliminación le permite volver a emitir la solicitud de servicio mediante una solicitud de cambio de autorización (CoA) de RADIUS o un comando de CLI, sin interferencia del servicio con errores.
authd envía un NACK en respuesta a la activación familiar, lo que hace que la aplicación cliente finalice el inicio de sesión del suscriptor.
Cuando se produce un error en la activación del servicio debido a un error de no configuración y el servicio es opcional o obligatorio:
AUTHD elimina los atributos de activación del servicio almacenados en caché para el servicio.
Nota:Esta eliminación le permite volver a emitir la solicitud de servicio mediante una solicitud de cambio de autorización (CoA) de RADIUS o un comando de CLI, sin interferencia del servicio con errores.
authd envía un NACK en respuesta a la activación familiar, lo que hace que la aplicación cliente finalice el inicio de sesión del suscriptor.
Cuando la activación del servicio se realiza correctamente:
authd activa el servicio.
authd envía un ACK en respuesta a la solicitud de activación de la familia y la familia se activa.
El inicio de sesión del suscriptor continúa.
A menos que se requiriera la activación del servicio y se produjera un error, lo que provocara un error en la activación de la familia en la primera solicitud, la aplicación cliente puede enviar una segunda solicitud, pero solo para la familia que no se solicitó la primera vez. Si la primera solicitud fue para IPv4, la segunda solicitud solo puede ser para IPv6. Si la primera solicitud fue para IPv6, la segunda solicitud solo puede ser para IPv4.
AUTHD revisa los atributos de activación de servicios almacenados en caché y solicita la activación de los servicios asociados con la familia de direcciones solicitada.
Lo que authd haga a continuación depende de si la solicitud de activación del servicio falla y si el servicio es opcional o obligatorio.
Cuando se produce un error en la activación del servicio debido a un error de configuración y el servicio es opcional:
AUTHD elimina los atributos de activación del servicio almacenados en caché para el servicio.
Nota:Esta eliminación le permite volver a emitir la solicitud de servicio mediante una solicitud de cambio de autorización (CoA) de RADIUS o un comando de CLI, sin interferencia del servicio con errores.
authd envía un ACK en respuesta a la solicitud de activación de la familia y la familia se activa.
El inicio de sesión del suscriptor continúa.
Cuando se produce un error en la activación del servicio debido a un error de configuración y se requiere el servicio:
AUTHD elimina los atributos de activación del servicio almacenados en caché para el servicio.
Nota:Esta eliminación le permite volver a emitir la solicitud de servicio mediante una solicitud de cambio de autorización (CoA) de RADIUS o un comando de CLI, sin interferencia del servicio con errores.
authd envía un NACK en respuesta a la activación familiar. Dado que se trata de la segunda solicitud de activación familiar, el resultado de la primera activación familiar determina lo que sucede a continuación:
Si la primera activación familiar se realizó correctamente y ese suscriptor inició sesión, el error de la segunda solicitud no detiene el inicio de sesión del suscriptor actual. Este evento tampoco hace que authd cierre la sesión del suscriptor anterior (primera solicitud).
Si la primera activación de familia no se realizó correctamente, un error de la segunda solicitud hace que la aplicación cliente finalice el inicio de sesión del suscriptor actual.
Cuando se produce un error en la activación del servicio debido a un error de no configuración y el servicio es opcional o obligatorio:
AUTHD elimina los atributos de activación del servicio almacenados en caché para el servicio.
Nota:Esta eliminación le permite volver a emitir la solicitud de servicio mediante una solicitud de cambio de autorización (CoA) de RADIUS o un comando de CLI, sin interferencia del servicio con errores.
authd envía un NACK en respuesta a la activación familiar, lo que hace que la aplicación cliente finalice el inicio de sesión del suscriptor.
Cuando la activación del servicio se realiza correctamente:
authd activa el servicio.
authd envía un ACK en respuesta a la solicitud de activación de la familia y la familia se activa.
El inicio de sesión del suscriptor continúa.
Configurar cómo afectan los errores de activación del servicio al inicio de sesión del suscriptor
Puede configurar cómo un error de activación de servicios opcionales durante el inicio de sesión del suscriptor afecta el resultado del inicio de sesión. Estos servicios opcionales son aquellos a los que hace referencia el VSA de servicio activado de RADIUS (26-65) que aparece en el mensaje de aceptación de acceso de RADIUS durante el inicio de sesión inicial del suscriptor.
Puede configurar estos dos tipos de activación de servicio para que sean obligatorios u opcionales.
dynamic-profile: estos servicios se configuran en el perfil dinámico que aplica el perfil de acceso del suscriptor para proporcionar acceso del suscriptor y servicios para aplicaciones de banda ancha. De forma predeterminada, la activación del servicio es necesaria para iniciar sesión correctamente. Un error de configuración durante la activación del servicio impide que se active la familia de redes y hace que se produzca un error en el inicio de sesión del suscriptor.extensible-service: estos servicios se aplican mediante scripts de operación gestionados por el daemon Extensible Subscriber Services Manager (ESSM) (ESSMD) para suscriptores empresariales. De forma predeterminada, la activación del servicio es opcional para el inicio de sesión exitoso del suscriptor.
La service-activation configuración de la instrucción solo afecta a los errores de activación debidos a errores de configuración en el perfil dinámico o en la secuencia de comandos de operación ESSM. Los errores debidos a errores de no configuración siempre dan lugar a la denegación de acceso para el suscriptor y a la finalización del intento de inicio de sesión.
Para configurar el comportamiento de los servicios de perfiles dinámicos, realice una de las siguientes acciones:
Especifique que la activación del servicio es opcional.
[edit access profile profile-name radius options service-activation] user@host# set dynamic-profile optional-at-login
Especifique que la activación del servicio es necesaria (valor predeterminado).
[edit access profile profile-name radius options service-activation] user@host# set dynamic-profile required-at-login
Para configurar el comportamiento de los servicios ESSM, realice una de las siguientes acciones:
Especifique que es necesaria la activación del servicio.
[edit access profile profile-name radius options service-activation] user@host# set extensible-service required-at-login
Especifique que la activación del servicio es opcional (la opción predeterminada).
[edit access profile profile-name radius options service-activation] user@host# set extensible-service optional-at-login
Ver también
Códigos de causa de error (atributo RADIUS 101) para solicitudes dinámicas
Cuando una operación de CoA o desconexión iniciada por RADIUS no se realiza correctamente, el enrutador incluye un atributo de causa de error (atributo RADIUS 101) en el mensaje CoA-NAK o Disconnect-NAK que envía de vuelta al servidor de RADIUS. Si el error detectado no se asigna a uno de los atributos de causa de error admitidos, el enrutador envía el mensaje sin un atributo de causa de error. En el Cuadro 4 se describen los códigos de causa de error.
Código |
Valor |
Descripción |
|---|---|---|
401 |
Atributo no compatible |
La solicitud contiene un atributo que no se admite (por ejemplo, un atributo de terceros). |
402 |
Atributo faltante |
Falta un atributo crítico (por ejemplo, el atributo de identificación de sesión) en una solicitud. |
404 |
Solicitud no válida |
Algún otro aspecto de la solicitud no es válido, como si uno o más atributos no tienen el formato adecuado. |
503 |
No se encontró el contexto de la sesión |
El contexto de sesión identificado en la solicitud no existe en el enrutador. |
504 |
El contexto de la sesión no extraíble |
El suscriptor identificado por atributos en la solicitud es propiedad de un componente que no es compatible. |
506 |
Recursos no disponibles |
No se pudo cumplir una solicitud debido a la falta de recursos de NAS disponibles (como la memoria). |
Ver también
Verificar estadísticas de solicitudes dinámicas de RADIUS
Propósito
Muestra estadísticas e información de solicitudes dinámicas de RADIUS.
Acción
Para mostrar estadísticas de solicitudes dinámicas de RADIUS:
user@host>show network-access aaa statistics dynamic-requests
Ver también
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.