Strong Certificate Mapping Enforcement: So bereiten Sie Ihr MDM/UEM vor

Das Problem: KB5014754 Full Enforcement

Microsoft führt Strong Certificate Mapping Enforcement ein, um Schwachstellen in der zertifikatsbasierten Authentifizierung von Active Directory zu schliessen.

Mit den Windows-Updates vom Februar 2025 verlangen Domain Controller, dass jedes für die Client-Authentifizierung verwendete Zertifikat eine sichere Zuordnung zum Benutzerkonto enthält: konkret durch Einbetten des Security Identifier (SID) des Benutzers. Diese Änderung (beschrieben in KB5014754) soll verhindern, dass Angreifer mit Zertifikaten fremde Identitäten vortäuschen.

Bisher wurden Zertifikate über Attribute wie den UPN oder den Subject Name einem Benutzer zugeordnet. Das gilt neu als «schwache» Zuordnung. Unter der neuen Durchsetzung akzeptiert der Kerberos-Logon nur noch «starke» Zuordnungen, also explizite Mappings oder eine im Zertifikat eingebettete, passende SID.

Für Enterprise Mobility ist das vor allem für die Kerberos-Authentifizierung auf Mobilgeräten relevant. Hypergate Authenticator (ermöglicht Kerberos SSO auf Android) bezieht Kerberos-Tickets über Benutzerzertifikate. Diese Zertifikate werden üblicherweise per MDM (etwa Ivanti Neurons oder MobileIron) via SCEP oder ähnliche Verfahren ausgestellt und enthalten die AD-SID bisher nicht. Sobald die volle Durchsetzung aktiv ist, schlagen solche zertifikatsbasierten Logins von Mobilgeräten standardmässig fehl, sofern Sie nichts anpassen. Anders gesagt: Die Kerberos-Authentifizierung für mobile Clients (Android, iOS usw.) mit zertifikatsbasiertem Login bricht, wenn die Zertifikate nicht aktualisiert werden.

Betroffen sind die folgenden Windows-Server-Versionen:

• Windows Server 2025
• Windows Server 2022
• Windows Server 2019
• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2008 R2 mit ESU

Und alle MDM/UEMs, versionsunabhängig, etwa:

• Microsoft Intune
• Ivanti Neurons, ehemals MobileIron Core/Cloud
• Omnissa Workspace One, ehemals VMware AirWatch
• BlackBerry UEM
• Soti Mobicontrol
• Samsung Knox

Microsoft hat eine Übergangsphase im «Kompatibilitätsmodus» eingeräumt (Warnungen im Log, aber keine Blockierung der Authentifizierung). Seit dem 11. Februar 2025 ist die starke Zuordnung jedoch der Standard, und am 10. September 2025 wird der Kompatibilitätsmodus vollständig abgeschaltet.

Auswirkungen auf Hypergate Authenticator

In aktuellen MDM-Deployments erhalten Android-Benutzer mit Hypergate Authenticator ein per MDM verteiltes Benutzerzertifikat und verwenden es für die Kerberos-Authentifizierung (PKINIT). Ohne starke Zuordnung funktionieren diese Logons derzeit nur dank des Kompatibilitätsmodus, und auf Ihren Domain Controllern erscheinen Warnungen. Sobald die starke Zuordnung strikt durchgesetzt wird (spätestens im September 2025), wird jedes Zertifikat ohne korrekte SID-Bindung abgelehnt. Mobile Benutzer können sich dann nicht mehr per Kerberos an Intranet-Diensten anmelden.

Konkret: Ein heute per MDM verteiltes Benutzerzertifikat enthält typischerweise den UPN des Benutzers im Subject oder SAN, den Active Directory dem Konto zuordnet. Unter der strikten Durchsetzung verlangt das KDC eine sichere Zuordnung (entweder ein explizites altSecurityIdentities-Mapping in AD oder die eingebettete SID-Extension). Fehlt die SID im Zertifikat, verweigert das KDC die Ausstellung eines TGT. Damit beginnen Kerberos-SSO-Sitzungen (via Hypergate Authenticator) fehlzuschlagen. Microsoft weist ausdrücklich darauf hin, dass Zertifikate aus einem MDM oder via NDES (sogenannte «Offline-Templates») gefährdet sind und Authentifizierungsfehler wahrscheinlich sind, wenn diese Zertifikate die neuen Anforderungen nicht erfüllen. Kurz: Ihre mobilen Benutzer können plötzlich den Zugriff auf Kerberos-geschützte Ressourcen verlieren, wenn Sie nichts unternehmen.

Diese Fehler treten auf, wenn die Zertifikatszuordnung fehlschlägt

Nachfolgend einige Beispiele für Fehler, die Ihnen in diesem Zusammenhang begegnen können:

• Windows Event Viewer (Domain Controller, KDC): Event ID 39 (Warning oder Error):

  «The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a secure way (such as via explicit mapping, key trust mapping, or a SID)…»

  Das bedeutet: Das präsentierte Zertifikat hatte keine starke Zuordnung (keine SID-Extension und kein explizites Mapping). Im Kompatibilitätsmodus wird dies als Warnung protokolliert und der Login zugelassen; im vollen Durchsetzungsmodus ist es ein Fehler und der Login wird abgelehnt.

• Windows Event Viewer (Domain Controller, KDC): Event ID 41 (Error):

  «The Key Distribution Center (KDC) encountered a user certificate that was valid but contained a different SID than the user to which it mapped. As a result, the request involving the certificate failed.»

  Hier enthielt das Zertifikat zwar eine SID, sie stimmte aber nicht mit der SID des Zielkontos überein (die sichere Zuordnungsprüfung ist fehlgeschlagen). Die Authentifizierung wird aus Sicherheitsgründen verweigert.

• Kerberos-Client-Logs (Hypergate Authenticator): In ausführlichen Kerberos-Logs (oder Hypergate-Debug-Logs) sehen Sie beim Bezug eines TGT einen Fehler wie «Received error from KDC: … Certificate mismatch».

  Ein kinit-Versuch gibt beispielsweise KDC_ERR_CERTIFICATE_MISMATCH aus. Das entspricht dem obigen Ereignis auf dem KDC. Der Domain Controller sagt damit sinngemäss: «Ich kann dieses Zertifikat für diesen Benutzer nicht akzeptieren.»

Diese Fehler zeigen, dass die Kontozuordnung des Zertifikats nicht als sicher gilt. Der Schlüssel zur Lösung ist die SID-Extension. Im nächsten Abschnitt gehen wir durch, wie Sie das in einer MDM/UEM-Umgebung mit Hypergate beheben.

Die Lösung: starke Zertifikatszuordnung über Ihr MDM

Damit das mobile Kerberos SSO weiterläuft, gibt es zwei Wege: Sie aktivieren zunächst den Kompatibilitätsmodus und aktualisieren die Zertifikate später, oder Sie aktualisieren die Zertifikate direkt.

Das Ziel bleibt in beiden Fällen, die Zertifikate spätestens bis September 2025 zu aktualisieren, damit alle Kerberos-Client-Zertifikate die korrekte SID-Zuordnung enthalten.

Übergangslösung: Kompatibilitätsmodus auf den Domain Controllern aktivieren

Als Sofortmassnahme aktivieren Sie den Kompatibilitätsmodus für die Zertifikatszuordnung auf allen Domain Controllern. Damit funktioniert die Authentifizierung mit «schwach» zugeordneten Zertifikaten weiter, bis Sie diese aktualisiert haben, und Sie vermeiden Ausfälle vor dem Stichtag. Gemäss Microsoft setzen Sie dazu auf jedem DC einen Registry-Schlüssel:

• Registry-Pfad: HKLM\SYSTEM\CurrentControlSet\Services\Kdc

• Wertname: StrongCertificateBindingEnforcement (REG_DWORD)

• Wert: 1 (für den Kompatibilitätsmodus, in dem Zertifikate ohne SID weiterhin zugelassen, aber protokolliert werden)

Mögliche Werte sind:

• 0: Kompatibilitätsmodus: Deaktiviert die Prüfung der starken Zertifikatszuordnung. Nicht empfohlen, da damit alle Sicherheitsverbesserungen ausgeschaltet werden. (seit dem 11. Februar 2025 nicht mehr möglich)
• 1: Kompatibilitätsmodus mit Warnungen: Prüft, ob eine starke Zertifikatszuordnung vorliegt. Falls ja, wird die Authentifizierung zugelassen. Andernfalls prüft das KDC, ob das Zertifikat die neue SID-Extension enthält, und validiert diese. Fehlt die Extension, wird die Authentifizierung zugelassen, sofern das Benutzerkonto älter ist als das Zertifikat.
• 2: Strikte Durchsetzung: Prüft, ob eine starke Zertifikatszuordnung vorliegt. Falls ja, wird die Authentifizierung zugelassen. Andernfalls prüft das KDC, ob das Zertifikat die neue SID-Extension enthält, und validiert diese. Fehlt die Extension, wird die Authentifizierung verweigert.

Mit dem Wert 1 bleiben die DCs im Kompatibilitätszustand (protokollieren und zulassen). Der Wert 2 steht für die volle Durchsetzung: protokollieren und Zertifikate ohne SID ablehnen. Genau das wird nach den Updates zum Standard. Der Wert 0 würde die neuen Prüfungen komplett deaktivieren, was Microsoft bereits mit früheren Updates entfernt hat. Ein Neustart ist nicht nötig, die Einstellung wirkt sofort.

Sehr wahrscheinlich müssen Sie zusätzlich den Registry-Schlüssel CertificateBackdatingCompensation berücksichtigen. Er behandelt den Spezialfall, dass das Ausstellungsdatum eines Zertifikats vor dem Erstellungsdatum des Benutzerkontos liegt (was das KDC als verdächtig einstuft). Im Kompatibilitätsmodus erlaubt das KDC standardmässig nur eine Differenz von 10 Minuten:

