Foro en Español

Reply
Highlighted
Aruba Employee

[Tutorial] Onboard con Sponsor y control de duración del certificado

La autenticación de los dispositivos que se quieren conectar a la red (wireless or wired) es uno de los requisitos más demandados a día de hoy. La autenticación no sólo nos permite tener control y visibilidad de quien se conecta a la red, sino que nos permite poder aplicar autorización a la conexión para definir que tipo de conectividad tendrá un dispositivo según el contexto (quien se conecta, desde que dispositivo, desde donde, a qué hora, etc).

Hay varios puntos a tener en cuenta a la hora de pensar en la implementación de un proyecto de autenticación:

  • Mecanismo y método de autenticación: existen diferentes mecanismos de autenticación (los más utilizados son MAC Auth, Captive Portal, 802.1X) que permiten validar a un dispositivo a la red y cada mecanismo puede tener diferentes métodos (PAP, CHAP, EAP-PEAP, EAP-TLS, etc). Cada mecanismo y método de autenticación tiene un ámbito diferente donde aplicarse, por ejemplo:
    • MAC Auth: Para validar a dispositivos que no disponen de suplicante 802.1X (impresoras, teléfonos, cámaras, etc) pero que tienen que tener acceso a la red
    • Captive portal: Para validar a usuarios sin credenciales corporativas (guest) o usuarios corporativos que no tienen configurado un mecanismo más seguro como 802.1X
    • 802.1X: Para validar usuarios/dispositivos con credenciales corporativas. El método más seguro es EAP-TLS, donde existe una autenticación tanto del dispositivo/usuario como del servidor RADIUS utilizando certificados digitales.
  • Configuración de la electrónica de red y servidor RADIUS: La electrónica de red debe permitir poder autenticar a un dispositivo con diferentes mecanismos para asegurar que, independientemente de quien se conecte, pueda tener una conexión adecuada a su contexto. Por su parte, el servidor RADIUS tiene que permitir poder definir políticas para autenticar tanto a dispositivos wired como wireless. También es importante que permita trabajar con electrónica de red de diferentes fabricantes. En este enlace podréis encontrar una guía para la configuración de switches de Aruba, HPE y Cisco y su integración con ClearPass para realizar autenticaciones MAC, Captive Portal y 802.1X.
  • Configuración segura del suplicante 802.1X: Uno de los puntos más olvidados en este tipo de despliegues es la configuración del suplicante 802.1X (es el que inicia la autenticación). Es importante realizar una configuración correcta para evitar ataques de tipo man-in-the-middle; en este enlace encontrareis un post donde se explica la configuración adecuada del suplicante. Lo más habitual es utilizar el suplicante que viene por defecto en el sistema operativo del dispositivo y es posible desplegar su configuración a través de políticas GPO del AD.

La configuración ideal para una red autenticada seria el poder validar a todos los dispositivos posibles con 802.1X con EAP-TLS (certificado digital). En este caso, otro punto a tener en cuenta es la distribución de los propios certificados, ya que si se dispone de un parque muy grande puede llegar a ser una tarea compleja. Existen herramientas que permiten automatizar este despliegue, se puede hacer a través de políticas GPO del AD, MDM o utilizando la funcionalidad de OnBoard de ClearPass. Esta última, además de automatizar el despliegue del propio certificado, permite automatizar la configuración del suplicante 802.1X del dispositivo en un único proceso automatizado a través de un portal web.

 

El objetivo de este post es el de centrarse en el caso particular de querer automatizar el despliegue de certificados y configuración segura del suplicante 802.1X para usuarios temporales y sin credenciales corporativas (consultores, contractors, etc) a los que queremos dar acceso a la red de una forma controlada, segura, temporal y sin tener que crear credenciales temporales en los sistemas de identidad de la compañía.

 

Para poder conseguir este objetivo vamos a mezclar diferentes funcionalidades que tiene ClearPass:

  • ClearPass Guest: Va a permitir definir un flujo muy flexible para dar acceso al servicio de Onboard. Se creará una cuenta guest temporal para el usuario que permitirá asegurar que no se puede realizar el Onboard hasta que no se de el acceso adecuado
  • Guest con Sponsor: Va a permitir que el usuario temporal no pueda iniciar el proceso de Onboard hasta que una persona corporativa no lo valide. Al utilizar la funcionalidad de Sponsor de ClearPass Guest se pueden utilizar todas las opciones avanzadas que permite, como puede ser que el Sponsor seleccione el periodo de validez de la cuenta de guest y, por tanto, el tiempo de duración del certificado o validar que el Sponsor sea de un grupo del AD o de un dominio concreto.
  • ClearPass Onboard: Va a permitir definir que tipo de certificado se va a generar para el usuario temporal y los parámetros adecuados para la configuración del suplicante 802.1X

Una cosa a tener en cuenta es que no se va a utilizar la opción de Sponsor de Onboard, ya que proporciona tanta flexibilidad, por ejemplo, no permitiría seleccionar la duración del certificado digital que se crearía y requeriría de un sistema de identidad externo para validar a diferentes usuarios que quieran hacer el Onboard.

 

WORKFLOW:

El flujo de ejecución que vamos a tener es el siguiente:

  • El usuario temporal se va a conectar a un SSID abierto con portal cautivo (puede ser el SSID de invitados). En caso de una red cableada, se puede conectar a un puerto donde esté configurado la redirección a un portal cautivo
  • Al intentar navegar, el usuario va a ser redirigido al portal cautivo, donde habrá un enlace para iniciar el proceso de Onboard
  • El primer paso para iniciar el proceso será rellenar un formulario donde se le pedirán datos importantes para identificarlo (nombre, email, empresa, teléfono, etc) y la dirección de correo de la persona que tiene que permitir su proceso de Onboard (Sponsor), es como un autoregistro con Sponsor de ClearPass Guest
  • Una vez rellenado el formulario se le redireccionará a otra página donde se le mostrará la información de su conexión que nosotros configuremos y se le indicará que está a la espera de que el Sponsor apruebe su Onboard
  • En este momento el Sponsor recibirá un email con la solicitud del usuario temporal. En este correo habrá un link que le redireccionará a una página de ClearPass para que acepte o deniegue el Onboard. En esta página, también podrá seleccionar la duración de la cuenta de guest, que será la duración del certificado digital que se generará
  • Una vez aprobado el proceso de Onboard por parte del Sponsor, el usuario temporal verá que se habilita el botón para acceder y podrá iniciar el proceso de Onboard
  • A partir de aquí el proceso es el mismo que el de un proceso habitual de Onboard, donde se instala el perfil con la configuración del suplicante 802.1X y el certificado digital creado para ese usuario con ese dispositivo.
  • Una vez terminado el proceso de Onboard, el dispositivo del usuario temporal tendrá configurado el suplicante 802.1X e instalado el certificado digital para poderse conectarse al SSID corporativo o a un puerto cableado con 802.1X habilitado.

Hay que tener en cuenta que aunque durante el proceso no se van a pedir credenciales al usuario si que hay una validación del usuario con unas credenciales temporales (guest) creadas en ClearPass. Estas credenciales temporales no tienen porque ser visibles al usuario, ya que se utilizan para poder controlar la validación del Sponsor y para disponer de la información importante (CN, duración, etc) para incluirla en el certificado digital del usuario (la configuración para no mostrar las credenciales es la misma que en el caso de un Guest con Sponsor).

 

CONFIGURACIÓN:

Este post no tiene como objetivo explicar como configurar todas las opciones de Onboard o de Sponsor de Guest, se van a explicar las configuraciones para poder unir ambas funcionalidades y algunas configuraciones especificas para disponer del comportamiento esperado.

El primer paso es configurar la funcionalidad de Onboard según las características de nuestra red, habrá que configurar la parte de Network Settings, Configuration Profile y Provisioning Settings (no hay que configurar la parte de Sponsorship Configuration). Podéis encontrar videos de Configuracion de Onboard en este enlace.

Una vez configurado el Onboard hay que configurar un portal de Guest con Sponsor tal y como se configuraría para un proceso habitual de Sponsor. Las configuraciones especificas para conseguir el objetivo definido son:

  • Relacionar el portal Guest con el proceso de Onboard para que una vez el usuario esté autenticado en la red se inicie de forma automática el proceso de Onboard. En la configuración del portal Guest con Sponsor:
    • Login >> Enabled >> Enable Onboard device enrollment
    • Login >> Provisioning Settings >> seleccionar el perfil de provisión creado en el apartado de Onboard
  • Opción para que el Sponsor pueda seleccionar el tiempo de duración del certificado:
    • Sponsor Confirmation >> Account Overrides >> Extend Expiration. Se pueden poner diferentes valores (uno por línea) para que el Sponsor escoja antes de validar el acceso. El certificado tendrá de duración el tiempo seleccionado por el Sponsor añadiéndole 30 minutos adicionales.
  • Opción para limitar que las direcciones de correo de los Sponsor sean de un dominio concreto:
    • En el campo sponsor_email del formulario de la pagina creada hay que modificar el valor de Validator Argument con:

 

array (
  'allow' =>
  array (
    0 => 'dominio_permitido.com',
  ),
  'deny' =>
  array (
    0 => '*',
  ),
)

 

Una vez realizada esta configuración cumpliremos con los puntos que se habían definido como objetivo del post.

Una vez realizado el proceso de Onboard el dispositivo tendrá configurado el suplicante 802.1X con los parámetros indicados en el Provissioning Settings de Onboard y dispondrá de un certificado digital para autenticarse a la red del que hay que destacar que su CN será el username de la cuenta de invitados creada (por defecto la dirección de correo que haya introducido el usuario), se incluye información de la dirección MAC, sistema operativo y nombre del dispositivo y se incluye un campo con la dirección de correo del Sponsor que ha validado el proceso de Onboard. 

En la siguiente imagen se pueden ver los valores añadidos al certificado y como la validez del certificado es de 1 día + 30 minutos (el Sponsor seleccionó una validez de 1 día).Picture1.png

Picture2.png
LICENCIAMIENTO NECESARIO:

 

Para poder realizar esta funcionalidad es necesario disponer de licencias ACCESS y Onboard de ClearPass. En este enlace se explica como se tienen que dimensionar las licencias.

Hay que tener en cuenta que con el nuevo sistema de licenciamiento (a partir de la versión 6.7 de ClearPass) la funcionalidad de Guest no requiere una licencia adicional, está incluida en la licencia ACCESS.

Frequent Contributor I

Re: [Tutorial] Onboard con Sponsor y control de duración del certificado

Muchas gracias por este tutorial


Ricardo Luis Cañavate García - ACMP / ACCA / ACCP / ACDX#972
Contributor I

Re: [Tutorial] Onboard con Sponsor y control de duración del certificado

Muy bueno!

Carlos Villanueva Humanes
ACMP
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: