Configuración de EAP
En este artículo se proporciona una guía paso a paso para crear un XML de configuración del Protocolo de autenticación extensible (EAP) para un perfil de VPN, incluida la información sobre el filtrado de certificados EAP en Windows 10.
Creación de un XML de configuración de EAP para un perfil de VPN
Para obtener la configuración de EAP desde el escritorio mediante la herramienta rasphone que se incluye en el cuadro:
Ejecute rasphone.exe.
Si actualmente no tiene una conexión VPN y ve el siguiente mensaje, seleccione Aceptar.
En el asistente, seleccione Red de Workplace.
Escriba una dirección de Internet y un nombre de conexión. Estos detalles pueden ser falsos, ya que no afectan a los parámetros de autenticación.
Cree una conexión VPN falsa. En la interfaz de usuario que se muestra aquí, seleccione Propiedades.
En el cuadro de diálogo Propiedades de prueba , seleccione la pestaña Seguridad .
En la pestaña Seguridad, seleccione Usar protocolo de autenticación extensible (EAP).
En el menú desplegable, seleccione el método EAP que desea configurar y, a continuación, seleccione Propiedades para configurar según sea necesario.
Cambie a PowerShell y use los siguientes cmdlets para recuperar el XML de configuración de EAP.
Get-VpnConnection -Name TestEste es un ejemplo de salida.
Name : Test ServerAddress : 1.1.1.1 AllUserConnection : False Guid : {EC87F6C9-8823-416C-B92B-517D592E250F} TunnelType : Automatic AuthenticationMethod : {Eap} EncryptionLevel : Optional L2tpIPsecAuth : Certificate UseWinlogonCredential : False EapConfigXmlStream : #document ConnectionStatus : Disconnected RememberCredential : True SplitTunneling : False DnsSuffix : IdleDisconnectSeconds : 0$a = Get-VpnConnection -Name Test$a.EapConfigXmlStream.InnerXmlEste es un ejemplo de salida.
<EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig"> <EapMethod> <Type xmlns="http://www.microsoft.com/provisioning/EapCommon">13</Type> <VendorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorId> <VendorType xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorType> <AuthorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</AuthorId> </EapMethod> <Config xmlns="http://www.microsoft.com/provisioning/EapHostConfig"> <Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1"> <Type>13</Type> <EapType xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV1"> <CredentialsSource> <CertificateStore> <SimpleCertSelection>true</SimpleCertSelection> </CertificateStore> </CredentialsSource> <ServerValidation> <DisableUserPromptForServerValidation>false</DisableUserPromptForServerValidation> <ServerNames /> </ServerValidation> <DifferentUsername>false</DifferentUsername> <PerformServerValidation xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">true</PerformServerValidation> <AcceptServerName xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">true</AcceptServerName> <TLSExtensions xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2"> <FilteringInfo xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV3"> <ClientAuthEKUList Enabled="true" /> <AnyPurposeEKUList Enabled="true" /> </FilteringInfo> </TLSExtensions> </EapType> </Eap> </Config> </EapHostConfig>Nota
Debe comprobar con el proveedor de Mobile Administración de dispositivos (MDM) si necesita pasar este XML en formato de escape. Los XSD para todos los métodos EAP se incluyen en la caja y se pueden encontrar en las siguientes ubicaciones:
- C:\Windows\schemas\EAPHost
- C:\Windows\schemas\EAPMethods
Filtrado de certificados EAP
En la implementación, si tiene varios certificados aprovisionados en el dispositivo y el perfil de Wi-Fi aprovisionado no tiene un criterio de filtrado estricto, es posible que vea errores de conexión al conectarse a Wi-Fi. La solución consiste en asegurarse de que el perfil de Wi-Fi aprovisionado tenga criterios de filtrado estrictos para que coincida solo con un certificado.
Las empresas que implementan la autenticación EAP basada en certificados para VPN y Wi-Fi pueden encontrarse con una situación en la que hay varios certificados que cumplen los criterios predeterminados para la autenticación. Esta situación puede dar lugar a problemas como:
- Es posible que se le pida al usuario que seleccione el certificado.
- El certificado incorrecto puede seleccionarse automáticamente y provocar un error de autenticación.
Una implementación preparada para producción debe tener los detalles de certificado adecuados como parte del perfil que se va a implementar. En la siguiente información se explica cómo crear o actualizar un XML de configuración de EAP para que los certificados extraños se filtre y se pueda usar el certificado adecuado para la autenticación.
EL XML de EAP debe actualizarse con información relevante para su entorno. Esta tarea se puede realizar manualmente mediante la edición del siguiente ejemplo XML o mediante la guía de interfaz de usuario paso a paso. Una vez actualizado el XML de EAP, consulte las instrucciones de su MDM para implementar la configuración actualizada de la siguiente manera:
- Para Wi-Fi, busque la
<EAPConfig>sección de su XML de perfil WLAN actual. (Esta sección es lo que se especifica para el nodo WLanXml en el CSP de Wi-Fi). Dentro de estas etiquetas, encontrará la configuración completa de EAP. Reemplace la sección de con<EAPConfig>el XML actualizado y actualice el perfil de Wi-Fi. Puede consultar las instrucciones de su MDM sobre cómo implementar un nuevo perfil de Wi-Fi. - Para VPN, la configuración de EAP es un campo independiente en la configuración de MDM. Trabaje con su proveedor de MDM para identificar y actualizar el campo adecuado.
Para obtener información sobre la configuración de EAP, vea Protocolo de autenticación extensible (EAP) para el acceso a la red.
Para obtener información sobre cómo generar un XML EAP, consulte el artículo configuración de EAP.
Para obtener más información sobre el uso extendido de claves (EKU), vea https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12.
Para obtener información sobre cómo agregar EKU a un certificado, vea https://technet.microsoft.com/library/cc731792.aspx.
En la lista siguiente se describen los requisitos previos para que un certificado se use con EAP:
El certificado debe tener al menos una de las siguientes propiedades de EKU:
- Autenticación de cliente: tal como se define en RFC 5280, esta propiedad es un OID bien definido con el valor 1.3.6.1.5.5.7.3.2.
- Cualquier propósito: esta propiedad es una definida por EKU y microsoft la publica. Es un OID bien definido con el valor 1.3.6.1.4.1.311.10.12.1. La inclusión de este OID implica que el certificado se puede usar para cualquier propósito. La ventaja de este EKU sobre el EKU de uso general es que todavía se pueden agregar otras EEKU no críticas o personalizadas al certificado para un filtrado eficaz.
- Todos los propósitos: tal como se define en RFC 5280, si una CA incluye EKU para satisfacer algunas necesidades de la aplicación, pero no quiere restringir el uso de la clave, la ENTIDAD de certificación puede agregar un valor EKU de 0. Un certificado con un EKU de este tipo se puede usar para todos los propósitos.
El usuario o el certificado de equipo del cliente deben encadenar a una CA raíz de confianza.
El usuario o el certificado de equipo no produce ningún error en ninguna de las comprobaciones que realiza el almacén de certificados CryptoAPI y el certificado supera los requisitos de la directiva de acceso remoto.
El usuario o el certificado de equipo no produce ningún error en ninguna de las comprobaciones de identificador de objeto de certificado especificadas en el servicio de autenticación de Internet (IAS)/Servidor Radius.
La extensión Subject Alternative Name (SubjectAltName) del certificado contiene el nombre principal de usuario (UPN) del usuario.
En el ejemplo XML siguiente se explican las propiedades del XML DE TLS de EAP, incluido el filtrado de certificados.
Nota
En el caso de los perfiles PEAP o TTLS, el XML TLS de EAP se inserta en algunos elementos específicos de PEAP o TTLS.
<EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
<EapMethod>
<Type xmlns="http://www.microsoft.com/provisioning/EapCommon">13</Type>
<!--The above property defines the Method type for EAP, 13 means EAP TLS -->
<VendorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorId>
<VendorType xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorType>
<AuthorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</AuthorId>
<!--The 3 properties above define the method publishers, this is seen primarily in 3rd party Vendor methods.-->
<!-- For Microsoft EAP TLS the value of the above fields will always be 0 -->
</EapMethod>
<!-- Now that the EAP Method is Defined we will go into the Configuration -->
<Config xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
<Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1">
<Type>13</Type>
<EapType xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV1">
<CredentialsSource>
<!-- Credential Source can be either CertificateStore or SmartCard -->
<CertificateStore>
<SimpleCertSelection>true</SimpleCertSelection>
<!--SimpleCertSelection automatically selects a cert if there are mutiple identical (Same UPN, Issuer, etc.) certs.-->
<!--It uses a combination of rules to select the right cert-->
</CertificateStore>
</CredentialsSource>
<ServerValidation>
<!-- ServerValidation fields allow for checks on whether the server being connected to and the server cert being used are trusted -->
<DisableUserPromptForServerValidation>false</DisableUserPromptForServerValidation>
<ServerNames/>
</ServerValidation>
<DifferentUsername>false</DifferentUsername>
<PerformServerValidation xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">false</PerformServerValidation>
<AcceptServerName xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">false</AcceptServerName>
<TLSExtensions xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">
<!-- For filtering the relevant information is below -->
<FilteringInfo xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV3">
<CAHashList Enabled="true">
<!-- The above implies that you want to filter by Issuer Hash -->
<IssuerHash>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
<!-- Issuing certs thumbprint goes here-->
</IssuerHash>
<!-- You can add multiple entries and it will find the list of certs that have at least one of these certs in its chain-->
</CAHashList>
<EKUMapping>
<!-- This section defines Custom EKUs that you may be adding-->
<!-- You do not need this section if you do not have custom EKUs -->
<!-- You can have multiple EKUs defined here and then referenced below as shown -->
<EKUMap>
<EKUName>
<!--Add a friendly Name for an EKU here for example -->ContostoITEKU</EKUName>
<EKUOID>
<!--Add the OID Value your CA adds to the certificate here, for example -->1.3.6.1.4.1.311.42.1.15</EKUOID>
</EKUMap>
<!-- All the EKU Names referenced in the example below must first be defined here
<EKUMap>
<EKUName>Example1</EKUName>
<EKUOID>2.23.133.8.3</EKUOID>
</EKUMap>
<EKUMap>
<EKUName>Example2</EKUName>
<EKUOID>1.3.6.1.4.1.311.20.2.1</EKUOID>
</EKUMap>
-->
</EKUMapping>
<ClientAuthEKUList Enabled="true">
<!-- The above implies that you want certs with Client Authentication EKU to be used for authentication -->
<EKUMapInList>
<!-- This section implies that the certificate should have the following custom EKUs in addition to the Client Authentication EKU -->
<EKUName>
<!--Use the name from the EKUMap Field above-->ContostoITEKU</EKUName>
</EKUMapInList>
<!-- You can have multiple Custom EKUs mapped here, Each additional EKU will be processed with an AND operand -->
<!-- For example, Client Auth EKU AND ContosoITEKU AND Example1 etc. -->
<EKUMapInList>
<EKUName>Example1</EKUName>
</EKUMapInList>
</ClientAuthEKUList>
<AllPurposeEnabled>true</AllPurposeEnabled>
<!-- Implies that a certificate with the EKU field = 0 will be selected -->
<AnyPurposeEKUList Enabled="true"/>
<!-- Implies that a certificate with the EKU oid Value of 1.3.6.1.4.1.311.10.12.1 will be selected -->
<!-- Like for Client Auth you can also add Custom EKU properties with AnyPurposeEKUList (but not with AllPurposeEnabled) -->
<!-- So here is what the above policy implies.
The certificate selected will have
Issuer Thumbprint = ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
AND
((Client Authentication EKU AND ContosoITEKU) OR (AnyPurposeEKU) OR AllPurpose Certificate)
Any certificate(s) that match these criteria will be utilised for authentication
-->
</FilteringInfo>
</TLSExtensions>
</EapType>
</Eap>
</Config>
</EapHostConfig>
Nota
El XSD de TLS de EAP se encuentra en %systemdrive%\Windows\schemas\EAPMethods\eaptlsconnectionpropertiesv3.xsd.
Como alternativa, puede usar el procedimiento siguiente para crear un XML de configuración de EAP:
Siga los pasos del 1 al 7 en el artículo configuración de EAP.
En el cuadro de diálogo Propiedades de Microsoft VPN SelfHost , seleccione Microsoft: Tarjeta inteligente u otro certificado en el menú desplegable (este valor selecciona EAP TLS).
Nota
En PEAP o TTLS, seleccione el método adecuado y siga este procedimiento.
Seleccione el botón Propiedades debajo del menú desplegable.
En el menú Tarjeta inteligente u otras propiedades de certificado , seleccione el botón Opciones avanzadas .
En el menú Configurar selección de certificados , ajuste los filtros según sea necesario.
Seleccione Aceptar para cerrar las ventanas y volver al cuadro de diálogo principal rasphone.exe.
Cierre el cuadro de diálogo rasphone.
Siga el procedimiento del artículo de configuración de EAP del paso 9 para obtener un perfil TLS de EAP con el filtrado adecuado.
Nota
También puede establecer todas las demás propiedades de EAP aplicables a través de esta interfaz de usuario. Puede encontrar una guía para lo que significan estas propiedades en el artículo Protocolo de autenticación extensible (EAP) para el acceso a la red .
Temas relacionados
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de