RADIUS, NPS y certificados Wildcard (2/2)

En el artículo de ayer veíamos un escenario donde queríamos configurar la autenticación de nuestra red Wireless para utilizar las credenciales de dominio. Para ello configurábamos un NPS como servidor RADIUS y como certificado utilizábamos un wildcard.

Veíamos que una vez configurado todo y cogiendo un cliente Windows cualquiera recibíamos un error y no podíamos iniciar sesión y conectarnos.

Hoy vamos a ver como analizar el problema y posibles soluciones.

Para ello lo mejor es empezar activando el tracing en el servidor NPS y ver que pasa cuando el punto de acceso nos manda la información con las credenciales del usuario a autenticar:

Esto nos genera dos ficheros de log en C:Windowstracing que son svchost_RASCHAP y svchost_RASTLS correspondientes a las 2 fases que se tienen lugar en la autenticación que hemos especificado. Nos fijamos en el segundo.

[1360] 08-09 14:02:30:859: EapPeapBegin

[1360] 08-09 14:02:30:859: EapPeapBegin – flags(0x2)

[1360] 08-09 14:02:30:859: PeapReadUserData dwSize:0x38

[1360] 08-09 14:02:30:859:

[1360] 08-09 14:02:30:859: EapTlsBegin(PLAINCONCEPTSamarcos)

[1360] 08-09 14:02:30:859: SetupMachineChangeNotification

[1360] 08-09 14:02:30:859: State change to Initial

[1360] 08-09 14:02:30:859: EapTlsBegin: Detected PEAP authentication

…..

[1360] 08-09 14:02:30:938: EapTlsSMakeMessage, state(3)

[1360] 08-09 14:02:30:938: Client sent an alert; negotiation unsuccessful

[1360] 08-09 14:02:30:938: GetAlert

[1360] 08-09 14:02:30:938: Error 0x8009030c

 

El error y sobre todo la razón del mismo, fue lo que nos dieron una pista muy importante. El cliente es el que manda la alerta de que la autenticación no se ha podido realizar correctamente.

Si vemos el siguiente artículo de Microsoft, se entiende mejor:

Certificates and NPS

http://technet.microsoft.com/en-us/library/cc772401(WS.10).aspx

IEEE 802.1X authentication provides authenticated access to 802.11 wireless networks and to wired Ethernet networks. 802.1X provides support for secure EAP types, such as TLS with smart cards or certificates. You can configure 802.1X with EAP-TLS in a variety of ways. If the Validate server certificate option is configured on the client, the client authenticates the server by using its certificate. Client computer and user authentication can be accomplished using certificates from the client certificate store or a smart card, providing mutual authentication.

With wireless clients, PEAP-MS-CHAP v2 can be used as the authentication method. PEAP-MS-CHAP v2 is a password-based user authentication method that uses TLS with server certificates. During PEAP-MS-CHAP v2 authentication, the IAS or RADIUS server supplies a certificate to validate its identity to the client. Client computer and user authentication is accomplished with passwords, which eliminates some of the difficulty of deploying certificates to wireless client computers.

 

Si las credenciales son correctas, y el cliente es el que está mandando la alerta, debe estar fallando el paso en el que «the IAS or RADIUS server supplies a certificate to validate its identity to the client»

Acudimos a los requisitos necesarios en cuanto a certificados para este tipo de escenarios:

Certificate requirements when you use EAP-TLS or PEAP with EAP-TLS

http://support.microsoft.com/kb/814394/en-us

You can configure clients to validate server certificates by using the Validate server certificate option on the Authentication tab in the Network Connection properties. When a client uses PEAP-EAP-MS-Challenge Handshake Authentication Protocol (CHAP) version 2 authentication, PEAP with EAP-TLS authentication, or EAP-TLS authentication, the client accepts the server’s certificate when the certificate meets the following requirements:

• The computer certificate on the server chains to one of the following:
  • A trusted Microsoft root CA.
  • A Microsoft stand-alone root or third-party root CA in an Active Directory domain that has an NTAuthCertificates store that contains the published root certificate. For more information about how to import third-party CA certificates, click the following article number to view the article in the Microsoft Knowledge Base:
    295663
    How to import third-party certification authority (CA) certificates into the Enterprise NTAuth store
