> 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/otros/troubleshooting/sid-spoofing-vulnerability.md).

# Vulnerabilidad de suplantación SID

Dirk-jan Mollema recientemente [describió cómo extender a Intune ataques similares a Certifried](https://dirkjanm.io/extending-ad-cs-attack-surface-intune-certs/). Aunque en el artículo utilizó AD CS y NDES, los problemas descritos no son específicos de ellos y, en general, se aplican a todas las PKI que usan Intune para el registro SCEP, incluido SCEPman.

Sin embargo, existen algunas restricciones adicionales para otras PKI. Lo más importante es que, dado que esto se basa en la general [vulnerabilidad Certifried](/es/otros/troubleshooting/certifried.md), requiere que el certificado de la CA esté en el almacén NTAuth del dominio. Aunque AD CS está de forma predeterminada en el almacén NTAuth, SCEPman no lo está, por lo que los usuarios de SCEPman solo podrían verse afectados si agregaron explícitamente el certificado de la CA al almacén NTAuth. Si no lo has hecho, estás a salvo. Sin embargo, algunos casos de uso requieren agregar el certificado de la CA al almacén NTAuth, en particular [certificados de Domain Controller](/es/administracion-de-certificados/domain-controller-certificates.md) y [autenticación RDP basada en certificados](/es/despliegue-de-scepman/deployment-guides/scenarios/certificate-based-authentication-for-rdp.md). Si el certificado de tu CA está en el almacén NTAuth y habilitas el registro de Intune en SCEPman, esto normalmente permitirá a tus administradores de Intune aprovecharlo y registrar certificados con los que pueden tomar el control del dominio; es decir, tus administradores de Intune deben considerarse administradores de nivel 0.

Pero Dirk-jan describió otro problema, más grave. Intune, aparentemente, no comprueba si un SID proporcionado por el usuario coincide con el atributo onPremisesSecurityIdentifier del usuario o del dispositivo, anulando las mitigaciones que Microsoft ha implementado con su aplicación de Strong Mapping. Un usuario sin privilegios elevados (bueno, los privilegios de administrador local en su equipo pueden o no ser necesarios) puede registrar un certificado con el SID de otro usuario. El usuario todavía necesita incluir en el certificado el UPN del otro usuario, para lo cual actualmente no conocemos ningún exploit existente, pero es un obstáculo de seguridad menos. Para los certificados de dispositivo, es incluso peor y Dirk-jan detalló los requisitos específicos con los que un usuario normal puede registrar un certificado que le permita autenticarse como sistema Domain Controller y tomar el control de la máquina.

Si tienes el certificado de la CA de SCEPman en el almacén NTAuth y quieres prevenir el ataque, puedes establecer [AppConfig:IntuneValidation:AllowRequestedSidExtension](/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-allowrequestedsidextension) a *false*. Esto filtrará las extensiones SID, incluidas las falsificadas. Este también es el valor predeterminado de esta configuración en SCEPman 2.11.1460 o versiones más nuevas. Las versiones anteriores de SCEPman también eliminan de la extensión SAN los URI SID que normalmente son legítimos si configuras esta opción, lo que podría impedir casos de uso válidos.


---

# 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/otros/troubleshooting/sid-spoofing-vulnerability.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.
