Zum Inhalt springen
05 · AD-ZertifikatdiensteTeil 3 von 4Fortgeschritten

AD-CS-Webregistrierung gegen ESC8 und ESC11 absichern

NTLM-Relay auf AD CS unterbinden: HTTP-Registrierungsendpunkte finden, HTTPS und EPA erzwingen, NTLM abschalten, Webregistrierung entfernen, RPC verschlüsseln.

Florian Amette7 Min. Lesezeit

ESC8 ist der Grund, warum PetitPotam zu einer Technik der Domänenübernahme wurde statt zu einer Kuriosität. Ein Angreifer zwingt einen Domänencontroller zur Authentifizierung per NTLM, leitet diese Authentifizierung an die HTTP-Registrierungsseite der CA weiter und erhält ein Zertifikat, das auf das Computerkonto des Domänencontrollers selbst ausgestellt ist. Dieses Zertifikat authentifiziert per PKINIT als der DC, was genügt, um Replikationsdaten anzufordern. Keine Vorlage ist falsch konfiguriert, kein Kennwort wird erraten; der Fehler besteht darin, dass die CA NTLM über einen Kanal akzeptiert, der die Authentifizierung nicht an die Sitzung bindet (siehe den Glossareintrag zu ESC8). ESC11 ist dieselbe Idee gegen die RPC-Registrierungsschnittstelle der CA, wenn die Verschlüsselung der Anforderungen nicht erzwungen wird.

Dieser Leitfaden behandelt die Registrierungsangriffsfläche im Detail: jeden HTTP- und RPC-Endpunkt finden, der Zertifikate ausstellt, entscheiden, welche davon überhaupt existieren sollten, und die übrigen mit HTTPS, Extended Protection for Authentication (EPA), dem Entfernen von NTLM und IF_ENFORCEENCRYPTICERTREQUEST härten. Er ergänzt den ESC-Überblick im Leitfaden zur AD-CS-Härtung und die übergreifenden Relay-Maßnahmen in NTLM-Relay stoppen.

Messen: jeden Registrierungsendpunkt finden

AD CS kann vier Registrierungswege bereitstellen. Nur der erste ist immer vorhanden:

EndpunktRollendienstTransportRelay-Klasse
MS-ICPR / DCOM (ICertPassage, ICertRequest)Certification AuthorityRPCESC11, wenn Verschlüsselung nicht erzwungen wird
/certsrvCertification Authority Web Enrollment (ADCS-Web-Enrollment)HTTP/HTTPSESC8
Certificate Enrollment Web Service (CES)ADCS-Enroll-Web-SvcHTTPSESC8 mit integrierter Windows-Authentifizierung
Network Device Enrollment Service (/certsrv/mscep)ADCS-Device-EnrollmentHTTP/HTTPSEigenes Risiko, gleiche Härtung

Beginnen Sie damit, was auf jeder CA und jedem Registrierungsserver installiert ist:

PowerShell
# Auf jeder CA / jedem Registrierungs-Webserver ausführen
Get-WindowsFeature ADCS-* | Where-Object Installed | Select-Object Name, DisplayName