• The IAS or the VPN server computer certificate is configured with the Server Authentication purpose. The object identifier for Server Authentication is 1.3.6.1.5.5.7.3.1.
• The computer certificate does not fail any one of the checks that are performed by the CryptoAPI certificate store, and it does not fail any one of the requirements in the remote access policy.
• The name in the Subject line of the server certificate matches the name that is configured on the client for the connection.
• For wireless clients, the Subject Alternative Name (SubjectAltName) extension contains the server’s fully qualified domain name (FQDN).
• If the client is configured to trust a server certificate with a specific name, the user is prompted to make a decision about trusting a certificate with a different name. If the user rejects the certificate, authentication fails. If the user accepts the certificate, the certificate is added to the local computer trusted root certificate store.

 

Y aquí viene nuestro problema. Al estar utilizando un certificado wildcard, el SAN del mismo va dirigido a *.plainconcepts.com, pero eso no es explícitamente el FQDN del servidor RADIUS. Por tanto, la validación del certificado y del servidor no se produce correctamente, y la autenticación falla.

Los clientes Windows son los únicos que por defecto en una conexión de este tipo verifican el certificado del servidor. Los otros clientes con los que hemos probado (Android, iOS o OSX) te advierten previamente de que no van a verificar el certificado del servidor y funcionan OK. Esto aun así puede provocar un problema de seguridad si te realizan un man in the middle.

Comprobamos que efectivamente este es el problema desactivando en el cliente la opción de la conexión Wireless de la oficina que verifica el certificado del servidor:

 

Si volvemos a probar y cogemos una traza de red vemos como todo va sobre ruedas:

4181        14:03:51 09/08/2013        180.2069361        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = Identity

4182        14:03:51 09/08/2013        180.2129407        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP,PEAP start

4183        14:03:51 09/08/2013        180.2269086        svchost.exe        192.168.2.1        DC5         TLS        TLS:TLS Rec Layer-1 HandShake: Client Hello.

4184        14:03:51 09/08/2013        180.2278678        svchost.exe        DC5         192.168.2.1        TLS        TLS:TLS Rec Layer-1 HandShake: Encrypted Handshake Message.

4186        14:03:51 09/08/2013        180.2469132        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = PEAP

4187        14:03:51 09/08/2013        180.2475661        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP

4188        14:03:51 09/08/2013        180.2669155        svchost.exe        192.168.2.1        DC5         TLS        TLS:TLS Rec Layer-1 HandShake: Certificate. Client Key Exchange.

4189        14:03:51 09/08/2013        180.2736570        svchost.exe        DC5         192.168.2.1        TLS        TLS:TLS Rec Layer-1 Cipher Change Spec; TLS Rec Layer-2 HandShake: Encrypted Handshake Message.

4190        14:03:51 09/08/2013        180.2868939        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = PEAP

4192        14:03:51 09/08/2013        180.2880059        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP

4193        14:03:51 09/08/2013        180.2968700        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = PEAP

4194        14:03:51 09/08/2013        180.2976007        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP

4195        14:03:51 09/08/2013        180.3069125        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = PEAP

4196        14:03:51 09/08/2013        180.3121415        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP

4197        14:03:51 09/08/2013        180.3269171        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = PEAP

4198        14:03:51 09/08/2013        180.3294832        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP

4199        14:03:51 09/08/2013        180.3370064        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = PEAP

4200        14:03:51 09/08/2013        180.3387234        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP

4201        14:03:51 09/08/2013        180.3570453        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = PEAP

4202        14:03:51 09/08/2013        180.3598720        svchost.exe        DC5         192.168.2.1        EAP        EAP:Success

 

¿Qué soluciones planteamos ante un escenario así?

Estas son las que nosotros pusimos encima de la mesa:

1. Comprar un certificado para el NPS que cumpla estrictamente con los requisitos que comentábamos arriba. Sobre todo que el SAN sea el FQDN del NPS. Unos 300€ al año.
2. Crear uno auto-firmado y distribuirlo a todos los clientes.
3. Por GPO deshabilitar la verificación del certificado del servidor. Como es algo que hay que cambiar a nivel de la conexión wifi en el cliente, hay que generar una conexión wifi para el perfil con el mismo nombre y con la casilla desactivada.

Esperamos que os haya gustado el artículo. Happy networking!