# SID-Spoofing-Sicherheitslücke Dirk-jan Mollema hat kürzlich [beschrieben, wie man Certifried-ähnliche Angriffe auf Intune ausweiten kann](https://dirkjanm.io/extending-ad-cs-attack-surface-intune-certs/). Zwar verwendete er im Artikel AD CS und NDES, die beschriebenen Probleme sind jedoch nicht spezifisch dafür und gelten im Allgemeinen für alle PKIs, die Intune für SCEP-Enrolment verwenden, einschließlich SCEPman. Es gibt jedoch einige zusätzliche Einschränkungen für andere PKIs. Am wichtigsten ist, dass dies auf der allgemeinen [Certifried-Schwachstelle](/de/sonstiges/troubleshooting/certifried.md) aufbaut und daher erfordert, dass das CA-Zertifikat im NTAuth-Store der Domäne vorhanden ist. Während AD CS standardmäßig im NTAuth-Store enthalten ist, ist SCEPman das nicht. Daher können SCEPman-Benutzer nur betroffen sein, wenn sie das CA-Zertifikat explizit zum NTAuth-Store hinzugefügt haben. Wenn Sie das nicht getan haben, sind Sie sicher. Es gibt jedoch einige Anwendungsfälle, die das Hinzufügen des CA-Zertifikats zum NTAuth-Store erfordern, insbesondere [Domänencontroller-Zertifikate](/de/zertifikatsverwaltung/domain-controller-certificates.md) und [zertifikatsbasierte RDP-Authentifizierung](/de/scepman-bereitstellung/deployment-guides/scenarios/certificate-based-authentication-for-rdp.md). Wenn sich Ihr CA-Zertifikat im NTAuth-Store befindet und Sie die Intune-Enrolment auf SCEPman aktivieren, können Ihre Intune-Admins dies in der Regel ausnutzen und Zertifikate enrolen, mit denen sie die Domäne übernehmen können, d. h. Ihre Intune-Admins sollten als Tier-0-Admins behandelt werden. Doch Dirk-jan beschrieb noch ein weiteres, schwerwiegenderes Problem. Intune prüft offenbar nicht, ob eine vom Benutzer angegebene SID mit dem onPremisesSecurityIdentifier-Attribut des Benutzers oder Geräts übereinstimmt, und hebt damit die von Microsoft mit der Durchsetzung von Strong Mapping ergriffenen Gegenmaßnahmen auf. Ein Benutzer ohne erhöhte Rechte (nun ja, lokale Administratorrechte auf seinem Gerät können notwendig sein oder auch nicht) kann ein Zertifikat mit der SID eines anderen Benutzers enrolen. Der Benutzer muss dennoch die UPN des anderen Benutzers in das Zertifikat bekommen; hierfür kennen wir derzeit keinen bekannten Exploit, aber es ist eine Sicherheitsbarriere weniger. Bei Gerätezertifikaten ist es sogar noch schlimmer, und Dirk-jan erläuterte die genauen Voraussetzungen, unter denen ein normaler Benutzer ein Zertifikat enrolen kann, das es ihm ermöglicht, sich als Domänencontroller-System zu authentifizieren und das Gerät zu übernehmen. Wenn Sie das SCEPman-CA-Zertifikat im NTAuth-Store haben und den Angriff verhindern möchten, können Sie [AppConfig:IntuneValidation:AllowRequestedSidExtension](/de/scepman-konfiguration/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-allowrequestedsidextension) nach *false* setzen. Dadurch werden SID-Erweiterungen, einschließlich gefälschter, herausgefiltert. Dies ist auch der Standardwert für diese Einstellung in SCEPman 2.11.1460 oder neuer. Frühere Versionen von SCEPman entfernen bei Aktivierung dieser Einstellung außerdem SID-URIs aus der SAN-Erweiterung, die normalerweise legitim sind, und könnten dadurch gültige Anwendungsfälle verhindern. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.scepman.com/de/sonstiges/troubleshooting/sid-spoofing-vulnerability.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.