Migración multisitio de RADIUS: secuenciación de sitios, puntos de acceso y políticas

Puede migrar un entorno multisitio a RADIUS en la nube en cuatro fases sin necesidad de una transición repentina mientras los servidores anteriores y los nuevos funcionan a la par. Cada SSID lista ambos, y cada dispositivo confía en el certificado del nuevo servidor. Cada sitio realiza la transición bajo IEEE 802.1X con una prueba de salida por escrito. En Purple, la transición en sí suele ser un ejercicio de fin de semana.

¿Qué cambia en una migración de RADIUS multisitio y qué permanece igual?

El estado final es una sola directiva de RADIUS en la nube que atiende a cada sitio, donde la identidad define la VLAN. RADIUS, definido en RFC 2865, es el protocolo que sus puntos de acceso utilizan para preguntar a un servidor si un dispositivo puede conectarse. El servidor acepta o rechaza el dispositivo. También puede devolver atributos como la VLAN, el segmento de red donde termina el dispositivo.

En una red segura, ese intercambio se ejecuta dentro de IEEE 802.1X, el estándar para el control de acceso a la red basado en puertos. 802.1X transporta EAP (Extensible Authentication Protocol) entre el dispositivo, el punto de acceso y el servidor. EAP-TLS, definido en RFC 5216, autentica a ambas partes mediante certificados. PEAP envuelve un intercambio de contraseñas dentro de un túnel TLS.

Cuatro cosas cambian:

• Cada punto de acceso o controlador apunta a una nueva dirección de servidor y secreto compartido. RADIUS denomina a ese dispositivo como el NAS (network access server).
• Los dispositivos ven un nuevo certificado de servidor durante la negociación EAP.
• La directiva lee los grupos de Microsoft Entra ID, Okta o Google Workspace en lugar de un directorio local.
• Los registros se trasladan a una nueva consola.

Las cosas que permanecen igual importan más. Conserva sus puntos de acceso, nombres de SSID, IDs de VLAN, enlaces troncales de switches y zonas de firewall. Nadie cambia una contraseña ni se une a una red nueva.

El mismo enfoque se aplica a las tres redes en Purple Access. En redes abiertas, muchos portales cautivos autorizan dispositivos mediante RADIUS. Las redes seguras utilizan EAP-TLS o PEAP. En redes xPSK, RADIUS otorga a cada dispositivo o residente su propia clave precompartida. Esta guía aborda la red segura, ya que es la que conlleva el mayor riesgo.

{"tone":"warning","title":"El riesgo más crítico: confianza en el certificado del servidor","text":"Los dispositivos en EAP-TLS o PEAP verifican el certificado del servidor RADIUS, y muchos solo confían en la autoridad de certificación del servidor anterior. Distribuya la nueva CA a cada perfil de dispositivo antes de que el primer sitio realice la transición, o esos dispositivos no podrán conectarse y seguirán reintentándolo."}

Una vez resuelta la confianza en el certificado, el resto de la migración consiste en trabajo de configuración y periodos de espera.

¿Qué debe cumplirse antes de la fase 1?

Cinco condiciones deben estar listas antes de crear cualquier directiva. Si falta una, causará problemas en una fase posterior.

Un inventario de NAS completo

Enumere todos los dispositivos que envían solicitudes al servidor anterior. Eso incluye puntos de acceso, controladores inalámbricos, switches con 802.1X por cable y puertas de enlace VPN. Cree la lista a partir de la lista de clientes RADIUS del servidor anterior, no del diagrama de red. Si falta un NAS en el inventario, no podrá apagar el servidor anterior en la fase 4.

Un mapa de políticas, fila por fila

Anote cada regla que aplica el servidor anterior, junto con su condición, su resultado y los atributos que devuelve. Las filas típicas se ven así: grupo de personal a VLAN de personal, contratistas a una VLAN restringida, laptops corporativas por certificado a la VLAN corporativa. Note qué atributos llevan la VLAN. RFC 3580 define el conjunto estándar: Tunnel-Type, Tunnel-Medium-Type y Tunnel-Private-Group-ID. En su lugar, algunas instalaciones utilizan atributos específicos del proveedor, y debe replicarlos exactamente.

Un plan de certificados

Decida qué autoridad de certificación (CA) emite el nuevo certificado del servidor. En dispositivos administrados, distribuya esa CA a través de Microsoft Intune, Jamf o su plataforma de administración de dispositivos móviles (MDM) antes de trasladar cualquier sitio. Para EAP-TLS, el nuevo servidor también debe confiar en la CA que emitió los certificados de sus dispositivos.

Una fuente de identidad que el nuevo servidor pueda leer

Conecte su proveedor de identidad y confirme que todos los grupos del mapa de políticas existan allí. Si un grupo solo existe en el servidor anterior, vuelva a crearlo primero en el proveedor de identidad.

Alcanzabilidad, responsables y ventanas de cambio

Cada sitio necesita una ruta de red hacia el servidor en la nube, utilizando las direcciones y puertos de la documentación de incorporación de Purple. Nombre a un responsable para cada sitio y acuerde ventanas de cambio con los administradores del sitio. Anote el detonante de reversión antes de mover cualquier elemento.

{"title":"Lista de verificación para la migración de RADIUS multisitio","groups":[{"heading":"Antes de la fase 1","items":[{"text":"Exporte la lista de clientes RADIUS del servidor antiguo y concíliela con el inventario de NAS","why":"Un NAS olvidado bloquea la desactivación"},{"text":"Mapee cada regla de política: condición, resultado y atributos devueltos"},{"text":"Confirme que cada grupo de políticas exista en Microsoft Entra ID, Okta o Google Workspace"},{"text":"Despliegue la CA del nuevo servidor en los dispositivos administrados a través de su MDM"},{"text":"Abra las rutas indicadas en la documentación de incorporación de Purple en cada sitio"},{"text":"Asigne un responsable y una ventana de cambio por sitio, y acuerde por escrito el activador de reversión"}]},{"heading":"Fase 1: construcción","items":[{"text":"Congele los cambios de políticas en el servidor antiguo"},{"text":"Vuelva a crear cada fila de política en el nuevo servidor"},{"text":"Pruebe una identidad por fila en ambos servidores y verifique que las respuestas coincidan"}]},{"heading":"Fases 2 y 3: piloto y olas de despliegue","items":[{"text":"Registre una tasa de rechazo de referencia por sitio antes del cambio"},{"text":"Agregue el nuevo servidor junto al antiguo en cada SSID"},{"text":"Confirme que cada clase de dispositivo se autentique en el nuevo servidor"},{"text":"Mantenga cada ola de despliegue durante un ciclo comercial completo antes de pasar a la siguiente"}]},{"heading":"Fase 4: desactivación","items":[{"text":"Elimine el servidor antiguo de cada SSID y NAS"},{"text":"Confirme que haya cero solicitudes en el servidor antiguo durante el período de inactividad acordado"},{"text":"Exporte y conserve los registros del servidor antiguo según su política de retención"},{"text":"Retire las claves compartidas utilizadas con el servidor antiguo"},{"text":"Actualice el manual operativo y archive el registro de prueba de salida de cada sitio"}]}],"download":{"filename":"radius-migration-checklist.csv"}}

¿Cuáles son las 4 fases, en orden?

El plan consta de cuatro fases. Cada una termina con una prueba de salida que se aprueba o se reprueba. Nada pasa a la siguiente fase hasta que se apruebe la prueba, evitando así una transición drástica sin retorno.

{"kind":"timeline","direction":"lr","caption":"An illustrative 40-site estate: four phases, each closed by an exit test","alt":"Timeline showing preparation, then phase 1 build, phase 2 pilot, phase 3 waves and phase 4 decommission across roughly 12 weeks.","nodes":[{"id":"p0","label":"Before phase 1","sub":"Inventory, policy map, CA push, identity source","tone":"neutral","when":"Weeks 1-2"},{"id":"p1","label":"Phase 1: build and mirror","sub":"Policy rebuilt on cloud RADIUS, lab replies match","tone":"brand","when":"Week 3"},{"id":"p2","label":"Phase 2: pilot site","sub":"One site, old server kept as secondary","tone":"brand","when":"Weeks 4-5"},{"id":"p3","label":"Phase 3: waves","sub":"Five, then 10, then the remaining 24 sites","tone":"brand","when":"Weeks 6-10"},{"id":"p4","label":"Phase 4: decommission","sub":"Zero requests on the old server, then shut down","tone":"success","when":"Weeks 11-12"}],"edges":[{"from":"p0","to":"p1","label":"prerequisites met"},{"from":"p1","to":"p2","label":"lab replies match"},{"from":"p2","to":"p3","label":"pilot exit test"},{"from":"p3","to":"p4","label":"all sites cut over"}]}

{"caption":"Plan de fases para una migración de RADIUS en múltiples sitios","asOf":"2026-06-10","columns":[{"key":"phase","label":"Fase"},{"key":"scope","label":"Alcance"},{"key":"owner","label":"Responsable"},{"key":"exit","label":"Prueba de salida"}],"rows":[["Antes de la fase 1","Inventario NAS, mapa de políticas, despliegue de CA, fuente de identidad, rutas por sitio","Gerente de TI con el líder de identidad y acceso","Cada NAS listado, cada grupo de políticas en el proveedor de identidad, nueva CA en dispositivos administrados"],["Fase 1: construcción","Política reconstruida en RADIUS en la nube, sin tráfico en vivo","Líder de identidad y acceso","Una identidad de prueba por fila obtiene la misma respuesta y VLAN desde el servidor anterior y el nuevo"],["Fase 2: piloto","Un sitio representativo, nuevo servidor primario, anterior secundario","Arquitecto de red","Un ciclo operativo sin rechazos no explicados y cada clase de dispositivo vista en el nuevo servidor"],["Fase 3: olas","Sitios restantes en olas crecientes, agrupados por plantilla de consola","Arquitecto de red con responsables del sitio","Cada ola aprueba la prueba de salida del piloto antes de que comience la siguiente"],["Fase 4: desmantelamiento","Servidor anterior eliminado de cada SSID y NAS","Gerente de TI","Cero solicitudes en el servidor anterior durante el periodo de calma, registros conservados, secretos retirados"]],"footnote":"Los responsables son roles, no personas específicas. Establezca el periodo de calma en al menos un ciclo de reautenticación más una semana hábil.","download":{"filename":"radius-migration-phase-plan.csv"}}

¿Qué sucede dentro de cada fase?

Fase 1: construir y replicar la política

Reconstruya el mapa de políticas en el nuevo servidor antes de que le llegue cualquier solicitud en vivo. Conecte el proveedor de identidad y luego vuelva a crear cada fila con su condición, resultado y atributos devueltos. Mantenga los ID de VLAN idénticos para que la configuración del switch y del firewall nunca cambie.

Pruebe cada fila desde un laboratorio. Utilice eapol_test, una herramienta del proyecto wpa_supplicant. Envía un intercambio EAP real a un servidor RADIUS e imprime la respuesta. Ejecute una identidad por fila en ambos servidores y compare las respuestas. La prueba final es una coincidencia en cada fila, con la misma aceptación o rechazo y el mismo VLAN.

Fase 2: prueba piloto en un sitio

Elija un sitio que represente a toda la propiedad, no el más fácil. Debe tener cada clase de dispositivo que utilice, incluidos los más difíciles. Piense en escáneres portátiles, terminales de pago con WiFi y laptops más antiguas. También necesita a alguien en el sitio que pueda probar un dispositivo cuando se le solicite.

Agregue el nuevo servidor junto al anterior, pruébelo y luego convierta el nuevo servidor en el principal. Déjelo así durante un ciclo comercial completo. Para un hotel, eso significa una semana de patrones de turnos. Para una oficina, significa una semana de inicios de sesión los lunes por la mañana. La prueba piloto se aprueba cuando se cumplen dos condiciones. Primero, cada clase de dispositivo se ha autenticado en el nuevo servidor. Segundo, la tasa de rechazo no es peor que su línea base.

Fase 3: mover la propiedad por olas

Haga que cada ola sea más grande que la anterior a medida que se aprueben las primeras. Una propiedad de 40 sitios podría mover un sitio piloto, luego cinco, luego 10 y después los 24 restantes. Agrupe cada ola por plantilla o grupo de consola, de modo que un solo cambio llegue a cada sitio en ella. Las plantillas de configuración de Meraki, las plantillas WLAN de Juniper Mist y los grupos de HPE Aruba Central se adaptan a este enfoque.

Realice la transición mientras el personal del sitio esté presente, no a las 3:00 a. m. Un cambio que nadie prueba hasta la mañana es un cambio que no ha probado. Evite agrupar otros cambios de red en la misma ventana de tiempo.

Fase 4: desmantelar el servidor anterior

Elimine el servidor anterior de cada SSID y de cada NAS del inventario, luego observe sus registros. Las solicitudes deben caer a cero. Cualquier solicitud que aún llegue proviene de un NAS que pasó por alto. Mantenga el período de inactividad durante al menos un ciclo de reautenticación más una semana hábil. Luego exporte los registros según su política de retención, apague el servidor y retire sus secretos compartidos.

Escenario práctico: un grupo de 40 hoteles en Cisco Meraki

Tome como ejemplo un grupo de 40 hoteles que utiliza WiFi para empleados en Cisco Meraki. Utiliza PEAP contra un servidor RADIUS local en la oficina central. Cada solicitud cruza la WAN hacia un solo edificio, por lo que una interrupción en la oficina central deshabilita la red WiFi para empleados en todos los hoteles.

El grupo envía la nueva CA a través de su MDM en la primera semana. Reconstruye cinco filas de políticas en el servidor RADIUS en la nube contra Microsoft Entra ID y luego realiza una prueba piloto en un hotel urbano de 120 habitaciones. Le siguen olas de cinco, 10 y 24 hoteles, cada una como una plantilla de configuración de Meraki. Un hotel revierte los cambios durante una tarde porque una tableta del personal de limpieza solo confía en la CA anterior. Se vuelve a mover una semana después.

El resultado:

• Los 40 hoteles se mueven en seis ventanas de cambio.
• Un sitio revierte los cambios una sola vez.
• La oficina central ya no está en la ruta de autenticación.

¿Cómo funcionan en paralelo el servidor RADIUS anterior y el nuevo?

La ejecución en paralelo depende de cómo los puntos de acceso realizan la conmutación por error. Un NAS envía cada solicitud al primer servidor de su lista. Intenta con el siguiente servidor solo cuando el primero no responde dentro del tiempo de espera.

Un Access-Reject cuenta como una respuesta, no como una falla, por lo que el NAS no reintentará la solicitud en otra parte. Esto tiene dos consecuencias:

• Ambos servidores deben dar la misma respuesta. Si difieren, la experiencia del dispositivo dependerá de qué servidor haya respondido.
• La ejecución en paralelo es una red de seguridad, no una prueba. Pruebe la política en la fase 1 y en el piloto. No la pruebe esperando a ver qué hace la conmutación por error.

Verifique los tiempos de espera antes de trasladar el primer sitio. Un servidor en la nube está más distante que un servidor en su sala de comunicaciones. Compare los ajustes de tiempo de espera y reintento del NAS de cada sitio con su tiempo de ida y vuelta (round-trip time). Si los ajustes son demasiado estrictos, las solicitudes conmutarán por error al servidor anterior sin una razón real, y eso ocultará problemas. Mueva la contabilidad de RADIUS al nuevo servidor en el mismo momento que la autenticación, para que los registros de sesión residan en un solo lugar.

La transición en cada sitio consiste simplemente en invertir el orden de los dos servidores. Estos pasos se aplican a todos los sitios, con las diferencias del proveedor que se muestran en el paso 2.

{"title":"Migre un sitio sin un día de corte crítico","steps":[{"title":"Confirme que el sitio esté listo","body":"Verifique el sitio con la lista de verificación de migración: NAS en la lista, nueva CA en dispositivos administrados, ruta a Purple abierta, responsable en el sitio.","check":"Cada prerrequisito para el sitio está marcado."},{"title":"Agregue el nuevo servidor junto al anterior","body":"Agregue el RADIUS en la nube de Purple a la lista de servidores RADIUS del SSID, usando el secreto compartido que Purple emite para el sitio. Deje el servidor antiguo primero por ahora.","check":"La consola muestra ambos servidores en el SSID.","variants":[{"label":"Meraki","body":"En el Meraki Dashboard, agregue el servidor en la configuración de control de acceso del SSID, idealmente en la plantilla de configuración."},{"label":"Aruba","body":"En HPE Aruba Central, agregue el servidor al grupo de servidores de autenticación que usa la WLAN."},{"label":"Ruckus","body":"Agregue el servidor al perfil de servidor AAA que usa la WLAN, como servidor secundario."},{"label":"Mist","body":"En el portal de Juniper Mist, agregue el servidor a los servidores de autenticación RADIUS de la WLAN, idealmente en la plantilla WLAN."},{"label":"UniFi","body":"En la aplicación UniFi Network, agregue el servidor al perfil RADIUS asignado a la red WiFi."}]},{"title":"Pruebe antes de cambiar","body":"Desde un host de prueba registrado como cliente RADIUS, envíe una identidad por fila de directiva al nuevo servidor.","code":{"lang":"bash","text":"eapol_test -c eap-tls.conf -a <purple-radius-address> -p 1812 -s <shared-secret>"},"check":"Cada identidad recibe Access-Accept o Access-Reject según lo indique el mapa de directivas, con la VLAN esperada."},{"title":"Invierta el orden","body":"Convierta el nuevo servidor en el primario y mantenga el servidor antiguo como secundario. Este es el momento de la transición.","check":"Los registros del nuevo servidor muestran solicitudes de todos los puntos de acceso en el sitio."},{"title":"Retenga durante un ciclo comercial","body":"Compare la tasa de rechazo con su línea base y confirme que cada clase de dispositivo se haya autenticado.","check":"No hay rechazos sin explicación y el sitio aprueba su prueba de salida."}]}

¿Cómo revertir un sitio o una ola de migración?

Revertir el proceso es la transición a la inversa: vuelve a colocar el servidor antiguo en primer lugar. En cada consola mencionada anteriormente, esto representa un solo cambio de configuración. Solo funciona si el servidor antiguo sigue en ejecución, sin cambios y con sus secretos compartidos intactos. Es por eso que el desmantelamiento se realiza al final. También es la razón por la que congela la directiva en el servidor antiguo al comienzo de la fase 1.

Acuerde los detonadores antes de comenzar. Los detonadores típicos son:

• Una clase de dispositivo que no puede unirse y no tiene una solución el mismo día.
• Asignaciones de VLAN que difieren del mapa de directivas.
• Una tasa de rechazo superior a la línea base que no pueda explicar dentro de la ventana de cambio.

{"title":"Avanzar, pausar o revertir una ola","start":"q1","nodes":[{"id":"q1","question":"¿Está fallando alguna clase de dispositivo en el nuevo servidor que haya funcionado en el anterior?","help":"Compare los rechazos por tipo de dispositivo con la línea base que registró antes del cambio.","options":[{"label":"Sí","to":"q2"},{"label":"No","to":"q3"}]},{"id":"q2","question":"¿La falla se limita a una sola clase de dispositivo con una solución conocida?","help":"La falta de una CA en un perfil es una solución conocida. Los rechazos en varias clases no lo son.","options":[{"label":"Sí","to":"o2"},{"label":"No","to":"o3"}]},{"id":"q3","question":"¿Cada identidad de prueba llega a la VLAN esperada en cada sitio de la ola?","options":[{"label":"Sí","to":"q4"},{"label":"No","to":"o3"}]},{"id":"q4","question":"¿Ha funcionado la ola durante un ciclo comercial completo sin rechazos no explicados?","options":[{"label":"Sí","to":"o1"},{"label":"No","to":"o2"}]},{"id":"o1","outcome":"Avanzar: iniciar la siguiente ola","detail":"Registre el resultado de la prueba de salida por sitio y programe la siguiente ola.","link":"[Una sola política en cada ubicación](guide:cloud-radius-multi-site)"},{"id":"o2","outcome":"Pausar: corregir y volver a probar","detail":"Coloque el servidor anterior en primer lugar solo en el SSID afectado, corrija el perfil o la regla y ejecute nuevamente la prueba de salida."},{"id":"o3","outcome":"Revertir la ola","detail":"Coloque el servidor anterior en primer lugar en todos los SSID de la ola, capture los registros de ambos servidores y encuentre la causa antes de intentarlo de nuevo.","link":"[Cuando RADIUS no está disponible](guide:radius-server-down-wifi)"}]}

Después de cualquier reversión, exporte los registros de ambos servidores para la ventana con fallas. Encuentre la causa y corríjala en la nueva política. Luego, vuelva a ejecutar la prueba de laboratorio de la fase 1 para la fila afectada antes de mover el sitio nuevamente.

¿Cómo saber si la migración ha finalizado?

La migración finaliza cuando la evidencia lo confirma, no cuando se mueve el último sitio. Cinco pruebas la cierran:

1. El servidor anterior ha registrado cero solicitudes durante el periodo de inactividad acordado.
2. Cada NAS en el inventario aparece en los registros del nuevo servidor.
3. Un dispositivo real ha probado cada fila de la política y ha llegado a la VLAN esperada.
4. La tasa de rechazo está en o por debajo de la línea base que registró antes de la fase 2.
5. El servidor anterior está apagado, sus registros se conservan, sus secretos se han retirado y la guía de procesos está actualizada.

Mantenga un registro de una página para cada sitio, con la fecha, el resultado de la prueba de salida y cualquier reversión. Junto con los nuevos registros de autenticación, esos registros son su evidencia para los controles de registro de PCI-DSS y de control de acceso de ISO 27001. También sirven como evidencia de control de cambios para el próximo ciclo de auditoría.

Modos de falla vistos en el campo

Dispositivos que confían solo en el certificado anterior

Esta es la falla más común. Los dispositivos PEAP no administrados pueden solicitar el nuevo certificado o rechazarlo por completo. Algunos perfiles administrados fijan el nombre del servidor así como la CA. Verifique ambos antes del piloto.

Un NAS que nadie listó

Los controladores olvidados, los switches 802.1X cableados y los gateways VPN mantienen ocupado al servidor antiguo mucho tiempo después de haber migrado el WiFi. El periodo de inactividad de la fase 4 es la forma de detectarlos.

Políticas que residían en el servidor antiguo

Los grupos locales, las listas MAC programadas explícitamente y las reglas por hora del día a menudo solo existen en el servidor antiguo. Si no están en el mapa de políticas, desaparecerán durante la transición.

Discordancias de secretos compartidos y atributos

Un secreto mal escrito falla de forma silenciosa en algunas consolas. Una VLAN devuelta por nombre en lugar de por ID puede transferir dispositivos a la VLAN predeterminada. Ambos problemas deberían aparecer en las pruebas de la fase 1, y se deben verificar de nuevo en el piloto.

Tiempos de espera ajustados para un servidor local

Los tiempos de espera ajustados en un NAS causan una conmutación por error falsa al servidor antiguo. Todo parece funcionar hasta que se retira el servidor antiguo.

Escenario práctico: una empresa de retail de 120 tiendas en dos consolas

Tomemos como ejemplo una empresa de retail de 120 tiendas con sucursales antiguas en HPE Aruba y otras más nuevas en Juniper Mist. Las terminales portátiles y las laptops de las tiendas utilizan EAP-TLS contra un par de servidores RADIUS on-premises. El piloto y las etapas avanzan sin problemas, agrupados por grupo de Aruba Central y plantilla WLAN de Mist.

En la fase 4, los servidores antiguos siguen registrando solicitudes de tres direcciones después de haber migrado cada SSID. Dos son controladores del centro de distribución fuera del conjunto de tiendas. La tercera es un gateway VPN para laptops de la oficina central. El equipo agrega las tres al inventario, las migra en una ventana adicional y reinicia el periodo de inactividad. El desmantelamiento finaliza con dos semanas de retraso, sin interrupciones en ninguna tienda.

Dónde encaja Purple

Purple Access ejecuta redes abiertas, seguras y xPSK en una sola plataforma, utilizando los puntos de acceso que ya posee. La red segura impulsa esta migración. Proporciona RADIUS en la nube, EAP-TLS e identidad desde Microsoft Entra ID, Okta o Google Workspace. También admite Passpoint, también conocido como Hotspot 2.0, que permite a los dispositivos unirse a una red segura automáticamente con una credencial. Purple es independiente del hardware, por lo que una sola política atiende a sitios en estas plataformas:

• Cisco Meraki
• HPE Aruba
• Ruckus
• Juniper Mist
• Ubiquiti UniFi
• Cambium
• Extreme Networks
• Fortinet

Esto significa que una infraestructura mixta puede migrarse con un solo plan.

Purple opera el RADIUS en la nube más grande del mundo. Incluye un SLA de tiempo de actividad de RADIUS del 99.9%, en una plataforma que funciona con un tiempo de actividad del 99.999%. Como la infraestructura de Purple se configura antes de iniciar la fase 2, la transición de cada sitio suele ser un proceso de fin de semana. El escalonamiento existe para gestionar el riesgo en su infraestructura, no en nuestra plataforma.

{"items":[{"value":"80,000+","label":"sucursales activas","note":"Datos propios de Purple"},{"value":"90","label":"países"},{"value":"99.9%","label":"SLA de tiempo de actividad de RADIUS","note":"En una plataforma que opera al 99.999%"}]}

