Aktivieren der Basic Authentication für den Registrierungsdienst für Netzwerkgeräte (NDES)

Wird der Registrierungsdienst für Netzwerkgeräte (NDES) neu installiert (Vorzugsweise ohne Enterprise Administrator Berechtigungen), wird zunächst nur die Windows-integrierte Authentisierung für die Administrations-Webseite aktiviert. Mit dieser ist (per NT LAN Manager, NTLM) Protokoll auch eine Authentisierung per Benutzername und Passwort möglich. Nicht alle Client-Anwendungen unterstützen diese jedoch.

Ebenso könnte ein Unternehmen gewillt sein, NTLM wo möglich zu deaktivieren und Kerberos für die Anmeldung zu erzwingen. Mit dem Erzwingen von Kerberos fällt die Möglichkeit weg, sich per Benutzername und Passwort an der Administrations-Seite für den Registrierungsdienst für Netzwerkgeräte anzumelden (da dies mit NTLM-Anmeldedaten erfolgt). Um hier wieder eine Möglichkeit zu schaffen, kann jedoch die Basic Authentication nachgerüstet werden.

Einen Ausweg aus diesem Dilemma kann die Basic Authentisierung sein, deren Einrichtung im folgenden dargelegt werden soll.

„Aktivieren der Basic Authentication für den Registrierungsdienst für Netzwerkgeräte (NDES)“ weiterlesen

Deaktivieren von NTLM und erzwingen von Kerberos an der Administrations-Webseite des Registrierungsdienstes für Netzwerkgeräte (NDES)

Viele Unternehmen verfolgen die Strategie, das NT LAN Manager (NTLM) Authentisierungsprotokoll in ihren Netzwerken (weitestgehend) abzuschalten.

Auch für die Administrations-Webseite des Registrierungsdienstes für Netzwerkgeräte (NDES) ist dies möglich. Wie genau die Umsetzung erfolgt, und wie sich dadurch eventuell das Anwendungsverhalten ändert soll nachfolgend erläuert werden.

„Deaktivieren von NTLM und erzwingen von Kerberos an der Administrations-Webseite des Registrierungsdienstes für Netzwerkgeräte (NDES)“ weiterlesen

Änderungen an der Zertifikatausstellung und an der zertifikatbasierten Anmeldung am Active Directory mit dem Patch für Windows Server vom 10. Mai 2022 (KB5014754)

Mit dem Patch vom 10. Mai 2022 versucht Microsoft, eine Sicherheitslücke im Active Directory zu schließen, in welcher die zertifikatbasierte Anmeldung (im Allgemeinen bekannt als Smartcard Logon) zu schließen.

Das Update ändert sowohl das Verhalten der Zertifizierungsstelle als auch das Verhalten des Active Directory beim Verarbeiten von zertifikatbasierten Anmeldungen.

„Änderungen an der Zertifikatausstellung und an der zertifikatbasierten Anmeldung am Active Directory mit dem Patch für Windows Server vom 10. Mai 2022 (KB5014754)“ weiterlesen

Ein Policy Modul, um sie zu bändigen: Vorstellung des TameMyCerts Policy Moduls für die Microsoft Zertifizierungsstelle

Als Betreiber einer Zertifizierungsstelle ist man für die Identifikation der Antragsteller und die Bestätigung ihrer Identität verantwortlich. Dass diese Aufgabe gewissenhaft und fehlerfrei ausgeführt wird, ist der zentrale Grundpfeiler für das Vertrauen, dass der Zertifizierungsstelle eingeräumt wird. Namhafte Firmen sind bereits an dieser Aufgabe gescheitert, mussten in Folge von Falschausstellungen sogar Insolvenz anmelden und/oder wurden durch die großen Player am Markt empfindlich bestraft.

In vielen Fällen sind wir als (Microsoft-)PKI-Betreiber in Unternehmen in der Lage, unsere Aufgabe an das Active Directory zu delegieren (ungeachtet der damit einhergehenden Qualität). In vielen Fällen müssen wir unsere Zertifizierungsstelle(n) aber auch anweisen, einfach alles auszustellen, was beantragt wird.

Namhafte Beispiele hierfür sind unter Anderem:

  • Mobile Device Management (MDM) Systeme wie VMware AirWatch beantragen stellvertretend Zertifikate für die Benutzer der verwalteten Endgeräte.
  • Viele im Unternehmen eingesetzte Gerätetypen erfordern den Betrieb eines Simple Certificate Enrollment (SCEP) Servers. Schlecht abgesicherte SCEP-Schnittstellen können ein Einfallstor für Angriffe auf die Umgebung sein.
  • Weitergabe oder Diebstahl von Zugangsdaten zu Benutzer- oder Dienstkonten können zur Ausstellung potentiell böswilliger Zertifikate führen.
  • Und natürlich der Faktor Mensch. Auch PKI-Betreiber können bei der Konfiguration der Zertifizierungsstellen oder manuellen Prüfung von Zertifikatanforderungen Fehler machen und somit Fehlausstellungen von Zertifikaten verursachen. Das gleiche gilt natürlich auch für andere Administratoren, denen vielleicht die Beantragung von Zertifikaten eingeräumt wurde (im schlimmsten Fall sogar über die Zertifizierungsstellen-Webregistrierung).

Namenseinschränkungen des Zertifizierungsstellen-Zertifikats können diese Fälle teilweise, aber nicht ansatzweise vollumfänglich adressieren.

„Ein Policy Modul, um sie zu bändigen: Vorstellung des TameMyCerts Policy Moduls für die Microsoft Zertifizierungsstelle“ weiterlesen

Grundlagen: Namenseinschränkungen (Name Constraints)

Namenseinschränkungen sind ein Teil des X.509 Standard und im RFC 5280 beschrieben. Sie sind ein Werkzeug, das im Rahmen der qualifizierten Subordinierung eingesetzt werden kann, um den Gültigkeitsbereich eines Zertifizierungsstellenzertifikats feingranular zu steuern.

„Grundlagen: Namenseinschränkungen (Name Constraints)“ weiterlesen

Grenzen der Microsoft Active Directory Certificate Services

Die Active Directory Certificate Services bestehen (wenn auch unter anderem Namen) in ihren Grundzügen seit Windows NT 4.0. Die heutzutage verwendete auf Active Directory besierende Architektur wurde mit Windows 2000 Server eingeführt. Die AD CS sind sehr gut in das Windows-Ökosystem integriert und erfreuen sich weiterhin weltweit großer Beliebtheit in Unternehmen und Behörden jeglicher Größenordnung.

Gerne wird auf die vielen Möglichkeiten hingewiesen, welche die Active Directory Certificate Services bieten. Selten wird allerdings darauf verwiesen, was mit ihnen nicht möglich ist. Das Produkt stößt nämlich mittlerweile an vielen Stellen auch an seine Grenzen.

Welche das sind, soll nachfolgend näher ausgeführt werden, um besser entscheiden zu können, ob die AD CS für geplante Vorhaben die richtige Lösung sein können.

„Grenzen der Microsoft Active Directory Certificate Services“ weiterlesen

Neues Blog zum Thema Active Directory Certificate Services mit Fokus auf Sicherheit

Mit Freuden kann ich verkünden, dass meine sehr geschätzte ehemalige Kollegin Dagmar Heidecker wieder am bloggen ist.

In ihrer neuen Rolle in der Microsoft Compromise Recovery Security Practice setzt Dagmar den thematischen Schwerpunkt insbesondere (aber nicht nur) auf Sicherheitsthemen rund um die Active Directory Certificate Services und damit verbundene Komponenten.

Ihr Blog ist zu finden im Core Infrastructure and Security Blog.

Grundlagen: Einschränkung der Pfadlänge (Path Length Constraint)

Der Ende 2008 vorgeführte Angriff auf den MD5 Signaturalgorithmus konnte nur deshalb zur Erstellung eines nutzbaren gefälschten Zertifizierungsstellen-Zertifikats verwendet werden, da die angegriffene Zertifizierungsstelle keine Einschränkung der Pfadlänge konfiguriert hatte.

Die Einschränkung der Pfadlänge ist im RFC 5280 beschrieben. Die Idee dahinter ist, dass in der "Basic Constraints" Erweiterung eines Zertifizierungsstellen-Zertifikats die maximale Tiefe der Zertifizierungsstellen-Hierarchie hinterlegt wird.

„Grundlagen: Einschränkung der Pfadlänge (Path Length Constraint)“ weiterlesen

Konfigurieren der Trusted Platform Module (TPM) Key Attestation

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 Nichtexportierbarkeit des Schlüssels – auch mit Werkzeugen wie mimikatz – gegeben.

Auf den Ersten Blick ist allerdings nicht ersichtlich, dass nicht garantiert werden kann, dass auch wirklich ein TPM zum Einsatz kommt. Zwar wird keine Beantragung über die Microsoft Management Console oder AutoEnrollment möglich sein, wenn der Computer über kein TPM verfügt.

Es handelt sich jedoch bei der Konfiguration in der Zertifikatvorlage lediglich um eine Voreinstellung für den Client. Die Zertifizierungsstelle wird bei Beantragung nicht explizit prüfen, ob auch wirklich ein Trusted Platform Modul verwendet wurde.

Um sicherzustellen, dass der private Schlüssel einer Zertifikatanforderung wirklich mit einem Trusted Platform Modul geschützt wurde verbleibt also nur die TPM Key Attestation.

„Konfigurieren der Trusted Platform Module (TPM) Key Attestation“ weiterlesen

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.

„Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle“ weiterlesen

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.

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

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.

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

Details zum Ereignis mit ID 5127 der Quelle Microsoft-Windows-Security-Auditing

Ereignisquelle:Microsoft-Windows-Security-Auditing
Ereignis-ID:5127 (0x1407)
Ereignisprotokoll:Security
Ereignistyp:Information
Ereignistext (englisch):The OCSP Revocation Provider successfully updated the revocation information. CA Configuration ID: %1 Base CRL Number: %2 Base CRL This Update: %3 Base CRL Hash: %4 Delta CRL Number: %5 Delta CRL Indicator: %6 Delta CRL This Update: %7 Delta CRL Hash: %8
Ereignistext (deutsch):Der OCSP-Antwortdienst hat die Sperrungsinformationen erfolgreich aktualisiert. Konfigurations-ID der Zertifizierungsstelle: %1 Basissperrlistennummer: %2 Basissperrliste, diese Aktualisierung: %3 Basissperrlistenhash: %4 Deltasperrlistennummer: %5 Deltasperrlistenanzeige: %6 Deltasperrliste, diese Aktualisierung: %7 Deltasperrlistenhash: %8
„Details zum Ereignis mit ID 5127 der Quelle Microsoft-Windows-Security-Auditing“ weiterlesen

Details zum Ereignis mit ID 5059 der Quelle Microsoft-Windows-Security-Auditing

Ereignisquelle:Microsoft-Windows-Security-Auditing
Ereignis-ID:5059 (0x13C3)
Ereignisprotokoll:Security
Ereignistyp:Information
Ereignistext (englisch):Key migration operation. Subject: Security ID: %1 Account Name: %2 Account Domain: %3 Logon ID: %4 Cryptographic Parameters: Provider Name: %5 Algorithm Name: %6 Key Name: %7 Key Type: %8 Additional Information: Operation: %9 Return Code: %10
Ereignistext (deutsch):Schlüsselmigrationsvorgang. Antragsteller: Sicherheits-ID: %1 Kontoname: %2 Kontodomäne: %3 Anmelde-ID: %4 Kryptografische Parameter: Anbietername: %5 Algorithmusname: %6 Schlüsselname: %7 Schlüsseltyp: %8 Zusätzliche Informationen: Vorgang: %9 Rückgabecode: %10
„Details zum Ereignis mit ID 5059 der Quelle Microsoft-Windows-Security-Auditing“ weiterlesen

Details zum Ereignis mit ID 5120 der Quelle Microsoft-Windows-Security-Auditing

Ereignisquelle: Microsoft-Windows-Security-Auditing
Ereignis-ID: 5120 (0x1400)
Ereignisprotokoll: Security
Ereignistyp: Information
Ereignistext (englisch): OCSP Responder Service Started.
Ereignistext (deutsch): Der OCSP-Antwortdienst wurde gestartet.
„Details zum Ereignis mit ID 5120 der Quelle Microsoft-Windows-Security-Auditing“ weiterlesen