# Unternehmens-CAs und alle in AD veröffentlichten CES-URIs
$pks = "CN=Public Key Services,CN=Services,$((Get-ADRootDSE).configurationNamingContext)"
Get-ADObject -SearchBase "CN=Enrollment Services,$pks" -LDAPFilter '(objectClass=pKIEnrollmentService)' `
    -Properties dNSHostName, msPKI-Enrollment-Servers |
    Select-Object Name, dNSHostName, @{n='CES';e={$_.'msPKI-Enrollment-Servers' -join '; '}}

Prüfen Sie dann, was jeder Web-Endpunkt tatsächlich anbietet. Von einer in die Domäne eingebundenen Admin-Arbeitsstation aus liefert eine nicht authentifizierte Anfrage in Windows PowerShell 5.1 die Authentifizierungsverfahren im Header WWW-Authenticate. NTLM oder Negotiate über unverschlüsseltes HTTP ist der schlimmste Fall.

PowerShell
foreach ($url in 'http://ca01.corp.example/certsrv/','https://ca01.corp.example/certsrv/') {
    try   { Invoke-WebRequest -Uri $url -UseBasicParsing -ErrorAction Stop | Out-Null; "$url -> anonymous 200" }
    catch { "$url -> $($_.Exception.Response.StatusCode) $($_.Exception.Response.Headers['WWW-Authenticate'])" }
}

Messen Sie abschließend die Nutzung. Zeigen die IIS-Protokolle in 90 Tagen keine legitimen Zugriffe auf /certsrv, härten Sie den Endpunkt nicht — Sie löschen ihn.

PowerShell
Get-ChildItem 'C:\inetpub\logs\LogFiles\W3SVC1\*.log' |
    Where-Object LastWriteTime -gt (Get-Date).AddDays(-90) |
    Select-String -Pattern ' /certsrv' |
    ForEach-Object { ($_.Line -split ' ')[8] } |   # Spalte c-ip in der Standard-Feldreihenfolge von W3C
    Group-Object | Sort-Object Count -Descending | Select-Object -First 20 Count, Name

Prüfen Sie den Spaltenindex anhand des Headers #Fields: Ihrer Protokolldateien, bevor Sie sich auf die Spalte mit der Client-IP verlassen.

Pro Endpunkt entscheiden

Klassifizieren Sie jeden Endpunkt, bevor Sie etwas ändern. Ein Endpunkt ohne legitimen Datenverkehr wird entfernt. Ein Endpunkt, der nur von in die Domäne eingebundenen Windows-Clients genutzt wird, lässt sich meist auf RPC-basierte automatische Registrierung umstellen und dann entfernen. Ein Endpunkt, der Nicht-Domänengeräte, Partner-Gesamtstrukturen oder Appliances bedient, bleibt und erhält die vollständige Behandlung mit HTTPS, EPA und ausschließlich Kerberos, wie unten beschrieben. CES verdient einen eigenen Hinweis: Der Dienst kann mit integrierter Windows-Authentifizierung, Benutzername und Kennwort oder Clientzertifikat-Authentifizierung konfiguriert werden. Nur die Variante mit integrierter Windows-Authentifizierung ist im Sinne von ESC8 weiterleitbar, doch Authentifizierung per Benutzername und Kennwort präsentiert jedem, der den Dienst erreicht, eine Kennwortabfrage — bevorzugen Sie für Erneuerungsszenarien daher die Zertifikatauthentifizierung. NDES ist nicht in gleicher Weise ein ESC8-Ziel, da es Zertifikate auf Basis eines Challenge-Kennworts statt der Windows-Identität des Aufrufers ausstellt; es läuft aber auf demselben IIS-Stack und verdient dieselbe Prüfung von HTTPS und Exposition.

Erzwingen, Option 1: Webregistrierung entfernen

Die alten certsrv-Seiten existieren hauptsächlich für manuelle Anforderungen aus Browsern. Die automatische Registrierung per Gruppenrichtlinie nutzt RPC/DCOM, nicht certsrv, sodass die meisten domänengebundenen Abläufe von der Entfernung unberührt bleiben. Wenn die Nutzungsdaten es erlauben, deinstallieren Sie sie:

PowerShell
# Auf dem Server mit der Webregistrierung
Uninstall-AdcsWebEnrollment -Force
Uninstall-WindowsFeature ADCS-Web-Enrollment

Läuft IIS auf dem CA-Server aus keinem anderen Grund, entfernen Sie auch die Rolle Webserver — das verkleinert die Angriffsfläche eines Tier-0-Hosts. Prüfen Sie CES und NDES auf dieselbe Weise: Nutzt sie niemand, entfernen Sie sie.

Erzwingen, Option 2: HTTPS, EPA und kein NTLM

Muss ein Endpunkt bestehen bleiben, härten Sie ihn in drei Ebenen. Die Authentifizierungsabschnitte in IIS sind standardmäßig auf Serverebene gesperrt; schreiben Sie die Einstellungen daher mit einem Location-Pfad in applicationHost.config statt in die web.config der Website.

PowerShell
Import-Module WebAdministration
$loc = 'Default Web Site/CertSrv'

# 1. TLS verlangen
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/access' -Name sslFlags -Value 'Ssl'

# 2. Extended Protection for Authentication (Channel Binding) verlangen
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/authentication/windowsAuthentication' `
    -Name 'extendedProtection.tokenChecking' -Value 'Require'

# 3. Nur Kerberos anbieten: NTLM-Anbieter entfernen, Negotiate behalten
Remove-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/authentication/windowsAuthentication/providers' `
    -Name '.' -AtElement @{ value = 'NTLM' }

Entfernen Sie außerdem die unverschlüsselte HTTP-Bindung von der Website (oder zumindest von den virtuellen Registrierungsverzeichnissen), damit nichts auf Port 80 zurückfällt. Das Entfernen des Anbieters NTLM allein verhindert NTLM innerhalb von Negotiate nicht; Negotiate kann weiterhin auf NTLM zurückfallen. Um NTLM vollständig zu entfernen, blockieren Sie es nach einer Audit-Phase auf Betriebssystemebene auf dem Registrierungsserver:

  • Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Restrict NTLM: Audit Incoming NTLM Traffic = Enable auditing for all accounts
  • Nach einer unauffälligen Audit-Phase: Network security: Restrict NTLM: Incoming NTLM traffic = Deny all accounts

