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

# Vulnérabilité de spoofing SID

Dirk-jan Mollema a récemment [décrit comment étendre des attaques de type Certifried à Intune](https://dirkjanm.io/extending-ad-cs-attack-surface-intune-certs/). Bien qu'il ait utilisé AD CS et NDES dans l'article, les problèmes décrits ne leur sont pas spécifiques et s'appliquent généralement à toutes les IGC utilisant Intune pour l'inscription SCEP, y compris SCEPman.

Cependant, il existe quelques contraintes supplémentaires pour d'autres IGC. Plus important encore, comme cela repose sur la vulnérabilité générale [Certifried](/fr/autres/troubleshooting/certifried.md), cela exige que le certificat de l'AC se trouve dans le magasin NTAuth du domaine. Alors qu'AD CS s'y trouve par défaut, SCEPman n'y figure pas ; les utilisateurs de SCEPman ne peuvent donc être concernés que s'ils ont explicitement ajouté le certificat de l'AC au magasin NTAuth. Si vous ne l'avez pas fait, vous êtes en sécurité. Certains cas d'usage exigent toutefois d'ajouter le certificat de l'AC au magasin NTAuth, notamment [certificats Domain Controller](/fr/gestion-des-certificats/domain-controller-certificates.md) et [authentification RDP basée sur certificat](/fr/deploiement-de-scepman/deployment-guides/scenarios/certificate-based-authentication-for-rdp.md). Si votre certificat d'AC se trouve dans le magasin NTAuth et que vous activez l'inscription Intune sur SCEPman, cela permettra généralement à vos administrateurs Intune d'exploiter cette faille et d'inscrire des certificats grâce auxquels ils peuvent prendre le contrôle du domaine, c'est-à-dire que vos administrateurs Intune devraient être considérés comme des administrateurs de niveau 0.

Mais Dirk-jan a décrit un autre problème, plus grave. Intune ne semble pas vérifier si un SID fourni par l'utilisateur correspond à l'attribut onPremisesSecurityIdentifier de l'utilisateur ou de l'appareil, annulant les mesures d'atténuation mises en place par Microsoft avec l'application du mappage fort. Un utilisateur sans droits élevés (enfin, des droits d'administrateur local sur sa machine peuvent ou non être nécessaires) peut inscrire un certificat avec le SID d'un autre utilisateur. L'utilisateur doit encore faire figurer le UPN de l'autre utilisateur dans le certificat, pour ce dont nous ne connaissons actuellement pas d'exploit existant, mais c'est un obstacle de sécurité de moins. Pour les certificats d'appareil, c'est encore pire et Dirk-jan a exposé les exigences spécifiques grâce auxquelles un utilisateur normal peut inscrire un certificat qui lui permet de s'authentifier comme système d'un Domain Controller et de prendre le contrôle de la machine.

Si vous avez bien le certificat d'AC SCEPman dans le magasin NTAuth et que vous souhaitez empêcher l'attaque, vous pouvez définir [AppConfig:IntuneValidation:AllowRequestedSidExtension](/fr/configuration-de-scepman/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-allowrequestedsidextension) à *faux*. Cela filtrera les extensions SID, y compris les extensions usurpées. C'est également la valeur par défaut de ce paramètre dans SCEPman 2.11.1460 ou plus récent. Les versions précédentes de SCEPman suppriment également les URI SID de l'extension SAN, qui sont généralement légitimes si vous configurez ce paramètre, ce qui peut potentiellement empêcher des cas d'usage valides.


---

# 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/fr/autres/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.