Problemas conocidos

No se admite el comando Get dentro de un comando atómico.

No se admite un comando Get dentro de un comando atómico.

Las aplicaciones instaladas mediante clases WMI no se quitan

Las aplicaciones instaladas con clases WMI no se quitan cuando se quita la cuenta MDM del dispositivo.

Pasar CDATA en SyncML no funciona

Pasar CDATA en datos de SyncML a ConfigManager y CSP no funciona.

La configuración de SSL en el servidor IIS para SCEP debe establecerse en "Omitir"

La configuración del certificado en "Configuración SSL" en el servidor IIS para SCEP debe establecerse en "Omitir".

Se produce un error en la inscripción de MDM en el dispositivo Windows cuando el tráfico pasa por el proxy

Cuando el dispositivo Windows está configurado para usar un proxy que requiere autenticación, se produce un error en la inscripción. Para solucionar este problema, el usuario puede usar un proxy que no requiera autenticación o quitar la configuración de proxy de la red conectada.

Error de anulación de inscripción iniciado por el servidor

La inscripción iniciada por el servidor para un dispositivo inscrito agregando una cuenta profesional de forma silenciosa no puede dejar la cuenta MDM activa. Las directivas y los recursos de MDM siguen en vigor y el cliente puede seguir sincronizándose con el servidor.

La anulación de la inscripción del servidor remoto está deshabilitada para los dispositivos móviles inscritos a través de Microsoft Entra unión. Devuelve un mensaje de error al servidor. La única manera de quitar la inscripción de un dispositivo móvil que está Microsoft Entra unido es borrando el dispositivo de forma remota.

Certificados que causan problemas con Wi-Fi y VPN

Cuando se usa ClientCertificateInstall para instalar certificados en el almacén de dispositivos y el almacén de usuarios y ambos certificados se envían al dispositivo en la misma carga de MDM, el certificado destinado al almacén de dispositivos también se instala en el almacén de usuarios. Esta instalación dual puede causar problemas con Wi-Fi o VPN al elegir el certificado correcto para establecer una conexión. Estamos trabajando para solucionar este problema.

Información de versión de Windows 11

La información de versión de software de DevDetail/Ext/Microsoft/OSPlatform no coincide con la versión de Configuración en System/About.

Varios certificados pueden provocar Wi-Fi incapacidades de conexión

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, de modo que coincida solo con un certificado.

Las empresas que implementan la autenticación EAP basada en certificados para VPN/Wi-Fi pueden enfrentarse a 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 lista 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 ejemplo XML siguiente 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 <sección EAPConfig> de su XML de perfil WLAN actual (este detalle es lo que especifica para el nodo WLanXml en el CSP de Wi-Fi). Dentro de estas etiquetas, puede encontrar la configuración completa de EAP. Reemplace la sección de <EAPConfig> por el XML actualizado y actualice el perfil de Wi-Fi. Es posible que deba consultar las instrucciones de 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 Configuración de EAP.

Para obtener más información sobre el uso extendido de claves, vea https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12.

Para obtener información sobre cómo agregar el uso extendido de claves (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 (uso extendido de claves):
  • 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.
  • Un EKU, definido y publicado por Microsoft, 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.
  • Todo propósito.
  • Tal como se define en RFC 5280, si una CA incluye usos de clave extendidos 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 de uso de clave extendida 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 en las cadenas de cliente 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 dentro de 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.

1. Siga los pasos del 1 al 7 en la configuración de EAP.

2. En el cuadro de diálogo Propiedades de Microsoft VPN SelfHost, seleccione Microsoft : Tarjeta inteligente u otro certificado en el menú desplegable (este menú desplegable selecciona TLS de EAP).

   

   Nota

   En PEAP o TTLS, seleccione el método adecuado y siga este procedimiento.

3. Seleccione el botón Propiedades debajo del menú desplegable.

4. En el menú Tarjeta inteligente u otras propiedades de certificado , seleccione el botón Opciones avanzadas .

   

5. En el menú Configurar selección de certificados , ajuste los filtros según sea necesario.

   

6. Seleccione Aceptar para cerrar las ventanas para volver al cuadro de diálogo principal rasphone.exe .

7. Cierre el cuadro de diálogo rasphone.

8. Siga el procedimiento 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 sobre lo que significan estas propiedades en Protocolo de autenticación extensible (EAP) para el acceso a la red.

El cliente MDM se protegerá inmediatamente con el servidor MDM después de que el cliente renueve el URI del canal WNS.

Después de que el cliente MDM renueve automáticamente el URI del canal WNS, el cliente MDM se registrará inmediatamente con el servidor MDM. En adelante, para cada registro de cliente MDM, el servidor MDM debe enviar una solicitud GET para "ProviderID/Push/ChannelURI" para recuperar el URI de canal más reciente y compararlo con el URI de canal existente; después, actualice el URI del canal si es necesario.

Error de aprovisionamiento de usuarios en dispositivos unidos a Microsoft Entra

En Microsoft Entra dispositivos unidos, se produce un error en el aprovisionamiento .\User de recursos cuando el usuario no ha iniciado sesión como usuario Microsoft Entra. Si intenta unirse a Microsoft Entra ID desde la interfaz de usuario Configuración>del sistema>Acerca de , asegúrese de cerrar sesión e iniciar sesión con Microsoft Entra credenciales para obtener la configuración de la organización desde el servidor MDM. Este comportamiento es así por diseño.

Requisitos que se deben tener en cuenta para los certificados VPN que también se usan para la autenticación Kerberos

Si desea usar el certificado usado para la autenticación VPN también para la autenticación Kerberos (necesario si necesita acceso a recursos locales mediante NTLM o Kerberos), el certificado del usuario debe cumplir los requisitos para el certificado de tarjeta inteligente, el campo Asunto debe contener el nombre de dominio DNS en el DN o la SAN debe contener un UPN completo para que el controlador de dominio se pueda encontrar desde los registros DNS. Si se usan certificados que no cumplen estos requisitos para VPN, es posible que los usuarios no puedan acceder a los recursos que requieren autenticación Kerberos.

El agente de administración de dispositivos para el restablecimiento de botón no funciona

El agente de DM para el restablecimiento de botón mantiene la configuración del Registro para las sesiones de OMA DM, pero elimina las programaciones de tareas. La inscripción de cliente se conserva, pero nunca se sincroniza con el servicio MDM.