Nach mehrfachen Verschiebungen hat Microsoft letztendlich entschieden, dass die Änderungen an der Zertifikatausstellung und an der zertifikatbasierten Anmeldung am Active Directory mit dem Patch für Windows Server vom 10. Mai 2022 (KB5014754) nun endgültig in Kraft treten sollen.
Domänencontroller werden zum 25. Februar 2025 daher automatisch in den Full Enforcement Mode gehen, wenn nichts anderes konfiguriert ist. Zum September 2025 ist angekündigt, dass abweichende Einstellungen wegfallen werden und somit keine Alternative mehr zum Full Enforcement bestehen wird.
Dies hat zur Konsequenz, dass für Anmeldungen via PKInit nur noch dann für eine Anmeldung verwendet werden können, wenn sie über die mit dem Patch neu eingeführte Security Identifier (SID) Zertifikaterweiterung verfügen.
Was zunächst klingt, als wäre dies kein großes Problem, kann durchaus zu einem werden, wenn man bedenkt, dass in der heutigen Zeit immer weniger Zertifikat-basierte Anwendungsfälle klassisches Autoenrollment verwenden.
Wie das TameMyCerts Policy Modul für die Active Directory Certificate Services bei diesem Problem helfen kann, wird im nachfolgenden Artikel näher beleuchtet.
Wer und was ist betroffen?
Die Änderung betrifft grundsätzlich alle Anwendungsfälle, die nicht mit klassischem Autoenrollment abgedeckt werden können, wenn die Zertikate für eine Anmeldung per PKInit verwendet werden.
Fehlt die SID-Zertifikaterweiterung in solchen Zertifikaten, kann dies zu Authentisierungsproblemen, insbesondere mit folgenden Diensten führen:
- Always On VPN
- Network Access Control (NAC) mit dem Microsoft Netzwerkrichtlinienserver (NPS)
- Windows Hello for Business, wenn Zertifikate zur Anmeldung der Benutzer eingesetzt werden
Dieses Problem betrifft aber nicht nur Microsoft Intune, sondern auch alle anderen Mobile Device Management (MDM) Systeme, welche Geräte verwalten, die in einer Active Directory Umgebung mit Zertifikaten arbeiten.
Unter Anderem können dies sein:
- Microsoft Intune
- VMware Workspace One (previously known as AirWatch)
- Ivanti MobileIron UEM
- Jamf Pro
- Baramundi Enterprise Mobility Management
- BlackBerry Enterprise Mobility Suite
- Good for Enterprise
- Sophos Mobile
- SOTI MobiControl
Das Problem beschränkt sich hierbei aber nicht nur auf Mobile Device Management Systeme.
All diese Systeme arbeiten nach einem ähnlichen Muster: Der Zertifikatantrag wird durch das MDM-System, die Zertifizierungsstelle muss in der Regel konfiguriert werden, diesen ungeprüft zu signieren.
Die Lösung – TameMyCerts
TameMyCerts ist ein Policy Modul für die Microsoft Active Directory Certificate Services (ADCS). Es greift in den Zertifikatausstellungs-Prozess ein und ermöglicht hierbei die Anwendung von erweiterten Regeln.
TameMyCerts ist Open Source und kann kostenfrei verwendet werden. Für den Einsatz im Unternehmensbereich empfiehlt sich jedoch der Abschluss eines Wartungsvertrags. Dies stellt sicher, dass Sie qualifizierte Unterstützung erhalten und dass das Modul langfristig in hoher Qualität weiterentwickelt werden kann.
Nehmen wir beispielhaft an, unser Unternehmen bietet Benutzern die Verwendung von Endgeräten an, die über ein Mobile Device Management System (MDM) verwaltet werden. Die Benutzerkonten sind zwar im Active Directory vorhanden und verfügen somit über einen Security Identifier (SID), jedoch bietet das MDM-System keine Möglichkeit, diese in den Zertifikatantrag einzufügen.
TameMyCerts kann hier Abhilfe schaffen, indem es eine Verbindung zwischen dem Zertifikatantrag und dem Benutzerkonto herstellt.
Nachdem das Policy Modul installiert wurde, erstellen wir eine entsprechende Konfigurationsdatei:
<CertificateRequestPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Subject>
<SubjectRule>
<Field>userPrincipalName</Field>
<Mandatory>true</Mandatory>
<Patterns>
<Pattern>
<Expression>^[a-zA-Z0-9]*$</Expression>
</Pattern>
</Patterns>
</SubjectRule>
</Subject>
<DirectoryServicesMapping>
<SearchRoot>OU=ADCS Labor Users,DC=intra,DC=adcslabor,DC=de</SearchRoot>
<CertificateAttribute>commonName</CertificateAttribute>
<DirectoryServicesAttribute>sAMAccountName</DirectoryServicesAttribute>
<ObjectCategory>user</ObjectCategory>
<AllowedSecurityGroups>
<string>CN=MDM Users,OU=ADCS Labor Groups,DC=intra,DC=adcslabor,DC=de</string>
</AllowedSecurityGroups>
<DisallowedSecurityGroups>
<string>CN=Administrative Accounts,OU=ADCS Labor Groups,DC=intra,DC=adcslabor,DC=de</string>
</DisallowedSecurityGroups>
</DirectoryServicesMapping>
<SecurityIdentifierExtension>Add</SecurityIdentifierExtension>
</CertificateRequestPolicy>
In diesem Beispiel erwarten wir, dass der Zertifikatantrag lediglich den Benutzernamen (sAMAccountName Attribut) im commonName Attribut des Subject Distinguished Name des Zertifikatantrages aufweist.
Dieser Teil muss entsprechend im MDM-System konfiguriert werden. Für VMware Workspace One wäre die Syntax beispielsweise "CN={EnrollmentUser}".
Die erwartete Syntax für den commonName geben wir als regulären Ausdruck im "Pattern" an.
Die "DirectoryServicesMapping" Direktive nimmt nun den commonName und sucht im Active Directory nach einem Objekt vom Typ "user", der als "sAMAccountName" Attribut den Wert aus dem commonName des Zertifikatantrags vorweisen kann, jedoch nur im Unterverzeichnis "ADCS Labor Users", was wir über "SearchRoot" spezifizieren.
Im Bereich "AllowedSecurityGroups" spezifizieren wir, dass das gefundene Benutzerkonto Mitglied der Sicherheitsgruppe "MDM Users" sein muss, unter "DisllowedSecurityGroups" schränken wir dies wiederum darauf ein, dass gefundene Konten aber nicht Mitglied von "Administrative Users" sein dürfen.
Wird kein Objekt gefunden, das all diese Kriterien erfüllt, wird der Zertifikatantrag abgelehnt.
Wird jedoch ein Objekt gefunden, können wir nun dessen Security Identifier (SID) in das ausgestellte Zertifikat schreiben, was wir über "SecurityIdentifierExtension" konfigurieren.
Das ausgestellte Zertifikat wird nun über die entsprechende Zertifikaterweiterung verfügen.
Als angenehmen Nebeneffekt sorgen wir auch dafür, dass nur Zertifikat für bekannte Konten ausgestellt werden, aber auch nur dann, wenn sie Mitglied einer bestimmten Gruppe sind und keine Administratoren sind. Entsprechend haben wir hiermit das Sicherheitsniveau im Vergleich zu vorher deutlich erhöht.
Weiterführende Links:
- Änderungen an der Zertifikatausstellung und an der zertifikatbasierten Anmeldung am Active Directory mit dem Patch für Windows Server vom 10. Mai 2022 (KB5014754)
- Anmeldungen über den Netzwerkrichtlinienserver (engl. Network Policy Server, NPS) scheitern mit Grund "Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect."
- Ein Policy Modul, um sie zu bändigen: Vorstellung des TameMyCerts Policy Moduls für Microsoft Active Directory Certificate Services
Deutsch 
English