• Registry-Pfad: HKLM\SYSTEM\CurrentControlSet\Services\Kdc

• Wertname: CertificateBackdatingCompensation (REG_DWORD)

• Wert: 5E0C89C0 (hex: lassen Sie das 0x weg, um den Wert via regedit korrekt einzugeben)

Mögliche Werte sind (wählen Sie einen Wert knapp über der Laufzeit Ihrer Zertifikate):

• 0x5E0C89C0: 50 Jahre
• 0x2EFE0780: 25 Jahre
• 0x12CC0300: 10 Jahre
• 0x9660180: 5 Jahre
• 0x5A39A80: 3 Jahre
• 0x1E13380: 1 Jahr

Damit können sich ältere Zertifikate innerhalb dieses Zeitfensters weiterhin als schwache Zuordnung authentifizieren. Setzen Sie diesen Wert nur, wenn nötig. Er wirkt ausserdem nur im Kompatibilitätsmodus und ist ebenfalls nur eine Übergangslösung.

Mit aktiviertem Kompatibilitätsmodus funktionieren die Hypergate-Logins Ihrer Benutzer während der Übergangsphase weiter (die DCs protokollieren allerdings Warnungen). Das verschafft Ihnen Zeit, die dauerhafte Lösung ohne Serviceunterbruch umzusetzen.

Dauerhafte Lösung: Zertifikate mit SID-Zuordnung aktualisieren

Die langfristige Lösung besteht darin, die SID des Benutzers in das Client-Zertifikat einzubetten, das Hypergate (und andere Dienste) verwenden. So lässt sich das Zertifikat sicher dem Benutzerkonto zuordnen. Dazu passen Sie in der Regel Ihre Zertifikatsvorlagen sowie die SCEP- oder PKCS-Profilkonfiguration in Ihrem MDM/UEM an. Wir zeigen das am Beispiel einer Umgebung mit Ivanti Neurons:

1. Navigieren Sie zu «Configurations», filtern Sie nach «Identity Certificate» und wählen Sie Ihre aktuelle Zertifikatskonfiguration aus:
   
2. Fügen Sie einen zusätzlichen Subject Alternate Name Type vom Typ Uniform Resource Identifier hinzu: tag:microsoft.com,2022-09-14:sid:${user.sid}. Das Datum darin ist statisch: Ändern Sie es nicht, es muss exakt 2022-09-14 lauten.
   Die korrekten Platzhalter sind:

   Microsoft Intune: {{OnPremisesSecurityIdentifier}}
   Ivanti EPMM / MobileIron Core: tag:microsoft.com,2022-09-14:sid:$USER_SID$
   Ivanti Neuron / MobileIron Cloud: tag:microsoft.com,2022-09-14:sid:{user.sid}
   BlackBerry UEM: tag:microsoft.com,2022-09-14:sid:%UserSID%
   Soti Mobicontrol: tag:microsoft.com,2022-09-14:sid:$USER_SID$
   Samsung Knox: tag:microsoft.com,2022-09-14:sid:<UserSID>

3. 
5. Die Zertifikatskonfiguration sollte danach so aussehen:
   

6. Das ergibt schliesslich ein Zertifikat, das die folgenden Subject Alternative Names enthält:

   
   

7. Prüfen Sie die neue Zertifikatszuordnung: Sobald ein Gerät das neue Zertifikat erhalten hat, führen Sie eine Kerberos-Authentifizierung (PKINIT) über Hypergate Authenticator durch. Sie sollte wie gewohnt funktionieren. Prüfen Sie anschliessend erneut die Logs Ihrer Domain Controller: Für den Logon dieses Benutzers sollten keine Event-39-Warnungen mehr erscheinen. Ist die SID vorhanden und korrekt, wertet das KDC die Zuordnung als stark und protokolliert keinen Fehler.

8. Nachdem wir die Zertifikatszuordnung erfolgreich geprüft haben, können wir sie durchsetzen. Das ist nur nötig, wenn Sie starke Zertifikatsbindungen bereits vor September 2025 erzwingen wollen. Danach ist der Registry-Schlüssel ohnehin irrelevant, die Bindung wird dann in jedem Fall durchgesetzt. Um die Durchsetzung heute zu aktivieren, setzen Sie auf jedem DC einen Registry-Schlüssel:

   • Registry-Pfad: HKLM\SYSTEM\CurrentControlSet\Services\Kdc

   • Wertname: StrongCertificateBindingEnforcement (REG_DWORD)

   • Wert: 2 (für den strikten Modus)

Mit diesen Schritten erfüllen Sie die neuen Anforderungen von Microsoft, und das mobile SSO in Ihrem Unternehmen läuft ohne Unterbruch weiter. Auch wenn Strong Certificate Mapping Enforcement vollständig aktiv ist, melden sich Ihre Android-Benutzer weiterhin über Hypergate per Kerberos an, und Ihre Domain Controller akzeptieren die SID-basierten Zuordnungen auf jedem Zertifikat.