Die Überwachungsereignisse landen unter Applications and Services Logs > Microsoft > Windows > NTLM > Operational (Ereignis 8002 für eingehendes NTLM). Das schrittweise Vorgehen beschreibt NTLM auditieren und einschränken.

Für CES verlangt Microsofts ESC8-Hinweis (KB5005413) zusätzlich zur IIS-Einstellung, EPA in der eigenen web.config des Dienstes zu aktivieren, typischerweise unter C:\Windows\SystemData\CES\<CA name>_CES_Kerberos\, indem Sie extendedProtectionPolicy policyEnforcement="Always" am Transportsicherheitselement setzen. Wo ein Load Balancer TLS vor CES oder certsrv terminiert, kann EPA nicht funktionieren, weil sich das Channel-Binding-Token des Clients auf das Zertifikat des Load Balancers bezieht; leiten Sie TLS entweder bis zu IIS durch oder veröffentlichen Sie den Endpunkt nicht über diesen Load Balancer.

Erzwingen: RPC-Anforderungsverschlüsselung (ESC11)

Die von certreq und manchen Clients genutzte Schnittstelle MS-ICPR akzeptiert Anforderungen ohne Packet Privacy, sofern das Schnittstellen-Flag IF_ENFORCEENCRYPTICERTREQUEST der CA nicht gesetzt ist. Prüfen Sie jede CA:

PowerShell
certutil -config "ca01.corp.example\CORP-Issuing-CA" -getreg CA\InterfaceFlags

Fehlt IF_ENFORCEENCRYPTICERTREQUEST in der Ausgabe, setzen Sie es und starten Sie den Dienst neu:

PowerShell
certutil -config "ca01.corp.example\CORP-Issuing-CA" -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST
Restart-Service certsvc   # auf der CA ausführen

Das Flag ist bei aktuellen CA-Installationen standardmäßig aktiviert. Fehlt es, liegt das meist an einer früheren Fehlerbehebung für einen Legacy-Client — finden Sie heraus, um welchen Client es sich handelt, bevor Sie annehmen, dass das Setzen gefahrlos ist.

Die Seite der Authentifizierungserzwingung verkleinern

EPA und das Entfernen von NTLM machen das Relay-Ziel unbrauchbar; verringern Sie zusätzlich das Angebot an erzwungenen Authentifizierungen. Deaktivieren Sie die Druckwarteschlange auf Domänencontrollern, wenden Sie die EFSRPC- und RPC-Filter-Maßnahmen gegen Coercion im Stil von PetitPotam an und blockieren Sie ausgehendes SMB und HTTP von DCs zu allem, was kein anderes Tier-0-System ist. Diese Maßnahmen werden in Authentifizierungserzwingung blockieren und Firewall für Domänencontroller behandelt.

Überprüfen

Lesen Sie die IIS-Konfiguration für jedes gehärtete virtuelle Verzeichnis zurück:

PowerShell
$loc = 'Default Web Site/CertSrv'
Get-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/access' -Name sslFlags
Get-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/authentication/windowsAuthentication' -Name 'extendedProtection.tokenChecking'
Get-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/authentication/windowsAuthentication/providers' -Name '.' |
    Select-Object -ExpandProperty Collection | Select-Object value

Erwartet: Ssl, Require und in der Anbieterliste nur Negotiate (oder Negotiate:Kerberos). Wiederholen Sie die WWW-Authenticate-Abfrage aus dem Schritt „Messen“: Die HTTP-URL sollte nicht mehr antworten, und die HTTPS-URL sollte kein NTLM mehr anbieten. Führen Sie certutil -getreg CA\InterfaceFlags erneut auf jeder CA aus und bestätigen Sie, dass Locksmith oder Ihre eigenen Prüfungen ESC8 und ESC11 nicht mehr melden.

Überwachen Sie auf der CA weiterhin die Ausstellung (Ereignisse 4886 und 4887) und alarmieren Sie, wenn ein Zertifikat für das Computerkonto eines Domänencontrollers aus einer anderen Vorlage als Ihrer Vorlage für die Domänencontroller-Authentifizierung ausgestellt wird oder von einem Antragsteller, der nicht der DC selbst ist. Diese Warnung erfasst ein Relay, das über einen vergessenen Endpunkt durchrutscht.

Was dabei ausfallen kann

  • Entfernen der Webregistrierung: Manuelle browserbasierte Anforderungen, manche Registrierungsskripte unter Linux und macOS sowie Appliances, die die certsrv-Seiten auslesen, funktionieren nicht mehr. Stellen Sie diesen Benutzern certreq auf einem Domänenrechner, eine dedizierte, über einen kontrollierten Dienst angeforderte Vorlage oder ein ordentliches ACME/SCEP-Frontend bereit.
  • EPA verlangen: Clients und Proxys ohne Channel-Binding-Unterstützung scheitern mit HTTP 401. TLS-terminierende Load Balancer und manche Reverse Proxys sind der häufigste Fall, ältere HTTP-Clients von Drittanbietern der andere.
  • NTLM entfernen: Anforderungen von nicht in die Domäne eingebundenen Rechnern, von Clients, die die CA per IP-Adresse oder über einen Namen ohne passenden SPN erreichen, und von gesamtstrukturübergreifenden Clients ohne Kerberos-Pfad schlagen fehl. Registrieren Sie den SPN für jeden verwendeten Alias (HTTP/pki.corp.example auf der Identität des Anwendungspools).
  • IF_ENFORCEENCRYPTICERTREQUEST: Sehr alte Clients (aus der Ära von Windows XP und Server 2003) und manche Drittanbieterwerkzeuge, die MS-ICPR ohne Packet Privacy aufrufen, können sich nicht mehr über RPC registrieren.
  • Deaktivieren der Druckwarteschlange auf DCs: Das Bereinigen veröffentlichter Drucker (Printer Pruning) endet; sonst sollte auf einem DC nichts davon abhängen.

Weiterführend: der Themenbereich AD-Zertifikatdienste, der Glossareintrag NTLM relay und LDAP-Signierung und Channel Binding für den entsprechenden Relay-Schutz auf Domänencontrollern.

Häufige Fragen

Verhindert starke Zertifikatzuordnung ESC8?

Nein. Bei einem ESC8-Relay erhält der Angreifer ein Zertifikat für das Konto, dessen Authentifizierung weitergeleitet wurde, etwa das Computerkonto eines Domänencontrollers. Die CA trägt die echte SID dieses Kontos in das Zertifikat ein, das Zertifikat ist also stark zugeordnet und besteht die Erzwingung gemäß KB5014754. Nur das Entfernen des weiterleitbaren Endpunkts oder die Kopplung der Authentifizierung an den TLS-Kanal per EPA zusammen mit dem Entfernen von NTLM schließt den Pfad.

Genügt HTTPS allein, um certsrv zu schützen?

Nein. HTTPS schützt den Datenverkehr während der Übertragung, verhindert aber kein Relay: Der Angreifer öffnet einfach seine eigene TLS-Sitzung zur CA und leitet den NTLM-Austausch durch sie hindurch. Erst Extended Protection for Authentication koppelt den NTLM- oder Kerberos-Austausch an den konkreten TLS-Kanal, wodurch eine weitergeleitete Authentifizierung scheitert. Sie benötigen HTTPS und EPA gemeinsam — oder gar kein NTLM.

Wovor schützt IF_ENFORCEENCRYPTICERTREQUEST?

Es sorgt dafür, dass die CA Zertifikatanforderungen über die RPC-Schnittstelle MS-ICPR ablehnt, sofern der RPC-Aufruf nicht Packet Privacy (Verschlüsselung) verwendet. Ohne dieses Flag lässt sich NTLM-Authentifizierung an der RPC-Registrierungsschnittstelle weiterleiten — das ist die Klasse ESC11. Das Flag ist auf aktuellen Windows-Server-CAs standardmäßig gesetzt, wird von Administratoren aber manchmal für alte Clients entfernt; prüfen Sie es daher auf jeder CA.

AD-CS-Webregistrierung gegen ESC8 und ESC11 absichern

Verwandte Leitfäden

NTLM & Legacy-Protokolle

LDAP-Signierung und Channel Binding auf DCs erzwingen

LDAP-Signierung und Channel Binding faktenbasiert einführen: Ereignisse 2887, 2889 und 3039 sammeln, Clients anpassen und LdapEnforceChannelBinding sicher setzen.

Fortgeschritten
AD-Zertifikatdienste

Starke Zertifikatzuordnung (KB5014754) in der Praxis

Zertifikatauthentifizierung fit für die volle Erzwingung nach KB5014754 machen: SID-Erweiterung, altSecurityIdentities, KDC-Ereignisse 39/40/41 und wirksame Lösungen.

Experte