> For the complete documentation index, see [llms.txt](https://docs.scepman.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation.md).

# Validación de Intune

{% hint style="info" %}
Estos ajustes solo deben aplicarse al App Service de SCEPman, no al Certificate Master. Consulte [Configuración de SCEPman](/es/configuracion-de-scepman/application-settings.md).
{% endhint %}

## AppConfig:IntuneValidation:ComplianceCheck

*Linux: AppConfig\_\_IntuneValidation\_\_ComplianceCheck*

{% hint style="warning" %}
**Configuración experimental**

Solo en SCEPman Enterprise Edition

Antes de la versión 1.9, debido a la evaluación tardía del estado de cumplimiento durante el registro, esta característica rompe el registro de Windows Autopilot. Después de la implementación del certificado, la comprobación OCSP inmediatamente siguiente devolverá '**no válido**' durante el registro y el proceso de Autopilot no tendrá éxito.

Con la versión 1.9 y superiores, los clientes reciben un "Certificado de arranque efímero" durante la fase de registro, que luego se reemplaza por un certificado de cliente normal en cuanto el cliente pasa a cumplir los requisitos.

Con la versión 2.5 y superiores, también puedes configurar un período de gracia durante el cual el dispositivo siempre se considera conforme con la configuración ComplianceGracePeriodMinutes.
{% endhint %}

**Valor:** *Siempre* o *Nunca* (predeterminado)

**Descripción:** Cuando SCEPman recibe una solicitud OCSP, SCEPman puede comprobar opcionalmente el estado de cumplimiento del dispositivo. Cuando se establece en **Siempre** SCEPman consultará el estado de cumplimiento del dispositivo y el resultado OCSP solo puede ser GOOD si el dispositivo también está marcado como conforme en Azure AD.

Establecer esto en **Nunca** deshabilitará la comprobación de cumplimiento.

## AppConfig:IntuneValidation:ComplianceGracePeriodMinutes

*Linux: AppConfig\_\_IntuneValidation\_\_ComplianceGracePeriodMinutes*

{% hint style="warning" %}
Solo en SCEPman Enterprise Edition

Aplicable a la versión 2.5 y superiores
{% endhint %}

**Valor:** *Entero* (predeterminado: 0)

**Descripción:** Inmediatamente después del registro, los dispositivos a menudo todavía no cumplen los requisitos en Intune. Esta configuración define un período de gracia en minutos durante el cual el dispositivo se considera conforme, aunque todavía no lo esté. Si el dispositivo no cumple los requisitos después del período de gracia, el certificado se revoca. Esto evita el problema de un dispositivo Windows que recién se está registrando y necesita completar correctamente el perfil SCEP para finalizar el registro de Windows Autopilot, pero solo pasará a cumplir los requisitos en Intune algún tiempo después.

La configuración comprobará la propiedad EnrolledDateTime de Intune y comenzará a contar desde ese momento.

Es una alternativa al uso de Certificados de arranque efímeros. Si configuras cualquier valor superior a 0, SCEPman nunca emitirá Certificados de arranque efímeros.

Esta configuración solo surte efecto si [ComplianceCheck](#appconfig-intunevalidation-compliancecheck) se establezca en *Siempre*.

## AppConfig:IntuneValidation:DeviceDirectory

*Linux: AppConfig\_\_IntuneValidation\_\_DeviceDirectory*

**Valor:** Cadena

Opciones disponibles:

* `AAD`\
  (predeterminado para SCEPman 2.0)
* `Intune`
* `AADAndIntune`
* `AADAndIntuneOpportunistic`\
  (predeterminado para SCEPman 2.1 o posterior)
* `AADAndIntuneAndEndpointlist`\
  (disponible en SCEPman 2.2 y posteriores)

{% hint style="warning" %}
Si quieres cambiar esta configuración en una implementación existente que se instaló con una versión anterior de SCEPman, vuelve a ejecutar el [script de configuración de PowerShell](/es/despliegue-de-scepman/permissions/post-installation-config.md#acquire-and-run-the-scepman-installation-powershell-module) para asegurarte de que SCEPman tenga los permisos más recientes para acceder a los directorios de dispositivos correspondientes.
{% endhint %}

**Descripción:** Determina dónde buscar dispositivos en las solicitudes OCSP para certificados de dispositivo. Se consulta el directorio correspondiente para encontrar un dispositivo que coincida con el ID del dispositivo escrito en el campo CN del sujeto del certificado. El certificado solo es válido si el dispositivo existe. Para **`AAD`**, también debe estar habilitado (Intune no admite deshabilitar dispositivos). Si se activa ComplianceCheck, el dispositivo también debe cumplir los requisitos. Si no se configura nada y para SCEPman 1.9 y anteriores, `AAD` se usa.

Por lo tanto, debes configurar en consecuencia el perfil de configuración de Intune para los dispositivos. `{{AAD_Device_ID}}` es el ID de dispositivo de Entra/AAD, mientras que `{{DeviceID}}` es el ID de dispositivo de Intune.

Para **`AADAndIntune`**, ambos directorios se consultan en paralelo. En este caso, basta con que el dispositivo exista en uno de los dos directorios. Esta configuración permite migrar de una configuración a otra cuando aún hay certificados válidos para ambos tipos de directorios. También admite casos en los que configuras las plataformas de forma diferente. Además, puede usarse como solución alternativa para dispositivos iOS o Android que reciben un ID de Intune en lugar de un ID de objeto de Entra ID, porque no están completamente unidos a Entra en el momento del registro del certificado.

Si has actualizado de SCEPman 1.x a SCEPman 2.x y todavía estás usando [un registro de aplicación para permisos de SCEPman](/es/despliegue-de-scepman/permissions/azure-app-registration.md), SCEPman carece de los permisos para consultar Intune en busca de dispositivos. Por lo tanto, estás limitado a la `AAD` opción. La opción **`AADAndIntuneOpportunistic`** comprueba si se han concedido a SCEPman los permisos para consultar Intune. Si están presentes, esto funciona como `AADAndIntune`. Si no están, esto se comporta como `AAD`.

El valor **`AADAndIntuneAndEndpointlist`** funciona igual que `AADAndIntune`, pero además consulta [la lista de certificados emitidos de Intune](https://endpoint.microsoft.com/#view/Microsoft_Intune_DeviceSettings/DevicesMonitorMenu/~/certificateReport). Si Intune [desencadenó la revocación de un certificado](https://learn.microsoft.com/en-us/mem/intune/protect/remove-certificates#scep-certificates), esto hará que el certificado quede revocado en SCEPman.

{% embed url="<https://www.youtube.com/watch?v=K0SK0BtoBUQ>" %}
SCEPman 2.0: Validación de certificados
{% endembed %}

## AppConfig:IntuneValidation:RevokeCertificatesOnWipe

*Linux: AppConfig\_\_IntuneValidation\_\_RevokeCertificatesOnWipe*

{% hint style="info" %}
Aplicable a la versión 2.1 y superiores.
{% endhint %}

**Valor:** *true* (predeterminado) o *false*

**Descripción:** Esta configuración amplía la validación de dispositivos cuando se usa el ID de dispositivo de Intune. No funciona cuando se usa el ID de dispositivo de Entra/AAD. Si está habilitada, SCEPman evalúa la propiedad Management State de un dispositivo de Intune cuando se valida su certificado de dispositivo. Si el estado indica uno de los siguientes valores, el certificado se revoca:

* RetirePending
* RetireFailed
* WipePending
* WipeFailed
* Unhealthy
* DeletePending
* RetireIssued
* WipeIssued

En particular, esto significa que cuando un administrador desencadena un Wipe o Retire para un dispositivo, el certificado se revocará inmediatamente. Incluso si el dispositivo está apagado o sin conexión y, por tanto, la acción no puede realizarse en el dispositivo, el certificado ya no es válido.

## AppConfig:IntuneValidation:UntoleratedUserRisks

*Linux: AppConfig\_\_IntuneValidation\_\_UntoleratedUserRisks*

{% hint style="warning" %}
**Configuración experimental** - Aplicable a la versión 2.2 y superiores. Requiere el permiso *IdentityRiskyUser.Read.All* otorgado por el módulo PS de SCEPman versión 1.7 y superiores.

Solo en SCEPman Enterprise Edition
{% endhint %}

**Valor:** Lista de niveles de riesgo de usuario separados por comas, p. ej. *Bajo*, *Medio*, *Alto*.

**Descripción:** Esta configuración solo tiene efecto si estableces [UserRiskCheck](#appconfig-intunevalidation-userriskcheck) a *Siempre*. Los certificados de usuarios con niveles de riesgo de esta lista se considerarán no válidos.

Ejemplo: defines `Medium,High` para esta configuración. Un usuario tiene Nivel de riesgo *Bajo*. El certificado del usuario es válido y puede utilizarse para conectarse a la VPN corporativa. Luego, un evento de riesgo aumenta el Nivel de riesgo del usuario a *Medio*. El usuario intenta conectarse a la VPN, pero no lo consigue, porque la puerta de enlace VPN comprueba la validez del certificado en tiempo real y SCEPman responde que está revocado.

## AppConfig:IntuneValidation:UserRiskCheck

*Linux: AppConfig\_\_IntuneValidation\_\_UserRiskCheck*

{% hint style="warning" %}
**Configuración experimental** - Aplicable a la versión 2.2 y superiores. Requiere el permiso *IdentityRiskyUser.Read.All* otorgado por el módulo PS de SCEPman versión 1.7 y superiores.

Solo en SCEPman Enterprise Edition
{% endhint %}

**Valor:** *Siempre* o *Nunca* (predeterminado)

**Descripción:** Cuando SCEPman recibe una solicitud OCSP para un certificado emitido a un usuario de Intune, SCEPman puede comprobar opcionalmente el [el nivel de riesgo del usuario](https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#user-linked-detections). Cuando se establece en **Siempre** SCEPman consultará el estado de riesgo del usuario y el resultado OCSP solo puede ser GOOD si el riesgo del usuario no está en la lista de [UntoleratedUserRisks](#appconfig-intunevalidation-untolerateduserrisks).

Establecer esto en **Nunca** deshabilitará la comprobación de riesgo del usuario.

## AppConfig:IntuneValidation:WaitForSuccessNotificationResponse

*Linux: AppConfig\_\_IntuneValidation\_\_WaitForSuccessNotificationResponse*

**Valor:** *true* (predeterminado) o *false*

**Descripción:** Después de que un certificado se haya emitido correctamente, SCEPman envía una notificación sobre el certificado a Intune. Microsoft recomienda esperar la respuesta en su especificación. Sin embargo, algunas instancias muestran retrasos largos que ocasionan timeouts ocasionalmente. Por lo tanto **Verdadero** es el valor predeterminado.

Establecer esto en **Falso** hace que SCEPman devuelva el certificado emitido antes de que Intune responda a la notificación. Esto va en contra de la letra de la especificación, pero mejora el rendimiento y evita timeouts en las instancias en las que surge este problema.

## AppConfig:IntuneValidation:ValidityPeriodDays

*Linux: AppConfig\_\_IntuneValidation\_\_ValidityPeriodDays*

**Valor:** Positivo *Entero*

**Descripción:** Esta configuración reduce aún más los ValidityPeriodDays globales para el endpoint de Intune.

## AppConfig:IntuneValidation:EnableCertificateStorage

*Linux: AppConfig\_\_IntuneValidation\_\_EnableCertificateStorage*

{% hint style="info" %}
Aplicable a la versión 2.7 y superiores

Solo en SCEPman Enterprise Edition
{% endhint %}

**Valor:** *true* o *false* (predeterminado)

**Descripción:** Cuando se solicitan certificados a través del endpoint de Intune, SCEPman almacena esos certificados solicitados en el Storage Account en Azure si esto se establece en *true*. Esto hará que los certificados emitidos aparezcan en SCEPman Certificate Master, donde puedes verlos y revocarlos manualmente. Además, los certificados se revocan automáticamente cuando el objeto asociado de Entra o Intune entra en un estado no válido, según lo especificado por las otras configuraciones (como estar deshabilitado o eliminado). Si se establece en *false*, SCEPman no almacenará los certificados emitidos y los certificados solo serán visibles en los registros o en la vista clásica de Intune en Certificate Master o en el portal de Intune. Si no se establece esto, el comportamiento depende de la configuración global [AppConfig:EnableCertificateStorage](/es/configuracion-de-scepman/application-settings/basics.md#appconfig-enablecertificatestorage).

## AppConfig:IntuneValidation:AllowRenewals <a href="#appconfig-dbcsrvalidation-allowrenewals" id="appconfig-dbcsrvalidation-allowrenewals"></a>

**Valor:** *true* o *false* (predeterminado)

**Descripción:** Esto permite usar la operación *RenewalReq* en este extremo SCEP. Solo funciona para tipos de certificado agregados a *AppConfig:*&#x49;ntuneValidatio&#x6E;*:ReenrollmentAllowedCertificateTypes*.

Esta operación se puede usar con el módulo [SCEPmanClient ](https://github.com/scepman/scepmanclient)PowerShell.

{% hint style="warning" %}
Ten en cuenta que Intune no hará uso de la *RenewalReq* operación y que esta configuración no es necesaria para el funcionamiento habitual.
{% endhint %}

## AppConfig:IntuneValidation:AllowRequestedSidExtension

{% hint style="info" %}
Aplicable a la versión 2.11.1460 y superiores. Las versiones anteriores se comportan de manera diferente a la descrita si se modifica esta configuración, y recomendamos no configurarla para estas versiones más antiguas.
{% endhint %}

**Valor:** *true* o *false* (predeterminado)

**Descripción:** Si hay una extensión SID (OID 1.3.6.1.4.1.311.25.2) en la solicitud de certificado, se copiará al certificado emitido si esta configuración es verdadera. Si es falsa, se filtrará. El SID es importante para un mapeo sólido de certificados en escenarios de autenticación de AD local. Sin embargo, Intune aparentemente [no comprueba la autenticidad del SID solicitado](/es/otros/troubleshooting/sid-spoofing-vulnerability.md) en la extensión, por lo que permitir extensiones SID solicitadas puede suponer una vulnerabilidad de seguridad.

Las extensiones SID agregadas mediante [AppConfig:AddSidExtension](/es/configuracion-de-scepman/application-settings/certificates.md#appconfig-addsidextension) no se ven afectadas por esta configuración. Además, los SID agregados como un URI SAN que contiene un SID tampoco se ven afectados si la versión de SCEPman es 2.11.1460 o posterior — las versiones anteriores de SCEPman copian el SID del URI SAN solo si esto *true*, pero tienen *true* como valor predeterminado.

## AppConfig:IntuneValidation:ReenrollmentAllowedCertificateTypes <a href="#appconfig-dbcsrvalidation-reenrollmentallowedcertificatetypes" id="appconfig-dbcsrvalidation-reenrollmentallowedcertificatetypes"></a>

**Valor:** Lista separada por comas de tipos de certificados de esta lista:

* DomainController
* Static
* IntuneUser
* IntuneDevice
* JamfUser
* JamfUserWithDevice
* JamfUserWithComputer
* JamfDevice
* JamfComputer

**Descripción:** Puede usar el extremo SCEP para renovaciones de certificados de los tipos especificados en esta configuración. Si no especifica ningún valor, el valor predeterminado es ninguno.

Por ejemplo, si quisiera renovar certificados emitidos manualmente a través de Certificate Master, especificaría `Static`. Si además quiere renovar certificados Domain Controller, especificaría `DomainController,Static`.

{% hint style="warning" %}
Ten en cuenta que Intune no hará uso de la *RenewalReq* operación y que esta configuración no es necesaria para el funcionamiento habitual.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.scepman.com/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
