El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
La versión 1.3 del Cisco Identity Services Engine (ISE) tiene un tipo nuevo de portal del invitado llamado el portal registrado uno mismo del invitado, que permite el uno mismo-registro de los Usuarios invitados cuando él accede a los recursos de red. Este portal permite que usted configure y que personalice las características múltiples. Este documento describe cómo configurar y resolver problemas estas funciones.
Cisco recomienda que usted tiene experiencia con la configuración ISE y el conocimiento básico de estos temas:
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
Este escenario presenta las opciones múltiples disponibles para los Usuarios invitados cuando realizan el uno mismo-registro.
Aquí está el flujo general:
Paso 1. Socios del Usuario invitado al Service Set Identifier (SSID): Invitado. Esto es una red abierta con el MAC que filtra con el ISE para la autenticación. Esta autenticación hace juego la segunda regla de la autorización en el ISE y el perfil de la autorización reorienta al portal registrado uno mismo del invitado. El ISE vuelve un access-accept RADIUS con dos cisco av-pair:
Paso 2. Reorientan al Usuario invitado al ISE. Bastante que las credenciales para iniciar sesión, el usuario que los tecleos “no tienen una cuenta”. Reorientan al usuario a una página donde esa cuenta puede ser creada. Un código secreto opcional del registro se pudo habilitar para limitar el privilegio del uno mismo-registro a la gente que conoce ese valor secreto. Después de que se cree la cuenta, el usuario es credenciales proporcionadas (nombre de usuario y contraseña) y abre una sesión con esas credenciales.
Paso 3. El ISE envía un cambio RADIUS de la autorización (CoA) Reauthenticate al WLC. El WLC reautentifica al usuario cuando envía el pedido de acceso del RADIO con el atributo del autorizar-Solamente. El ISE responde con el access-accept y el Airespace ACL definidos localmente en el WLC, que proporciona el acceso a Internet solamente (el acceso final para el Usuario invitado depende de la directiva de la autorización).
Observe que para las sesiones del Protocolo de Autenticación Extensible (EAP), el ISE debe enviar un CoA termina para accionar la reautentificación porque la sesión EAP está entre el supplicant y el ISE. Pero para MAB (MAC que filtra), el CoA Reauthenticate es bastante; no hay necesidad de-associate/de-authenticate el cliente de red inalámbrica.
Paso 4. El Usuario invitado ha deseado el acceso a la red.
Las características adicionales múltiples como la postura y Bring Your Own Device (BYOD) pueden ser habilitadas (discutido más adelante).
Utilize esta sección para confirmar que su configuración funcione correctamente.
Esta sección proporciona la información que usted puede utilizar para resolver problemas su configuración.
En esta etapa, el ISE presenta estos registros:
Aquí está el flujo:
Los informes (las operaciones > señalan que > el ISE señala > los informes del acceso de invitado > informe del invitado del master) también confirman eso:
Un usuario del patrocinador (con los privilegios correctos) puede verificar el estado actual de un Usuario invitado.
Este ejemplo confirma que la cuenta está creada, pero el usuario nunca ha abierto una sesión (“aguardando la conexión con el sistema inicial”):
Para cada etapa de este flujo, diversas opciones pueden ser configuradas. Todo el esto se configura por el portal del invitado en el acceso de invitado > la configuración > los portales > PortalName del invitado > edita > las configuraciones porta del comportamiento y del flujo. Configuraciones más importantes incluyen:
Si seleccionan a los invitados uno mismo-registradoes Require a ser opción aprobada, después la cuenta creada por el invitado se debe aprobar por un patrocinador. Esta característica pudo utilizar el correo electrónico para entregar la notificación al patrocinador (para la aprobación de la cuenta de invitado):
Si el servidor o el valor por defecto del Simple Mail Transfer Protocol (SMTP) de la notificación del correo electrónico no se configura, después la cuenta no será creada:
El registro de guest.log confirma que el global del direccionamiento usado para la notificación falta:
2014-08-01 22:35:24,271 ERROR [http-bio-10.62.97.21-8443-exec-9][] guestaccess.
flowmanager.step.guest.SelfRegStepExecutor -:7AAF75982E0FCD594FE97DE2970D472F::-
Catch GuestAccessSystemException on sending email for approval: sendApproval
Notification: From address is null. A global default From address can be
configured in global settings for SMTP server.
Cuando usted tiene la configuración apropiada del correo electrónico, se crea la cuenta:
Después de que usted permita a los invitados uno mismo-registradoes Require para ser opción aprobada, los campos del nombre de usuario y contraseña se quitan automáticamente del incluir esta información sobre la sección de la página del éxito del Uno mismo-registro. Esta es la razón por la cual, cuando la aprobación del patrocinador es necesaria, las credenciales para los Usuarios invitados no se visualizan por abandono en la página web que presenta la información para mostrar que se ha creado la cuenta. En lugar deben ser entregadas por los servicios de mensajería cortos (SMS) o el correo electrónico. Esta opción se debe habilitar en la notificación credencial del envío sobre la aprobación usando la sección (marca email/SMS).
Un correo electrónico de notificación se entrega al patrocinador:
Los registros del patrocinador en el patrocinador porta y aprueban la cuenta:
Desde aquí, se permite al Usuario invitado iniciar sesión (con las credenciales recibidas por el correo electrónico o SMS).
En resumen, hay tres direcciones de correo electrónico usadas en este flujo:
Las credenciales del invitado se pueden también entregar por SMS. Estas opciones deben ser configuradas:
Si seleccionan a los invitados de la permit para registrar la opción de dispositivos después de que un Usuario invitado abra una sesión y valide el AUP, usted puede registrar los dispositivos:
Note que el dispositivo se ha agregado ya automáticamente (está en la lista de dispositivos Manage). Esto es porque los dispositivos del invitado del registro fueron seleccionados automáticamente.
Si se selecciona la opción de la conformidad del dispositivo del invitado del requerir, después los Usuarios invitados son aprovisionado con un agente que realice la postura (agente NAC/Web) después de que inicien sesión y validen el AUP (y realice opcionalmente el registro del dispositivo). El ISE procesa las reglas del aprovisionamiento del cliente para decidir a qué agente debe ser aprovisionado. Después el agente que se ejecuta en la estación realiza la postura (según las reglas de la postura) y envía los resultados al ISE, que envía el CoA reauthenticate para cambiar el estatus de autorización si es necesario.
Las reglas posibles de la autorización pudieron parecer similares a esto:
Los primeros usuarios nuevos que encuentran la regla de Guest_Authenticate para reorientar al portal del invitado del registro del uno mismo. Después de que los uno mismo-registros del usuario y abran una sesión, el CoA cambia el estatus de autorización y proporcionan el usuario el acceso limitado para realizar la postura y la corrección. Solamente después que es el agente del NAC el aprovisionado y la estación es obedientes hace el estatus de autorización del cambio CoA de nuevo para proporcionar el acceso a Internet.
Los problemas comunes con la postura incluyen la falta de reglas correctas del aprovisionamiento del cliente:
Esto puede también ser confirmada si usted examina el archivo de guest.log (nuevo en la versión 1.3 ISE):
2014-08-01 21:35:08,435 ERROR [http-bio-10.62.97.21-8443-exec-9][] guestaccess.
flowmanager.step.guest.ClientProvStepExecutor -:7AAF75982E0FCD594FE97DE2970D472F::-
CP Response is not successful, status=NO_POLICY
Si seleccionan a los empleados de la permit para utilizar los dispositivos personales en la opción de red, después los usuarios corporativos que utilizan este portal pueden pasar con BYOD fluyen y registran los dispositivos personales. Para los Usuarios invitados, esa configuración no cambia cualquier cosa.
¿Qué los “empleados que usan el portal como invitado” significan?
Por abandono, los portales del invitado se configuran con el almacén de la identidad de Guest_Portal_Sequence:
Ésta es la secuencia interna del almacén que intenta a los usuarios internos primero (antes de los Usuarios invitados):
Cuando en esta etapa en el portal del invitado, el usuario proporciona las credenciales que se definen en los usuarios internos salvan y el cambio de dirección BYOD ocurre:
Los usuarios corporativos de esta manera pueden realizar BYOD para los dispositivos personales.
Cuando en vez de las credenciales de los usuarios internos, se proporcionan se continúan las credenciales de los Usuarios invitados, flujo normal (ningún BYOD).
Esto es una opción similar al cambio de VLAN configurado para el portal del invitado en la versión 1.2 ISE. Permite que usted ejecute activeX o los subprogramas java, que acciona el DHCP para liberar y para renovar. Esto es necesario cuando el CoA acciona el cambio del VLA N para el punto final. Cuando se utiliza el MAB, el punto final no es consciente de un cambio del VLA N. Una Solución posible es cambiar el VLA N (la versión del DHCP/renueva) con el agente del NAC. Otra opción es pedir una nueva dirección IP vía el applet vuelto en la página web. Un retardo entre la versión/CoA/renueva puede ser configurado. Esta opción no se soporta para los dispositivos móviles.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
13-Feb-2015 |
Versión inicial |