RADIUS, NPS y certificados Wildcard (1/2)

Hace un tiempo en Plain Concepts nos planteamos la posibilidad de cambiar la autenticación en la red wifi para poder utilizar nuestro usuario y contraseña de dominio. Este tipo de autenticación es conocida como RADIUS, y en el caso de las redes Wireless el AP o punto de acceso actúa como cliente RADIUS, hablando luego con el servidor RADIUS que realiza la autenticación en última instancia contra el directorio de usuarios correspondiente.

Como servidor RADIUS nos planteamos utilizar NPS (Network Policy Server), un rol incluido dentro de Windows Server de Microsoft, y que podíamos instalar en una VM.

Al intentar utilizar NPS nos encontramos con un problema que es el que intentaremos plasmar en este artículo, así como posibles soluciones.

La configuración es muy simple en el caso del AP, únicamente hay que especificar la dirección IP, el puerto (por defecto RADIUS trabaja con el 1812, y la clave compartida que van a utilizar cliente y servidor):

Configurar el servidor NPS también es bastante sencillo, definiendo el grupo de usuarios que van a poder acceder a la red interna utilizando su usuario y contraseña corporativos y el método de autenticación a utilizar, en nuestro caso PEAP con MSCHAPv2,  usando como certificado un wildcard que utilizamos para multitud de cosas.

Completamos el resto de la configuración, cogemos un cliente con Windows 8.1 cualquiera, nos vamos a conectar y ouch! recibimos un error. No tengo pantallazo del mismo, pero si tenemos una bonita traza de red 🙂

Esto es lo que se ve entre el cliente RADIUS (AP) y nuestro servidor RADIUS  / NPS (DC5). Como os comentábamos antes, el servidor RADIUS en última instancia autenticará al usuario contra el directorio correspondiente, en nuestro caso al ser un entorno Windows lo hará contra un Controlador de Dominio utilizando Kerberos, por lo que el instalar el rol de NPS en un DC nos dará mayor rapidez en la operación.

2719        14:02:30 09/08/2013        99.9773874        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = Identity

2720        14:02:30 09/08/2013        99.9832878        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP,PEAP start

2721        14:02:30 09/08/2013        99.9973892        svchost.exe        192.168.2.1        DC5         TLS        TLS:TLS Rec Layer-1 HandShake: Client Hello.

2722        14:02:30 09/08/2013        99.9983551        svchost.exe        DC5         192.168.2.1        TLS        TLS:TLS Rec Layer-1 HandShake: Server Hello. Certificate.

2724        14:02:30 09/08/2013        100.0173182        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = PEAP

2725        14:02:30 09/08/2013        100.0180056        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP

2726        14:02:30 09/08/2013        100.0374329        svchost.exe        192.168.2.1        DC5         TLS        TLS:TLS Rec Layer-1 HandShake: Certificate. Client Key Exchange.

2727        14:02:30 09/08/2013        100.0441988        svchost.exe        DC5         192.168.2.1        TLS        TLS:TLS Rec Layer-1 Cipher Change Spec; TLS Rec Layer-2 HandShake: Encrypted Handshake Message.

2728        14:02:30 09/08/2013        100.0672320        svchost.exe        192.168.2.1        DC5         TLS        TLS:TLS Rec Layer-1 Encrypted Alert

2729        14:02:30 09/08/2013        100.0681224        svchost.exe        DC5         192.168.2.1        EAP        EAP:Failure

 

Toda la comunicación se realiza correctamente pero falla en uno de los últimos pasos. El error que veis en las trazas suele aparecer cuando no se ha podido autenticar correctamente al cliente, es decir, normalmente ocurre cuando las credenciales no son correctas.

Pero nos hemos asegurado de que sean correctas. ¿Qué puede fallar entonces?

Lo veremos en el próximo capítulo 🙂