For the complete documentation index, see llms.txt. This page is also available as Markdown.

Solución de problemas

Problemas de conexión

Vista de cliente

XML incorrecto

Compruebe que su cliente tiene un certificado para autenticarse y que está usando el correcto perfil de configuración de WiFi o XML.

Problemas con la CA raíz de confianza

Compruebe que ha hecho lo siguiente:

  • Ha indicado a su servidor RADIUS qué certificados se permiten conectar como se describe aquí

  • Ha importado el certificado activo del servidor RADIUS como raíz de confianza en su cliente, como se describe aquí

  • Compruebe sus Registros. Hay una descripción detallada del error. Quizá sea este problema.

¿Seguir conectando?

Si sus clientes necesitan verificar al conectarse por primera vez, y ve este cuadro de diálogo:

Asegúrese de haber referenciado el certificado del servidor RADIUS en su perfil de WiFi y de haber proporcionado el atributo SAN del certificado del servidor (FQDN) y el nombre común (CN):

Mostrando el atributo SAN del certificado del servidor (FQDN) y el nombre común (CN)

Vista de servidor

CA desconocida

Si sus Registros contienen mensajes de error similares a los que se muestran abajo

puede tener las siguientes causas raíz:

  • El cliente devuelve error Alerta TLS read:fatal:CA desconocida

    • Su cliente no conoce el certificado del servidor y rechaza la conexión. Compruebe que ha añadido su certificado del servidor como se describe aquí.

    • Ha cambiado/añadido un nuevo certificado del servidor y su perfil XML en el cliente está usando el antiguo. En ese caso, compruebe nuevamente que ha actualizado su perfil de WiFi/por cable o que ha regenerado su XML después de añadir los certificados y lo ha enviado a sus clientes.

  • El servidor devuelve error Alerta TLS write:fatal:CA desconocida

    • Su servidor RADIUS no conoce al emisor del certificado que se utilizó para la autenticación. Añada su CA como se describe aquí.

Certificado desconocido

Si usa macOS (y posiblemente otras plataformas Apple) y si sus Registros contienen mensajes de error similares al que se muestra abajo

puede tener las siguientes causas raíz:

  • Hay un carácter de espacio en algún lugar en el nombre del servidor del certificado en su WiFi o por cable perfil de configuración.

Error de descifrado | Acceso denegado

Si sus Registros contienen mensajes de error similares a los que se muestran abajo

... entonces probablemente sea un error del software TPM en sus máquinas Windows. Puede encontrar más información al respecto en la documentación de SCEPman.

Si ve algo como esto en sus Registros

... puede haber dos razones. Una es que su perfil de WiFi está haciendo referencia al certificado raíz incorrecto para la validación del servidor. Asegúrese de que su perfil esté configurado correctamente. Si lo está y todavía se enfrenta a este problema, intente establecer su KSP en KSP de software.

No se puede continuar, ya que el par se está comportando de forma incorrecta

Si sus Registros contienen rechazos con el error "No se puede continuar, ya que el par se está comportando de forma incorrecta" esto indica que el cliente dejó de comunicarse con el servicio RADIUS, en la mayoría de los casos porque la configuración de confianza es incorrecta. En este caso, verifique los certificados en los dispositivos afectados.

Secreto compartido RADIUS incorrecto

Si su (proxy) Registros contienen mensajes de error similares a los que se muestran abajo

entonces uno de sus puntos de acceso o switches que intenta conectarse a su instancia RADIUSaaS a través de un Proxy RADIUS está usando un Secreto compartido.

Para identificar el punto de acceso o switch afectado, primero determine el proxy RADIUS expandiendo el mensaje de error y buscando proxyip la propiedad. Ahora que conoce el proxy, use su inventario y su conocimiento de ubicaciones específicas o grupos de dispositivos que no pueden conectarse a su red para identificar el dispositivo de red mal configurado. Por último, actualice el secreto compartido para que coincida con el valor configurado en su instancia RADIUSaaS para ese proxy.

Solución de problemas de conexión con registros CAPI2

Los clientes Windows usan el API criptográfica (CAPI2) subsistema para gestionar operaciones de certificados durante la autenticación EAP-TLS. Cuando una conexión falla y ni la interfaz de usuario del cliente ni los registros del servidor RADIUSaaS proporcionan una indicación clara de la causa raíz, habilitar el registro CAPI2 en el dispositivo afectado puede revelar fallos de validación de certificados, errores de construcción de cadenas o problemas de acceso a la clave privada que de otro modo serían invisibles.


Paso 1: habilitar el registro CAPI2

El registro CAPI2 está deshabilitado de forma predeterminada. Para activarlo:

  1. Abra Visor de eventos: pulse Win + R, escriba eventvwr.exe, y pulse Enter.

  2. En el árbol de la izquierda, expanda Registros de aplicaciones y servicios.

  3. Expanda Microsoft → Windows → CAPI2.

  4. Haga clic con el botón derecho en Operativo y seleccione Habilitar registro.

Una vez habilitado, Windows comenzará a registrar todos los eventos CAPI2. Vuelva a reproducir el fallo de conexión. Ahora intente conectarse a la red Wi‑Fi o por cable y luego pase al siguiente paso.

Consejo: Deshabilite el registro de nuevo después de recopilar los datos (clic derecho en Operativo → Deshabilitar registro) para evitar un uso innecesario del disco.


Paso 2: localizar los eventos relevantes

Después de reproducir el problema, busque eventos en las siguientes fuentes de registro:

Fuente de registro
Ruta en Visor de eventos

CAPI2

Registros de aplicaciones y servicios → Microsoft → Windows → CAPI2 → Operativo

WLAN AutoConfig

Registros de aplicaciones y servicios → Microsoft → Windows → WLAN-AutoConfig → Operativo

Céntrese en los eventos que se registraron en el momento del intento de conexión fallido. Los indicadores útiles incluyen:

  • CAPI2 — errores relacionados con la construcción de la cadena de certificados, comprobaciones de revocación o acceso a la clave privada (por ejemplo, IDs de evento 11, 70, 90).

  • WLAN-AutoConfig — eventos que describen el resultado de la negociación 802.1X (por ejemplo, IDs de evento 8001, 8002, 12013).


Paso 3: exportar y enviar los registros

Para enviarnos los registros para revisión:

  1. En el Visor de eventos, haga clic con el botón derecho en el Operativo registro en CAPI2 y seleccione Guardar todos los eventos como…

  2. Guarde el archivo como un Archivo de registro de eventos (*.evtx) archivo y asígnele un nombre descriptivo, por ejemplo CAPI2_<nombre-dispositivo>_<fecha>.evtx.

  3. Repita los mismos pasos para el registro WLAN-AutoConfig → Operativo .

  4. Envíe ambos .evtx archivos a nuestro equipo de soporte en https://www.radius-as-a-service.com/help/ junto con una breve descripción del dispositivo afectado, la versión del SO y cuándo ocurre el problema.

Problemas de certificado

No se pudo verificar la cadena de certificados

Cuando desea usar su propio certificado de servidor, su servidor RADIUS requiere la cadena de certificados completa para permitir que otros participantes (Proxy, clientes RadSec, puntos finales que intentan conectarse) verifiquen la identidad del servidor. Si ve este mensaje, copie y pegue el certificado CA debajo del certificado del servidor en el campo de texto o cree un paquete de certificado PCKS8 que incluya todos los certificados desde el intermedio hasta la raíz.

Problemas del Portal de administración

Inicio de sesión

Para iniciar sesión en el portal web de RADIUSaaS ("RADIUSaas Admin Portal"), deben cumplirse los siguientes requisitos:

  • La dirección UPN/correo electrónico que proporcionó como administrador técnico debe poder autenticarse contra algún Microsoft Entra ID (Azure AD) (no tiene por qué ser una identidad del tenant cuyos usuarios aprovecharán RADIUSaaS para la autenticación de red).

  • La dirección UPN/correo electrónico que proporcionó como administrador técnico debe haberse registrado en su instancia RADIUSaaS como se describe aquí. En caso de que sea el administrador inicial, por favor contáctenos si cree que registramos al usuario incorrecto.

  • El objeto de usuario de Microsoft Entra ID (Azure AD) detrás de la dirección UPN/correo electrónico debe estar autorizado para conceder a la aplicación empresarial RADIUSaaS los siguientes permisos (véase la captura de pantalla abajo):

    • Leer el perfil básico de usuario

    • Mantener acceso a los datos a los que le ha dado acceso (permitir la solicitud de token de actualización)

  • En caso de que su usuario de Microsoft Entra ID (Azure AD) no tenga permisos para conceder los permisos requeridos, no se creará automáticamente ninguna aplicación empresarial en su Microsoft Entra ID (Azure AD). Para evitar esto, pida a su departamento de TI que conceda a su usuario los permisos necesarios.

Problemas de configuración de Intune

Asignación de perfiles

La configuración de Wi‑Fi no se despliega si los perfiles de Wi‑Fi, SCEP y certificado de confianza se asignan a grupos diferentes. Pueden aparecer como "Pendiente" o no mostrar ningún estado. Utilice el mismo grupo o "Todos los dispositivos" resp. "Todos los usuarios" para todos los perfiles vinculados.

Puede asignar el perfil de certificado raíz SCEP tanto a "Todos los usuarios" como a "Todos los dispositivos" si tiene en uso un certificado de dispositivo (asignado a "Todos los dispositivos") y un certificado de usuario (asignado a "Todos los usuarios").

certificado SCEP

Android

Android parece requerir un UPN en el nombre alternativo del sujeto en versiones más recientes (incluso para certificados de dispositivo). Añádalo en su perfil SCEP (por ejemplo, {{DeviceId}}@contoso.com):

perfil de Wi‑Fi

Android

Códigos de error comunes: 0xc7d24fc5 o -942518331

Los puntos clave son:

  • seleccione el certificado de CA raíz para validación del servidor (importante: no cargue el certificado del servidor de RADIUSaaS) - y -

  • defina un nombre del servidor radius

    • Nota: Parece haber un límite de caracteres para este campo. Para resolver posibles problemas, podría usar simplemente la parte del dominio sin subdominio, como "radius-as-a-service.com" (en lugar de "contoso.radius-as-a-service.com").

    • Desarrolladores de Android indica: "[...] debe configurar tanto un certificado de CA raíz, y ya sea un coincidencia de sufijo de dominio o una coincidencia de sujeto alternativa". Por tanto, el MDM puede usar "setAltSubjectMatch" o "setDomainSuffixMatch" después de añadir un certificado raíz a la configuración de Wi‑Fi. Intune parece usar "setDomainSuffixMatch" ya que solo "radius-as-a-service.com" es suficiente.

  • a veces privacidad de identidad es necesaria (por ejemplo, visto en dispositivos quiosco Android / Android Enterprise dedicados)

Última actualización

¿Te fue útil?