Active Directory – Seite 2

Die Installation der Standard-Zertifikatvorlagen schlägt fehl mit Fehlermeldung "This security ID may not be assigned as the owner of this object."

Folgendes Szenario angenommen:

Es soll erstmalig eine ins Active Directory integrierte Zertifizierungsstelle (Enterprise Certification Authority) im Netzwerk installiert werden.
Die Rechte für die Installation der Zertifizierungsstelle wurden aus Sicherheitsgründen auf eine separate Sicherheitsgruppe oder ein separates Konto delegiert, sodass keine Anmeldung als Enterprise Administrator erforderlich ist. Andersherum formuliert: Der verwendete Benutzer ist nicht Mitglied der Gruppe "Enterprise Administrators" in der Active Directory Gesamtstruktur.
Da es sich um die erste Zertifizierungsstelle im Netzwerk handelt, sind noch keine Standard-Zertifikatvorlagen im Active Directory installiert. Beim Öffnen der Verwaltungskonsole für Zertifikatvorlagen (certtmpl.msc) wird man aufgefordert, diese zu installieren.
Die Installation schlägt mit folgender Fehlermeldung fehl:

Windows could not install the new certificate templates. This security ID may not be assigned as the owner of this object.

Stammstellen-Zertifikate werden auf Domänenmitgliedern in den Zertifikatspeicher für Zwischenzertifizierungsstellen importiert

Manch einem wird aufgefallen sein, dass der Zertifikatspeicher für Zwischenzertifizierungsstellen üblicherweise auch Zertifikate für Stammzertifizierungsstellen beinhaltet.

In der Regel ist dieses Verhalten unkritisch. In bestimmten Fällen kann dies allerdings auch Probleme mit Anwendungen hervorrufen.

Grundlagen: Ersetzen (Superseding) von Zertifikatvorlagen

Mit der Einführung der Zertifikatvorlagen der Version 2 zusammen mit Windows XP und Windows Server 2003 wurde die Option eingeführt, dass eine Zertifikatvorlage eine oder mehrere andere ersetzen kann.

Hiermit ist es möglich, ausgestellte Zertifikate durch solche einer anderen Zertifikatvorlage zu ersetzen, oder mehrere Zertifikatvorlagen zu einer einzigen hin zu konsolidieren.

Der lokale Zertifikatspeicher für vertrauenswürdige Stammzertifizierungsstellen wird nicht aus dem Active Directory synchronisiert

Folgendes Szenarion angenommen:

Es ist eine Zertifizierungsstellen-Hierarchie im Netzwerk etabliert und die Stammzertifizierungsstelle ist in der Configuration-Partition der Active Directory Gesamtstruktur abgebildet.
Die Domänenmitglieder sind konfiguriert, den Autoenrollment-Prozess auszuführen und somit vertrauenswürdige Stammzertifizierungsstellen aus der Configuration-Partition zu aktualisieren.
Bei einigen Clients funktioniert dieser Prozess allerdings nicht. Die Stammzertifizierungsstellen-Zertifikate werden nicht automatisch heruntergeladen und in den lokalen Vertrauensspeicher eingetragen.
Als Folgeerscheinung können Zertifikatbeantragungen fehlschlagen, da beispielsweise der Zertifizierungsstellen-Hierarchie nicht vertraut wird.

Von Null auf Enterprise Administrator durch den Registrierungsdienst für Netzwerkgeräte (NDES) – und was dagegen getan werden kann

Nachfolgend möchte ich eine der breiten Öffentlichkeit vielleicht nicht unbedingt bekannte hochgefährliche PKI-Konfiguration vorstellen, die so in Unternehmensnetzwerken wahrscheinlich recht häufig angetroffen werden kann.

Ich zeige auf, wie durch Ausnutzung verschiedener unglücklicher Umstände in der Windows-PKI eine Erhöhung von Rechten, ausgehend von bloßem Netzwerkzugang bis hin zur vollständigen Übernahme des Active Directory möglich ist.

Der initiale Angriffspunkt ist in diesem Beispiel der Registrierungsdienst für Netzwerkgeräte (NDES).

Die Beantragung eines Zertifikats schlägt fehl mit Fehlermeldung "The requested certificate template is not supported by this CA. 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE)."

Folgendes Szenario angenommen:

Es wird versucht, ein Zertifikat von einer ins Active Directory integrierten Zertifizierungsstelle (Enterprise CA) für einen Benutzer oder Computer zu beantragen.
Die Beantragung des Zertifikats schlägt mit folgender Fehlermeldung fehl:

The requested certificate template is not supported by this CA. 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE).

Konfigurieren einer Zertifikatvorlage für die Verwendung des Microsoft Platform Crypto Provider, um Schutz des privaten Schlüssels durch ein Trusted Platform Module (TPM) zu ermöglichen

Seit Windows 8 ist es möglich, dass private Schlüssel für Zertifikate mit einem – sofern vorhanden – Trusted Platform Modul (TPM) geschützt werden. Dadurch ist eine echte Nichtexportierbarkeit des Schlüssels gegeben.

Nachfolgend wird der Prozess zur Einrichtung einer Zertifikatvorlage, die ein Trusted Platform Modul verwendet, beschrieben.

Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle

Immer wieder kommt in Diskussionen zur Sicherheit einer Zertifizierungsstelle auf, dass ein Missbrauch der Zertifizierungsstelle durch deren Sicherheitseinstellungen eingedämmt werden könnte.

Dass die Integrität einer Zertifizierungsstelle jedoch unmittelbar an ihr Schlüsselmaterial gebunden ist und sie somit durch dieses auch kompromittiert werden kann, ist auf den Ersten Blick nicht offensichtlich.

Muss man sich die Zertifizierungsstellen-Software als eine Art Management um das Schlüsselmaterial herum vorstellen. Die Software bietet beispielsweise eine Online-Schnittstelle für die Zertifikatbeantragung an, kümmert sich um die Authentifizierung der Antragsteller, um die automatisierte Durchführung von Signaturoperationen (Ausstellen von Zertifikaten und Sperrlisten) und deren Protokollierung (Zertifizierungsstellen-Datenbank, Auditprotokoll, Ereignisprotokoll).

Signaturoperationen benötigen jedoch nichts weiter als den privaten Schlüssel der Zertifizierungsstelle. Nachfolgend wird anhand eines Beispiels aufgezeigt, wie ein Angreifer, wenn er Zugang zum privaten Schlüssel der Zertifizierungsstelle erhält, Zertifikate erzeugen und ausstellen kann, ohne dass die Zertifizierungsstellen-Software und deren Sicherheitsmechanismen dies mitbekommen würden.

Mit einem solchen Zertifikat wäre es im schlechtesten Fall sogar möglich, die Active Directory Gesamtstruktur unerkannt zu übernehmen.

Bei der Installation einer Active Directory integrierten Zertifizierungsstelle erscheint die Fehlermeldung "Insufficient access rights to perform the operation. 0x80072098 (Win32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)"

Folgendes Szenario angenommen:

Es wird eine ins Active Directory integrierte Zertifizierungsstelle (Enterprise Certification Authority) per Windows PowerShell installiert.
Für die Installation der Zertifizierungsstelle werden delegierte Berechtigungen verwendet. Der installierende Benutzer ist also nicht Mitglied der Gruppe "Enterprise Administrators".
Nach Ausführen des Rollenkonfigurations-Assistenten wird eine oder mehrere der folgenden Fehlermeldungen auf der Kommandozeile ausgegeben:

Setup could not add the Certification Authority's computer account to the Pre-Windows 2000 Compatible Access security group. Certificate managers Restrictions feature will not work correctly on this Certification Authority. To fix this, an administrator must manually add the Certification's Authority's computer account to the Pre-Windows 2000 Compatible Access security group in Active Directory. Insufficient access rights to perform the operation. 0x80072098 (Win32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)

Warning: Setup could not add the certification authority’s computer account to the cert Publishers Security Group. This Certification Authority will not be able to publish certificates in Active Directory. To fix this, an administrator must manually add the Certification Authority’s computer account to the Cert Publishers security group in Active Directory.  Insufficient access rights to perform the operation. 0x80072098 (Win32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)

Die Installation eines Zertifizierungsstellen-Zertifikats schlägt fehl mit Fehlermeldung "Insufficient access rights to perform the operation. 0x80072098 (WIN32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)"

Folgendes Szenario angenommen:

Es wird eine ins Active Directory integrierte Zertifizierungsstelle (Enterprise Certification Authority) installiert.
Für die Installation der Zertifizierungsstelle werden delegierte Berechtigungen verwendet. Der installierende Benutzer ist also nicht Mitglied der Gruppe "Enterprise Administrators".
Nach der Ausstellung des Zertifizierungsstellen-Zertifikats durch die übergeordnete Zertifizierungsstelle wird dieses installiert, um die Rollenkonfiguration abzuschließen.
Die Installation des Zertifizierungsstellen-Zertifikats schlägt mit folgender Fehlermeldung fehl:

Insufficient access rights to perform the operation. 0x80072098 (WIN32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)

Der Anzeigename einer Zertifikatvorlage wird nicht aufgelöst. Es wird nur der Objektidentifizierer (OID) der Zertifikatvorlage angezeigt.

Folgendes Szenario angenommen:

Für eine Zertifikatvorlage wird nur der Objektidentifizierer (Object Identifier) angezeigt, jedoch nicht der Anzeigename und/oder
Abfragen gegen die Zertifizierungsstellen-Datenbank enthalten für die Zertifikatvorlage (Feld "CertificateTemplate") nur den Objektidentifizier, jedoch nicht den Anzeigenamen.

Gibt es eine Abhängigkeit des Registrierungsdienstes für Netzwerkgeräte (NDES) mit dem NTAuthCertificates Objekt?

Der Registrierungsdienst für Netzwerkgeräte (NDES) verfügt über zwei Registration Authority Zertifikate. Mit dem Enrollment-Agenten-Zertifikat werden Zertifikatanforderungen signiert und man kann die NDES-Gerätevorlage entsprechend konfigurieren, sodass Zertifikate auch nur dann ausgestellt werden, wenn die eingereichten Zertifikatanforderungen auch eine entsprechende Signatur aufweisen.

Plant man, die mit dem NDES verbundene Zertifizierungsstelle aus dem NTAuthCertificates Objekt zu entfernen, kommt eventuell die Frage auf, ob hier wechselseitige Abhängigkeiten zu berücksichtigen sind – schließlich erfordert Enroll on Behalf Of (EOBO) das Vorhandensein des Zertifizierungsstellen-Zertifikats in NTAuthCertificates.

Übersicht über die für die PKI relevanten Active Directory Ereignisse

Nachfolgend eine Übersicht über die für die Public Key Infrastruktur relevanten auf Domänencontrollern erzeugten Ereignisse in der Windows-Ereignisanzeige.

Domänencontroller (oder andere Teilnehmer) zwingen, einen Onlineresponder (OCSP) zu verwenden

In der Standardeinstellung werden Windows-Systeme, auch wenn ein Onlineresponder (OCSP) konfiguriert ist, nach einer bestimmten Anzahl von OCSP-Anfragen auf eine (falls vorhanden) Sperrliste zurückfallen, weil dies in einem solchen Fall meistens effizienter ist. Nicht immer ist dieses Verhalten aber gewünscht.

Setzt man beispielsweise Smartcard-Anmeldungen ein, möchte man vielleicht wissen, ob Anmeldungen mit unberechtigt ausgestellten Zertifikaten ausgeführt wurden. In Verbindung mit dem deterministischen Good des Onlineresponders kann man so einen (beinahe) lückenlosen Auditierungspfad für alle Smartcard-Anmeldungen schaffen.

Details zum Ereignis mit ID 32 der Quelle Microsoft-Windows-Kerberos-Key-Distribution-Center

Ereignisquelle:	Microsoft-Windows-Kerberos-Key-Distribution-Center
Ereignis-ID:	32 (0x80000020)
Ereignisprotokoll:	System
Ereignistyp:	Warnung
Ereignistext (englisch):	The Key Distribution Center (KDC) uses a certificate without KDC Extended Key Usage (EKU) which can result in authentication failures for device certificate logon and smart card logon from non-domain-joined devices. Enrollment of a KDC certificate with KDC EKU (Kerberos Authentication template) is required to remove this warning.
Ereignistext (deutsch):	Vom Schlüsselverteilungscenter (Key Distribution Center, KDC) wird ein Zertifikat ohne erweiterte Schlüsselverwendung (Extended Key Usage, EKU) für das KDC verwendet. Dies kann bei Gerätezertifikatanmeldungen und Smartcardanmeldungen von Geräten ohne Domänenzugehörigkeit zu Authentifizierungsfehlern führen. Die Registrierung eines KDC-Zertifikats mit KDC-EKU (Kerberos-Authentifizierungsvorlage) ist erforderlich, um diese Warnung zu beseitigen.