{"tone":"proof","title":"WiFi para personal a escala de sucursales","text":"JPMorgan opera el WiFi para su personal con Purple en 5,000 sucursales."}

Consulte cloud RADIUS en Purple Access para ver los detalles del producto, y la guía de seguridad WiFi empresarial para el conjunto completo de controles. El marketing para invitados se encuentra en Engage y el filtrado DNS en Shield. Ninguno de los dos cambia durante una migración de RADIUS.

Preguntas frecuentes

¿Cuánto tiempo tarda una migración de RADIUS en múltiples sitios?

Planifique varias semanas para toda la red y un fin de semana por sitio. En Purple, la transición de cada sitio suele ser un trabajo de fin de semana. Toda la infraestructura tarda más porque cada fase se mantiene durante un ciclo comercial completo antes de iniciar la siguiente. Una red ilustrativa de 40 sitios toma alrededor de 12 semanas desde el inventario hasta la puesta fuera de servicio. La mayor parte de ese tiempo se destina a la preparación y a los periodos de espera, no a las tareas de cambio.

¿Necesito nuevos puntos de acceso para migrar a cloud RADIUS?

No. Cloud RADIUS cambia el servidor al que consultan sus puntos de acceso, no los puntos de acceso en sí. Purple funciona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet. Solo debe agregar el nuevo servidor a la lista de servidores RADIUS de cada SSID en la consola que ya utiliza. Sus SSID, IDs de VLAN y la configuración de los switches se mantienen exactamente igual.

¿Cómo debo calcular el costo de cloud RADIUS en varios sitios?

Calcúlelo basándose en dos cifras: sitios e identidades. Cuente cada sitio que se autentica y cada identidad que se conecta, incluidos los dispositivos con EAP-TLS. Luego compare eso con el costo total del servidor anterior: hardware, licencias, parches, alta disponibilidad y la ruta WAN hacia la oficina central. Nuestra guía para calcular el costo de cloud RADIUS por sitio lo guía paso a paso a través del cálculo.

¿Puedo mantener el servidor RADIUS anterior como respaldo después de la migración?

Manténgalo durante la ejecución en paralelo y luego apáguelo. Mientras esté listado como secundario, cubrirá las pasarelas de pago y los tiempos de espera en los sitios que aún están en proceso de transición. Después de la fase 4, un servidor que conserva una copia congelada de la directiva anterior se convierte en un riesgo, porque cualquier respuesta que dé utilizará reglas desactualizadas. A partir de ese momento, la resiliencia proviene del SLA de 99.9% de tiempo de actividad de RADIUS y de un plan de recuperación ante interrupciones.

¿Tendrá el personal que volver a registrar sus dispositivos?

No si se confía en el certificado del nuevo servidor antes de la transición. Distribuya la nueva CA a los dispositivos administrados mediante su MDM durante la fase de creación. Los dispositivos EAP-TLS conservan sus certificados de cliente existentes, siempre que el nuevo servidor confíe en la CA que los emitió. Los dispositivos PEAP no administrados son la excepción, ya que algunos solicitarán aceptar el nuevo certificado una sola vez. Envíe un breve aviso a ese personal antes de que su sitio sea migrado.

¿Afecta la migración a nuestras evidencias de ISO 27001 o PCI-DSS?

Esto cambia la procedencia de sus evidencias, por lo que debe planificarlo desde el principio. Los registros de autenticación, las definiciones de políticas y los registros de cambios se trasladan a la nueva plataforma. Conserve los registros del servidor antiguo conforme a su política de retención y archive el registro de la prueba de salida de cada sitio. Purple cuenta con la certificación ISO 27001, lo que proporciona a sus auditores evidencia respaldada del lado de la plataforma. Sus propios controles aún requerirán su propia evidencia.

¿En qué se diferencia esto para un MSP que gestiona varias instalaciones?

Las fases son las mismas. Lo que cambia es el aislamiento entre las instalaciones. Un MSP ejecuta las mismas cuatro fases para cada instalación, pero cada una requiere su propia política, fuente de identidad y registros en una plataforma compartida. Las olas de despliegue suelen guiarse por los límites contractuales en lugar de las plantillas de la consola. Nuestra guía sobre RADIUS multinquilino para MSP explica cómo mantener cada instalación independiente durante y después de la migración.